Reflections on Ten Years Professionally Programming
I recently hit a decade of professional programming. I’d like to take a moment here and reflect on what I’ve learned.
This post is for me ten years ago. These ideas are always evolving. Maybe they’ll reinforce something you heard somewhere. Maybe you’ll agree, or disagree. I’d be interested to hear either way.
Start now. “The best time to plant a tree is twenty years ago. The second best time is now.” Transitioning to programming was a leap for me. I wasn’t sure it would work. Now most people assume I’ve been doing it forever. It’s amazing what can change in ten years. Get started now.
There is no ‘right’ technology to learn. If you’re doing web, learn a text editor, scripting language, HTML, CSS, JavaScript, and a relational database. The ‘right’ one is some other person’s dubious opinion. You can change later! Get your running shoes on and get out the door.
CS degrees matter, a little. I can count on one hand the programmers I’ve worked with who have a degree in computer science. Most of this work is learned on the job. I respect those that have a CS degree, and the theoretical knowledge they bring. But don’t let your lack of a degree stop you.
If you’re struggling initially as a programmer, keep going. My transition from amateur to professional wasn’t easy. There is a massive difference between the skill required to get a badge on a coding website and the skill required to deliver a production feature. Programming educators downplay this reality to keep students sane. If you stick with it, you can get better.
Beware the Dunning-Kruger Effect. I feel immensely grateful that I got hired by Hashrocket early in my career. I was surrounded by programmers who were much better than me. It’s easy as a junior developer to look around and conclude that you have it all figured out after a year. Don’t get stuck in the bubble.
Learn to communicate. The skill that lets you go far in this job is communication. You can practice it via blogging, open source, Meetup and conference speaking, internal demos, or show-and-tells. Every great engineer I know is masterful at explaining their work.
Learn to debug. Most engineers can build a feature, but fewer can quickly debug that feature, or more importantly, any feature. Debugging– correctly, intentionally, fearlessly– is one skill that separates the best engineers from everyone else.
Learn boring technology. A programmer I know is an SQL expert: he reads SQL books from twenty years ago and translates their ideas into modern databases. That expertise strangely gets more potent. It’s a wise career move to have one or two such areas of expertise: Linux, SQL, C, scripting, database administration, etc.
Learn a little about a lot. Engineers who are conversant in the basics of design, QA, project management, and database administration solve more of their own problems. They move faster and ship better work.
Learn to negotiate. Everyone should learn to negotiate. Negotiation is simply presenting a complete picture to your manager, who isn’t thinking about you always, of the value that you provide. You are valuable. It would be hard to replace you. If you want a truly remarkable career, you must learn to advocate for yourself.
Be as fast as you can be. The faster you can be, the better you can be. I’m referring to boring basics like inserting, reading, changing, and deleting code, and all the administration that surrounds it: debugging, committing code, opening pull requests, taking screenshots, and opening tools. Great programmers don’t hesitate to rename a function because they’re afraid they’re going to break something.
The user is everything. Learn to make all your arguments from the perspective of solving a user’s problem. Why are we adding valid HTML labels to our forms? Not because tooling said we should. We’re adding labels because some of our customers use screen readers, and we want to serve them, too. When you’re on the side of the user, you’re on the right side.
No technology is bad. “JavaScript sucks,” said the amateur. JavaScript is the most successful language in the history of programming; you’re going to learn it. I try to be curious about why something is dominant rather than focusing on what’s wrong with it.
Cultivate your curiosity. The best engineers are fanatically curious. When you tell them production is down, jump straight to questions: “Are we getting any messages from error monitoring software? When was the last deployment?” This is how issues are resolved. Once resolved, they stay curious, investigating how the outage was reported or why it wasn’t caught earlier. More broadly, letting your curiosity guide your career is a much better path than chasing trends or trying to anticipate the job market.
See you in ten years.