24 Jan 2015 - The Dark Side

How To Solve Programming Problems

I have a bad habit: a few days per year, I teach. One of my topic is to try to push engineering students on more technical topics where they are not comfortable. For a lot of them writing software (and maybe just using a Linux system) is something really scary, a beast that does not want to be dominated.

Sometimes some technical problem are hard to solve. Those few considerations are intended for the new comers, if you are writing software or have written software everyday for more than a few months you should not discover anything new here.

This is normal

Using a computer should be easy, it's not that easy, at least in the beginning. Losing hours on some stupid, uninteresting and bearly understandable problems is normal, we all go through this (at least I do). Don't let this destroy your motivation, you are not a loser, everybody has those problems when they come to the topic that is blocking you, some people don't try and don't do computer science / software engineering, others stay on the problem and beat it.

This is temporary

The more you get this kind of problem, the less you will meet this kind of problem if you solve them correctly. By correctly I mean: solving after understanding the root and not by dirty patching.

You will learn and recognize your former problems, you will be quicker to solve them the second time you meet them.

You'll get better at this

Even if you don't know your problem, it's your first encounter, you will know you a set of pattern to solve it in a quicker way.

For example:

  • Most Unix command can get more verbose if you add -v, -vv or -vvv, the output is sometime very informative
  • Most services write log somewhere, and those stubborn Apache and MySQL are not very talkative when they crash, but they push some very interesting data in their log
  • If you have a pure code problem, using a debugger is something you will get used too. I'm not against the print debugging, but I think you need the right tool for the right job and debuggers are the right tools for sticky, "why is this even happening ?" bugs.
  • When you have some explicit and precise error message you will remember that this is the most precious thing you have to help you. Something that your friend Google will help you leverage. That's why you should never configure your system to use another language than english.

If you were alone

Aside the four examples above, here are some stuff I would suggest you to always do in front of a sticky problem:

  • Try to understand every single part of what you are doing. The weird name that have classified has magic may deserve more attention.
  • Google your problem, try different formulation of your problem and try to use the vocabulary of your environment. For example I'm often Googling about "array" problem in Python, but the Python community talks about "list".
  • Stay on the problem a long time. A very long time. Einstein used to say: "It's not that I'm so smart. It's just that I stay with problems longer"."
  • Have a break, if you are a smoker, smoke. I you are a coffee drinker go for a coffee. Have a walk. Leave you screen. I solve an impressive number of technical problems in my bed. Sometimes it prevents me from sleeping, but it's something really efficient. If you do not really know what to look for a computer is too much distraction to actually focus on your problem, and some time focusing needs to be follow by some easier time.
  • If you are stuck on a program, run it on paper, or in your head.
  • Your problem seems to be linked with something in particular, a database query? Loading a library? Parsing a particular file? Produce a minimal reproducible example, often you will understand what in particular causes the problem, and you may solve your problem wy writing this small example.
  • If you have someone close to you (even if is a non programming person or even just a rubber duck), explain him what you are doing (see rubber duck debugging). It looks stupid, but you will primarly talk to yourself, out loud, and may have some "ahah" moment.
  • Read the documentation. I know it is boring and not fun, yet there are tons of information in there. More than often the solution of your problem.
  • When everything else fails, try stupid things ! "I'm sure this wouldn't change a thing", try it however! Random tests shouldn't provide you fixes (read about Voodoo programming), but they can help you to identify the problem.

Yet you are not alone

You can't learn everything by yourself, the trick is to know where to ask and to be brave enough to ask (the first time is hard, the second time is way easier).

  • Stack Overflow (and his brothers and sisters Server Fault and Super User are the best communities to ask question. Use them! Make a clear question with the minimum code you need to reproduce your problem and some proofs that you have tried stuff by yourself (like what you have tried). People will be happy to help you.
  • Many communities are using IRC (read about it if you don't know it). You are playing with stuff related to unit testing in Python, the #python channel is the place to be. This medium is slower than Stack Overflow and similar communities, but sometimes the true experts are too busy and getting in touch with them is easier through IRC (having a well formatted question somewhere helps though).
  • If you are stuck using a specific software or library, many are using project management tool where you can ask some questions (like GitHub).
tags: learning

Fräntz Miccoli

This blog is wrapping my notes about software engineering and computer science. My main interests are architecture, quality and machine learning but content in this blog may diverge from time to time.

Since a bit of time now, I am the happy cofounder, COO & CTO of Nexvia.

Ideas are expressed here to be challenged.

About me Out Of The Comfort Zone Twitter