The Value of Readable Code

Early in my career, a manager told me something that went against everything I had learned in college.

When I started working at Electronic Data Systems (EDS) in the early 1990s, one of my managers made a statement that shocked me:

"I don't care if the code is the most efficient. Storage space is cheap. I'd rather have code that's readable than code with the most efficient structure."

Wait a minute. What?

In college, we were taught to write the least amount of code possible and make it run as efficiently as possible, even if that made it harder to understand.

Now my manager was telling me that readability mattered more than efficiency? Then he introduced another concept:

Make sure your code is self-documenting.

His reasoning was simple. Another programmer should be able to pick up my code, understand what it was doing, and maintain it without spending days trying to figure it out. And with the amount of turnover on our team, that actually made a lot of sense.

I was beginning to see two different perspectives:

The programmer's perspective: Write efficient, optimized code.

The manager's perspective: Write understandable, maintainable code that someone else can support.

Over time, I learned that these two approaches don't have to be mutually exclusive.

I eventually found a balance between them, and that lesson has influenced how I approach software development and leadership ever since.

On Thursday, I'll share how I learned to balance efficiency with maintainability.