Sharpening the Saw

Sharpening the saw is Habit 7 in the cringe inducing book entitled “7 Habits of Highly Effective People”. This post isn’t yet another book review but rather the work we do to make the rest of my work, better, faster and more consistently. The label Covey gave to this work was “sharpening the saw”.It conveys the idea that, given a new saw, one cannot just continuously cut wood all day, every day. Time needs to be given to sharpen the saw, literally, so that the wood cutting rate remains consistent.

As a developer, I interact with hundreds of tools, websites and system a day. Each one has it’s own cognative overhead such as keyboard shortcuts and the like. Furthermore, as technology is so rapidly evolving, there is seldom reason why you shouldn’t attempt to iterate your approach to problems. My quest to sharpen the saw started, like most new things, with a question - “How can I make my life easier as less stressful”.

1. Keeping better personal notes

Most of the people I admire across a broad spectrum of industries love to keep notes. Learning from your mistakes is very easy to say but not so easy to actually do. And more importantly, implement a system to do so.I solved this by doing the following:

• Creating a new GitHub repo called Notes, each note is then a simple text or markdown file. I chose GitHub for storing this so I do not need anything asides from my YubiKey and a terminal - simple and low friction when moving across machines. Also text will never die, platforms will, eventually - even the best
• Treating my Todoist Inbox as a brain dump - I run my life on Todoist, so it’s a super easy way, if I have a bunch of ideas to just dump them into Todoist. Since this is my task manager, I can process them as if they were a task. If they need action, I will expand them and sort them into their appropriate project. If the idea is a new project entirely (more than 2 actions), I will either do it or look at where I can schedule it
• Keeping a currently.txt file open in one terminal window that I update before I context switch to something else. For example, if my wife calls me to help her with something round the house or someone comes to the door, I quickly write what I was “currently” doing. When I then come back, rather than trying to rack my brain to figure out where I was, I just read that document.

2. Improving my Desktop Productivity Setup

I want to expand on this section a bit more in a personal infrastructure post but here is a brief summary of how I got my PC to work for me rather than me working for it.

• Store my dotfiles in GitHub and have them auto sync from any of machines when they are edited, this keeps the aliases, functions and programs in sync across the machines
• Switch my terminal from Bash to ZSH and install a bunch of plugins to make hopping around the shell easier
• Got a USB switcher so I could clamshell my Macbooks (personal and work) and switch between them easily
• Got well aquianted with the *nix terminal and keyboard shortcuts
• Purchased a solid keyboard as I try to avoid using the mouse at all costs
• Analysing all software deeply and attempting to speed up its performance as much as possible

3. Dedicated learning time

Each week, I spend at least 20 minutes learning something new. But it can’t just be anything. It has to be something that will further my knowledge in a new paradigme. Learning a new JS framework will not extend my knowledge in a new paradigme. Learning how the TCP/IP stack works in *nix or how a certain part of the V8 engine works will.Personally, I enjoy teaching others so part of my “learning” time can involve teaching others things I already know. The effect this has on the brain and knowledge storage is fairly well documented and I’m not a neuroscientist (yet) so I’ll leave it to them to explain why this is so effective at knowledge retention.

Additionally, I find attending meetups (such as LeicesterJS, one I help run), and speaking with other developers facinating. I like to hear of their problems and throw myself in. It helps improve my questioning ability - something I did not cultivate enough early in my career. In the past, I was very much “open the bonnet and have a rummage” kind of debugger, this approach works for a lot of problems, but there are others such as ones documented where this strategy does not cut it. To combat this, I have invested time in trying to be better at asking questions. As a child we are very akin to simply asking “why” all the time, but asking good questions is more than just why as often things boil down to more than 1 problem. It’s about asking questions that carve away at the ultimate nugget of truth based on absolutes.These questions also help me when presenting new ideas. If I present an idea after having read about it on a large companies engineering blog, I would have no foundation of which to base my reasoning on. Instead, by gathering data and arriving at a solution that way, it has a basis to stand on. Don’t try to wedge a solution from someone else into a problem you are experiencing, it mostly won’t fit.

4. Post mortums and reviews

Part of learning from your mistakes involves reviewing what happened, what went wrong and most importantly why. Although at my workplace we do not have an engineering blog or a culture of writing post mortums for absolutely every issue, I’ve found it personally beneficial to keep a “war” log of all the big issues I’ve faced, why they came about and how we solved them. I keep these write ups in my personal notes.

Overview

I’m happy I spent time doing this, and is a process I will continue to follow. Hopefully this helped you practically speaking as there is a lot of wish-wash in this sector. If you have any more suggestions let me know on twitter. You can also following progress of my startup TurboAPI - here