In the real world, in quite a few companies, in order to accomplish X, you must sit through many meetings with others that have nothing to do with accomplishing X.
There are also many other logistical hurdles that you must overcome to accomplish X. The problem is that often, I do not need to attend the meetings, nor do I need to overcome the logistical/political) hurdles to accomplish X, and more often than not these are impediments to accomplishing X.
It really varies from company to company, my point is, I want to get paid for the time, because I can never be certain how much I will have to waste in meetings and other un-related tasks before I can complete a given accomplishment, due to dependencies on others.
Add to all of that the litmus test of a completed "accomplishment" can be very subjective, e.g. something one person thinks is done, is not seen that way by someone else, and you don't get paid until everyone agrees it is done?
There's also the old scope creep monster, that rears it's ugly head. What you had to accomplish at the beginning of the project changed half way through and now you have do twice the work to complete the "accomplishment".
My time is the most valuable thing I have and the older I get the move valuable it becomes. I'm not going to roll the dice that whoever is writing the checks will have the same perception that something was accomplished as I do. I don't want to have to spend more time to "accomplish" something, just because someone "moved the goal-post".
On the other hand if you are a consultant and it's a vendor/customer relationship, then it's up to you as the vendor to define the "accomplishment" and build in a way that both vendor and customer can agree on when an "accomplishment" is finished. Scope creep is handled by additional statements of work, etc.
When there are contracts and potentially lawyers involved, paying for accomplishments is a little more tenable, in an employer employee relationship, where as the employee if you don't like it you can find another job, not so much.
Imagine if every time you got paid you had to have a meeting with your manager to determine exactly what you had accomplished, with the manager making the final decision on whether it was done or not? Suppose they decide that program you wrote needs more testing to be "accomplished", or an extra feature that was not originally scoped needs to be added and until such time, they aren't going to pay you? That sounds like the stuff of nightmares to me.
I've used what I learned in this course more than any learning I've done. IMHO This should be a required course before a student graduates high school (or sooner).
This article has some good links to studies and articles, some math and science.
It also points out you don't even have to science very much, there is lots of anecdotal evidence that shows that in gatherings where masks are worn, transmission is slowed.
Lot's of other factors play into that, but you only have to math a wee tiny bit to realize that properly worn masks can help fewer people be infected, and therefore fewer people will die.
MATH.
This has some nice visualizations based on anecdotal evidence and statistical analysis and compares transmission rates in different settings given the variables of masks wearing vs. no masks and ventilation vs no ventilation, while also taking into account surface based transmission.
We should all just be on GMT. In software development on Pacific time, I always feel bad for the guys offshore that have to stay up late at night to make our morning meetings. It sure would make things a lot more easy from a coding perspective.
But to the point DST only adds complexity to the already complex task of converting time to GMT and back so that you can synchronize events in different time-zones, I fully support this effort.
This makes no sense. Your morning meeting will be at 17:00 UTC (for example), but it will still be “morning” in the SV office, and “afternoon”/“multiple hours past sunset”/“go away I’m asleep” for your offshore team (wherever they may be located). Changing the digits our clocks represent will only simplify those clocks, but it won’t, it can’t, it shouldn’t change business hours to 9-17 UTC everywhere. Because why would half of the world sleep when it’s light outside? Just because Europeans set UTC as a time zone and 23 as the time to go to sleep?
Guess what. You're still going to have morning meetings relative to your local solar cycle and the offshore guys are still going to joining the call at a time that they're probably thinking about bed based on their local solar time.
So this appears to be, the very old, software that was pushed to production before it was ready story. I have to wonder if there wasn't some Marketing/PR/Mgmt person(s) that pushed the engineers to release the software before it was ready or was it the result of lack of due diligence on the part of the engineers, who couldn't wait to get their code running in the real world.
>We did implement checks for what seemed to us as more common failure scenarios, but the devil here was that this one first appeared during the run and we did not cover it at the analytical analysis stage.
I little more time in testing for the edge cases could have helped avoid this expensive fail.
You have to test for much more than just the "common failure scenarios", when you engineer solutions where failure could be very expensive in terms of money and lives.
Someone just needs to create a swiss army knife headless browser streaming file saver/converter and leave out any text about how to download youtube videos with it.
Then the community can be like Popcorn time and say, ahem, no copyright infringing code here.
Or a version could even be released w/out the test cases and or README files that make any reference to any type of "illegal" activities.
Contribute to the Lynx browser to download embedded video's to mp4. Add flags to the command line to download them.
Then it serves as an integral part of a web-browser and you don't break the Youtube TOS.
Edit: Add to firefox a right-click option "Save Video As".
From my perspective it kind of seems like YouTube-dl is like a knife, it can cut your food, but it can also be used to kill someone. In the case of YouTube-dl the knife was included with instructions on how to kill someone, so it was deemed a potential "murder weapon".
What if someone sold a car and included instructions on how to run over pedestrians? Should the car no longer be sold, or should the instructions be removed?
My point here is that banning all of something based on the fact that the something could be used to commit illegal acts, when that same something also has legitimate legal uses, is a slippery slope. These days the RIAA pretty much lives on that slippery slope.
I agree completely. Steve Ballmer put all of Microsoft eggs in the Office Basket that let mobile die on the vine. He pushed licensing and marketing and left developers and new tech to languish. It's why to this day, Microsoft doesn't have a place in the mobile space, it's iOS or Android. I also aggree that pushing MS in a more Open source direction has helped make them more palatable to developers.
From a business standpoint, I would have to agree he did turn them around from a business standpoint.
As a user of Windows since 3.1 (w/out networking). I do the same as MekaiGS "I honestly have no idea where all the Windows settings are anymore so I just search instead."
It was like multiple teams designed different parts of the settings but they never had any meetings or talked with each other.
There are days when I would rather use Microsoft Bob
than Windows 10
Or better yet, Microsoft Joe Bob
http://www.bytebrothers.org/joebob.htm
"Go Microsoft -- Go Intel -- Go America," and "QuickTime is for Pinko Hippie Wimps."
There are also many other logistical hurdles that you must overcome to accomplish X. The problem is that often, I do not need to attend the meetings, nor do I need to overcome the logistical/political) hurdles to accomplish X, and more often than not these are impediments to accomplishing X.
It really varies from company to company, my point is, I want to get paid for the time, because I can never be certain how much I will have to waste in meetings and other un-related tasks before I can complete a given accomplishment, due to dependencies on others.
Add to all of that the litmus test of a completed "accomplishment" can be very subjective, e.g. something one person thinks is done, is not seen that way by someone else, and you don't get paid until everyone agrees it is done?
There's also the old scope creep monster, that rears it's ugly head. What you had to accomplish at the beginning of the project changed half way through and now you have do twice the work to complete the "accomplishment".
My time is the most valuable thing I have and the older I get the move valuable it becomes. I'm not going to roll the dice that whoever is writing the checks will have the same perception that something was accomplished as I do. I don't want to have to spend more time to "accomplish" something, just because someone "moved the goal-post".
On the other hand if you are a consultant and it's a vendor/customer relationship, then it's up to you as the vendor to define the "accomplishment" and build in a way that both vendor and customer can agree on when an "accomplishment" is finished. Scope creep is handled by additional statements of work, etc.
When there are contracts and potentially lawyers involved, paying for accomplishments is a little more tenable, in an employer employee relationship, where as the employee if you don't like it you can find another job, not so much.
Imagine if every time you got paid you had to have a meeting with your manager to determine exactly what you had accomplished, with the manager making the final decision on whether it was done or not? Suppose they decide that program you wrote needs more testing to be "accomplished", or an extra feature that was not originally scoped needs to be added and until such time, they aren't going to pay you? That sounds like the stuff of nightmares to me.