30 years of programming

Some weeks ago, I remembered that this year has been my 30-year anniversary since I started programming. I celebrated the occasion by buying a cake for team “fika” at work, but I have also been thinking about the “coding journey” that I’ve done in these 30 years. So I decided to write this post about it.

30 years ago I was 12 years old. After saving money for what felt like a really long time, I finally bought my Commodore 64. Not that ugly brown “bread bin” version, but the slim and sleek C64C (also called C64 II, https://www.c64-wiki.com/wiki/C64C).

After reading the computer manual for a while (there was no Internet in 1989, remember?), I 0managed to start writing some BASIC code. The language was simplistic, and editing entered code was a pain. And there were absolutely no refact tools around. When developing a program you often ended up with having to change the line numbers manually (yep, every line of code had a line number), since you couldn’t fit some new code in between the existing rows. And no, there were no tool to help you change line numbers.

But at least there were a cassette recorder to store the programs on (https://www.c64-wiki.com/wiki/Commodore_1530). No punch cards needed!

I remember two programs that I did during the C64 years; one was a database containing Swedish soccer game results, that I planned to use to statistically predict what the results would be in future soccer games. After inputting the soccer results for a few weeks I got bored and gave up on it. Who knows, it might have done great predictions… Or not.

The other program was a kind of grocery store checkout program, that I built for my oldest sister to use together with a home made light pen (https://www.c64-wiki.com/wiki/Light_pen). You could slide the light pen over hand made bar codes to add it to the checkout cart. I was surprised to see that it could correctly distinguish between the bar codes every time. I still have no idea how that worked! (To clarify: The light pen was normally used to point at locations on the screen, but somehow the alternating black and white areas drawn on pieces of adhesive tape also worked to generate unique input values.)

A couple of years later I bought an Amiga 500 (https://en.wikipedia.org/wiki/Amiga_500), which felt like a huge step up from the Commodore 64. The Amiga 500 shipped with AmigaBASIC, that was actually developed by Microsoft. But I managed (rememeber, no Internet?) to get my hands on a C compiler and made a transition to coding in C instead. The concept of memory pointers was exciting, even though the learning curve was steep. Would be fun to know how many times the computer crashed due to weird usage of pointers.

When I went to high school (sv: gymnasiet) I was surprised to find that the school offered a C++ programming course. The teacher was a complete a**h***, but he could at least teach some basics of C++ and object oriented programming. This made me make the transition to code C++ instead of C. Syntax wise this wasn’t a big thing, but thinking object oriented opened up a new world of possibilities.

One problem I had was that the C++ compiler I had to my Amiga ran out of memory when compiling anything but really tiny programs. This could be solved by compiling parts of the program separately and later linking them together, which was a pain.

When I started university in 1996 to study for my M.Sc. in Computer Science and Engineering, I purchased my first PC. It was a used i486 which wasn’t great by any means, but running Windows gave new possibilities that the Amiga hadn’t. I somehow got hold of Microsoft Visual C++ that provided a good interface to build desktop applications. Compared to the Amiga, that required fairly low-level programming to create UI elements, Visual C++ had a drag & drop alternative that generated C++ code using the Microsoft Foundation Class Library (MFC, https://en.wikipedia.org/wiki/Microsoft_Foundation_Class_Library), pretty much like WinForms today.

Being able to build Windows desktop application was a boon for my programming career, building applications for Banverket (Swedish railroad administration) and Stora Enso. Especially the work I did for Banverket gave me a good income during my university years.

I also paused my studies for a couple of years to work for a software product company. Microsoft SQL Server was used a lot there, which was a nice change to using Microsoft Access databases that was prone to data corruption and single-user only (unless you put the database file on a shared drive, but then weird things could happen…).

During my studies at the university I also met my brief friends Java, LISP, Pascal, Fortran and Ada. Of those languages, LISP (https://en.wikipedia.org/wiki/Lisp_(programming_language)) and Ada (https://en.wikipedia.org/wiki/Ada_(programming_language)) was definitely the most interesting ones. Ada being a very strict language with hard type checks and predictability, that was designed for critical real-time systems where application crashes could be fatal. LISP being almost the complete opposite, an incredibly “fluffy” language (yes, it’s a feeling 😊). It also forces you to think functionally and recursive. And writing a gazillion parenthesis while doing so.

This was also the times of waterfall-style projects. One course, that I don’t remember the name of, teached the “correct” way to build an application. Project plans, collection of requirements, creating test plans, then finally coding stuff. After everything had been tested, the result was presented to our customer (that was actually a real customer at Nokia), the result was “almost, but not quite, entirely unlike what they wanted” (https://en.wikipedia.org/wiki/Phrases_from_The_Hitchhiker%27s_Guide_to_the_Galaxy#Not_entirely_unlike). Luckily, they didn’t have to pay anything for it (even thought we got a nice dinner from our customer for our time spent). Ok, it didn’t turn out that bad, but you get my point.

In 2005 I got my M.Sc. degree and got a job at Capgemini, Stockholm. There I started a project that used C# .NET, and that is the language I've been using since then, with minor side tracks. Apart from technical advances I think the biggest learnings for me in the last 15 years has been:

• Test driven development (TDD): At around year 2010 I got into a project that was using some concepts that I hadn’t been using before that. The concept of writing code that was only used to test the other code was a bit weird at first, but then gave an “Aha!” experience on the same scale as when I learned about object-oriented programming.
• Agile development: In the same project we also used Scrum. Not having to have a plan or design up front was a bit scary at first, but soon changed into a very nice and smooth way of working. I won’t go into the agile pros and cons here, there are other people far better than I to talk about that. But I do think that (proper) Scrum has improved the daily work for developers to the better. As long as you have a good PO…
• DevOps: There are many different definitions of what DevOps really is. But in my view the most defining part is that the development team takes full responsibility of the lifetime of the system. Having the developers having to manage the operations leads to a lot of benefits from a quality perspective. Mostly from the fact that developers will focus on improving things that is or might become a pain for themselves, instead of building something that will be “someone else’s” problem after the delivery is done. Pain points are always a good driver for fixing things! Hopefully the team also want to use some good development practices like TDD and using automatic CI/CD pipelines while doing so, but I consider those different practices to be able to get to the goal, and not part of the goal itself.
• System architecture/design: Having built multiple systems do give valuable learnings about what works and what doesn’t work I reality. I guess this is what is called “experience”. 😉 Using this knowledge is definitely one of the most interesting and rewarding areas for me at this time, so my prediction for the next decade is that this area will be the one that will hold the biggest learnings for me. It feels like an area that you can never fully master.

Before I end my ramblings, I can only appreciate that I’ve managed to get into a field of work that I really love. It’s far from everyone that loves their job, and even more rare to have it as your personal hobby. Of course, everything has it ups and downs, but if it’s “up” almost all the time you should be really happy.

This pretty much sums up my “30-year coding story”. I hope is was readable and contained something interesting. I sure had a nice trip “down the memory lane” when writing it.

And since we’re only a few days away from 2020 now, I wish you all a happy and productive new year!