Being a Professional Programmer
When I was around 12, I set myself the goal to become a professional programmer.
I can tell, because at this time I made the conscious decision to use my right hand to control the mouse — even though I'm left-handed.
My reasoning was, that if I ever had to help out a colleague with a computer problem I sure did not want to move her mouse to the other side before getting started. That would be awkward. (Of course I did not foresee the advent of the wireless mouse... As a matter of fact, I still use the right hand out of habit.)
One thing I always wanted to know is how a typical workday of a programmer looked like. Was I wasting my time by pursuing this career? Only later I found the answer — but I had to become a professional programmer myself. This article aims to save you from a few years of uncertainty.
Before you dig into this, be sure to read the first part of this series titled "Why I love Programming".
In one word: accountability.
You are expected to be responsible.
Programming in your free time is like throwing a party without having to clean up: pure fun! If you get bored you're free to move on. Not so in professional programming, where you're expected to get the job done.
Every application requires constant bug fixing, refactoring and sometimes even monkey patching. Maintaining code is no amusement park; especially if it's not your own.
Fresh out of school you might think you're a pretty kick-ass programmer. Let me tell you: you're not. You wouldn't guess what talented people can do with these blinking machines. You'll have tons of things to learn in the first few years.
Professional software development is a lengthy process. Writing readable, well-tested, well-documented code is a substantial effort. You will need patience, lots of it. Both, with yourself and with others.
As a junior, you only think in black and white. You look at some code, and it's all wrong. Who in their right mind created this horrible monstrosity?! As you become more experienced, you'll see the shades of grey.
Eventually, you'll understand that those neckbeards were not slower than you, but more careful. You learn how to test your code, how to document it. You even begin to appreciate UML diagrams.
"The world is moving too fast. What you learned today is obsolete tomorrow. Why bother?". I've heard that saying countless times throughout my career. It's both, popular and wrong.
If a skill becomes obsolete, it's not a skill. Throughout your career you don't want to be known as "the Jenkins guy", you want to be the expert in Software Quality. Hint: If you don't know what Jenkins is, that's the whole point. You should not narrow down your scope too much. The right skills never become obsolete.
From time to time it happens, that due to some new company policy your beautiful creation will become obsolete. As depressing as it sounds: it's a regular part of the software business. You need to adapt. One advice I can give you is not to take it too seriously. Drop the project, keep the wisdom. Embrace change.
A professional programmer has to deal with deficiencies all the time. The game is called "balancing constraints". Deadlines, budgets, and code quality are just a few competing constraints we have to consider. Elegant designs fade away in the face of reality. In the end you want to earn money with your software, so you have to ship it!
The best developers I know, keep the balance between pragmatism and elegance. They know which parts matter and which don't. Those who don't will be replaced when there's a need.
For me, I was always leaning more towards elegance. That's just a nicer way to say I was a perfectionist. I needed to learn the pragmatic part through hard work.
The better you become at programming, the less you code.
Instead, you will spend more time thinking about Software Architecture, high-level designs and splitting up the work into smaller junks for other developers to consume. You will start mentoring Junior Developers. Recruiting will require a lot of your attention. You will spend your time in Meetings, discussing project goals with business people. One might say, you take the role of a mediator. Others might call you a manager.
Once you know the ins and outs of the business, you are an essential asset for the company. You might get asked to become a manager, or at least managing projects will slowly feel like a natural extension of your responsibilities. But beware! This slow and gradual process is dangerous. Moving back to being a full-time programmer is not easy. During the time you were busy with project management, others were busy improving their coding skills. You can try to keep up-to-date in your free time but that's hard.
I've seen excellent developers become great managers. At some point in your career it's a decision you need to make for yourself.
However you decide, it pays off to invest some time into learning how to communicate. Empathy plays a prominent role in that. Developing software as a team is so complicated that a lot of time is spent on aligning goals and communicating problems. In fact, communication is what you get paid for. This includes documentation, tests and the code itself.
Talk to others, listen to their problems. Read books about Software Project Management, even though you don't want to be a manager yourself. It will help you understand the role of your boss.
There are many good reasons to work in IT, but money is not one of them.
While it can be tempting to base your career decisions on prospective salary, don't do it. You will be very unhappy. You will spend eight hours or more each day sitting in front of a blinking cursor. That's a lot of time, and time is much more valuable than money.
Don't get me wrong. There's plenty of jobs that pay well. You will most likely not get rich, though. If you want to make it big, I can't help you. Maybe look into Real Estate or so... The only way to get rich as a developer is to work on something really hard, put in lots of hours and get lucky. Startups, basically. Keep in mind: One Bill Gates takes a thousand failed attempts. Another way is to stop being a programmer and become a manager instead. I've already shared my opinion on that in the last section.
While you should learn to read (and maybe write) code, working as a professional programmer is not for everyone. You might ask: "Is it worth it?". For me it was the right decision. Hopefully I could help you to make your own.
Thanks for reading! I mostly write about Rust and my (open-source) projects. If you would like to receive future posts automatically, you can subscribe via RSS or email: