What to Expect from this Book
I’ll do my best to make all these weird tweaks accessible, quick to implement, and quick to learn. This does not mean that this book will let you sit down, spend thirty minutes reading the chapter on Vim, and be a Vim expert. We’ll cover many diverse fields that are deep in themselves. This book scratches the surface of these areas, explores why and how you may want to incorporate them into your workflow, and then provides pointers on diving deep, if you want to dive deep.
Don’t expect yourself to dive deep into all those topics. Any one of them can take months, if not years, of your free time, if you choose to spend your time there. Staying with the easy-to-use example of editors and IDEs, there’s no point to mastering five different flavors of Vim and Emacs and three IDEs. You can do it, if that’s your idea of fun (it is mine). You may have to do it in some very specific lines of work, but otherwise just invest enough time so you can make an educated decision, and go with it. Each chapter ends with an “In a Hurry?” section with my personal recommendation, so you don’t even need to do that if you don’t want to. Even so, I recommend skimming all the sections, just to get a taster of what’s out there.
Once again: you don’t have to learn all this stuff. Take what’s useful, leave the rest, maybe look it up when it becomes useful because your work changes. My background is in infrastructure, the cloud, and distributed systems, and my perspective on what’s useful is heavily influenced by this. Don’t take my word for it. Evaluate it for yourself.
All this takes time. Why would you invest that time? There’s a simple way to make that decision: do you expect the time you invest to make a positive return on investment, during your developer lifetime? If yes, it’s probably a good investment to make. To make that call, you’ll need understand where you could be investing time. A good rule of thumb is that you should first sharpen the tool you use the most.
Another reason to invest time may be that it’s fun. I get a feeling of satisfaction when the whole system works exactly like it should, after tweaking it for hours. “Like it should” is absolutely subjective – I can give you my list of shell aliases, and they’ll annoy you. Because they’re not solving a problem you have, in a way that makes sense to you. So instead, I’ll show you why and how you may want to create your own aliases. Realize that the development environment you’re using is made of the same stuff that you work on day to day. It’s software, it’s code. You can understand it, you can tweak it, you can change it – especially if it’s well designed.
Finally, let’s tackle a topic that comes up a lot when discussing this kind of development environment tweaking. It seems there is a correlation between how customized ones environment is, and how efficient an engineer they are in general. I think this works in a number of ways. Obviously, if your environment helps you more than my environment helps me, then you can work faster than me. This book contains many specific snippets, and quick techniques to build your own customizations, so you can reap this benefit without spending years to dive deep into everything. But that seems to not explain all the effects we’re seeing.
During the course of working on your environment, you learn a lot – you pick up lexical knowledge of how the components you’re touching work. Over time this can galvanize into an intuitive understanding of these kinds of systems, leading to sentences like “I expect this to work like X, and I can test this by performing experiment Y”. The Main Course of this book provides some of that lexical knowledge on just-in-time basis. The Dessert chapters at the discuss some of the topics touched upon in more depth than is strictly needed for tweaking your development environment. This is most useful if your development environment share components with your actual work items, like if you both work on a Linux desktop and manage Linux servers. If that’s not the case, some of that knowledge is useful just to understand your own desktop. I also expect that at least some of this knowledge and intuition transfers into other areas, but we’re getting to rather shaky ground here.
Even more importantly, your development environment is a great training course for software development in general. You get to explore your own requirements in depth. You get to understand how the existing tools solve those requirements, and then you get to make changes to said tools, so that they better solve the requirements. Most importantly, you hit bugs and problems, and you fix them. This loop of identifying a requirement or problem, debugging it, learning as you go, and finally fixing the problem, builds a habit of fixing stuff. It teaches you that you can fix everything; there’s always a bigger hammer. Your own development environment provides visceral feedback, and iterations tend to be short – much shorter than any kind of project work. You make a change, maybe restart an application, and boom, it’s in production. Make sure to use virtual or test environments for experiments though!
The conviction that the complex and weird behavior you’re seeing is something you can fix translates into any kind of software engineering. Unfortunately this book can’t do this part for you – you need to make your own mistakes, debug them, and fix them. The point here is not to have the problem fixed – it’s to have fixed the problem. The best we can do here is give you the lexical knowledge so you know where to start debugging. Or at least, know what to break in the first place.
However! Messing around with your development environment is not the only way to gain that confidence for fixing problems. It is not the way to becoming a great engineer. Spending hours and months and years tweaking your development environment, making new mistakes and learning new things, seems to “cause” good software engineering skills. But there are other ways to get there. I’m not saying this is even the right way, I’m saying it’s one way. And it’s the one journey this book takes you on.