ProgrammingJavascriptCareerProductivityGadgetsASP.NETWeb Design

3 skills every programmer needs to develop

Written by
Published on
Filed under
3 skills every programmer needs to develop

A programmer is many things. Particularly at a company. Not only do they build the software that other people rely on, but they also act like the translator between the code and the humans that work with them.

It really is more than just writing a for loop or a while loop and then going home. In my 20 years of coding, here are 3 invaluable skills that I have had to learn to develop in order to be a more effective programmer at my job.

Reading technical documents

I assume if you are reading this, then you can read just fine. But many of those new to programming never realize that a big part of the job is in reading complex documentation sometimes for hours at a time.

If you don't believe me, here is a write up I did on the Amazon Product API. It is a C# implementation that I coded and wrote about and that took me hours upon hours to figure out. The official documentation for the API is roughly 200 pages long and it isn't exactly clear which part of the 200 pages is the relevant part that I needed. Which means that I had to read most of the entire document until I found what I was looking for.

And the same will hold truth for many libraries that you implement into your code at your job. So if you are the kind of person that reads 2 paragraphs and then falls asleep soon after, then you are going to have to work on your ability to sustain focus for long periods of time and to take notes and take them well.

Remember that in the corporate world you have deadlines and you have project managers. Sometimes (most of the time) the work is out of your hands. Someone on your team may decide that it is time to start using a brand new 3D graphing library to build the new reports. That job might go to you, which means that you are going to have to spend a fair amount of time in the documentation for that library.

It isn't fun and you will fall asleep many times, but it's an important part of the job that not many people talk about. So learning to read and to take notes along side of that will make your overall coding life much easier.

This applies to both your professional and to your personal work.

Communication

This one sounds boring, but hear me out.

The biggest challenge for most programmer's, even experienced ones, is in translating a specification document into running code. For alot of reasons. Sometimes people use words that we aren't familiar with and other times the spec sheet is just wrong and we end up coding wrong things. It happens.

In wood-shop you are taught to measure twice and to cut once. And the same is true with code. You might think that it's less serious with coding, because you can simply change the code later on and you are good to go. But that's not quite so. If you make a mistake early on and continue to code on top of that mistake, then you are pretty much writing invalid code until you stop and realize it.

If something doesn't make sense, you have to suck it up and pick up the phone. This is something that I struggled with early on in my career. I felt that if I called my manager to verify certain elements of a project, that they might think I wasn't up to par with the task. Nothing could be further from the truth. In fact quite the opposite.

I can't count the number of times that my manager would run up 3 flights of stairs to my desk in order to go over the specs in person and in more detail. They did it with a smile on their face and were genuinely pleased that I was paying close attention and wanted to reduce the chances of bugs and errors.

An added side-effect was that many times as we discussed the specifications, things came up that no one had thought about earlier and that didn't quite fit into the model. So we scrapped these items which made my overall work much easier.

Programmer's like to think that they can ride out their jobs listening to music in their cubicle's while partaking in energy drinks and coding on terminals. And you can, I promise you, but only if you and your team are in sync with what each other are doing.

Typing speed

And last on the list, is an easy one. Every programmer should make it a point to increase their typing speed and their typing accuracy. I still know way too many programmer's that only use their index fingers to type. You can be fast with your index fingers, but you won't be touch-type fast.

The difference really is noticeable. The average typing speed for most people today sits at around 40WPM. It's definitely better than say 20 years ago, but far from perfect. My own speed, on a good day with a good keyboard sits at around 100WPM.

And the only way to get good at is, is to practice for hours and to build up that muscle memory. I personally started to practice touch-typing when I was 17 years old using various Windows applications from back in the day and I've never looked back.

Which is why I built a touch-typing practice JS app that you can test and train your speed with. I designed 5 levels of difficulty and 3 different time intervals. I use it myself whenever I have an extra 30 seconds to spare just to stay sharp.

Just for reference, the world-record for typing sits at around 230WPM. I am still a long way from that level, which is why I still make it a point to practice every now and then.

And there you have it. 3 things that you can work on to become a stronger developer. I hope those were helpful and I hope they become things that you incorporate into your day to day coding life.

Walter Guevara is a software engineer, startup founder and currently teaches programming for a coding bootcamp. He is currently building things that don't yet exist.

Comments

No messages posted yet

Developer Poll

Q:

Stay up to date

Sign up for my FREE newsletter. Get informed of the latest happenings in the programming world.

Add a comment

Keep me up to date on the latest programming news
Add Comment

Stay up to date

Get informed of the latest happenings in the programming world.

No thanks