Short history of me as a developer
Started out with Commodore 64 BASIC when I was eight. Built programs to randomize the seating of me and my classmates in school. Built small text-games often labyrinth-like or boxman-influenced.
Switched to Amiga 500 programming using AMOS Professional when I was twelve. This is when I started to undestand that programming was what I wanted to do in my life. Build small 2d-games like car racing, shoot-em-ups and click-and-shoot. When I found a bug in the collision-detection-routines of AMOS, I was crushed. That made me dig deeper, closer to the machine, so when I was sixteen I started to learn C via the Turbo C manual from Borland.
Made a switch to the, at the time, much more primitive PC with DOS. Built worm-clones, text-games similar to MUDs but with single player (this is where I learned about data structures like linked lists! Actually had to build malloc/free by hand since the libc routines were buggy). Tetris too, of course.
Computer Science was an easy choice for me at the university – the only real contender was physics, but my grades were not enough for that programme. While games had always been my motivation for learning maths, programming and physics, I realized at the university years that the Games Business was nothing for me. I'd rather continue building my small games in my spare time, with full freedom of choice, than being a cog in a machine at some game company with low wages and insane working hours, and 90% risc of the game being a business failure.
So after I had my master in Computer Graphics/Interaction I joined a CAD company called Cadcraft in Sweden. My first two years in the industry taught me many lessons of time-pressure and quality. At some time during those first two industry years I realized how fragile software systems become without unit tests. Picked up TDD.
Since 2007 I'm working on a CAD/CAM product for Windows called IGEMS, focused on water jet cutting - think AutoCAD with additional support for making cut paths for cutting machines.
About software craftmanship
I take pride in the software artefacts I produce. That is, if someone finds errors or complains about something when using my software, I get hurt. But not only am I emotionally engaged and try to fix the problem – I try to understand the context and dynamics that made the situation occur, and learn from that.
I believe a software developer is never fully trained, and I view lifelong-learning as being a part of the craft. Fundamentally it is about the love of software, and will to create high-quality software.
I'm test-infected, and have been so for the last two years. It started out with a christmas project in C++ were I did all unit testing using simple asserts. I had heard of unit tests almost ten years ago now, but just ignored them since ”no one else does it”. The feeling when doing my first few classes using TDD is one of the defining moments in the story of me as a software developer.
But there is more to software than avoiding bugs and creating maintainable source code bases. Software is used by human beings and human beings view software from the other side – the user interface. The psychology of using software is something that is cultural and without using my own software, it does not matter how beautiful my source code is! Because of this observation, I try to follow this maxim: ”Software developers should also be users of their own software, be it code libraries, games or webb-apps”.