July 25, 2020
It's Supposed to be Difficult

We choose to go to the moon in this decade and do the other things, not because they are easy, but because they are hard...

John F. Kennedy Moon Speech - Rice Stadium, September 12, 1962

Pretty bold statement, starting off with a quote about going to the moon when my intention is to write about the challenge of software engineering. Let's call it a moonshot.

In my current role, I get to work with a lot of engineers, all of whom are at different levels of experience (present company included, of course). I get to talk through interesting new problems and solution to those problems, and sometimes help people learn new things along the way. When we talk about solutions, generally, we're faced with a decision that boils down to one of the following: do something easier that makes using the sysm harder, or do something more complicated that makes using our system easier.

I suppose that's paradoxical, but isn't most of how we approach computing? I mean, the things humans thing are easy tend to be easy for a computer, and vice versa. A digression saved for another time.

In all of those conversations, and most of the ones I have at work, I push for the "rightest" decsision we can make, and that tends to be harder for the engineers and easier for the users. So far, I've managed to bring folks along on that journey, which makes me happy. Here's why that matters to me.

Every line of code we write and instruction we give to the computer is for the benefit of a user. For passion projects, that's a future version of you. In my specific example, that tends to be human beings holding mobile devices in Target stores. But we're always writing code for someone else to consume, and we owe it to them to make their experience better at the pain of our own, because we're doing the work for them.

For all the code I've written, this has been true without exception. When I was working on SDKs in a previous role, my users were quite literally paying for the code, so it was obvious that the right thing to do was make their experience as easy and painless as we could. That situation had the added pain of usually working with engineers who were using our product because of decisions they had no control over, so not only were we fighting complexity, we were fighting some slight resentment.

Even when writing internal-facing code for a large company meant for internal consumption, this applies, maybe moreso even. The shape and requirements of an API, configuration options and settings in a required YAML file, everything we choose to expose is consumed bu someone. There's the implicit agreement that a large company is generally on the same in team in that we share the same goals, but that doesn't mean we can't still be excellent providers of services to our coworkers.

Consider also code only shared by a single team. There are ways to do this there, and things to consider here as well. Commenting code, good PR descriptions, clean code are all gifts to your team and your future self. They take more effort now, but you'll appreciate it in the long run. I'm infamous for my comments at work, primarily stemming from the fact that I lose context so quickly that I'd be lost without notes to my future self - which, coincidentally, is usually to whom my comments are addressed.

Maybe this whole thing makes sense and could have gone without saying, but I think it warrants saying it anyway. Take a look at your code and how it presents to your users. Could it be better? Could you do something different, not because it is easy, but because it's hard?


June 11, 2020
The Next eddieroger.com