Keyboard keys in a pile

Tabs ARE Better Than Spaces?

For a few years, I’ve been working with a team that prefers spaces to tabs. More specifically, 2 spaces. I agree that this is a superior visual arrangement and having everyone use it benefits those of us who prefer it, those who don’t care, and will eventually bring those who don’t like it to see the light. Today, however, for reasons that will be more obvious in future posts, it occurred to me that tabs may actually be superior.

This revelation requires first admitting that this is a preference. You may code on a 32” curved 16:9 or a 20” 4:3 rotated to 3:4 portrait. You could be writing code on a flip phone for all I know. Whether you use tabs or spaces, the desired effect is the same: to provide consistent formatting to make the code easier for you to read.

This leads me to my argument for tabs: Tabs are the democratic choice. Tabs put the details of the implementation in th hands of the consumer. Most modern IDEs allow you to customize your tabs. Want tabs to be 7 spaces? Let your crazy-big-odd-numbered-tab freak flag fly! It’s much easier to customize tabs or replace them with spaces than to replace spaces with tabs. So I’m sure this debate will rage on and I will happily continue to use spaces for my code, but for you, my friend, I will give you tabs.

Tutorials Are (Often) Bad

Yes, that is a broad generalization. Yes, broad generalizations are (often) bad. Yes, I see the irony in that. However, tutorials are often bad. The good news is, this is often by design. Tutorials are intended to show you how to do something very specific. This means most basic tutorials are intended to show you how to do that specific thing as succinctly as possible. The problem (or potential problem) with this is that good code is often not particularly succinct. As I mentioned in my previous post, “optimal” code isn’t easy to design and what is “optimal” for one scenario might not be fore another. So in this post, I’m going to explore some concepts that are (often) good. Since they are often not followed in tutorials, it stands to reason that tutorials are (often) bad.


woman drying hair too vigurously

OK, not that kind of DRY. DRY means “Don’t Repeat Yourself”. Tutorials typically keep code in as few places as possible to make it easy to follow the examples. DRY code requires separation of concerns. This means putting your code in the “right” place which means you have to have multiple places to put it. Chances are you need a more complex project/file structure than what a tutorial will show you.


test test test test test test

Unless a tutorial is demonstrating some aspect of testing, it most likely doesn’t include any tests. Because of this, the code won’t necessarily be very testable. Making your code testable requires a certain degree of DRYness since you typically want to test small units of code (“unit tests”). Most modern frameworks support features like dependency injection to improve testability, but these features are often absent from tutorials, so beware of tutorials without any tests.



Testability and maintainability go hand in hand. Maintainability is definitely an art and beauty is in the eye of the beholder when it comes to what “easy to read” code looks like, but there are some good rules of thumb:

  1. Keep functions short enough to read on the screen.
  2. Use descriptive names for functions that follow the law of least astonishment
  3. Avoid unnecessarily concise notations
  4. Use consistent formatting and spacing

Tutorials probably follow number 4, might follow number 3, and very often ignore 1 and 2.

Putting it All Together

The code in tutorials is not typically well structured. Good structure means your code is DRY, testable, and easy to maintain. When following tutorials, look for opportunities to improve the structure. Develop your own toolbox of reusable code and components. You will quickly find that all projects benefit from having at least 3 components: a “core” set of code not tied to a specific implementation, at least one specific implementation, and tests. Nothing is one-size-fits-all so no one template will match every project, but it’s good to have a general approach that prepares you to write “good” code.

brain art science

The Science and Art of Code Structure

Clearly, I should have been in game development. I’ve been coding since the third grade so software was always in the cards for me. I have a degree in Mechanical Engineering so I have the physics chops to handle pretty much any kind of real-world simulation from projectile motion and particle physics to fluid dynamics and even heat transfer. My masters degree is in Industrial Engineering so I know about things like optimization and simulation that are helpful for AI (among other things). And games are fun!

What I realized recently, is that writing “good” code is an Industrial Engineering optimization problem. You see, optimization problems deal with multiple dimensions with often multiple optimal solutions. Note the use of the word “optimal” and not “best”. Optimization problems often have multiple variables and an astronomical number of potential solutions. So when you are optimizing code, what is your goal? Maximize speed of execution? Minimize size of compiled code? Minimize bandwidth used? Minimize processing power used? Minimize total operating cost? Maximize test code coverage? Why not all of them? Well…I’ll tell you why.

One of the most famous examples of an optimization problem and how mind-bogglingly many solutions they could have is the “traveling salesman problem“. The traveling salesman must visit some number of potential clients and then return home. In the simplest version, he is flying from city to city and the only concern is the order of the flights to the various airports. A much more practical and complex version is a package delivery company with a fleet of trucks needing to deliver packages over routes through a complex network of highways and city streets with variable traffic, one way streets, traffic lights, etc. Every variable multiplies the number of solutions by the number of possible options for that variable.
The number of possible solutions very quickly gets large – like more than the total number of atoms in the known universe large. What hope do we have of solving these problems? Luckily, we have pretty cool brains.

Malcolm Gladwell wrote a book titled Blink: The Power of Thinking Without Thinking. It’s a great book and I highly recommend reading it, but the gist is our brains are able to take in a vast array of information and come to a conclusion (an “optimal solution”) without consciously thinking about it. This ability to organically problem solve was also recently discovered in single cell organisms. This is why we are pretty good at coming up with decent solutions to these problems without knowing anything about linear algebra. Our brain operates on “heuristics” that our life experiences have allowed our brains accept without having to think about them. In the world of software development, the use of these heuristics are the “art” and allow us to optimize variables that are extremely more challenging and seemingly abstract such as “maximize code reuse” and “maximize maintainability” and, as I like to say, “minimize astonishment“.

Another important consideration in optimization is boundaries. For example, you may be able to purchase a certain amount of computing resources for a certain cost. Additional resources add more cost. This means that you don’t necessarily need to use an absolute minimum number of resources, you just need to make sure that the amount of resources used doesn’t trip the threshold or that if it does, you have a source of revenue to cover the added cost.

In future posts, I will dive into more detail on the day-to-day practical advise on optimizing your code, but first I wanted to take some time to lay some groundwork. In the early days of computers, you were greatly constrained by memory and processing power. You had a limited number of pixels that could be rendered on the screen in a limited number of colors. You could only store so many bytes of code. You were limited to a small number of operations the processor performed. You were limited in the language you could code in and the structure of that language. The optimization required was much more science with a small number of options for each variable. Now, the options are astronomical. What language do you use? What platforms or devices run that code? What communication channels does it leverage? How many millions of colors and pixels does it render? Sure, it is still important to minimize operating cost (storage, CPU cycles, bandwidth, etc.), but you can also get access to a significant amount of resources for little or no cost. This allows you to focus on the art – maintainability and reuse – first, and then solve the challenging scientific problems later (or not at all).

teacher and student

Eminence Imminent

After spending nearly 20 years working for a defense contractor, I joined Deloitte to focus more on software and to build that software for clients outside of the defense business. I’ve been with Deloitte for a few years now and I’m starting to take a more active role in Systems Design and Engineering leadership. This means helping with activities to establish “eminence” of our practitioners. For me, that means being more active in those activities myself…practicing what I preach…eating my own dog food…I think you get the point.

I’ve consolidated some of my old blogs here. It’s been a long time since I’ve posted anything technical, so most of that stuff did not survive the move here. However, I have some nerdy things in the works and a few decades of…wisdom? share. I’m looking forward to unleashing the avalanche of blog posts swirling in my head.

I’m trying to run a little more often (ok, a LOT more often) so I’ll be posting about that too. Beware, I am a running nerd so expect plenty of over-analysis while I try to regain or even surpass my fitness level of years gone by.

So for those of you who have stumbled onto my little corner of the internet, I welcome you and hope you find some knowledge, inspiration, or at least some entertainment.