Setting up a build system can be a bitch. Not every developer needs to be able to build every obscure module of all your companies tooling. A .net developer shouldn't have to rebuild c++ boost just because he relies on a small native dll.
In some cases the tooling of one developer can even conflict with the one of another, one requires python 2.7 to be in your PATH while the other requires 3.3, etc.
I fully agree that it should be easy to set up but the reality is different, especially when you deal with legacy, rely on third party libraries or build open source projects from source.
I've been using it for a while too now and my verdict is that i can't remove google from the second row in my search bar but i find the results of ddg to be good enough to use as my first choice.
80% searches work flawlessly on ddg, and for the remaining part you learn which kind of searches that will work and which ones doesn't. Many times i know in advance that this particular query will probably not work here but on google it will and i'll just append !g to the search to go straight to google.
What i find mostly interesting is that I have re-learned to use multiple different search engines, you know like we all did back before in the days, and that it actually helps me find more relevant information. Not only because the quality of Google has dropped significantly the past 5 years but even when google delivers a pretty solid result i check DDG after and i might find an even more relevant result, or an opposing story in a political topic etc. We all learn to check your information sources, this includes your search engine!
In C# there's a similar tool called Code Digger. It analyzes all possible branches of a function and generates input to cover all of them, this includes not only your own "if's" but also branches inside library functions and stuff like divide by zero and dereferencing null pointers. It's really impressive and can even generate strings and arrays with data that causes a different branch to be taken.
Sadly i found it to be no more than that, cool. On real life code it's not useful. Real code usually has a lot of mutable state, this tool works best with pure functions. Real code does pretty complex things like parsing xml, that takes too much time to analyze for these tools. Bugs in real code are not always exceptions or error codes returned, maybe you assigned foo.x to bar.y instead of bar.x, maybe the sort doesn't crash but your numbers came out unsorted, how would the tool know that's a fault? Real bugs happen across threads or even modules running on different machines. And the list goes on. Only if you have functions that are very pure and mostly work with simple data types, few strings and lists, it can be good to use as startng point for input to a test suite but doesn't replace it fully.
Oh this is the worst part, i could once not start my viasat-app on smart-tv because samsungs, not viasats, servers were down. The workaround was to reconfigure the dns to point samsung to a local server that just said "im alive" and then i could start my apps and use them without any problems. T_T
You are not only paid to write your piece of code and be happy about it. You are also paid to be on stand by and do whatever you can to move the company forward which includes helping out other people at work.
We have one employee who thinks he is a rock star (he is not), he finishes his assigned tasks in 4 days instead of 5 and then takes Friday off because he thinks he "deserved" it for being so damn creative and intellectual and he thinks about work at home anyway... Guess what happens on Fridays, people are still at work and need to contact this guy, questions about old code, plans for future, a new task came in, and surprise surprise, the code he merged in on Thursday night wasn't as good as he thought, it has tons of bugs and actually breaks the build which stalls everyone else, who should take care of that?
Its a tough balance, i am also very against pushing through when unispired and the sit on your chair and wait for the clock kind of job and I also need distraction free creative time. But this guy has thought me that many times the team needs you more than you need your oh so precious creativity and that is what you are being paid for, helping the team, the company, to move forward.
A team leader that uses people like this - cogs that munch through assigned tasks - is not operating at high efficiency. It's top-down directed, and is missing effective feedback from people who know most about the code, its architecture, what it can and can't do. People are treated as manual laborers rather than self-directed professionals. You're only using 40% - if that - of their capabilities.
There are times when a team needs to operate like that - e.g. impending business-related deadlines - but they should be exceptional. The top-down model creates work politics, where the team members need to lobby and scheme to influence the team leader to make particular choices, and it leads to atrophy of initiative, and destroys most of the creativity that ought to be latent in a team.
I'm extrapolating a lot from a single statement of yours, so it may not actually apply to your organization, but it definitely does apply to a lot of dysfunctional workplaces.
the code he merged in on Thursday night wasn't as good as he thought, it has tons of bugs and actually breaks the build which stalls everyone else, who should take care of that
The person merging code should be the person reviewing the code, not the author of the code. If code breaks the build, the person reviewing it is at fault for merging it. And code isn't finished until it's reviewed and merged. Reviewing, at a minimum, means making sure it builds, the tests pass, and the tests have enough coverage, using code coverage tools if necessary.
If the code is no good and accidentally got merged, the merge commit should be reverted. If the code is absolutely necessary (e.g. for Monday), that's a crunch, the guy shouldn't have left on Friday, and he's let the team down. You can't do that too often without needing to leave. But not for productivity reasons, for team reasons.
I'm curious what guarantees c++ gives on reading variables like the 'data' in his first example when it can be modified from elsewhere.
Yes, the lock will prevent concurrent access but will it prevent the compiler from optimizing away the read completely since main() was the last function that wrote to the variable. I've seen nasty optimization bugs like that happen in C with single threading and strict pointer aliasing and they are not easy to track down.
One could interpret his example program like this (unrolled and tweaked a bit).
int data = 0; //ok data is now guaranteed to be equals to 0
thread t(produce, &data); //called thread with a pointer to data so if i want to read data again i must invalidate my registers
data = 5; // i know i set data to 5 here
this_thread::sleep_for(chrono::milliseconds(500)); // call contains no references to data, sleep is a "pure" call
lock_guard<mutex> lock(theLock); // call contains no references to data
if (data == 5) // i set data to 5 myself, and i haven't done anything that could touch data since then so we optimize away this branch
cout << "data is 5";
Will the call to lock_guard simply disable all such kind of optimizations? Or are you required to write memory barriers yourself in some way? I guess a simple way to look at it would be that the compiler assumes that thread will keep the pointer to data and that lock_guard has access to that pointer behind the scenes somehow, so that acquiring the mutex "invalidates" your last write, but that would mean acquiring any mutex would invalidate all variables as the mutex doesn't specify which data-sets it is locking. Am i thinking correctly? Where can i find more information regarding this.
Revealing the salary is one thing but i think revealing the monthly expenses is even more important for kids to realize how much money actually just "disappears", into recurring bills like rent, for one to live a comfortable life.
There's a reality TV show in Sweden, called the teenage boss(tonårsbossen), where in each episode the teenager of a family get's to control the whole budget for his family for one month. Surely there's selection bias on what type of family they put on the show but it's quite revealing to see how kids think when they get that much money because they don't understand how much or how little it is. Even when the hosts help them lay out a budget they always always end up overspending. First they go buy tons of clothes the first week, they give their parents less pocket money than what they themselves normally got before, the food bill is always double because they don't know what's normal price for grocery items, there's always some recurring monthly expense that's easy to forget like gas for the car, they don't take into account unexpected events like the fridge breaking down, nothing goes into savings etc etc.
I think every kid would benefit greatly from doing this kind of exercise at least once, at least letting them join the budgeting and let them see where the money goes.