Four Things I've Changed My Mind About in Engineering

I think a mark of a great engineer is being willing to change one’s mind when presented with new information. Here are four technological things I’ve changed my mind about.

Own Your Confusing Software

Before: “If a customer thinks software is confusing, they might just need training.”

Today: “If a customer thinks your software is confusing, it is confusing.”

When building a SaaS product, it’s easy to write off difficult or noisy customers. Especially if that’s part of a team’s culture.

A more profitable approach is to own that your software is confusing. People don’t want to contact support. They are speaking for many. You don’t have to act on their feedback, but you’d be wise to consider it.

This change of mind was less about any particular customer, and more about ownership. It was influenced by being in this industry for a while as a SaaS producer and consumer: it’s no fun to raise a good bug report and be dismissed. Be that person who listens.

Write Boring Code

Before: “Code is art, and it can be flashy and clever.”

Today: “Write boring code.”

Write boring code. I’ll use an example from my own coding practice. Let’s say that I have a truthy or falsy value in JavaScript and I need to coerce it to a boolean. I’ve written something like this a lot of times:

> const value = null
> Boolean(value)
< false

This function returns a coerced boolean. I think that it’s cool.

The much more common way of doing this is to use !!.

> const value = null
> !!value
< false

The weakness of my pet technique is that nobody I’ve met knows about it. Some people hate it, some love it, nobody emulates it, and I’ve never seen it in someone else’s code. Is it more readable? That’s debatable. Is it less common, and less understood, on every team I’ve been on? Absolutely.

The “Zen of Python” is a useful measuring stick for code quality, and I’m violating several tenets of it here:

  • Explicit is better than implicit.
  • Simple is better than complex.
  • There should be one– and preferably only one –obvious way to do it.
  • If the implementation is hard to explain, it’s a bad idea.

Stuff like Boolean is magic. It’s fun to learn and teach. But for production code, leave it out and be boring.

Build Server-Side Tables

Before: “Client-side tables are a fine starting point.”

Today: “You almost always end up needing server-rendered, paginated tables, so it’s smart to build them from the start.”

YAGNI (You Aren’t Going to Need It) is considered a watchword in our field. Perhaps client-side tables, and the searching, sorting, and filtering they lead to, are good enough? Maybe their limitations are theoretical, and you’ll never hit them. And if you do, it’s a Champagne Problem™.

Over time, I’ve come to believe that tables in a web application are one of the rare YAGNI exceptions. Tables that fetch data and search, sort, and filter on the client-side work fine, until you hit a medium-sized number of records, then they start to get slow. Add in real-time serialization of the records, polling or websockets, multiple tables on the page. Everything is slow and crashing.

Rewriting all of your features on the server-side is painful. As a frontend-focused engineer this is tough to admit, because I still think that the browser can do almost anything. Can you ever do client-side? Hobby app, demo app, sure. But a production application, with aspirations of scale? Do it server-side.

Learn To Design

Before: “Developers don’t need to know design; it’s a designer’s job.”

Today: “Developers need to know some design.”

In my experience, developers do not like to do visual design! We present ugly, brutalist user interfaces like a badge of honor. I’ve heard a variety of reasons why:

  • “I don’t know how to design.” True— and fixable.
  • “I’ll never be as good as a great designer.” True— but what if you could be okay at it?
  • “Designing is the designer’s job.” But what if you don’t have a designer?

Becoming okay at UI/UX design is one of the most powerful things I’ve accomplished as an engineer. Over the course of a few years, I did a daily design challenge, read a few design systems’ documentation, and learned the basics of accessibility.

I’ll never be as good as the great designers I’ve worked with. But, I can work without one, and if I have one, I don’t need their input for every single design choice. And I can iterate on a sub-par design. I move faster. It’s empowering.

As you rise in technology, you start mingling with less and less technical people, and Joel Spolsky’s Iceberg Secret becomes a truth. If your proposed feature looks bad, your CEO is going to think that it will be bad, and that you are bad at technology. “I know this looks terrible” does not fly above certain altitudes.

Conclusion

That’s four things I’ve changed my mind about. There are many more! What have you changed your mind about in technology?