A friend of mine recently gave me a book called [The Good Enough Job](https://www.amazon.com/Good-Enough-Job-Reclaiming-Life/dp/059353896X) by Simone Stolzoff. It has made reevaluate my relationship with work and I want to document the various things that it's made me realize.

## 1. Your work identity need not be your only identity

Our sense of self-worth comes from a range of different places: the places we go, the things we own, the people we know, the services we provide, and yes, the work we do. Through each of these, we build a sense of identity that contributes to defining us.

The energy and time we give to each of these identities help strengthen them. The more you donate or volunteer, the more you strengthen your philanthropic identity. The more you write, the more you strengthen your writer identity. The more time you spend with your kids, the more you strengthen your parental identity.

The corollary to this is that *without* energy given, we actually weaken those identities. 

We spend at least 8 hours a day at work, so our work identity is typically pretty strong just due to the sheer amount of time we dedicate to it. This is normal—we need to work to sustain our lives. The problem is that work in today's world continuously threatens to encroach on all of our "extra" time. This time, which we would otherwise spend doing other activities and building bonds, is now used to further reinforce our already-strong work identity. As a result, it actively weakens those other senses of being that we thought were important to us.

## 2. We care about our work a lot more than it cares about us

With the recent wave of layoffs in the tech industry, it has never been clearer that in this capitalistic society, our value to a company is only as good as the work we continuously produce.

It makes logical sense—companies are incentivized to make a profit, and that profit is generally correlated to the work that employees produce.

If the reality were as cut and dry as that statement, it might be justifiable to sacrifice time outside of work hours. But the truth is often far more complicated. People who work hard and give their teams and companies everything are let go as collateral damage during layoffs.

Our job treats our professional output as the primary (and often the only) way to define us. But the other dimensions of our being are truly appreciated only by our family and friends. And yet, we find it easy to sacrifice far more of our time with them than with our job. The book includes this quote that resonated with me:

> *“Too many people bring the best of themselves to work, and bring the leftovers home*.” - Esther Perel 

## 3. Finding the "perfect" job is a myth

Growing up, the message of finding your dream job was deeply instilled in us. A job is not just a job but a calling, and to be satisfied with anything less is unacceptable.

This mentality causes us to constantly reevaluate our jobs and incentivizes us to change jobs as soon as the realities of day-to-day work don't match our expectations. It keeps us in a constant state of dissatisfaction because our jobs are supposed to be perfect, and any deviation from that leaves in a state of disappointment.

The book argues that all jobs have their ebbs and flows. If we tie such high expectations to work, we forever put ourselves in a state of dissatisfaction. On the other hand, if we don't attach such high expectations to our work and treat it as just one aspect of our lives—where other facets help regulate our happiness when work gets overwhelming—we can build a healthier and longer-lasting relationship with it (in addition to the other places where we choose to diversify our joy).

## 4. Diversifying your identity and happiness takes a lot of work

This crisis of our identity being so deeply tied to work takes significant effort to untangle and unlearn. It's extremely easy to use our evenings to catch up on work that couldn't be done during the day. It's also easy to get drawn into using our extra time to make progress on less important work that doesn't get prioritized during the day.

But as mentioned above, the time our work encroaches on these hours is akin to death by a thousand paper cuts. Before we know it, we're less present during those few times when we're trying to invest in our other identities. It's easy for years to pass by without doing an honest check-in with ourselves about our relationship with work.

I've been actively trying to do something else in my evenings to diversify my time and attention. Even if I could just review a PR or start on a doc I've been meaning to write, I now actively avoid it to advance in other areas of my life. And realistically, on days when I do need to do some work, I've been thinking of ways the work would be transferable beyond just work. For example: Could I write a blog post about it? Will this task help me start a new personal project I want to pursue? My litmus test is "Is this helping me put some extra coins in a different identity than just work?"

## Conclusion

This book has been an excellent guide in helping me reconsider my relationship with work. It has forced me to be more intentional about how I spend my extra time during evenings or weekends, and to intentionally disconnect from work during those times. This has actually resulted in me being happier both at work and outside of work. Because all my expectations of being fulfilled aren't coming from just one place, but are distributed among the various parts of my life.

The Good Enough Job

I recently gave a talk at work about realistic and practical use of AI as a software engineer. There is an incredible push from leaders in tech companies to drive up AI usage in an attempt to increase productivity from their engineers (atleast that's the stated reason). But reality often doesn't match expectations. In this post, I'm going to discuss the various pitfalls we fall into while comparing the ease of building software in a vibe-coded codebase vs. a large codebase.

## Why vibe coding skews expectations

The vast majority of hype built around AI comes from this growing trend of quickly vibe-coded projects that showcase how a complex idea could be implemented quickly in a small teams (often just individuals). From building sexy landing pages, to Slack clones, it is easy to believe that using AI enables us to build large complex pieces of software quickly and *correctly*. Additionally, CEOs regularly stating that a large percentage of code in their companies are now written by AI adds to this belief.

However, most experienced software engineers know that that isn't actually the case. Our day-to-day tasks are not just about producing code, but even just the writing code pieces haven't become *that* much better. Why is that?

### You need to understand the code you write

When vibe coding a little app, you mainly care about the final product, not any of the implementation details. As long as the end-user experience looks right, that's all that matters. So it's easy to feel satisfied that after a few turns of going back and forth with your favorite Vibe Coding app, it produces a beautiful looking app that you can show off.

But in production engineering, the engineers need to actually understand the code that's written.

This means understanding how the code behaves beyond just the golden paths. When writing code, you are actually making many micro-decisions which lead to you being confident that the code behaves a certain way, not just for golden paths, but also for edge cases. When an LLM is predicting tokens, it's simply doing what's common in its training set, which may often work, but may not.

Speaking of predicting tokens, the training that was involved in the LLMs training set could be out of date by the time you are exercising that particular path.

Mini anecdote: My team has been involved in building the v2 of [Teams SDK](https://microsoft.github.io/teams-sdk/welcome/). I spent some time building llmtxt for this next version to help folks use coding agents to quickly build apps using it. But testing it was fairly difficult because the various agents I used insisted on using the v1 paradigms that are well established. It's just really difficult to go against the LLMs training data.

Anyway, the problem is that, if you are not involved in those decision making processes, it's as if someone else wrote that code. And during a production issue, you are on the hook to know what *your* code did, and why. It is your responsibility.

### You need to write *good* code

Software Engineers get paid to write and build software that is well architected, extendible, scalable. This skill takes years to learn and master. Writing code isn't hard. But writing *good code* is hard.

Vibe coded projects do not focus on any of this. They focus on a good demo, and end-functionality for that demo. Without thinking through the code that's been written at somewhat an intimate level, we leave the "architecting" to the coding agent. And if we rely on it too much, we risk falling into the trap of feeling like we have written good code, when really we have just written code that happens to work.

Additionally, LLMs were trained on open-sourced code that was freely available on the internet. And anyone can push up code to Github. Heck, I post a dozen repositories every year (at least), and I would be extremely reluctant to have any of that code run in production. If we extrapolate this, we can generalize and say that the vast majority of the code written by an LLM is probably mediocre. Without us being deeply involved in the decisions that it's making, it opens our applications to be built on similarly mediocre code.

### Large code bases are a different beast

Each software project carries a number of features that it supports. Vibe coded projects are generally well scoped, built with some end-goal in mind. They contain some few numbers of features.

Large codebases are generally a different beast. They are built over a longer period of time with hundreds (and often thousands) of features. As software engineers, it is our job to demystify and build complex mental models around these codebases, so we know the best way to approach adding or improving features. The complexity of the mental models is generally correlated to the size of the project.

LLMs are constrained to the size of their context windows, and their "mental" models are limited to whatever is in their context windows. You could make the argument that LLM context window sizes are expanding, so it's easier to put more and more concepts in there.

The problems is that to take a complex piece of software and articulate the exact design structure for the whole thing is not a trivial matter. Agentic software these days suggests things like .md files that get injected into the agent's working memory to help it regain this context whenever it's working on anything. But now you need to articulate the design in this file (using an LLM, sure, but you need to verify that that design is accurate). And you need to continuously maintain this high-level document as well.

## So what's next?

This post mainly attempts to highlight that the AI hype that our industry is facing right now does not translate as fluidly to large-scale engineer projects that most engineers typically work on. But, I am not delusional. I know that AI tools are here to stay and can definitely help us be more efficient at our jobs. In the next post, I'm going to document the various strategies I use to actually help me in my day-to-day to help me be more efficient at building software.

aamir j.