Unlike what we usually blog about, this series is dedicated to getting inside the minds of our developers. What kind of problems do we face on a daily basis and, more importantly, how do we deal with them? By the end of this series you will have a better understanding of how the seemingly simple can become infinitely complex when translated back and forth between our language and computer language. To meet halfway from the get-go, this blog series will be in English, as it is the language of the computer.
A computer is a simple thing. It is basically a calculator, though be it a fast one, with a screen and some buttons. When you feed it instructions, it will execute them with fascinating precision. A computer will do exactly what you tell it to. Herein lies the problem.
For example, let’s say a program needs to load a file into memory, analyze it, and print out how many times a specific word is found in that file. A simple use case could look like this:
If you ask a computer to do this, it will gladly comply without an opinion on its given task. It seems simple enough. But what happens if your computer has a limited working memory of 4GB and the file you want to analyze is twice as large? The program will crash without giving you any results.
This is a classic example of how hardware limitations force the developer to adapt. However, from the user’s (or client’s) perspective the differences in hardware and necessary adaptations do not matter – the program should just work. This is the main challenge for any developer today: things should just run smoothly. Whether it is a website that should be able to scale from 4K screens to the tiniest of cellphones, or a desktop application that should work on machines older than seven years, the end result should be the same: it needs to work. It is the developer’s challenge to make this expectation a reality.
A seemingly simple use case is hence made a lot more difficult:
A developer’s job is to make sure the computer behaves. This can be done by carefully designing each line of code around the aim that it should always work.
This is the first post in this blog series in which we attempt to explain some of the challenges we face when transforming your, the customer’s, wishes and desires into working code. Some of these posts will be more technical in nature, while others may feature anecdotes about how we need to think like a computer in order to instruct it.