Top 5 things I learned from shaving with a straight razor (and how it relates to software development)

No alt text provided for this image

I’ve been shaving with a straight razor, or as some people know it, cut-throat razors for over 15 years. I’ve had my fair share of nicks and cuts, but with every new skill, you get better with time and practise. The same can be said about software development and some principles from shaving with a blade that can seriously hurt you and writing software that can cripple organisations are interchangeable.

1. You need to keep your tools in shape

When it comes to sharpening your new straight razor, you need to lap your sharpening stone aka whetstones. Lapping a whetstone means making the stone flat. That way, when you hone your razor, you’ll get an even edge and it will prevent your razor from becoming a smiling razor and potentially leave you with big gashes on your face. You also need to make sure your strop is clean and healthy and any cuts and nicks flattened so you don’t hurt the edge of your razor while stropping it.

In software development, it means that you need to keep your IDE up to date, your 3rd party libraries up to date and your tests in line with any new features that you’ve implemented. It also mean that commits are pushed to the repository in a timely fashion and any changes from other developers are pulled into your branch before developing. That way reducing the risk of bugs and duplicated work.

2. You need to set your edge

When you first get a new straight razor, you need to create an even and properly angled edge. This edge will serve a template for future honing and stropping. It will also ensure that your razor remain super sharp and just glide through your beard hair like a hot knife through butter.

In software this will equate to choosing the right language and frameworks for the job. When starting a new project, there are a few key questions to ask. Questions like what platforms do you want the application to run on? What is the application supposed to do? etc. Once you’ve got a better idea of the requirements, you will be better informed to choose the right language and frameworks for the project.

3. It takes time to get good

I’ve been shaving with a straight razor for over 15 years, and only in the last 3 years have become proficient enough not to look like I’ve walked through a bush full of razors that turned my face into cheese. A bit over dramatisation there, but seriously, when starting out with shaving with a straight razor, you will get cuts. A lot of cuts. Every now and then, I’ll still give myself a cut, but it’s nowhere near how bad it was in the beginning. I keep on honing and stropping my razor get a keener edge. Always trying new techniques to optimise the shaving experience and minimise cuts and rashes.

Over the 20 odd years of my development journey, I’ve made my fair share of mistakes. I’ll admit it. I’ve lost code. I introduced bugs to production systems. I merged changes out of existence. The list goes on. However, with each set back, comes the opportunity to learn and grow. I’m not perfect, and anyone who claim they are, is lying. All a person can do is to try your best and to learn from past mistakes and failures. Nowadays, I take testing more seriously, defensive programming is my new paradigm, constant communication to clarify requirements is more common and constant commits, pulls and merges are the norm. This all leads to more efficient, bug free code.

4. Patience is a virtue

Shaving should be a ritual. It should be something you enjoy. That’s why I take my time shaving. Lathering up ones face with hot soapy foam. Stropping your razor before shaving. Then slowly and steadily removing every hair from your face. At the end of the process, you have the satisfaction of not having cut your face and having and nice close shave without using a disposable razor with 5 blades, but with only 1. And more so, a single razor blade that will last you a lifetime, if you look after it. No more buying new razors every couple of weeks.

Now, I’m not saying that one should code slower. But if you take some time to think through your solution that you want to implement, think through the API’s that you need to create or consume, think about the test cases that you need to write, think about the defensive code you need to write to stop the application from crashing. Then you’ll spend less time fixing bugs, looking through endless lines of log lines and spend more time creating awesome bug free code and cool new features.

5. Satisfaction is guaranteed

When shaving with a straight razor, there is nothing as satisfying as feeling your face to be as smooth as silk without any cuts where it was previously rough enough to sand a slab of wood. All this with a single blade that you’ve sharpened yourself.

For software developers, I would say it’s seeing your code running out in the wild being used by hundreds, if not thousands, and in some cases millions of users. And the best part would is when you get positive feedback from users about your application.

Leave a Reply

Close Menu