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 it 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!
Top comments (20)
I'm glad to see that after "only" 13 years as a software developer, I already give more or less the same advice to people. I may be on the good track 😄
This is a great article. Golden advice.
Thank you Paul
Thanks for putting things into perspective.
nice one
Many thanks for all the advices, what a great read!
Great article. I love learn C and invest early part.
Thanks man
Fantastic read! I wish I had come across this advice 15 years ago, but it still resonates with me today as a mid to senior developer. Thanks!
Great tips, thanks, and good luck with your retirement.
Thank you for such a wonderful advice.
Great post
TIL what a 401k is. I've always heard people mention them in US sitcoms but never bothered to look them up. To be honest, I didn't realise the US had that kind of pension scheme; I thought they were almost all entirely private.
All good advice, though I think the idea of "invest even more of your money" is also a bit US-centric. A lot of us don't earn enough over the cost of living to invest anything in the first place - I think tech salaries in the US are a little skewed.
I’d call a 401(k) private since it’s funded by a portion of your salary, typically anywhere from 5-20% at your discretion. The only thing “government” about it is that the government taxes your salary differently (contributions are pre-tax so your salary is effectively lower so there’s less to tax) and defers taxing the contributions and accrued ROI until retirement. Better employers also match your contribution percentage, e.g., if you contribute 15% of your salary, your employer will match that with an additional 15% (though there sometimes are contribution caps), so it’s effectively a salary increase. The government does not contribute any money. Participation in 401(k) is optional, but anyone who doesn’t is a financial fool. The money in your 401(k) is entirely yours.
The actual government “retirement plan” is called Social Security and is also funded by a portion of your salary (before any 401(k) contribution is deducted). Participation is mandatory (presumably because most people are bad at saving for retirement). Your money goes into the general Social Security fund along with everyone else’s. Upon retirement, you get a monthly check based on how much you contributed over your working lifetime. The amount you get is, IMHO, barely enough to survive in retirement, so if you want to be able to have a nice life, you need to participate in a 401(k).
The “invest even more of your money” advice is for when you might find yourself in any given month to have a surplus. Rather than just let the money sit in your bank account (typically with a poor interest rate), invest that surplus into something with a better ROI. In addition to a “Roth IRA” (see below), even short-term investments like various funds and bonds give you a better ROI than simple interest and they’re typically not long-term commitments, so if you need the money at some point, you can access it without penalty.
The government also has things called IRAs. Like 401(k)s, they are entirely funded by you pre-tax. Typically they way they’re used is if you leave a company, you “roll” your 401(k) money from that company into an IRA to preserve its tax-deferred status. (At your new company, you start a new 401(k).) Depending on your situation, you may also be able to contribute more pre-tax dollars to an IRA.
There’s also the Roth IRA variant where you can contribute post-tax money. If you have any surplus money that you are confidant you will not need to withdraw before retirement, this is a good way to invest it. The deal with the Roth IRA is that, since you already paid tax on the money contributed, withdrawals upon retirement are tax-free including ROI.
As far as US salaries, they probably are inflated, but it really depends on where you live in the US. A programmer in Silicon Valley gets a higher salary because employers are forced to pay it because (1) the cost of living here is much higher than most anywhere else in the US; (2) because there are so many tech companies here, good programmers have ample choice where to work, so competition is high. It may be my ignorance, by, AFAIK, there is no Silicon Valley equivalent anywhere else in the world.
Great advice, thank you. With specialization, it is a bit more tricky, I think. While I reached the same conclusion eventually, that one will get better entry-point pay if being more specialized, eventually one starts hearing expectations like being T-shaped, expanding expertise, and so on. If a programmer wants to grow her/his career, dabbling into other technologies is unavoidable, paradoxically becoming a more general developer. So specialization: yes, to start with, but then don’t forget to learn also other things.
Also, getting more and more senior (read older), I started to realize that developing a solution (designing something, programming, testing) is not the hardest part anymore. The hardest is dealing with people. Discussions about value, prioritization, different opinions, fools at higher places, making decisions within the team, relationship with peers, relationship with manager, relationship with stakeholders… All people problems that have affected my work very much. I wouldn’t underestimate investing some effort in soft skills like effective communication and building relationships.
If you're a back-end developer, then expanding your career usually means learning a new back-end language. But then you again specialize in whatever the new language is.
Yes, similarly to most anything, the technology is the easy part; it's the people that cause all the bother.
For backend engineers, there can be overlap with data science/analysis, various databases, cloud infrastructure, monitoring infrastructure, AI/ML models training and integration, performance testing, and even frontend, as you mentioned in the article…
I have similar views on “full-stack” developers; however, a BE developer who can’t make a simple form to use with his/her API doesn’t inspire much confidence either, in general. Depends on the role, of course. So nothing against “full-stack” devs, who also have a narrower specialization.
I don’t really think expansion is about new programming languages, but rather about new paradigms and classes of problems the person can tackle.
And I still appreciate what you wrote. A lot of it rings true.
I am quite new in software and development industry and I will agree with you on all of these points especially the "Loyal to Coworkers, not to Company". That is a great advice and I am not emotionally intelligent and sometimes I can spend a good amount of time in the concept of loyalty with company and so on.
Your recommendation to ‘Specialize’ reminded me of discussions with colleagues in the ‘80’s about the growing ‘computer’ field. We’d grin wryly and say “We used to be gurus!?”: previously, we felt we knew/understood computers at all levels, from the hardware gate level up to output devices (big-iron printers and teletypes), and languages from binary and assembler on up (to FORTRAN and Basic).
My point: everyone specializes today, for the simple reason that even subparts of the IT field (like ‘programming’) are beyond one person. Better to make your own specialization choice than to let the vagaries of a workplace, or the current ‘hot’ language, or some other ‘not-you’ decide … you have to live with the choice, conscious or not.
Thank you
Great advice.
Some comments may only be visible to logged-in visitors. Sign in to view all comments. Some comments have been hidden by the post's author - find out more