[Home] Karl N. Redman:

How To Be A Computer Programmer

(A Realistic Assessment):

Every so often someone asks me or for advice on how to be a computer programmer. This question has always caused me a bit of anxiety because it brings up all sorts of other thoughts like, ‘the semantic and social differences in the definitions between a coder, a programmer and an engineer’, or ‘what is the context of the word “how” in this question?’. It’s a simple question with an extremely complex and subjective set of answers. My way of attempting to answer this question is to emphasize realistic components to what being a computer programmer is like for me -and my personal struggles thereof.

The short answer is that you have to work at it with passion just like any other skill. But that always comes across as aloof and elitist -and it’s not helpful at all. So I usually try to describe the mental and emotional struggles one must overcome to learn a programming language and go from there. This article is an attempt to provide new programmers with information about what kinds of things to keep in mind while learning the skill of computer programming.

Get used to feeling stupid/dumb:

As a programmer you will constantly find yourself in situations where you feel dumb. You will be constantly overwhelmed by the complexity of all the new things you must learn in order to accomplish your goals. This fact is daunting and emotionally exhausting. However, it’s not all doom an gloom. The payoff is what you are after; something that you wrote is working -be it a single line of code that prints to the screen or an entire application. Take frequent breaks away from the computer and articles and books you are reading but don’t stay away too long. And when you are really stuck, learn to let go of the problem at hand for a short time and work on something else that is related to your task but doesn’t require that you find a solution to said task. You will come to appreciate those ‘Ah Ha!’ moments as you are cleaning the house or taking a shower or otherwise adulting.

Don’t let anyone fool you. While seasoned programmers learn to ‘fake it’ they are riding exactly the same emotional roller coaster as you. Over time you will learn to be as confident as any other programmer. It just takes practice in knowing that, if you stick with it, you will eventually find a solution to the problem that you are trying to solve. And when you’re feeling depressed and overwhelmed and otherwise down about not accomplishing your goals when you want, just remember that everyone else who is doing something similar has the same kinds of feelings. Stick with it, ride the roller coaster, and endeavor to persevere.

Get used to failing a lot:

Computer Programmers fail 90% or more of the time with everything they do in coding at first. The difference between a novice and a seasoned programmer is that the seasoned programmer knows how to recover more quickly; the failure ratio is the same but at a much faster pace -so the incidences of that 10% success ratio occurs at a higher frequency. The feeling of failure, especially as a new programmer, is emotionally on-par with feeling dumb/stupid. Many people are able to get past feeling dumb/stupid but their egos can not tolerate the constant feelings of failure in programming. Often it is the fear of, and direct feeling of, failure that causes most new programmers to quit coding forever. As with feeling dump/stupid take frequent breaks if you find yourself feeling frustrated. And never project your frustrations onto other people, pets, objects, etc! It is extremely important that you learn to accept that failure is the price of admission as a programmer. Keep yourself in check and find ways of blowing off some steam without causing aggravation and/or harm to others. Generally speaking, it seems universal that most seasoned developers will find something physical to do in order to deal with their levels of frustration with failure.

Failure isn’t terrible. The more you code you will learn that most of your best ideas come from previous failures. And if you find yourself playing wack-a-mole with trying to get some particular code to work just right then it’s probably time to take a step back and think about what it is that you are trying to code. Most programmers will admit to brute forcing code “once in a while” but few will admit that, in reality, it happens a lot. One clear sign that you are frustrated and should take a break is that moment where you’ve just tried to do something umpteen times without the desired result. And if you are starting to feel like you want to ‘rage quit’ then it’s also time for a break. Keep in mind though that this might just be the break that you need. Often programmers will walk away from the code for a little bit and realize they have to scrap everything in order to make it all work better. And that’s a good thing. Just know that these feelings are common and that you will write better code over time because of your failures; we, as humans, more often remember our failures over our successes.

Work through programming books and tutorials:

Start learning by working from the beginning of any book or tutorial that interests you. For every language or task you perform always be thinking ‘Hello World’. From building an Apache server to writing your first program in C++ you should always start with ‘Hello World’ or it’s equivalent. The reason for this is that when you write the simplest form of code or break down your tasks to their simplest forms you get an idea of how things are supposed to work and the amount of work involved in accomplishing your goals. Always start learning via a tutorial if you can.

Work as much of a tutorial as you can stand, then take a break, and work on the tutorial(s) some more. Once you begin to feel so antsy that you can’t stand it then, and only then, should you consider branching out to trying your own things. The reason for this is that you’re practicing a new skill and your frustration levels will go through the roof over feeling dumb/stupid and like a failure if you move away from tutorials too quickly. Also, as you work with more and more languages and systems you will find yourself speeding through tutorials faster and faster.

Never feel embarrassed that you are reading HowTos while others are attempting to build the next killer app. The better you know the fundamentals of the systems and languages you are working with the more productive you will be in the (not so distant) future. Try to keep your code as best you can. I recommend that you figure out how to use a source code repository system (i.e. git) as well. This will help you with your organization skills as you progress.

Be realistic about the time investment:

Learning new things takes time. And being a programmer means that you are constantly learning new things. Every professional programmer knows they will never know every aspect of any particular programming language or development model or system -even if they wrote it themselves. As you learn more about how you learn you will be able to gauge your time more effectively. The number one administrative issue that new professional programmers have on the job is they grossly underestimate the amount of time it will take to learn and/or complete a task. The novice programmer that is just starting out has even less experience to draw upon for estimating time.

The general rule for learning and completing any new simple task is to estimate how long you think it will take and multiply it by three (at least). As a new programmer you should try to keep some notes about how long various tasks have taken you vs. how long you thought those tasks would take when you started. This will help you realize how long it takes to learn new things and apply that knowledge as well as give you a good idea of your estimating abilities -and help you improve upon those things respectively. Learn to track your time early on because you will always be accountable for it as a programmer. Likewise, if you are just starting out and doing things from home it’s a good idea to be realistic about how much time you are stealing from doing other things like socializing with family and friends or housework, etc.

Start Projects Often:

Practice your programming skills. Everyone says this but few people bother to explain what this means or how to go about it. Finding projects to work on is, hands down, the most important and the most difficult part of becoming a programmer. Every programmer struggles with this ‘If I only had a project’ problem -everyone. One common cause for never getting started on a new project is the overwhelming feelings mentioned earlier in this article: feeling dumb/stupid, frustration, and failure (or the fear of it).

The fact of the matter is you will eventually throw away 99.9% of all the projects you think up. And of the .1% projects you’ve thought about which actually make it to any code at all you will eventually throw that code away 99% of the time. Projects quickly become overwhelming for any programmer. Unless you have an expert’s level of understanding in regards to any particular language and/or system, one almost always realizes that the simplest of projects increases in complexity by orders of magnitude almost instantly. Don’t overwhelm yourself. Break your project down into smaller and smaller components until there’s nothing left to break down and it becomes obvious what you need to write/do in terms of coding or configuration or the like.

The easiest thing to do in terms of starting projects is to keep working on tutorials. At some point you will have worked through so many tutorials on a particular topic that you actually start a project out of sheer boredom or because you’ve become inspired in some way. Take notes: carry a pen and notebook with you at all times (or use your smartphone if that’s easy for you). Don’t assume that you have to build the next killer app. Start small and write code snippets that test things you are curious about -eventually those snippets could end up in a library or as a gist somewhere (i.e. github).

The main thing is to be either writing code or thinking about writing it for at least some part of your day every day -without exception. You may go for weeks without actually writing code but if you’re reading about it and thinking about it you will likely find some small project to start you off. Also don’t try to make every project into something that you will distribute or keep forever. If you’ve got some killer app in mind, great!, start off with building it as a ‘hello world’ and get your configuration infrastructure in place as soon as possible. Research your ideas and see if you might be able to start out by contributing to someone else’s project or tutorial or the like.

Generally speaking, don’t sit around and try to think up any specific or perfect project. Find an article online or in a book that interests you and type it in and test it -that’s all you need to get started. Eventually you will have a backlog of ideas that you can work on little by little. And that’s what people mean by ‘start a project’ -not that you have to build the most awesome thing ever right out of the box. Projects are for helping you prepare for other projects -so consider building yourself little tools that will help you with tasks that frustrate you or are tedious.

Try to have these things in place as soon as possible for any project that goes beyond ‘hello world’:

  • Use source code control (i.e. git).
  • Add the project to a remote repository if you can (for backup purposes).
  • Add unit tests
  • Implement a build process (if applicable -i.e. c/c++ makefiles)

Here are some suggested tasks that you might consider as a project:

Write a ‘hello world’ program package in a language of your choice and distribute it to yourself.

  • publish a ‘hello world’ program on github and build a readme.md page for it.
  • Create a project that uses gitlab as a private repository.
  • Create a project that uses github as a public repository.
  • Add unit testing to any ‘hello world’ or personal project.
  • Configure packaging (i.e. npm, autoconf, rpm, etc.) for any ‘hello world’ or personal project.
  • Install Jenkins and have it run a build, unit testing, and/or automatic packaging for you.

Build a website or webpage.

  • start with a ‘hello world’ page.
  • make it ‘responsive’ for various devices.
  • Add navigation for the site.

Host your web site on your own computer (i.e. Apache or NGINX).

  • Add an authentication section/url.
  • create a page that displays the output of a ‘hello world’ project in a language of your choice.