Lessons learned in 35 years of making software
dev.jimgrey.net
dev.jimgrey.net
That one hits close to home, although I think around half of what I did at my previous job and half of what I did at the job before that is still running.
Everybody agrees with this. Nobody actually does it. With very few exceptions (in my 30+ years of experience).
And the secret is that it is a 1000x productivity super power. If you learn this skill you will be far more productive.
For example: A developer I know recently implemented a real-time instant fail over hot backup/server system in 2 weeks. Because the architecture he had chosen for the system made it easy. Another developer (when asked) said that doing the same for the system he worked on would require a complete rewrite of the system. Because of different architectural choices.
In other words, it is most definitely true that some developers, by making better choices, can be 1000x more productive than other developers. They don’t type faster or have a higher IQ. They “simply” decide to not make things complex.
However it is not easy to make better architectural choices. You actually need to deeply study software architectures, and implement toy examples, to truly understand what “simple” means and the trade offs involved. Most software architecture articles are garbage.
I often see this advice, but to me sounds like a speed run to burnout. I've seen tech leads leaving the industry because of this too.
The takeaway from this advice is not to overdo it and burn out, but to recognize that not every responsibility needs to be delineated by bright line rules. Cultivating relationships with your team can take precedence over things that are strictly “not your job/responsibility”.
It isn’t an either or proposition.
Having said that, this advice is actually a bit problematic for me. I am over eager to help my teammates as well as those on other teams. I make a lot of connections that way, but the connections are almost always peer or lower on the ladder. They aren’t the connections that help as spoken of in other areas of this article. Also, with the time I’ve spent helping others, it’s less time I’m delivering something of value. I enjoy helping others, so I do it, but I try to keep it in moderation and keep in mind my priorities.
This is especially true when you're working at the extreme ends of the spectrum. Whether it's a startup or shithole corporate environment full of lazy shiftless bastards, picking up slack for incompetent management is not ok.
I'm saying this for the benefit of probably about half the people reading this right now. Enough is enough in this industry.
This one is way more difficult in practice.
Because the difference between something you’re super proud of vs mediocre work, could just be 5%.
But that 5% might be the most challenging work to complete.