Mental Hygiene for Software Engineers: Avoiding Micro Level Technical Debt

The essence of software engineering, in my opinion, can be captured in two words: managing complexity.   Perhaps it's not the same for others, but, for me, the most critical aspect of my job as a software engineer is to manage complexity.  Software is complex.  Far too complex for the all too human brain.  The human brain is not only limited by finite resources but it is subject to a variety of error prone behaviors that, while making us warmly human, are not necessarily a good fit for applications high levels of complexity and requirements for mathematical accuracy.  But this is old news, and the raison d'etre for software engineering as a field.

The essence of software engineering, in my opinion, can be captured in two words: managing complexity. 

But the focus of sofware engineering is on the code level and above.  Software design patterns, test driven methodologies, refactoring tactics, UML . . . these are all great tools that help achieve a cleaner, less complex software artifact.  But what about the lower level stuff?  No body looks much lower than the code, but the "physical" layer, if you will, consists of an individual engineer's minute to minute confrontation and resolution of tasks.  

Let's call this the micro level of software engineering.  Just like we should strive for clean code, we should also pay attention to these lower level tasks.  Most of the activity at this level is the personal domain of the individual engineer.  It's the stuff of how you apply your mental powers to the tasks at hand.  Instead of clean code, perhaps the goal at this level is clean mental processes.  Instead of hunting down code smells, we'll search for smells coming from our mental processes.  If we expect our code to be clean, we should start with our own mental hygiene.  

My assertion is that there are patterns and anti-patterns at the level of an individiual engineer's minute by minute processes that have impacts parallel to those on the code level.  Just as unclean, untested code can create a large technical debt that drags down efforts to maintain, modify and enhance the software, unclean workaday habits can lead to micro level technical debt that drags down the cognitive ability of the individual engineer.  Sure, we're all smart, but can any of us afford to be cavalier with the management of our mental capacities?  

Instead of hunting down code smells, we'll search for smells coming from our mental processes.  If we expect our code to be clean, we should start with our own mental hygiene.  

Let's consider a possible micro level anti-pattern: the micro level work around.  One of the most detrimental mental idiosyncrasies of software engineers is the pathological use of workarounds to avoid the micro level barriers that arise constantly during the work day.  I used to teach English and I like to draw a parallel to the habits of poor readers.  Many students, particularly those who struggle with reading comprehension to some degree, demonstrate several micro level reading behaviors that pretty much guarantee their failure.  One of the most glaring misteps is that poor readers often skip past words they don't understand.  They do this so much that it becomes a habitual, unconsious practice.  

The obvious best practice is to consult a dictionary.  But that takes time.  And it's only one word, out of pages of text, and who knows where the dictionary is anyway.  To the harried student, it seems that it would be impossible to complete the reading if one stopped to look up every new word.  But this just doesn't work.  Good reading takes advantage of the strong foundation of meaning given by previous sentences and paragraphs.  This semantic context is critical for comprehension of the sentences and paragraphs that follow.  If the reader has built a strong foundation from the preceding text, the meaning of an isolated unknown word might be easily guessed.  But, in truth, there will typically be another word and then another, and then another, and . . . soon, this literatary debt builds up, eroding the reader's comprehension further and further, leaving little context upon which to interpret even the sentences made of words the reader actually knows.

Just as unclean, untested code can create technical debt . . . the unclean workaday habits can lead to micro level technical debt that drags down the cognitive ability of the individual engineer.

This applies to the daily chores of a software engineering as well.  There's always something that isn't quite right, that you don't have the time to take care of correctly.  Perhaps it's the clumsy use of an ill-understood command.  Perhaps it's unwieldy permissions on a crucial set folders and files.  Perhaps it's a command that you type out many times a day rather than creating an alias.  Perhaps it's all of those crufty warnings in your build or in your application's logs.  These micro level barriers have many forms and arise constantly.  If left unattended, they quickly build up into your own personal technical debt.           

Let's consider a specific example.  I've watched more than one developer memorize phone directory amounts of raw IP numbers.  Sit and watch them work and you'll see them repeatedly type IP numbers as they ssh to a remote host, enter server addresses in browsers, connect to fileshares, anywhere and everywhere.  As amazing as this feat of memory is, you have to wonder what the cost is.  There's no getting around the fact that by memorizing these numbers you have not managed the complexity, you've beaten it back with brute force.  You've decided to allocate a portion of your mental capacity to a task that you could have solved more elegantly.

Worse yet, the whole effort that you've put into the brute force management of those IP numbers has ZERO re-use value.  It's a one off, developer specific throwaway.  Can a new developer to your team leverage your efforts?  No.  Do you personally even gain anything from the efforts?  Is there an item in your backlog that requires all developers to memorize the IP's of all developer environment servers?  By memorizing those four octets, you haven't reduced complexity of the raw IP's one bit. 

Just to state the obvious, the whole reason we strive to reduce the complexity of software is because, if unchecked, that complexity will consume 100% of our individual mental resources.  My assertion is that the same thing can happen to you from micro level technical debt.  I challenge you to confront each and every barrier that arises and defeat it.  Map those IP's to meaningful host names.  Create aliases for those commands that you constantly retype.  Declare a 30 minute moratorium on IM'ing!  Just clean up your mind!

I imagine the true blue multi-taskers are going to scoff.  For me personally, this is an essential part of being both a happy and a first rate engineer.  If you find it interesting, and wondering how to get started, I highly recommend checking out the pomodoro technique.  It's a systematic approach to the application of your mental powers.