Someone recently asked me if I had advice for early-career programmers. At first I thought this was a silly question. I only entered the workforce ten years ago; many of my newsletter subscribers have been programming for longer than I've been alive!

Then I went and read some "advice for starting programmer" essays and thought of some things they missed. So here's thirteen bits of advice for early-career programmers. Some of it is contradictory.

1. People don't listen to me because I'm a good programmer, they listen to me because I'm a good writer. The same is true of pretty much everybody you'll read. This doesn't mean you should automatically reject everything, but it means you should carefully think about it and evaluate how it applies to your situation. And take any argument about "objective truth" with a grain of salt: there is very little about software that's been scientifically studied, and most of the research is inconclusive.

2. But also don't worry too hard about getting "tricked" or learning "the wrong thing". If you like someone's ideas, try them out! As long as you're not actively sabotaging your coworkers then it'll probably work out in the end, even if you look back and think "I should have done that different." That's what learning is all about!

3. Read the book Debugging: The 9 Rules. Borrow it from the library or ask your company to buy a copy, whatever. It's a real easy read and teaches an important skill all the other "beginner programmer" books barely cover.

4. At some point you will discover the Right Way to program, the thing which makes this all make sense, and you'll be convinced that the whole field would be so much better off if everybody else programmed the Right Way, too. For me the Right Way was test-driven development; for you it might be functional programming, lisp, formal methods or one of a million other things.

   I'm not going to tell you to not get swept up in the Right Way, because that's pretty much impossible. And honestly it feels really great to discover the Right Way and life's too short to not feel good. Just be mindful of the fact you're getting swept up and try not to make your identity the Right Way Guy. Eventually the honeymoon will end and you'll learn that programming is frustrating and messy regardless of which Right Way people use, and that you can also make great software without doing it the Right Way. Over time you'll learn fifty other Right Ways and learn to mix and match them to the problem at hand.

5. When you first encounter the Right Way, it will likely be from someone who went full Right Way Guy. Try not to hold it against them later. And try not to conflate the actual technique with how the RWG pitches the technique. Most ideas need some modification from their purest form to integrate well with other ideas.

6. Julia Evans once said "behind every best practice is a horror story." If you don't understand a Best Practice, look for the horror story that inspired it. It might make the best practice make sense. It might turn out to be something that's completely irrelevant to you, and then you can feel comfortable doing a different practice instead.

7. Building on the last tip: a lot of best practices and conventions are "path dependent", arising from a mix of historical and cultural factors. There are things we do because our mentors do it, who do it because their mentors did it, who did it to address issues that aren't as relevant anymore. If something sounds like a just-so story, it very well might be. You can often retrace the whole path if you're willing to look.

8. Take walks.

9. Almost every tool you use has some form of hidden depth, from your programming language to git to JIRA. Don't feel like you have to become an expert in every single one, but do consider spending 5-10 minutes learning a bit more about what it can do.

10. Talk to people in other parts of the company: support, business domain, sales, etc. Consider shadowing them if you have the time (and feel comfortable asking). You'll be surprised by what you learn!

11. If possible, try to do a few different types of programming earlier in your career. This doesn't have to mean switching jobs: most companies are doing several different kinds of programming at once. So like if you're starting in a webdev company, try some frontend, some backend, some operations, some database stuff, and so forth. This helps you learn, but far more importantly increases your chances of finding a kind of software work that you really really like. My first job was as a frontend dev and I was miserable. Later I moved to backend and was much happier, as were the people who wanted to spent more time doing frontend!

12. You've probably heard the advice that software as a field is changing all the time, and that you shouldn't get swept up in the framework treadmill, just focus on learning fundamental skills. This is a true, but doesn't explain the "why". For structural reasons, information in software propagates really quickly. This is due to a lot of factors (internet, open source, conferences) but overall there's a lower barrier to sharing ideas in software. So it's really easy to get a lot of people to know about someone's pet project, even if only one person uses it.

    The upshot of this is that a lot of the technologies you hear about have very small userbases and will never get wide adoption, but it won't seem that way from how you hear about it. That's why it makes sense to be conservative. If you hear about something that gets you excited, go ahead and be an early adopter, otherwise it's okay to wait a couple years to see if it has legs.

13. Ultimately none of us can predict the future, just as none of us could have predicted the present. Just try to do the best you can, live according to your values, and enjoy the ride.

That's all from me for the year; new workshop dates when I get back. See you in 2024!

If you're reading this on the web, you can subscribe here. Updates are 6x a month. My main website is here.