Tree

Adam Ivarssons development blog

Making of the Book-List page

The blog part

First and foremost, check out the book page here: https://adamivarsson.com/books/.

In the fall of 2019 I became sick. The sickness was in itself not so bad; merely a sting of insistent irritation cough. It began with what I believe was a slight fever that quickly died down, followed by the cough itself. In the beginning the cough was slight, so I went to work for a few days. Then however it increased in both frequency and magnitude during the weekend, to the point where sleep was almost impossible. I started waking up 8-9 times a night to cough, staying awake between 20-30 minutes each time to drink and get my pulse down. It is very common for people to overestimate how much their sleep is disturbed, so I kept a log, which is where the 8-9 number came from. I was also adviced not to sleep during the day as a sleep scheduling shift even in cases like this usually do more harm than good. It was during these first sleepless nights the idea of the book list came to me. Preserving the memory of these books seemed really important to me at that time.

Sleep deprivation however set in quickly and even though I didn't feel that sick, I was beginning to be so tired I was loosing coordination. I had never before realized how much I value my short term memory and ability to concentrate; which when I was this sleep deprived no longer was something I had. A perfect example of this was when I had to go grocery shopping. Now with a list of 15-16 items I can usually get through by looking at the list 2-3 times (working from the heavy-unsquishable items to the softer frail items since I'm not insane). During the weeks I was sick however, unless I could see both items at the same time I had to look at the list between each item. When I went to the doctor, I had to bring a written document with the name of the prescription-free medication I was taking, the dates of when I started to get sick e.t.c. You know that feeling when you go into another room and forget why you went in there? That was me for 2+ weeks. So why did I decide to start programming the book list whilst this sick? I was simply unsure if I could work or not.

During the time of writing (and during the time of the sickness) I worked for a company called Sectra. For me, it was a bad time to get sick since i had quite a few balls I wanted to hit goal with before I could rest. So I started making the webpage which would display the books to see if I could still function as a programmer (I was coughing 24/7, but hitting keys on a keyboard was slow but possible). I then quickly stopped when I realized exactly how sleep deprived I was, with me making the same class three times with three different names before I realized I had already programmed that part twice already during the past half hour.

The technical part

But here's the interesting thing. If someone looked at how the project turned out in the end I think many people out there would think it was written in a delirium, even though most of it was written afterwards. Here are some of the things that might raise a few eye-brows:

Dark image of the UI so as not to burn out anyone's eyes.

All of the above things should be ringing alarm bells. So why am I so open about me having written something that messy and with so little forethought? Its simple: This code is unimportant. All those things would in a professional setting (in the literal sense of me being paid to write a piece of code) be unacceptable. But this isn't the case here, that was a personal project of mine done for fun. And even though I know quite a lot of best practices in both C# (which the site was written in) and Web in general, I also know why they are best practices and can therefore choose to ignore them to save time since I know full well what problems they might cause down the road. So here below I will justify the "bad" decisions I wrote about above.

I do realize however that many of the points above are easily countered with "but how do you know this won't come back and bite you later?". But it is in that specific point we find the skill I actually wanted to "show off" in this post. I have now after many years of programming learned how to weigh todays shortcuts against potential future "gotchas". And, in the examples of "bad" code above, I've done just that weighing.

The lesson

I know when to prematurely optimize, when to keep the long scope in mind and when (and how) to make pretty polished code. But almost more importantly, I know when it is appropriate to cut those corners.

Most programmers can show and explain their good work, but how many show and explain to you their bad work?