Why this blog?
Having worked in Java ecosystem for almost 10 years, one day I’ve found myself somehow bored. Another framework? Nah. Maybe dive into big data? Nada. DevOps? And being YAML-programmer? Meh. It seemed that I needed to get away from known waters and head towards something else. Maybe not more challenging but just something different than my everyday web-related world. Where should I go?
An answer I was looking for came to me after finishing reading one the most important books in my life – “Mastery: The Keys to Success and Long-Term Fulfillment” by George Leonard. It presents the path of mastery – getting better at specific craft or area in order to find a sense of purpose and accomplishment. Not for the shiny goal at the end of the path – the path is the goal. Of course, it is nothing new. How many times did You hear or read something like: ‘Make Your passion a job, and You will never work again’ or ‘Do things for the joy of doing, not for their goal’. Tens? Hundreds? Probably a lot. I have heard that too. However, this time, there was a small addition – the path although endless, has specific direction, and that direction is mastery. So don’t just do for the sake of doing (no matter how fun that is), but also be aware of the ultimate goal. To become a master, is to actually be involved in a never-ending process. We strive for perfection without actually never achieving it.
In short – that’s what the book is about and frankly speaking – for the first time in my life this obvious truth hit me so hard. It was a feeling I had for a long time. Like Neo in Matrix – everything seemed to be fine, but still, there was something that was bothering me. Somehow I’ve settled with the plateau I was on. Author of the Mastery book calls that being a hacker – however, not in a good way. Hacker is somebody that has reached certain level of proficiency in a specific skill or job, and then just stopped progressing. Usually because it is hard (the more You know, the more You have to work to improve), but in my case I think it was that it was sufficient. Of course job can be changed (in order to get a temporary drive to learn something). And again. And again. Although it is not a good quality for an employee to bounce back and forth with a new job every six months. Hence, the plateau. It sucks, but it’s stable. My private, warm and cozy rabbit hole.
Having read that book I was given tools and a method to not only do something. It also gave me the narrative to follow. A role I could be playing starting now. Right now. The question was – where should my path lead? And the answer came to me almost instantly. Bare metal. Close to the silica of CPU. Deep down the memory pages. Somewhere where (almost) no one goes, and I’ve always wanted to give it a try. I thought that if I go towards nowadays’ hyped world of DevOps, AI or whatever is the current flavour of the month, sooner or later (rather sooner), I would be following not the path of mastery, but CV-driven development. With going back to basics of CS, OS design and low-level programming (I did not study CS, I am a political sciences graduate and self-taught programmer) that would never be an issue!
I was longing to dive into the subject for quite some time. Unfortunately there was always something stopping me. That ‘something’ was actually me. Myself. All my disadvantages I knew could be a problem. Impostor syndrome. Underdeveloped strategy-thinking abilities from CliftonStrengths survey, and therefore insufferable drive to try new things over and over again. I saw all that. Clear as a sky. But what was the alternative? Still hacking on the plateau of everyday job? No way. Wake up, Neo….
It looked scary for the time being, although, I did not gave up. The first problem to be addressed was – what I actually want to achieve? I knew that if I’ve jumped only to theory of operating systems right away, I will be bored to death in two weeks. On the other side – spending three months heavy-lifting coding exercises in pure C did not look too good either. If this whole process was supposed to be fun then there must be fun component in it! Therefore I’ve decided to go with a three-road solution and split my studying into three categories:
- Operating system theory
- Linux and kernel development
- Low level programming
With such approach I am sure that boredom is not a threat. On the contrary – stillness and regularity – they are tough nuts to crack. Everyone experienced that at least once in life – flash in the pan with some new project (code name: New Project/Hello World/Unnamed). The solution is simple – a habit. They say it takes 30 days of constant effort to establish a habit. Therefore I set myself up writing about my progress for 30 days straight. What I’ve done every day (with small exceptions for Sundays if I wanted to). If after 30 days there still will be fire – I’m game. If not – no hard feelings, just some knowledge gained, which never is a bad thing.
So what are my ultimate sources of truth? After googling a lot I’ve decided to keep it simple and stick to three sources:
- Operating system theory – Andrew S. Tannenbaum – Modern Operating Systems
- Linux and kernel development – Dawid Ward – How Linux works? and additional materials on the net
- Low level programming – Peter Prinz, Tony Crawford – C in a nutshell
First book is The Bible of operating systems knowledge. I’ve seen this book around for the last ten years, being marked-down on IT sales all the time as ‘evergreen book’. Well, its time has come.
As for the Linux itself – I’ve mentioned RHCSA exam, which eventually I did not pass (should concentrate more on RHEL8 features). However my notes and example questions are right now the highest starred RHCSA-related repository on Github. So for the time being I will review from time to time aforementioned Dawid Ward’s book.
Low level programming obviously must start with C language (hold your horses assembly zealots!). No ifs. No excuses. C is out there. Period. Of course the problem was with learning materials. I did not want to go back to the 70s with K&R book – it’s 2020 and I should take that under consideration. After some research I’ve decided to start simple with C in a nutshell. From my research it seems like the most reasonable choice for already experienced developer. There were two factors that convinced me to choose this book – it was released in 2016 – so I can hope that at least in its structure and language it is more XXI-century-like. And the second factor were chapters covering C language ecosystem, compilers, debugging and IDE. Not only hardcore language features but also presentation of ‘how it is done today’.
That’s the plan for the upcoming 30 days – to get on (and try to stay on) the path of mastery. The amount of knowledge is big, therefore knowing myself I did not start big when it comes to technicalities of my project. Do You know this story about starting a blog? Spend a week configuring WordPress on VPS, add domain, certificates, choose a theme, and write a blog post about it. Then never write again. Story of my life.
Therefore, I’ve settled for simple and plain Markdown docs written on my computer. It’s simple, no distractions, no additional config. Just open notepad-like app or GitHub (that’s what I’m using) and start writing. And that’s it. I am writing this blog post on 01-09-2020 (Tuesday). Hopefully I will be writing updates about it in a month. Just wish me luck 😉