Lessons learned in 35 years of making software(dev.jimgrey.net)
dev.jimgrey.net
Lessons learned in 35 years of making software
https://dev.jimgrey.net/2024/07/03/lessons-learned-in-35-years-of-making-software/
9 comments
I’ve seen a lot of these lists lately, but this is the first one I can say I really agree with a lot of the points. I’ve been a professional developer close to 30 years, and have picked up a lot of these same lessons. I like lesson number 1, as I think sometime developers feel they need to come up with some clever way to stand out or show off and you learn over time that every line of code you write is a line of code that needs to be supported. Straight forward code may not show off your skills, but other team members and future developers will like it.
> The software we are building right now will one day be decommissioned and not be used anymore, probably before your career is over.
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.
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.
> Do things in the most straightforward way possible
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.
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.
> being relentlessly helpful to others, even in things that aren’t strictly your responsibility, keeps you as someone everybody wants on the team
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.
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.
Proper boundary setting and negotiation is an important soft skill.
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.
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.
Everyone is different- I absolutely love helping people. I could spend all day helping teammates and feel super energized by the end of the day.
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.
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.
> speed run to burnout
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 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.
> When you deliver work you’re really proud of, you’ve almost certainly done too much and taken too long.
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.
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.
I'm the OP. Good point.