January 9, 2018

Being A Good Programmer Isn’t Just About Writing Code

What makes up the ideal programmer, in your mind? 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 mad 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 that I’ve gathered– 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 go back to months’ old code and spend way too much time just remembering what the heck past me was thinking. Well-named and well-organized functions, comments, and documentation will pay back ten times in the amount of time it will save others (including you!) in the future.

Further info on writing good code (non-affiliate links, don’t worry!):
Clean Code
The Pragmatic Programmer
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.

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. But 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 to X number of hours, set in stone. Usually you can give a range, or you can even say that you can’t give a real estimate because you need 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)

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. I myself 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. (For starters, they talk to all the people, so you don’t have to!)

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 shouting, “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.

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.

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 the project, the best thing you can do for yourself and others you work with 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 yourself and 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.

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, StackOverflow, 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. When I was just starting out as a web developer, I relied a lot on the more experienced people at my company, and it really helped me get better. As I got more experienced, 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. 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)

When 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. You know, the whole “teach a man to fish” thing 🙂

Did any of these items resonate or hit home with you? Disagree with any of them? Feel free to leave a comment below!

Jessica Chan

I write about learning & problem-solving in web development https://coder-coder.com

Leave a Reply

Your email address will not be published.