Last updated March 14, 2024

I retired after 42 years in the software business. Here's 42 lessons I learned from a career in software development.

Section A: Education

Constantly improve your skill level.
Sharks have to keep swimming to stay alive and move oxygen past their gills. Programmers have to be continually learning to keep their careers alive.
1. Read basic software theory books.
  Browse Amazon, or your local bookstore's software section. Try to understand the deeper aspects of software development. Read classic books like Mythical Man-Month, The: Essays on Software Engineering, Anniversary Edition ,Extreme Programming Explained: Embrace Change, 2nd Edition (The XP Series) and Clean Code: A Handbook of Agile Software Craftsmanship My list is here.
2. Study your language.
  Spend time to really understand the deeper aspects of your current language.
3. Study your tools.
  Spend time to really understand your tools like Visual Studio, ReSharper, Git. Learn the shortcuts. Be a touch typist. Try a year with a Das keyboard with no lettering on the keys.
4. Keep current.
  Read software blogs, follow significant developers on Twitter, and listen to software podcasts.
5. Code with others.
  Try to spend time pair-programming and learn from other's their tips and shortcuts. Beg your friends to show you better ways to write code.
Be an active member in a local user/professional organization.
Join the local Java User's Group, Agile, or .Net groups. You'll meet new and interesting, sometimes scary, people. You learn so much in personal conversations. It never hurts to know a community of people while looking for a new job.
Your biggest enemy professionally is your pride.
Don't be afraid to say "Hmmm. Divya, I've never heard about that before; what is it?". We can all learn from each other in this voyage called life. Don't fear constructive criticism. "Faithful are the wounds of a friend."
Don't be afraid to change your tool set.
Tools constantly change. When you see a better tool, ditch your old one, and start using the new one. (Emacs is the only exception - there is no better editor.)

Section B: Employment

You can stay at a company too long.
Although it is not good to jump jobs too quickly, sometimes you can stay at a job too long. If you are not learning new technologies at a job with no prospect of that changing, especially at a small company, it's time to move on.

If you don't like the culture or people at your job, it's time to move on.

If you are working too many hours and it's affecting your family, it's time to move on.

If your commute is killing you, it's time to move on.
Work for a company that you agree wholeheartedly with their purpose.
Senior management doesn't understand programmers or programming.
Upper management thinks of programmers as ditch diggers. We need a bigger ditch? Hire more programmers. They haven't read "The Mythical Man-Month".

Management will transfer authors of one code base to another project without asking the developers. This will cause great frustration and damage productivity, but remember they just don't understand software. It's your job to help them understand. Good management will listen.
Anonymous employee surveys are not that anonymous.
Some managers will try to uncover who rated them poorly. Be careful what you say especially in small departments.
Push back on bad ideas.
Sometimes management wants you to do something that is really wrong. Gently push back and tell them the reasons why it's a bad idea. If that doesn't work push back harder and give more details. If that doesn't work, try your best to make it work.
Help your management understand your problems by providing data.
For example, if your machine is slow and it's hindering your productivity, do timed tests of your machine doing a common task and compare it to faster machines. Show your boss that you are losing 45 minutes a day waiting for your slow machine. Hopefully they can see it's better for the company to buy you a new crazy fast machine.
Being laid off is just part of the job.
Don't be surprised or depressed if you get laid off. Happens all the time. It's an opportunity to find a better job.
Don't leave anything personal on your work computer that you want to save.
You never know when you will be laid-off and escorted out the door without being able to access your work laptop.
Always have your resume up to date.
Have accounts on Indeed.com and Linkedin.com.
Interview once a year
It's good to interview with another company once a year whether you are looking or not. This keeps you sharp and you may find better employment or appreciate your current job.
Prepare for an interview
Before an interview, research the company. Brush up on your skills. Do whiteboard coding exercises with friends. Visit sites like leetcode.com. Know the Gang of Four software patterns by heart.
When you are a manager...
Remember your employees have real lives and real families. Giving harsh criticism or forcing late hours effects real people who go home to their loved ones.

My biggest regret from being a manager and a tech lead was not protecting my people more from the company.

I was a manager for eight years. The most accessible book for new managers I found was "Flight of the Buffalo". It emphasizes empowering employees to make their own decisions - don't micromanage.
Beware of Dark Agile.
Take time for fun at work.
Spend time to organize lunches, games, contests, birthday parties, and baby showers. I don't remember a lot about my first job forty years ago, but I remember the amazing breakfast party that Murray hosted in our conference room for 3 hours with games. We had so many skillets cooking eggs, sausage and tortillas we blew out the circuit breakers on the floor.
At some point in your career join a Toastmasters Club.
Work hard when starting a new job.
You need to show initiative, correctness, and completeness. If given even a small task, work diligently and deliver more than expected. Don't be afraid to ask for help, but research and try yourself first. Make sure you understand the overall system. Always go out for lunch when invited. Take on extra work. Shine.

Section C: Code

Code can be weird for a reason.
Don't "fix" code when you don't understand it. See "Chesterton's Fence". Also, put a warning comment in the code when you do something counter-intuitive.
Be bold.
Don't be afraid of fixing existing architectural flaws. It's often faster to bite the bullet and fix something that is bad, than constantly wasting time living with the flaws.
Keep a library of interesting code that you've written and things you've learned.
The best way is to just publish this on the web somewhere. That way you can always locate it and your knowledge can help others.
Know that software is trendy.
Don't always jump on the latest bandwagon, give it a little time to prove itself. SOAP messaging is the conical example. It was just a bad idea all the way around, but too many people went with it (I'm looking at you Microsoft). To be fair, in 5% of the use cases you need the power of SOAP, but not for the other 95%.

What's the best JavaScript front-end framework? Backbone, Angular, Angular4, React, Vue, knockout, Ember, aurelia, polymer? It changes every 9 months. Perhaps it's better to just hunker down and learn JavaScript really well.
Know that your software has the shelf life of bananas.
You should care passionately about software quality, but at the end of the day almost all your software will be replaced soon by something else.
As you code, think of maintenance.
Try to downgrade the skills needed to maintain your system. For example, to change a parameter use an init file instead of a java class, so someone with only text editing skills can update your program.

Don't use a tricky feature of a language just to show you can.
When you finally track down that hard to find bug, don't fix it immediately.
1. Write a unit test that exposes the error.
2. Change your code so that the error message is more descriptive.
  Then related bugs will be easier to find and fix. For example, if your controller fails and the only indication is the "page cannot be displayed" message on a browser, change it so that it writes a page to the browser explaining the error, "Cannot find the file 'Config/Messages-en-US.txt'". Or more likely, for security reasons, give a bit more general error message and tell the reader that a more detailed message is written in the system log file.
3. Fix the original bug.
4. Write a brief summary in your daily log file and a team Confluence page about what the original error message was and how you fixed it.
  I'm embarrassed by how many times I was asked by someone to fix a problem, and I knew I had the same problem once, but forgot how it was fixed. But sometimes in a brief, shining moment, I search in my daily log file for my co-workers error message, and find the solution.
Don't try to make your code modules reusable for some future mythical system.
To make a module reusable takes three times as long as for single use. The odds of you, or your friends, reusing the module is really low. Don't waster your employers money doing something that may never be used. If you find a use for that module later on, then make it reusable if it makes sense.
Don't spend time optimizing before all is working:
"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil." - Donald Knuth
Realize methodologies are just guidelines.
Don't follow methodologies blindly. Just because Object Oriented Programming is a great methodology, it doesn't imply you should always follow it. In some cases speed or memory constraints force a good programmer to go against OOP.

The same with Domain Driven Design or Vertical Slices. It is not appropriate for all applications.
"Do not develop an attachment to any one weapon or any one school of fighting." - 17th Century Japanese Samurai, Miyamoto Musashi

"More computing sins are committed in the name of efficiency (without necessarily achieving it) than for any other single reason - including blind stupidity." - W.A. Wulf
Never update your Windows/Network/System password during crunch time.
Invariably, some little process like version control will freak out and cost you time which you don't have.
Keep a daily record of major events during the day in a text file or something like OneNote.
Things like the phone numbers of people you talk with, significant bug fixes, code snippets, URLs, SQL clauses, email addresses. When you encounter a puzzling bug, enter the bug error details and solution so you can find it later. It is important to keep it in a file and not just on paper, so that it can searched, transferred and backed up easily.
Testing
I like this quote from a Rational brochure: "Continuous, automated testing that covers the entire development life cycle. It's the only way to manage the constant flow of changes, errors and general chaos."

Invest in a high level of automated testing. I like JUnit for Java and NUnit for .Net. If possible, write your tests so that the input is an XML/Json description of objects. This way your testers can write your tests, instead of programmers.
Post-Installation Test for Enterprise Software
In the administration portion of your application have an "installation test" section where all the major components get exercised. Have a link to test that the databases are connected, any web services, and that key configuration items have values. Installation is such a pain and you can relieve some of that with good tests and explanations when something is not quite cricket.
OHIO/DRY
Remember what Ray Ozzie calls the OHIO principle (Only Handle Information Once.) "If information must be entered in two places, it won't be."
This is also known as the 'DRY' Principle (Don't Repeat Yourself).
YAGNI - You Ain't Going to Need It
Don't put in code that will be needed in some future release, but isn't needed for this release. In my humble experience this often goes bad and wastes everybody's time. One example in my experience was someone adding a language field at the end of a chain of function calls, for the future day when we would go multi-language. It was a big time waste. And no, the product was never released using anything but English.
Test Driven Development
Test Driven Develop is a tool for better architecture. It forces you into separation of concerns. The actual tests are a side benefit.
Push Complexity Down
You should push complexity down to lower objects and not clutter the higher objects with details. All code in a method should have the same level of abstraction.
Command Query Separation (CQS)
Bertrand Meyer presented it as:
"... every method should either be a command that performs an action, or a query that returns data to the caller, but not both. In other words, asking a question should not change the answer" -Wikipedia
Section D: People
Remember - In the end, it's all about the people.
Be respectful. Be kind. Be helpful. It's the right thing to do, besides, at the end of your career, the software you've written won't go fishing with you. It won't bring you soup when you are sick. It won't attend your funeral.

Section E: Conclusion

Enjoy your work. Have fun. If you find yourself pining for the weekend, change jobs or change careers. Forty-two years goes by fast.

__________________ BONUS ______________________

My Favorite Quotes about Programming
1. "Software is eating the world." - Marc Andreessen
2. "There is nothing so useless as doing efficiently that which should not be done at all." - Peter Drucker
3. 'The only proof of working software is working software." - James McGovern
4. "Every line of code is a liability." - Taka Muraoka
5. "The most amazing achievement of the computer software industry is its continuing cancellation of the steady and staggering gains made by the computer hardware industry." - Henry Petroski
6. "It has been said that the great scientific disciplines are examples of giants standing on the shoulders of other giants. It has also been said that the software industry is an example of midgets standing on the toes of other midgets." -Alan Cooper, About Face
7. "Measuring programming progress by lines of code is like measuring aircraft building progress by weight." -Bill Gates
8. "I have quipped in various board meetings that maybe we ought to give the airplanes away and sell the software maintenance contracts," - Ned Allen, Lockheed's chief scientist.
9. "Debugging is at least twice as hard as writing the program in the first place. So if your code is as clever as you can possibly make it, then by definition you're not smart enough to debug it."
10. "An organization, sooner or later, ships its org chart as its product (Conway's Law; the Windows organization was no different." -Ben Fathi

The Art of Programming

I retired after 42 years in the software business. Here's 42 lessons I learned from a career in software development.