Preface

The Pitch

Maybe you’ve worked with them. Maybe you saw them in a hacker (or Hackers) movie. You know the type. Fingers flying on the keyboard, weird UI on the screen that doesn’t look like yours at all, windows showing up for seconds, always filling the whole screen, always showing the right information. Always the right tool at hand, every action a shortcut, every command an alias, always doing just the right thing. Idea to shell to editor to shell to passing tests in seconds, faster than the untrained eye can follow.

From the outside, it just looks like that person is typing really fast – and they probably are. It may feel like they’re just more experienced – and they might well be. But that’s not the real source of magic. The real power comes from a toolbox that has the right tool for whatever you want to accomplish. Where each tool is sharpened to an edge that can split a TCP stream in two. There’s no need to think about where each tool is, or how to use it, because of plain old practice. Just like the guitarist of your favorite band doesn’t consciously think about where to put their finger for that next chord, you shouldn’t need to think about whether to use sed or ngrep. After a point, it becomes muscle memory.

Not to mention: if you know what you want to do exactly, you have an easier time finding the right tool. If you have a variety of tools, you have an easier time pattern-matching and realizing what exactly it is you want to do. It’s a virtuous cycle.

That’s what a customized development environment feels and looks like, at its best. At its worst, it’s fighting obscure bugs and weird systems. It’s finding a bug tracker showing your exact problem as WONTFIX from six years ago. Somewhere in the middle is research, hard work, mindfulness, a special mindset, hard work, obsession with details, lots of learning, and some more work – though the work feels more like play.

This book aims to show you a path that leads to the good parts, without getting bogged down in the bad parts, no matter how much time you have to invest. At its core, putting in the effort to improve your development environment is spending time you can spare, to be more efficient when you don’t have any time to spare (say, when fixing an outage). Even when you’re not in a crisis, effortlessly and efficiently using your tools cuts down on context switches, helping you stay in the flow.

It’s a frustrating, joyous, fumbling, exciting journey through blogs, bug trackers, manuals and, dotfiles. I’m glad you joined the trip.

Who is This Book For?

You’ll get the most out of this book if you’re motivated to work in that magical way, and are ready to improve the way you use your development environment to that end, but didn’t yet put in a lot of time towards getting there. You’re ready to jump in with both feet – this book is your diving board. You’re in the right place.

Maybe you are motivated, but don’t have the time to pore through all the man pages and years of forum posts to figure it all out. You can expect some quick wins and techniques you can implement right away, as well as warning signs on time-sinks to avoid. This will be your cookbook.

But maybe you’re on the fence about whether spending time on improving your devenv is worth it. Again, the quick wins and time-sink warning signs should be useful. But more importantly, you’ll also be able to get a feel for the journey – if you get a taste for it, you can always dive deeper. If not, take the quick wins. Either way, I’m happy for you.

Or maybe you already went down the rabbit hole, and write Elisp code to make Emacs send birthday reminders to your family using the MTA you run on your VPS. For you, this book may help you organize your knowledge. It may point out blind spots, open new avenues of research, show new perspectives and approaches.

What Technologies are Covered?

I must also mention what technologies you can expect to see here. The biggest divide is across the axis of operating systems. The primary focus of the content is Linux, and macOS (you may know it as OSX). With minor exceptions, the same techniques and technologies apply to BSD as well – but if you’re using BSD, I don’t need to tell you where that breaks down.

If you develop on Windows, and for Windows, and you’ll only ever touch Windows, then I’ll be straight with you: there will be biggish chunks of content not directly applicable to your environment. You’ll still learn some ways of thinking that you can apply, and get ideas on what to start looking for, but much of the hands-on content will be irrelevant. In case you’re wondering, yes, I’m open and totally willing to add that Windows-specific content you were about to send to abesto0@gmail.com.

How to Read This Book

While you can certainly read most of this book on an e-book reader, there are a lot of code snippets and screenshots that are going to be way less colorful. You’ll definitely want to check at least those parts out on your computer. Ideally on the one where you’re tweaking your development environment, for easy copy-pasting of snippets. Going further, I strongly encourage you to download the PDF version for reading on a computer. While easy to quickly check something out, reading online (with the LeanPub app)

will not serve you well.

I encourage you to read the next chapter, “Appetizer”, straight through. It introduces some basic concepts, and provides a taste for the kind of wins you can get by tweaking your environment.

For the “Main course”, reading back to front is perfectly fine as well. Some sections build on each other – for instance, we evaluate terminal emulators first, then talk about choosing a shell to run in that terminal emulator. If any of the sections are not relevant for you, or if one of them seem especially exciting, feel free to skip around. You won’t miss anything. If you do jump around, make sure to check out the two Interludes – they provide ways of working that are useful across any part of your development environment.

“Dessert” contains deep dives, tips, and extra-geeky ideas you can try out. Who knows, maybe some of them will click for you. There’s little to no connection between the topics covered here, feel free to choose and pick the ones that look exciting. You may still want to skim through them all, just to get a picture of what’s out there.

About the Author

As cheesy as it sounds, a development environment is a highly personal thing. Especially so if you invest time and effort to customize it, to make it really yours – which is exactly what this book is for. That means it makes sense for us to get to know each other a bit before diving in. I hope knowing where I’m coming from will also help put some of my opinions and conclusions in context. They may not always make sense for you – and that’s alright!

One of my axioms (values?) is never to waste anyone’s time. I’m not very altruistic about it, that also includes my own. I get annoyed when I – or anyone – needs to spend more time doing something than they’d strictly have to, in an ideal world. So far, that’s not unique.

Where it gets weird is what I think about how much time things should take in an ideal world. It usually depends on how often you do something. For something that’s as common as opening a terminal, cd-ing or whatever to your project, and starting its unit tests? I want that whole thing to take somewhere around 2 seconds tops. Switching to documentation / editor / e-mail? O(1), a single shortcut. It shouldn’t matter how many windows you have open.

I’m most at home with tooling, infrastructure, Linux, and backend code, but I tinker with a lot of software things. I learned monads. Three times. Know them? Hell no. But there’s just something inherently fun in taking a piece of technology, learning it, then bending it as far as it will go. Wonder if I can make React talk to that Bacon.js stream? Speaking of JS, how does Emacs handle JS embedded in HTML? React DOM elements in JS embedded in HTML? How about a script tag in a React DOM element in JS embedded in HTML? Will that break syntax highlighting? How about in Vim?

A big chunk of that tinkering necessarily went into the development environment itself. Let’s see if I can give you the result of that tinkering, without you needing to spend the same hours – after all, we all hate wasted time.

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.

Conventions Used

Capitalization of names of software follows the most standard way I can find - this is usually the way the name appears on the website and documentation of the software in question: tmux, GNU Screen, Bash.

When mentioned in the context of a command to run from the command-line, software names are in monospace, and capitalization follows the name of the executable: tmux, screen, bash.

The string “development environment” tends to come up a lot when talking about, you know, how to build a great development environment. To make sentences shorter and more comprehensible, the string “devenv” will usually be used instead of the long form “development environment”.

class CodeExamples:
   "Look like this, obviously"
   def run(self):
       print('With syntax highlighting, when appropriate')

$ echo 'Interactive shell sessions always include the prompt'
Interactive shell sessions always include the prompt
$ echo -e 'To separate the command\nfrom the output\nLike this\n\n'
To separate the command
from the output
Like this


$

# Some longer sections designed for copy-pasting into a terminal
echo 'are formatted like this, with no prompts'
echo 'so that you can really just take the whole thing and paste it into your shell'