Throughout the last few weeks and months I’ve taken into great consideration what I actually need. Both personal and professionally, it seems like I’ve sort of had a decent layer of excess build up. By my own metrics I think I’m actually most the way “there” if you will. The last major step for me is moving from desktop to laptop. Regardless, I’m writing this to sort of set some of my personal preferences/metrics in stone for reading. One of the main pillars of these preferences is to promote myself getting into flow with the least resistance possible.
I find that a lot of the time I don’t configure my editors a lot. I will go out of way to make some obvious quality of life changes. For example, adding fzf to vim. Do I need it? No. Can I operate without it? Yeah. But the primary idea of this preference is that I can sit down at any computer, if it has it installed already just out of the box, I can get to working right away.
Keeping it Lean
This is where things really are circumstantial. I’m fortunate that most of the projects that I work with are relatively straightforward in a lot of aspects. The fun thing about large projects is that everything focuses on efficiency and quality within a span of time usually. Even as Astera approached 16,000 lines of code (in itself) I’m starting to notice a good bit of my workflow slow down. Things like clang-format on save are starting to add artificial delays. I often ask myself the following questions: Do I need all of the tools I’m using? Are any of my tools causing me to stop and break flow to accomplish something? Is my code arbitrarily verbose? Is there a simpler and more straightforward way to accomplish this? For this I refer to you, a timeless meme:
5 9s Theory
This might be something older (than I am) developers already know. But for some reason it’s fallen out of common lingo in programming lately. 5 9s refers to uptime of a given service (99.999%). I was exposed to this when working as a pseudo sysadmin which really gave me a respect for the other side of programming, those that have to live with our code. Many times you’ll be tasked with maintaining code within a company. The main sticking point is that if something were to happen, be it a career change or whatever, there is a distinct possibility that production code you write can and will live on somewhere, maintained by someone who can’t just fix it in a few minutes.
My point being, write good tools that work. To refer back to Keeping It Simple, use what you need, and don’t settle for “just alright” if you can afford to not. I’ve found that taking the time to set myself up with stable and reliable tools (and auditing them) be it once a year or every few months is infinitely more fruitful than jumping ship to whatever bleeding edge (it’s called bleeding edge for a reason) tech there is.
Give yourself space
This is one of those things that requires constant maintenance. It’s in part brought to the forefront of my observation due to me reading Deep Work by Cal Newport. I’d sort of tried to do this prior but didn’t have a lot of the words Cal had put into writing. I find I both get into flow faster and stay in it longer if I chunk out my schedule to ignore email, discord, social media etc. Just me, some music, and the code (or whatever I’m working on). This can be a difficult one to put into practice especially if your habits conflict with it. It’s been I get some of my best work done in these times. There is the common sentiment of a “10x engineer” that many often wager as a goal. I don’t think that such exists, just a true fully realized 1x engineer.
I guess one of the main common themes here is that less can be more in a lot of situations. Where is it really possible for us to improve not only as individuals but as professionals by making otherwise minor changes? If you actually read this far, I hope you take some time to just think on this a little bit. I don’t think my words do it complete justice, and am interested in your interpretations of this. What resonates with you? What would you add or remove?