351–360 of 505 posts
Earlier quoted context omitted.
Make a backup plan now Truer words rarely spoken. Tech is Logan's Run, No Country For Old Men.
I can't agree. I turn 50 this year and it's easier than ever to get a new gig. If anything I've noticed a bias in my favor where I would be viewed as a stabilizing force on the team.
"To replace out MediaWiki with a Java-based alternative (XWiki) ended up taking a total fo 24 dev-years over 4+ calendar years for the team, not counting the interruptions to pretty much every other team at Amazon as their pages were getting constantly migrated and un-migrated" I would love to hear more about this. I'm guessing that's a cost of at least $4M? How was this approved? How did they allow it to continue fo…
I mean, it gave a lot of people something to do (and get paid to do) for 4 years. There's your answer, most of the time.
I used to get called a 10x developer, I was also called a rockstar and a ninja and a 100x dev and every other compliment that was hip. Then I hit 30. That type of talk stopped. Then I hit 40. Now I will not be considered for any entry level, mid level, or senior level software dev job anywhere in the United States, despite being very desperate and willing to relocate for anything. Doesn't matter. Too old. I'm suppose…
I'm 55 and am constantly turning down jobs. That said, agism is rampant in this industry. After working with some turtles and fossils I can't say I disagree with it. People become calcified.
There is so much that is wrong with this. Follow this advise only if you are currently employed and your employment is extremely safe because your employer is deemed essential or because they are financial strong in the current economy. For everybody else very carefully consider why an employer should hire you when the current economy is failing, programmers generally are very expensive and add very little value to t…
> programmers generally are very expensive and add very little value to the employer's revenue Then either they are very bad at their job or working at a very bad company. Software companies have some of the highest revenue per employee numbers, compared to other industries. > The article opens with having kids and so they cannot work more than 8 hours a day in a specified time slot. This is an absence of ambition an…
> front end [..] consider something like Phoenix install = install Erlang + install Elixir + install Phoenix Well.. I'll stick to Node + vanilla JS
Installing something is easy, learning how to write Elixir/Phoenix/maybe Erlang is the hard part. Don't ever let "installation" prevent you from trying something, on Mac it's literally "brew install elixir" followed by a command to install phoenix framework.
Sometimes though installation is a real pain. (For ex. OCaml/OPAM on Debian)
Earlier quoted context omitted.
The best developers only have 10 years experience. 10 years is enough to understand software, process, and the rest at a deep level. You may have expertise in a particular area. You know pretty much all the things that are available to know. After 10 years, the previous experience becomes irrelevant and "drops off". The languages you learned? Gone. The APIs and weird hardware limitations? Irrelevant. Nothing beyond 1…
> After 10 years, the previous experience becomes irrelevant and "drops off". The languages you learned? Gone. The APIs and weird hardware limitations? Irrelevant. Nothing beyond 10 years matters. The experience you're really paying for with an older developer goes way beyond that. It's having a "deep" memory of a number of projects that have failed. It's having a true understanding of the value of quality and reliab…
1. Experience without knowing the latest stack is useless for a pure developer role.
2. Leaning into the deep memory of past failures is more consistent with a technical lead, which is one of the "other" growth paths.
Earlier quoted context omitted.
The best developers only have 10 years experience. 10 years is enough to understand software, process, and the rest at a deep level. You may have expertise in a particular area. You know pretty much all the things that are available to know. After 10 years, the previous experience becomes irrelevant and "drops off". The languages you learned? Gone. The APIs and weird hardware limitations? Irrelevant. Nothing beyond 1…
Java - first released 24 years ago. C - first released 48 years ago. Python - first released 30 years ago. C++ - first released 35 years ago. C# - first released 20 years ago. VB - first released 29 years ago. Javascript - first released 24 years ago. PHP - first released 25 years ago. SQL - first released 46 years ago. R - first released 26 years ago. Those are currently the top 10 most popular languages according t…
Earlier quoted context omitted.
Of course there is, but that's not the point. Every large organisation has organisational issues and nobody in the history of humanity has found a way of preventing them yet. The only thing you can do when the group sizes get large is to try and keep the problem under control relative to how bad it is at other large companies.
I'm lost; what specifically is not the point? As far as I could tell, the "reason" given by the OP for this waste was attributed to Amazon's scale. Could you explain how company size and broken corporate structure are correlated? Or explain why 20+ person-years of engineering time wasted isn't a symptom of broken corporate structure?
"To replace out MediaWiki with a Java-based alternative (XWiki) ended up taking a total fo 24 dev-years over 4+ calendar years for the team, not counting the interruptions to pretty much every other team at Amazon as their pages were getting constantly migrated and un-migrated" I would love to hear more about this. I'm guessing that's a cost of at least $4M? How was this approved? How did they allow it to continue fo…
There's a roughly ~12,000-word postmortem document that took an additional 2+ months to produce after the fact, which the OP has lightly quoted or summarized from in his post (including what you quoted). It really is an impressively magnificent failure at scale, but there's nothing really fundamentally earth-shattering about how this project went so far off the rails. Mistakes were made, but IMO nobody was outrageous…
Earlier quoted context omitted.
> After 10 years, the previous experience becomes irrelevant and "drops off". The languages you learned? Gone. The APIs and weird hardware limitations? Irrelevant. Nothing beyond 10 years matters. The experience you're really paying for with an older developer goes way beyond that. It's having a "deep" memory of a number of projects that have failed. It's having a true understanding of the value of quality and reliab…
I agree, there is a lot of context that comes with experience. However two things remain true: 1. Experience without knowing the latest stack is useless for a pure developer role. 2. Leaning into the deep memory of past failures is more consistent with a technical lead, which is one of the "other" growth paths.