Being a Good Programmer Isn’t Just About Writing Code
How do you imagine the ideal programmer? Is it a computer whiz who has been coding since they were seven years old and making million dollar apps? Is it an experienced developer with 10 or 20 years in the biz, who knows every language (but only the good ones, of course) and can build a website in the time it would take you to get another cup of coffee? Is it a code artiste who can write code so beautiful that it makes everyone simultaneously weep in awe and gnash their teeth in envy?
Er, maybe? Well, all those dream programmers sound pretty good. But would you believe me when I say that having coding skills isn’t everything? And that good programming only makes up half of a good programmer?
Now obviously you can’t be a good coder if you don’t know how to code. But I feel like sometimes other, non-computer aspects of being a programmer are a bit overlooked. There’s a lot about being a professional developer that has absolutely nothing to do with coding, and everything to do with being a professional.
True professionals are the ones who get the job done on time, who know how to be a team player (not just the hero that swoops in and saves the day), and who ultimately are an asset to their employer or their clients.
What are the marks of being a good developer, then? Here are a few to start with, and I’m sure there are many more.
1. Write clean code.
Yes, this one is actually about coding. I did say coding is part of it, didn’t I? 🙂 At its core, good code first of all works, is understandable to other developers, and can be refactored without causing toooo much suffering. Code communicates with computers, but is also supposed to communicate with humans. I can’t tell you how many times I had to puzzle over old code and try to remember what the heck past me was thinking. Well-named and well-organized functions, comments, and documentation will pay back ten times over for you and others in the future.
Further info on writing good code (non-affiliate links, don’t worry!):
Clean Code by Robert C. Martin
The Pragmatic Programmer by Andrew Hunt & David Thomas
Refactoring: Improving the Design of Existing Code
2. Stay current with trends.
We all know how insanely fast trends in web development change these days. I’m not saying that you need to be a magpie coder and chase after the newest new hotness. But at the other end of the spectrum, if you become comfortable and then complacent, you will become a dinosaur coder, which is far worse. There’s a happy medium, where you work at getting good at a few core skills, but stay at least familiar with other trends and news that are going on.
Here are a few publications that can help you stay on top of our ever-changing industry. Feel free to chime in and comment with any other ones that you find helpful too.
Hacker News
A List Apart
Smashing Magazine
CSS Tricks
3. Be open to new things and learn them quickly.
If you’re still in the beginning parts of learning coding, don’t be too hard on yourself. I’m not suggesting that you should be able to master Angular in a week. But be open to the possibility that for any given problem, the solution may be something that you don’t know yet. And the “yet” is an important distinction. Because that thing that you don’t know? It’s simply something that you can learn how to do and add it to your toolkit.
It is important to try to learn new things as quickly and efficiently as possible. Because the quicker you pick something up, the more time you will have to code and learn other new things. Learning coding skills is, in itself, a skill that you can learn. If you’re interested, I wrote another post about some techniques that you can use to learn coding more efficiently.
4. Focus and work efficiently.
We all know that multitasking is impossible for humans, as our brains operate with a single thread. What we can do is switch from one task to another, but it’s not very efficient and it honestly isn’t ideal. Depending on your job or your situation, however, interruptions may just be a part of daily life for you. That makes it all the more essential to make the best use of the finite time that you do have for coding.
Try to separate work and non-work time as much as possible, and don’t let them overflow into each other too much. For example, constantly flipping to Facebook every few minutes will cut into your productivity. When you work, you can help focus by closing any other browser tabs and trying to work steadily until you hit a reasonable benchmark. Using a pomodoro timer to work in bursts of 25 minutes or so can also help you focus on the single task in front of you.
Additional reading:
Deep Work by Cal Newport
5. Accurately estimate the time needed to complete tasks.
This is a hard one, and admittedly one that I myself am still working on getting better at. Being able to accurately assess your abilities in terms of hours is a very valuable skill. Whether you’re working for a company or for yourself, a bad estimate will mess up timelines of projects and create work for others around you. At worst, vastly underestimating how long it will take to complete a project will cost you or your employer money.
One quick note on this: you don’t always need to be able to pinpoint the time needed to X number of hours, set in stone forever. Usually you can give a range, or you can even say that you can’t give a real estimate until you get some more information about the project parameters.
One way that you can begin to estimate how long it takes you to complete a project is to keep track of your time when coding. (This also goes hand in hand with #4, because your estimates will be better when you’re not browsing Reddit half the time)
I use a free app called Toggl for time tracking, but I’m sure there are many other apps out there.
6. Be able to explain techy concepts to non-techy people.
Yes, it’s frustrating isn’t it? When you’re happily swimming through code blocks and methods, and then you have to surface into the real world and explain it all to people who aren’t programmers? Why can’t they just look at your source code and get it? The stereotypical coder is a loner who wants nothing more than to hunker down in an underground cave and hack away at the keyboard, without being bothered by the outside world. Not everyone is like this, of course.
I do admit that when I’m in the depths of trying to figure out a particularly annoying problem, getting interrupted can really break my stride and make me cranky. But just like you, the non-techy people you work with have a vital function.
Working well with everyone on your team means that you need to explain code stuff to them, and in a way that they will get it. The first step of this is understanding that while you may see the world in terms of coding problems to fix, others operate around principles like money, deadlines, and clients.
If you can figure out how to talk to others on their terms, and with their vocabulary, you will go a long way in being a great team player. Let’s say you’re asked to add some feature to your project. Instead of saying, “No that’s stupid I don’t wanna!” and running back into your cave, explain that that feature will add another 20 hours of work, and the deadline will likely need to be pushed back. Then whomever you’re talking with can make a decision based on the information you’ve given them.
7. Don’t bring your ego to work.
Achieving this 100% every day is impossible for all but the best of us. But we can at least try to not be driven purely by our egos when it comes to work. What does this mean? It means that you’re not just about making yourself look good. You want your project, your team, and your company to look good as well. If you work hard to help others and ensure success for everyone, not just yourself, people will love working with you. But if you go out of your way to step on others in order to achieve what you want for yourself, you’re setting the bridge on fire. And you’ll be in the middle of it when it collapses. Sure, you might make some short-term gains, but do you really want to be that asshole that everyone else hates working with?
8. Don’t hide your mistakes.
No one likes messing up. It’s only human. But when it comes to being a professional, we have to conquer that very human urge to hide our mistakes from the world. If you make a mistake that will negatively affect a project, the best thing you can do for yourself and others is to come clean, immediately. Tell your supervisor, tell the client, whomever you need to tell, and start working on triage. Covering up your wrong and hoping no one notices might work sometimes, but if you do get found out it will seriously break trust and it could jeopardize your project or even your job.
Now you don’t need to report every single tiny little mess up. But for mistakes that will require extra time to fix or that break something important, please do everyone a favor and ‘fess up. It’ll be better in the long run.
9. Be able to ask for help from others, and give help to others.
When I was just starting out as a web developer, I relied a lot on the more experienced people at my company. Don’t be afraid to ask questions if you get stuck or don’t understand something. If you’re working on a project with a deadline, don’t take hours and hours trying to figure something out on your own when you could ask for help and have a solution in less than one hour.
You do need to balance it out with getting as far as you can on your own, by using Google, Stack Overflow, or Slack. But I think there’s this tendency, especially if you’re in a company, to want to be independent and to be able to do anything without help. It can really cost you time. It’s tough, but swallow your pride and admit that you need help. You’ll learn and get your work done more quickly.
The flip side of this, of course, is helping others when they need help with something. As I got more experienced and my company hired entry level developers, the newer people would often ask me for help. Getting interrupted isn’t the most fun part of programming, but it’s also part of being a team player and being part of the greater coding community. If someone asks you for help, try to help them in a way that will set them up for success the next time. Instead of just giving them the answer, give them a bit of context so that they understand the underlying principles and how the problem is getting fixed. And if you’re in the middle of some deep coding, you can tell them that you will get back to them in a few minutes. (Unless their problem is really urgent)
If you enjoyed reading this post, feel free to give it a 👏or two! Did any of these items resonate or hit home with you? Disagree with any of them? Leave a comment below.
📝 ⇨ 📬
Subscribe to @thecodercoder for weekly emails with articles like this one!
