4 ms·

This is almost exclusively what I've encountered in most of the "elite" engineers. It's frustrating because they're the ones saying coding and job hopping is ea

by bgro 4y ago

This is almost exclusively what I've encountered in most of the "elite" engineers. It's frustrating because they're the ones saying coding and job hopping is easy. They're the ones in tech interviews who downplay your achievements. In my experience, rather than leaving for another company though, they're often a C-suite favorite and get to start some new project (often it's whatever they want to do as long as it's remotely justifiable). They get it up to 80% complete so they can hand it off to another team to do the last 20%. Since the project is whatever they want to do, they use very unusual languages or design choices that the new team has to pick up and fix. A lot of times it's whatever the big new thing is. (For example, expect statements like this: "Everything is obsolete legacy code now that Electron exists!" "No need to keep this standalone offline test database, setup shell scripts, or maintain the environment setup guide because Docker will automatically solve all of these cases!") They continue getting new projects because these 1 or 2 people "did the project 80% complete in 1 month, and the last 20% is taking the handoff team of five at least 3 months to do." Bonus points when it is expanded from some sort of hackathon, or some fake story about how some person completed the 80% portion over the weekend. In the former, all the connections and APIs are hard-coded and faked for their demo. In the latter, they had actually been working on this for the past couple months instead of doing their assigned work which made their official team look even less productive. I was on the teams always picking up the last 20%, but I got moved onto the 80% team once. I was amazed at how much code I could blow through with time to spare when I didn't have to worry about all the edge cases and minute details. Unfortunately, I got temporarily moved onto a company-wide prod support team which then got cut due to covid. Hooray.

lioeters 4y ago
The story reminds me of the so-called 80/20 rule. > Microsoft noted that by fixing the top 20% of the most-reported bugs, 80% of the related errors and crashes in a given system would be eliminated. Lowell Arthur expressed that "20% of the code has 80% of the errors. Find them, fix them!" More relevant part: > It was also discovered that, in general, 80% of a piece of software can be written in 20% of the total allocated time. Conversely, the hardest 20% of the code takes 80% of the time. https://en.wikipedia.org/wiki/Pareto_principle#In_computing https://en.wikipedia.org/wiki/Pareto_principle#In_computing It sounds like you were often stuck with the toughest 20% which actually took 80% of the effort. I also heard that of that 20%, there's another level of 80/20, where a further 20% takes 80% of the rest of the effort, and so on. Anyway, I hope you find a better situation!

by bgro 4y ago

lioeters 4y ago

The story reminds me of the so-called 80/20 rule. > Microsoft noted that by fixing the top 20% of the most-reported bugs, 80% of the related errors and crashes in a given system would be eliminated. Lowell Arthur expressed that "20% of the code has 80% of the errors. Find them, fix them!" More relevant part: > It was also discovered that, in general, 80% of a piece of software can be written in 20% of the total allocated time. Conversely, the hardest 20% of the code takes 80% of the time. https://en.wikipedia.org/wiki/Pareto_principle#In_computing https://en.wikipedia.org/wiki/Pareto_principle#In_computing It sounds like you were often stuck with the toughest 20% which actually took 80% of the effort. I also heard that of that 20%, there's another level of 80/20, where a further 20% takes 80% of the rest of the effort, and so on. Anyway, I hope you find a better situation!