Why We Work Matters

Have you ever worked on a project that you were passionate about? I'm fortunate in that I get to all the time. It makes a difference in how I approach the work. When I'm passionate about a problem, I want to solve it, and I want to do it well. The opposite is generally true too. If we are impassionate about a task or a problem, we may try to get the job done hastily so we can get back to the things that we enjoy working on.

What are some things you loathe doing? Writing documents? Working in a legacy code base? UI/UX?

If we are impassionate about a task or a problem, we may try to get the job done hastily so we can get back to the things that we enjoy working on.

I hate that we do that. So I sat down and thought about our passionless haste as a problem to be solved. This is what I found.

We don't understand Why We Work.

Why are you a software engineer? Yea, it's fun, it's interesting, and it can pay pretty well. But that's not where I'm going. We're hired for the way our brains work. We're quite adept at looking at something, understanding it, and offering solutions. We are hired to solve user problems. We're also hired to make systems that can scale, are resilient to the future, and have a low lift for others to enter and work on after we've moved on to other projects.

We are hired to solve user problems.

Most of us are passionate about that part. We like to know that we're contributing to something greater. But who are our users? That seems obvious... The people who use the applications we write, our "end users". Well, yes. That is true. Although that's an incomplete answer. What about our application's data, who uses that? What about the documents that you write? Or the internal API you're working on? What about the code base in general? Who are the users of your output?

Who are the users of your output?

That question changed the way I work. All of the code I write is not just for an end user. It's for the business and the new hires that we will make at a later date. It's for a future me, and those like me, who will maintain it. The same applies for the documentation that I write. The context a document can provide to future teams will help them steward the project. It doesn't immediately impact the end user, but the way we handle the mundane tasks will have a great impact on those users in the future.

Your users are many

I realized that we solve problems for more than the end user alone. We solve problems for our stakeholders, our data analysts, our project managers, our business units, our teammates, and even the people whom we've yet to hire.

I thought about my output, how it would be consumed, and the impact my work would have on the future. I didn't like the forecast. So I changed it. I decided that I work to serve others, not for the paycheck. I take "little things" quite seriously now. The impact has been significant.

All aspects of the craft are impacted by this decision. It's made me more serious about pure functions, explicit naming, making impossible state impossible, the Single Responsibility Principle, testing and so much more. Even documentation, which I used to dread, has become a thing I enjoy and take seriously.

I find myself asking, who will be a "user" of my output when I pull a ticket now. That habit lead me to perform a user interview with one of our data engineers recently, the result of which is now going to change the structure of our logs as a whole.

When I write a document, I ask similar questions. Who is my audience, what is the purpose, how does it serve?

"I decided that I work to serve others"

Why do you work?