Lessons learned in 35 years of making software

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.

&gt; The software we are building right now will one day be decommissioned and not be used anymore, probably before your career is over.<p>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.

&gt; Do things in the most straightforward way possible<p>Everybody agrees with this. Nobody actually does it. With very few exceptions (in my 30+ years of experience).<p>And the secret is that it is a 1000x productivity super power. If you learn this skill you will be <i>far</i> more productive.<p>For example: A developer I know recently implemented a real-time instant fail over hot backup&#x2F;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.<p>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.<p>However it is <i>not</i> 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.

&gt; being relentlessly helpful to others, even in things that aren’t strictly your responsibility, keeps you as someone everybody wants on the team<p>I often see this advice, but to me sounds like a speed run to burnout. I&#x27;ve seen tech leads leaving the industry because of this too.

&gt; When you deliver work you’re really proud of, you’ve almost certainly done too much and taken too long.<p>This one is way more difficult in practice.<p>Because the difference between something you’re super proud of vs mediocre work, could just be 5%.<p>But that 5% might be the most challenging work to complete.