Lessons learned in 35 years of making software

https://dev.jimgrey.net/2024/07/03/lessons-learned-in-35-years-of-making-software/

by r4um • 2 years ago

78 9 2 years ago

dev.jimgrey.net

punk-coder• 2 years ago

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.

jamesfinlayson• 2 years ago

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.

tiffanyh• 2 years ago

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.

mobilene• 2 years ago

I'm the OP. Good point.

meowtastic• 2 years ago

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.

move-on-by• 2 years ago

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.

sublinear• 2 years ago

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.

comte7092• 2 years ago

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.

deterministic• 2 years ago

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.

Lessons learned in 35 years of making software

Related Stories