Introduction

Now that I’ve retired after 45 years of developing software and given a career retrospective, here’s some things I’ve learned along the way that I suppose one might call advice.

Be Loyal to People, not Companies

As the years 2022–2024 should have made you painfully aware of via layoffs, companies aren’t loyal to you, so you shouldn’t be loyal to them. Of course you should do your job and do it well, but your company is not your family and do not believe them if they try to tell you that.

If there’s anybody you should be loyal to, it’s your coworkers as individuals or your team as a whole — but that’s as far as your loyalty should go.

Don’t Work Long Hours

I guess I’ve been fairly lucky in my career in that I’ve never had a job where I had to work long hours. Unless you’re under a deadline, don’t voluntarily work long hours. Have a life outside of work. Demonstrate your technical prowess by the quality of your work, not the number of hours worked.

Overestimate

Whenever you’re forced to estimate how long something will take, first determine how long it will likely take you, then add some padding. If you encounter unforeseen problems, you’ll need the extra time; if not, you’ll get it done early and it’ll make you look good — or you can just relax for a bit.

Master Your Craft

Whichever aspect of software development you’re in, become a master of it. Learn everything there is to learn about it. In addition to learning the syntax and semantics of a programming language, learn techniques by reading other people’s code, reading technical blogs, or watching technical videos; learn how compilers actually implement language features down at the machine code level. This will help make you a “10x developer” — and be sought after.

Even in a relatively small language like C, I’m still learning new techniques even though I’ve been using C for over 35 years.

That said, don’t be too “clever” in code you write. Unless you can prove via profiling that some piece of really terse clever code is actually more performant, be clear and explicit.

Code is actually written mostly for other humans to read (including yourself in several months’ time), not compilers. Compilers are really good these days anyway and often they’ll optimize your clear and explicit code down to the exact same code as the terse, clever version anyway.

Another thing that helps you really learn the details and techniques of a language is trying to teach an aspect of it to someone else in writing. (This technique is related to rubber duck debugging and works for the same reasons.) At least for me, writing articles for my blog forces me to question what I know and look up the details of things because I want to be thorough and right. Often, I learn something in the process.

Specialize

In the old days when the UI was the command line (1970s–mid-1980s), there were just “programmers.” Then GUIs happened (mid-1980s) and — somehow — “programmers” became “developers” (early 2000s). Somewhat concurrently, the web, JavaScript, and web toolkits started to become popular and developers split into “front-end developers” and “back-end developers.” Several years later (circa 2008), “full-stack developer” started to be used and its use grew (like cancer).

Originally, “full-stack developer” wasn’t that bad since there were only a very small number of web technologies. These days, there are dozens of web technologies to choose from. You can devote years to mastering just one of them. Of course technologies for the back end have expanded too, just nowhere near as much.

Hence, to me, being a “full-stack developer” is akin to being a jack of all trades, master of none — with emphasis on none. “Full-stack developer” is the general practitioner of software. Of course many companies love full-stack developers since it means they can hire one person instead of two — but you often get what you pay for. IMHO, you should specialize in either back end or front end. Be a cardiologist or dermatologist, not a general practitioner.

Money

One of the primary reasons to specialize is that specialists (in any field) make more money than generalists. Of course money isn’t a goal in and of itself, but money gives you peace of mind.

If you are in the US, definitely participate in your company’s 401(k) and contribute as much as you can afford. Also, find yourself a good financial advisor and invest even more of your money. With rare exception, the days of retiring with a pension are long gone. The goal is to amass “f--k you money” as fast as you can.

If you’re in your 20s or 30s, retirement may seem a long way off; but, seriously, start investing as soon as you can. Before you know it, you’ll be in your 50s or 60s. Although I personally haven’t experienced age discrimination (that I’m aware of), it’s supposedly rampant in the tech industry.

Learn C

Admittedly, I’m likely biased since I’ve only ever been a back-end developer, but, even if you’re a front-end developer, you should learn C. Even though C++ has pretty much supplanted C, learning C is akin to learning Latin — in a good way. Just as Latin is the root of many human languages, C is the root of many programming languages.

But I don’t just mean C syntax, I mean the ways you have to use C to get things done. Since C is so minimal, programming in C forces you to have to know how things are done at the machine level. It’s knowledge that will serve you well even if you program in higher level languages — especially since many higher level languages are implemented in C.

Even a language like Java is too high-level. True story: when I was at BEA on a team programming in Java, there was a bit of code running really slowly. After some investigation, I discovered that someone had included code that concatenated lots of strings together to be included in debug log messages. The thing was that just because debug logging might be switched off does not mean that the code that concatenated the strings together did not execute.

While you can make the same mistake in any language, the + operator in Java to concatenate strings just makes it too easy to forget what the JVM is doing under the hood. In C that doesn’t even have a proper string type and thus requires you to go through much more effort just to concatenate strings, you’re much less likely to make such a mistake.

Suffering Fools

I’ve never been one to suffer fools gladly. Early on, it tended to get me into trouble occasionally. (I’ve slowly mellowed over the years.) Try to be polite and respectful — grin and bear it if you have to. Later, vent to a trusted colleague or friend.

If someone is advocating for an idea that’s ill-thought out, unnecessary, or patently stupid, rather that being blunt and saying their idea is ill-thought out, unnecessary, or patently stupid, simply ask, “What problem does that solve?”

That question is one of the best things I learned from one of my mentors back at Bell Labs, Steve E. I no longer recall specific examples, but I know I must have occasionally been enthusiastically rambling to Steve about something — and he’d interject and ask, “What problem does that solve?” It stopped me dead in my tracks and really forced me to think. At the time, I hated when he did that, but I’ve come to appreciate its power.

When you ask the question, do not ask it sounding exasperated; instead, ask it calmly while sounding pensive and looking confused. This forces the other person to defend their idea (which they won’t be able to and hopefully come to realize themselves that their idea is dumb) while simultaneously keeping you off the hook by making you look like the dumb one for not understanding the implications of their supposedly “brilliant” idea.

Conclusion

That’s all I can think of at the moment. I may add to this article as I think of other things. I hope this helps!