10 Years as a Career Programmer
This month marks my 10 year anniversary taking this hobby pro. If you've never read Peter Norvig's essay, Teach Yourself Programming in Ten Years, you really should. It's a piece I read a long time ago that, while lacking a lot of immediate advice, definitely rings true now that I'm here.
How it All Started
While this marks 10 years being paid to program, I've been programming since I was roughly 7. My first programs were hilariously bad. I started on an old IBM PC clone running MS-DOS 5.0 where I first learned how to program in Batch scripts.
After learning a program called TheDraw and a utility called Batchman, I had the brilliant idea to
write a program that would, when you press a key, display a list of words from the dictionary. It's
no surprise I got as far as copy pasting 26 IF ERRORLEVEL 30 GOTO A lines and typing a
few dozen words from a dictionary split between A and B into TheDraw before I got bored. Hey, it
technically worked. Kind of funny how, to this day, I notice the tendency for programmers to code in
such a way to make solving the actual problem someone else's responsibility.
Since then I've learned about a dozen languages, written thousands of lines of software for fun and for profit, and both learned and forgotten many things about what a computer is and what it can do. Professionally I've worked as a DBA, IT admin, scientific computing dev, security researcher, instructor, information research scientist, ML dev, and now I'm doing some web full stack.
So, What Would You Tell Yourself?
The question everyone always wants to know, "What would you tell yourself if you could go back in
time?" Let's be honest, I was told a lot of things that I still only barely understand. None of the
advice I can give is much better than advice already out there. The big problem you have is that
there's a lot of counterproductive advice. I think the best advice I can point to comes from that
essay though,
Have the good sense to get off the language standardization effort as quickly as possible.
It's advice I never really understood when I first read it. I mean, I'd never been a part of this language standardization effort. But at this point, yeah, Norvig's more right than younger me could ever imagine, in many more ways than that simple sentence conveys.
Programming and Evidence
See, there's a large contingent of people you'll learn from and interact with as an aspiring programmer that preach a set of beliefs that you'll come to learn we actually have no real evidence for. Not only that, but some of their advice we actually do have data on. Data that shows they're wrong (trust me, they won't let that convince them). This isn't just a programmer problem, all humans are gullible to rhetoric.
So how are you to know who to trust for advice? Well, everyone and nobody. Learn as much as you can. It's better to be ignorant than only know a little. So always know a lot. If you can't explain succinctly how something really works (not just by metaphor or abstraction), you probably don't understand it but you can totally fix that. When someone says something is bad or can't/shouldn't be done, see what people who disagree with them have to say.
Just beware the statement, "You need to do X if you ever want a job as a real programmer." They're completely wrong. If they don't have data and a methodology to collecting and analyzing it, they're probably wrong or at least grossly over stating its impact. This is why we invented science. Rhetoric's greatest enemy is data. Data is not infallible mind you, but a lack of it is often a worrying sign. If they're right, why not collect some data on that claim?
Likewise when you read or hear "always" or "never," these people are also wrong. Don't ignore them, but try to find someone that disagrees with them and learn why. Everything in real life is situational and relative.
Honestly, the only skills that matter are;
- a profound curiosity,
- a high tolerance for ambiguity,
- a desire to do more with less, and
- the ability to solve problems.
Aesthetics
What you'll learn Norvig's talking about is every programmer's constant obsession with aesthetic taste. There's a lot of people who'll tell you without evidence that something will improve your code by some immeasurable degree. They'll use vague metaphors like technical debt, code smells, code cleanliness, and more. They'll champion buzzwords like big data, machine learning, software defined networks, service oriented architecture, agile, magic numbers, expert systems, concurrency, zero trust, blockchain, data mesh, test driven development, object orientation, story cards, pair programming, continuous delivery, open offices, 360 feedback, class factories, consensus management, flexible storage, domain driven design, dynamic programming, ontologies, delayering, layered architectures, innovation, and YAGNI's SOLID DRY KISS of OKRs… OMG!
It's not that none of these work (I mean some of them might and others definitely don't), but rarely if ever does the person talking about them have any serious data about their efficacy. No, "Here's a double blind randomized control trial proving this improves metric X across a wide range of people, places, and situations." Instead they use vague jargon, anecdotes, metaphors, their own and other's authority along with a good heap of fear, uncertainty, and doubt. The hard part's that disproving their claims takes real effort. Effort they're not going to put in here. They just want you to use their product, pay for their courses, read their ad infested blog, or just do things their way because that's the way they like it.
Meanwhile the real problems, the ones your user is relying on you to solve, become an afterthought. The metrics that really matter to them get forgotten in favour of doing the things that this person pinky promises matters. If only you did thing X, you would be successful for some abstract measure of success. Did X and it didn't work? You're probably not doing it right. If only you did it your code would be simpler for some undefined notion of simple.
Measure simple. Then we can easily see if your thing actually increases/decreases that number. Does that measure even matter? Is it correlated with something we actually care about? Do you have proof of that? Have you ever thought about what really matters?
What Really Matters
For me, minimizing the time I spend reading, writing, modifying, debugging, running, and discussing code matters. The less of each required, the more time I can spend problem solving. Unfortunately I don't really know what matters to you. You're going to need to look into that.
I'd suggest learning philosophy. Yeah, liberal arts. I strongly recommend it. Too much programming makes you think you understand everything too much. Sure, 2 + 2 = 4 and a circle's circumference is proportional to π radians times its diameter. But tell me, is beauty objective or subjective? What even is beauty? What does that say about your coding standards? Heck, why do you work? Why do we create art? What is truth?
You're not going to find definite answers in philosophy. You're not going to find definite answers in society. This isn't a coincidence. In physics, each new theory seeks to supersede the previous. In philosophy each new school seeks to recontextualize what matters. Plus, it'll stop people from asking you if you can fix their computer at parties.
Overall, just relax and make sure you never ever let working rob you of the joy programming first brought you. I mean it! Sure, if you're in this just for the career, yeah; specialize, build your network, engage in self promotion, and most importantly spend time practising. If you want to have fun though, that's gotta be on you. On the bright side, this field seems to be full of people who appreciate working with others who know a lot about how computers and everything else works. So for the love of learning, never stop.