The four books I will read this year - and why.
I failed my own advice last year. In the sense of “eat your own dog food”, I pledge to read the following books in 2023.
In an previous post, I suggested everyone to read at least four technical books per year. But, to be honest, I made that number up. There is no reason why you should not read more or less than that, as long as you read something at all.
I failed my own advice last year, as I only read two books: Clean Architecture by Robert C. Martin and Building Microservices: Designing Fine-Grained Systems by Sam Newman. I did not actively consider what I wanted to read in 2022. Not having a (rough) plan on how to spent your time is never a good idea. So, in the sense of “eat your own dog food”, I pledge to read the following books in 2023.
Designing Data-Intensive Applications
TL;DR: I expect to gain more background knowledge so that I can make better decisions and gain a quicker overview of technologies.
I have a history with this book. I bought it shortly after it was released and read the first one or two chapters. And I enjoyed them. However, for some reason, I put the book aside and eventually sold it.
You almost only hear positive voices about the book. The content might not be directly actionable at one's job, but it provides deep information on how things work. Do you need to know how a B-Tree works in order to use a relational database? I learned about B-Trees in the algorithms and data structures lecture years ago - and forgot everything. I can still use databases and indexes, so why read more about the background?
An example from the “real world”: We use Google’s Cloud Datastore in our application. If you do not spend the time to learn how it works, you will have a bad time with indexed timestamps.
So, first, I will read the book just out of curiosity and self-purpose. I just want to know (again) how that stuff works internally. Second, a deeper understanding of X enables us to work more efficiently with X. And, last but not least, I can join the people who brag about having read the book :-)
Site Reliability Engineering
TL;DR: I expect to learn how the “big players” handle their operations.
This book is a low hanging fruit. You can read it online for free, and, since it is more a collection of essays about SRE,you can pick what you need. However, I will read it from cover to cover.
Why? Designing and implementing software is just a fraction of the work. Designing and implementing software is the most enjoyable part of my job.. But, software lives long. Very long. If you do not take this into account from the very beginning, you1 will have a bad time in the future.
The books presents how Google runs it’s systems. Although our systems are much smaller than Google's, the principles and practices discussed in the book may still be applied. I've just started reading the book, but I've already learned something valuable from the first chapter: the error budget.
Essentially, the error budget is the time your application is allowed to be unavailable. It’s calculated as: 1 - availability target. If your target is to be 99% available per day, you can be unresponsive for about 14 minutes each day. So if your application was already unavailable for 10 minutes today, you might want to postpone the next feature release.
Staff Engineer: Leadership beyond the management track
TL;DR: I expect to get some insights on what could come next in my career.
Currently, I am a “Senior Developer” at my company. There is a lot discussion about what a Senior Developer is anyway, and your mileage may vary. Technical expertise is important, but I do not think that you need to have X years of experience to become a Senior Developer I think that a senior developer is also characterized by taking responsibility for things outside the code.
I wonder what might come next in my career. There is the almost stereotypical way to make a transition into management. Currently, I do not see this path for me. First, I enjoy the technical aspect of my work too much to leave it behind. Second, the idea that my day consists mainly of meetings scares me.
The title Staff Engineer: Leadership beyond the management track gained my attention. I am not completely sure about the book. To be honest, I am a little bit biased because it is self-published. However, I will give it a try and let you know if it is worth the time.
Something about frontend development
Since the beginning of my professional life, I worked on the backend for 95% of the time. In my spare time, I tried to get a little bit intro the frontend, but the world of java script frameworks is daunting.
Should I learn React, Angular or Vue? Actually I would have to brush up on my JavaScript skills first. I just can't decide!
So, I just cheat leverage my current knowledge and dive into KVision. The documentation is published via GitBook, so it is technically a book, isn’t it?
My goal is to be able to create web interfaces quickly, mostly for internal or private applications. So I do not have to take things like SEO into account which are often way harder with frameworks like KVision.
I worked with Vaadin before, and to be honest, I did not like it. Hopefully, KVision turns out to be more pleasurable.
Thank you for reading my post. I share my progress with these books in the upcoming weeks - so come back and see if I wasted my time on any of these books so you do not have to!
or someone else who will curse you then