A journey into the life of a programmer and the life-cyclus of a programming problem.

2016-07-21 - 6 minutes read - figaw

Ladies and gentlemen, let me welcome our very special guest tonight. Together we’re going to take you on a journey. A journey into the life of a programmer and the life-cyclus of a programming problem.

The Issue at Hand

We start out real slow, we have a problem. See, now, many would probably try to solve the problem right away, but this is where we first divide the sheep from the goats, by checking whether anyone has solved this problem before.

Now, three things will happen.

  1. We’re the first people IN THE UNIVERSE that’s ever had this problem. This is often due to the fact that we don’t understand the problem properly, and we file it under “feature to come..”. Alternatives include,
    1. the complainee not understanding the software properly in the first place and there is no problem at all, or
    2. we get bored and file it under “cannot reproduce error.”
  2. Someone online has solved the problem, and we can copy their solution verbatim in hopes that it’ll work. It won’t, see the section I don’t underst.. this is supposed to work??
  3. Someone online has solved the problem, and we can use the same strategy they applied.
    • This seems like the most work, and the slowest, but it’s mathematically provable, that since you’ll resort to this anyways, attempting any of the other solutions in first, will only make it slower.

The “programmer’s fallacy” (patent pend.): If I just copy a lot of code, my code will probably work and I’ll be done much quicker.

I don’t underst.. This is supposed to work??

Well, it did, but,

  • the software changed version,
  • the function is deprecated,
  • the solution is in another language, e.g. SQL is NOT MySQL,
    • you don’t understand the solutions language, and the weird symbol that ends the entire paragraph is actually part of the solution (tried this.)
  • Your KEYBOARD inserted a special character when YOU typed the symbols (no shit, this has been a problem for me on macbooks with the “or”-operator > || < in Eclipse IDE… and every time I had to use it, (100% still not kidding) I had to Google “Javascript Or Operator” because I knew it’d get me to W3Schools.com and they’d have it available for copy-pasting.
  • When you copied the data from the website, it inserted special html-characters in your clipboard and they’re invisible in your IDE because of the encoding. (The actual error here might not be very well explained in layman’s terms, and the average computer user will not understand what went wrong. Please don’t feel inferior. Advanced computer users don’t really understand what went wrong either.)

When Murphy’s Law was coined (the law of “what goes up, must go wrong.”) it was 1800-something, in an engineering society.. computers just sped “going wrong” up by orders of magnitude.

Solving the Problem

Now that we have a problem,

  1. we understand and,
  2. we’ve sucked up that we have to (more or less) construct a solution to ourselves,

It’s time to boot up an Integrated Development Environment (IDE) where we can program. (It’s much like Word for writing text for humans, but for writing code which is text for computers.)

– We probably had our IDE open when the problem arrived in the helpdesk, but then again, it probably crashed the second you wanted to do anything productive, so you’d have to start it anyways.

And now you have to update it. It’s much like trying to do online banking and having to update Java. See “Compiling”, https://xkcd.com/303/ which in plain english translates to “my hammer is loading, and I can’t do any work before it’s done.”

Solving the Problem.. Take Two

Firstly, we write a tonne of code that should work. Then we realize nothing works and mark the entire thing as a /* block-comment */ (you know, we might’ve written something correctly that we can totally use). Then we incrementially uncomment lines of code while we constantly print out variables and values to the screen in order to debug our code.

Most of the time it’s really just to see how far the code runs before it breaks, and our program starts to look a bit like..

.. some code ..
print("made it this far");
.. more code ..
print("I also think this works");
.. code ..
print("I also think this works1"); // messages start to become weird
.. code ..
print("asdf"); // complete disregard of human readability
.. code that might break something ..
/* ..
code .. */ // we don't trust code beyond this point

An abundance of funny things might happen while we incrementially uncomment lines and output values/text, including, but not limited to, we

  • find the actual error in the code, causing things to crash. (Yeah right.)
  • Uncomment a line of code that induces a side-effect, crashing code higher up in the file, that’s actually the faulty code we thought was working.
  • Get the naïve thought, that we might be able to juggle aplenty two thoughts simultaneously. We fix a ridiculous typo in a comment, forget everything about what we were doing, and have to start over. See the section Distractions.

“Finally” everything works, and we’re happy.. or, at least the code we’ve just written and have just tested works, see the section Fi..nope. Which is fine because that means whatever’s not working is not our immediate problem, and this might not seem like a very viable solution, but..

“You have no idea.” – Some guy, somewhere, at some point in time.

It’s called Agile Development, (read the following in a pretend-russian accent.)

“I get ticket, I fix problem. You have new problem? You create new ticket.”


While working on code, it’s often a good idea to be concentrating on the problem at hand, so you don’t introduce more errors while trying to fix the first one; see later picture.

Sometimes a programmer gets distracted all by themselves, at other times the outside world throws a tantrum, a wild distraction appears, and no holds barred, it’s super effective.

These might include, but not limited to,

  • An irrelevant piece of software (probably for your webcam) suddenly wants to update, maybe even rebooting your entire system automatically afterwards.
  • We run out of coffee/other beverage. This is important. You need to stay hydrated! (or in the case of coffee, dehydrated..)
  • Toiletbreaks.
    • Best practice: write ONE LINE saying what you were doing, before you leave.
    • Worst practice/what everyone does: give a fuck and walk away, knowingly forgetting everything you were working on.
  • Girlfriends wanting to discuss, literally anything. (Yes, programmers have girlfriends too. There’s this cool Russian service where you can import them as easy as a PERL lib, ping me, I’ll forward you.)
  • “Guy from sales” having a problem with Excel, which is something that runs on a computer, so you probably know how to fix it. Which is true because you actually give a fuck and read what’s written on the buttons on the screen, so it’s okay for everyone to waste your time and ruin your concentration, in order to export something to PDF. Because as a programmer you’re not really making any money for the company, you’re just the reason everyone else is able to.
  • “Guy from sales” wanting to discuss, literally anything.
  • Getting bored with the problem at hand, but having spent too long to just file it as “cannot reproduce error” or “feature to come..”, and now feeling sad that we didn’t do this in the first place.
    1. Spend 15 minutes wondering whether the ceiling would hold a noose,
    2. wake up from suicidal daydreams and,
    3. get a new beverage, because whatever we had in our cup is now the wrong temperature.

Pro-tip: even if you don’t like working to music, wear a pair of head-/earphones. It’ll instantly make you less approachable. Works in other job-types as well; would not recommend for doctors performing surgery.


There is no finally, only mo’ code, mo’ problems.

This is also a cute picture, that makes programmers laugh about coding, much in the same way doctors laugh about death.


My code isn’t working. It’s just not broken right now.