Following the Boy Scout Principle in Software Engineering

A post from Oleg Yanchinskiy

Software development isn’t very difficult. In fact anyone with a little motivation and an internet connection can figure out a way to hack something together in any language. The difficult part is being a good engineer. Good engineers don’t always have the answer, but they have a developed set of robust principles that they rely on to guide them during the toughest challenges. Being a good engineer takes patience and lots of it, it takes thoughtfulness, being able to see the big picture and an endless determination to continually improve. Good engineers are at the backbone of any startup, they're the motor that makes everything turn.

In software engineering, quality code is everything, it’s easy to take for granted but difficult to craft. Down the road, quality code can save a company hundreds of hours in engineering time and push a product to market at greater speed or cripple you to standstill and bankruptcy.

“mediocre engineers do not build great companies” - Sam Altman

After working in Angular for a few release cycles I was finding that the challenges I was solving were becoming easier with each new feature I created. I had been working day in and day out in the same framework and the same codebase and was starting to complete projects ahead of schedule. I reached a point where if I saw some design mocks for a new feature I would be able to have a pretty good understanding of how I would build it and how it would fit in the architecture. Building new standalone features became easy, building components inside of existing modules was more difficult and required a more surgical approach.

During the past few months I’ve spent a good amount of time thinking about a concept that was first introduced to me at Hack Reactor, the boy scout principal. It states, "Always leave the campground cleaner than you found it." Working within a codebase that has been built over several years by a number of different engineers with different design philosophies is much easier said than done. I found that consistently following this principle has provided much more meaning to my everyday work. Not only am I delivering a beautiful UI that our users will love, but behind the scenes I am crafting an easy to use API that will make the work of future engineers that much easier and more enjoyable.

I love taking on projects that are deeply nested inside of our application. I begin by drawing out the current architecture and the flow of data from one component to another. I won’t be able to leave the campground in a better state if I don’t understand the purpose of the module and how it works. Good variable naming convention is at the core of quality code, you can have the most efficient solution in the world but that means little if it’s difficult to read.

After I have a good picture of how the module functions, I begin stripping it down to its bare essentials. Removing old code and refactoring items to individual self-contained components has become my new favorite past time. There’s nothing like taking a 500 line controller, stripping it down to 200 lines and splitting everything else into compartmentalized directives.

In the past, I was too novice to fully appreciate the concept of the boy scout principal. I was overly concerned with making a feature work as opposed to maintaining a clean codebase. These days it’s much different. Upon completing a feature I always ask myself, “Does every variable make sense in plain english and did I leave this component in a better state than when I started?“ If the answer to any of these questions is no, then I must go back and address these issues before submitting my pull request.

Following this principle isn’t the easiest task nor is it the most mentally exciting task, but it forces you to understand the significance of each individual line. There’s a time and a place to think of big picture engineering challenges but that time is actually occurs outside of coding. These past few months I’ve personally challenged myself to make sure that each component I touch has an API that is simple to use and understand. This requires additional research into common Javascript design patterns and recognizing where they're applicable. At the end of a release I feel like a writer that has read and reread each line of their essay, marking up draft after draft until they finally find that perfect combination of words that will they can share with others.

bleak theme by Jack Preston