Thread by @Malkyne

I've been a senior programmer for over two decades. Here are a few tidbits for programmers:

1. As a Senior Programmer, you have a few different career progress options: You can stay in that role, if you like it. You can become a Lead. You can freelance. You can switch industries, for new challenges. You can start your own company. I've done all of these things.

2. To be a career programmer, you have to spend your whole life learning. There's no point at which you get to rest on your laurels. This constant learning is good for the brain, but you will end up jettisoning some things you haven't used in a while, and that's fine.

3. It is unlikely that you will do your greatest programming work before the age of 30, unless you let yourself atrophy or move into management. The things you learn through experience give you powers that more than compensate for any decline in neuroplasticity.

4. Programmers work best when they have interesting challenges. It's good to work with junior programmers because some of the things that may be old hat for you are still interesting challenges for them.

5. A lot of growing as a programmer is

Step 1 - Learning a thing.

Step 2 - Unlearning a thing.

Step 3 - Learning the nuance of WHEN to use the thing.

Don't be a fool at Step 2 who is maligning a person who is at Step 3.

6. It's tempting to approach programming principles like religious edicts, but this will make your thinking rigid and will make it harder for you to continue learning.

7. Akin's Law of Spacecraft Design #36: "Any run-of-the-mill engineer can design something which is elegant. A good engineer designs systems to be efficient. A great engineer designs them to be effective."

8. Obviously, you should do things according to best practices, but I've seen senior programmers get so far up their own asses trying to do things the "Right" way that they don't ship. Don't.

9. You're a grownup and learned to generalize things, so they'll be more reusable. Great! Now get better at identifying which things actually need that kind of TLC, instead of wasting time generalizing everything.

10. You're probably going to reuse far less of your code than you think you're going to. Yes, even your own code. You've learned things, and you're going to want to make it better, next time.

11. It's not the end of the world if you lose your work due to a power outage, git disaster, etc. Your code will usually be better the second time you write it.

12. For a program that is going to have programmer hands on it for years, maintainability should be one of your foremost concerns. This is not the place to, for example, show off your clever C++ template wizardry. Every subsystem should be approachable by your colleagues.

For those who like this one, you can find more of Akin's Laws, here: spacecraft.ssl.umd.edu/akins_laws.html

I worked for Dr. Akin's lab, back when I was in college.