Abstract

What would it look like to be a good software engineer? Would it mean that you are able to solve complex problems with proven solutions? Or would it mean that you can provide novel and creative ways to solve hard problems? The introduction of AI tooling into a developer's workflow promises gains in productivity. But what does that mean? More code? Better Code? Less toil? More time?

Some executives bullish on this technology claim that AI assistants will eventually shorten workers' work weeks. However, the likeliest scenario is not a shorter work week, but increased demands within the same time constraints.

How do we become better engineers within the current climate of overhyped AI technologies?

Notes

Something I've been thinking about lately is what it takes to be a good software engineer. You see, I had the great fortune of changing careers nearly two years ago into software development.

Seems like my timing was impeccable, because this industry seems to be doing just great!

What I'm saying is, I'm a bit of a novice, so I often deal with insecurity.

That's not necessarily a bad thing. Sometimes it me leads into technical areas that I am unfamiliar with. As a result, I end up going on a learning adventure, which can be quite rewarding.

Other times, it leads me into psychological or philosophical angst. As a result, I end up submitting a proposal to some conference in order to work it all out.

That can be rewarding too!

So yes, I've been wondering about what it takes to be a good software developer.

More. Better.

So what does it mean?

That might depend on who you ask...

Let's look at a recent job posting to see what potential employers might be looking for...

https://www.reddit.com/r/recruitinghell/comments/18n7efb/required_absolute_obsession_with_working_16hour/

Here's an example of a listing seeking a candidate who has an obsession with working 16-hour days.

Some other choice attributes, a "life longer learner" (as long as the learning is not grammar), a belief in denting the universe (watch out universe!), ... and perhaps my favorite, "believe in most the best the universe has to offer"... okay, maybe we should put grammar back on the table.

There all sorts of examples like this, not all of them quite as ridiculous, but often times very much unrealistic.

The takeaway? A "good software engineer" is not something that is clearly defined or even agreed upon throughout the industry.

Now, I know that tackling this particular issue is quite broad. I'm not going to pretend to have the ability or knowledge to provide you with an exhaustive examination on this topic...

So what can I provide?

On an esoteric level, I'll use a couple of metaphors to stimulate our thinking, knowing full well that metaphors often fall short. I'm not using them to "prove" anything, but you can think of them as half-formed parables that you can take for yourself and deconstruct as needed.

More tangibly, I do want to have something to anchor to. That way if someone asks you what this post is about, you're not left with a blank stare on your face trying to recall if it's about running, or cooking, or worse yet, artificial intelligence.

Tangible Parts

So, let's actually start with that tangible part.

Here is a somewhat arbitrary list of attributes that I believe apply to the conversation of what it takes to be a good software engineer.

• Experience
• Communication
• Attention to detail
• Accountability

But before diving in...

Why am I tackling the topic?

Along with personal angst, I have had conversations with other engineers and tracked discussions online.

This question predates the introduction of LLM tooling, but in this environment, the expectations of engineers, managers, and executives seem to be at odds.

Does being a better software engineer mean you are more productive? There seems to be a link...

If a developer codes in a forest, but nothing is there to ship, does the code even run?

If I'm unable to produce anything, am I good engineer? Does faster mean better? Does better mean faster?

Should I focus on any particular metric? Code quality? Maintainability? Elegance? Performance? Architectural decisions? Debugging? Decision making Etc...

Am I overthinking it? (Probably...)

Motivators

Before diving into my first metaphor, I want to write about motivators.

In your desire to be a good software engineer, you will have to balance the dichotomy of internal motivation versus external expectations.

An internal motivation might be linked to whatever it is that drew you into tech to begin with. Maybe it was fun. You liked the challenge or were curious. You found a community of like-minded weirdos.

The external expectations are placed upon you, such as your work obligations. Hoping to advance your career, you try to fulfill KPI metrics, assess yourself through annual reviews, try to meet deadlines or hit daily active user targets...

In the best of times, these two can overlap. Some of the things you find personally satisfying, you can bring to your job.

In the worst of times, they are mutually exclusive. You drudge along without any sense of personal satisfaction.

In the internal world, usually your measure of success is intrinsic.

You might like working on several projects at once, or iterating quickly with as many features as you can think of. Or, you may enjoy crafting, reworking, and refactoring. The joy is in the refining.

Neither scenario is wrong.

But if you're employed as a software engineer, these intrinsic measures of success may be at odds with business goals.

Maybe you like producing and completing projects, but at work you're tasked with maintaining an old, monolithic codebase. You're putting out fires instead of building features.

Or perhaps you're at a startup that's shipping microservices, constantly pivoting on a whim—whereas you'd rather spend your time polishing, writing documentation, and focusing on user accessibility.

How can you measure success in this environment? I may come back to that later...

Nonetheless—I am hopeful that the list I started with provides a helpful framing, regardless of your core motivators.

Metaphor: Running

Okay, time for a metaphor.

Nearly 2 years ago, I tore the ACL on my right knee while playing soccer. Yes, it hurt. No, I didn't do the surgery. Two different physical therapists affirmed that, through proper discipline, I could likely regain most of my mobility.

Over the last year, I've been pretty comfortable on long walks and moderate hikes without any issues, but it wasn't until February this year that I decided to start running.

Look, I generally dislike running. It seems so annoying and aimless, unless someone throws a soccer ball in front of me to distract me... I just lose interest.

Running suuuuucks...

And when you're way out of shape, there's no real shortcut. You just have to start somewhere. Forget any aspirations of distance or speed.

Now, luckily for me, I have a neighbor who asked if I wanted to start running with him, and thankfully that was the motivation I needed.

In addition, the city of Redlands (where I live) hosts an annual event called the Run Through Redlands, which was held on March 1st. I signed up for the 5k as an additional incentive.

The first few runs were rough. But really, the hardest part was just getting in the habit of running a few times a week, even when I didn't feel like it.

We had a lofty (for us) goal to finish the run in less than 28 minutes, and sure enough, we beat our goal by five seconds!

Experience

Some of you may have surmised that the correlation I'm making here is about building experience through a set practice.

In turn, that experience provides you the information you need to continue improving.

For example, now that I've developed a habit of running, I can use my experience to make small improvements. Should I take shorter and quicker strides to prevent harder impact on my heel? Can I control my breathing a little better and focus on endurance?

In fact, your practice should facilitate introspection, which in turn may inform how your goals might be met or changed altogether.

As another example, now that I'm comfortable running more often, should I focus on longer distances, or should I try to go for speed?

The same applies to software engineering. Develop a healthy and continual practice. Take time to reflect. Use those moments to make incremental gains in areas you wish to improve.

As your experience grows, you will be better equipped to make decisions and judgments that better fit the moment.

Social Dynamics

Software engineering is generally concerned with building or improving products/applications, and this is rarely, if ever, accomplished in isolation.

In 2025, Dr. Cat Hicks, a psychological scientists who studies software teams, produced a paper called "A Cumulative Culture Theory for Developer Problem-Solving"

The paper is fantastic examination that looks deeper than surface-level measures of individual "programming" performance.

It attempts to break through the paradigm of seeing engineers as workers in isolation.

Dr. Hicks writes:

It is time to move past debates about increasing individual developer productivity (which is frequently narrowly operationalized as developer output), and shift focus to creating a broader science of collective developer problem-solving.

A Cumulative Culture Theory for Developer Problem-Solving

Collective developer problem-solving!

There is much more to dissect which I don't have time to get into, but I wanted to emphatically echo the sentiment that software engineers do not live in a vacuum.

Successful software is the result of eschewing individualistic self-silos for healthier team dynamics.

And you cannot develop healthy teams without effective communication.

We're now living in a time where active communication is seen as an annoying byproduct of software engineering.

Kathryn Conrad & Digit / Isolation / Licenced by CC-BY 4.0

Technocrats dream of automated systems that can read and write emails, create tickets, construct documentation, create PRs, summarize specs, take meeting notes, prepare README files, and so on...

And I can almost understand. Traditionally, our educational systems have turned writing and communication into a rote chore—a templated and bland construction for the sake of fitting some standardized form of communication.

On his blog, Author Niklas Goke writes:

Traditional education turns writing into a dismal chore from the start, and so whatever linguistic skill it might imbibe on you will leave a bad taste in your mouth. Naturally, most people aren’t keen to pick up the pen later in life, and wherever they have to do it — and it’s a lot of places where we have to do it — they’d really rather not.

When AI Does Our Writing, Who Will Do Our Thinking?

Writing is more than just text on a page. There are dynamics at play within communities and teams. Rules of engagement. Nuance. Trust. Relationship.

That is why I believe honing our communication skills is as imperative and important as writing code. And just like code, it is something that must be continually practiced and adapted.

Effective writing has a purpose, understands its audience, and crafts a message that is consistent within that context.

As an engineer, the message of your communication should be mindful and respectful of your audience, whether a sole email recipient, engineering team members, stakeholders, customers, or an open source community.

The purpose of your message should be clear and comprehensible to that audience.

I'll go ahead and get a little salty here and say straight up that offloading your communication to an LLM completely destroys this rhetorical situation, because a language model cannot, by nature, be purposeful, or aware of who the audience is and what they need.

Sorry, I'm an English Major. I feel like I'm obligated to say that.

But really, offloading opportunities to write, even something rote like an email, will ultimately be a detriment to your engineering practice.

Attention To Detail

My next point has to do with attention to detail.

Let's enter another metaphor, shall we?

What does it take to be a good cook?

How many of us have tried to follow a recipe only to be tripped up by trying to figure out how much a "pinch of salt" really is or not knowing how long it takes to caramelize onions?

Cooking is an active practice that requires fundamental skills, specific knowledge, as well as deductive and inductive reasoning.

A chef may have a distinct skill in using a knife to chop. They have the knowledge of how a different skillet temperature may affect a food item. They may be able to deduce what ingredients to use amongst what is available, but also use creativity to find solutions if certain ingredients are lacking.

But beyond all, a chef must be meticulous about the details.

It's not like that time I was surprised by the definitely-not-cinnamon in my oatmeal.

Folks. It was cumin. I don't recommend cumin in your oatmeal...

I do want to point out, however, that attention to detail does not mean that you become error free.

Note the following limitation:

A SmartBear study of a Cisco Systems programming team revealed that developers should review no more than 200 to 400 lines of code (LOC) at a time. The brain can only effectively process so much information at a time; beyond 400 LOC, the ability to find defects diminishes.

https://smartbear.com/learn/code-review/best-practices-for-peer-code-review/

When I mention attention to detail, I don't mean a superhuman skill that somehow surpasses the limitations of repetition blindness or vigilance fatigue.

The detail I'm writing about is broader. Like a chef who knows what ingredients might be best to use for a particular plate. The chef might be aware of which seasonal ingredients are both, less costly and more flavorful for the moment. They may understand the taste preferences of their customers. They know when to experiment and when to play it safe.

All of this because they pay attention to more than just the plate.

And speaking of the plate... They never skimp on presentation!

Remember that your code is not meant to be read by machines (otherwise we'd be coding in ones and zeroes). Instead, your code is meant to be read by humans.

Accountability

This last point seems a little out of place.

What does accountability have to do with becoming a better software engineer?

A little over a month ago, Scott Shambaugh wrote a blog post titled "An AI Agent Published A Hit Piece On Me."

In short, an automated LLM agent of unknown ownership published a disparaging blog post about Scott, after he rejected an autonomous code change request to the popular matplotlib library.

This particular situation only highlights an ongoing problem with autonomous LLM-based workflows that are bombarding open-source maintainers.

While I'm not here to litigate the inconsiderate and asinine decision to unleash unsupervised agents into online communities, I do want to highlight a major lost opportunity.

Yes, I'm referring to accountability as an opportunity for growth.

By owning up to our mistakes, we then have an ability to reflect. We may learn how to make better decisions or things to watch out for in the future. If in a healthy team, we may even receive guidance from others who have faced the same challenges.

Friction and opposition yields creativity. It opens up our minds to instruction, guidance, and learning.

This really is a good thing!

Celeste Kidd, researcher and assistant professor of psychology at UC Berkley, studies the processes involved in learning and belief formation. She notes that uncertainty is when you're more apt to learn.

When you’re very curious is when you’re most open to changing your mind. That’s when you’re looking for information. That’s when learning happens. It’s a magical time.

https://vcresearch.berkeley.edu/news/what-can-psychology-teach-us-about-ais-bias-and-misinformation-problem

Also, the more you practice accountability, the more trust others will place on you. And as you gain trust and respect, your integrity can be a major factor during difficult times.

When I read through some of Scott's responses to the OpenClaw nonsense, (not to mention the fabricated quotes in subsequent reporting), I was struck by his sincerity and level-headedness.

I believe that kind of calm and collected behavior is not something that comes naturally. It is something he developed over time, and his integrity stands in stark contrast to the shadow cast by the autonomous LLM-code generators.

This post isn't one where I'm trying to convince you as to whether you should or shouldn't use LLM-assisted tools (you can check my other posts on this blog for that 😁).

But what I am advocating for is to be open, honest, and accountable.

If you are using these tools to hide behind... If your first instinct when something goes wrong is to blame a tool... Or if you feel that piloting an automated tool without reckoning with the consequences it is having on others...

You are missing a major component toward growth.

Productivity

Okay, so time to wind down... but before doing so, I wanted to return to the motivators I mentioned earlier.

The question, how do I become a better software engineer is sort of a red herring.

If you're just entering the engineering field, you already possess a quality that is missing from more "experienced" engineers. You're not plagued by the curse of knowledge, and you have the capacity to see things from a fresh perspective and a context that is impossible to reconstruct for someone who's been working for decades in the field.

Heck, you may have already developed better communication skills than most career software developers.

Becoming better has less to do with time invested than you might think.

There are several measures you could take to determine whether you are growing or improving as an engineer, but those data points might are sometimes hard to pinpoint.

However, companies need to find a way to commoditize you, or your work, which is why you will often see engineering skill measured through the lens of productivity.

It sort of makes sense. You wouldn't pay a junior engineer a high salary if you can't depend on them to ship a feature quickly enough.

Some companies try to establish leveling guidelines which set expectations—and these are usually tied to responsibilities that ensure efficient, business-objective outcomes.

I don't think it's too controversial to say that, in spite of how much you get paid, business do not value you based on how good of an engineer you are. If they could automate your job and still continue to produce a product without hiccups, you'd soon be off looking for another job.

That's a broad generalization, and I know there are circumstances where this isn't true. But on the whole, this is what the industry is pushing for.

What is the effect of increased productivity?

In your personal time, what do you get out of producing more? Does it free up time? Maybe you can now spend less time on your computer... more time with family, reading, exercising, sleeping... But if it's time that you want, increased productivity won't get you there.

At work, what do you get out of producing more? Well, mostly, you get more work. Does it lead to more profitable business? Does it increase market share? Does that mean you'll get to do more things that matter? Will you get a raise commensurate to your level of production?

I'll let my cynicism take over here and make a guess that this is not the case. Companies will find ways to exploit workers to make things as quickly as possible, cutting corners where they can.

Productivity alone is a poor proxy for good engineering practice. Sure, if you can make more and make it better than before, you may be more valuable to your company, but you might quickly burn out if you're widely misaligned from your primary motivators.

Conclusion

I'll conclude with a story you may know about an engineer whose contract ended with Apple Computer after they canceled his project.

However, frustrated by all the wasted effort, he continued showing up to Apple's campus, finding that his badge still worked and his prior office space was still vacant.

He eventually recruited the help of another engineer who's contract had ended, and together they continued showing up... long hours, no meetings, no office politics, no managers...

Eventually, through a bit of subterfuge, cleverness, they were able to demo what they were working on.

But even more remarkably, they were able to build a network of supportive engineers and managers within Apple, and even got help from QA testers. After receiving and acting on this feedback, they were able to ship their software with the original PowerPC computers as the Graphing Calculator 1.0.

Ron Avitzur and Greg Robbin's story has been retold on This American Life, highlighted over at Newsweek, and a few other outlets. The story is also captured from Ron's point of view on the Pacific Tech website, which is still viewable today. Near the end of the piece, he writes:

The secret to programming is not intelligence, though of course that helps. It is not hard work or experience, though they help, too. The secret to programming is having smart friends.

Remember Dr Hick's point about shifting the debate from individual productivity to that of collective developer problem solving?

Becoming a better software engineer does involve experience... This can't be automated away. It must be earned.

It requires better communication. It must be sincere and built on trust.

It requires attention to detail, which is only possible by paying attention to the contexts both inside and outside of the code.

And it requires accountability, which is also not something you can pass off to a machine.

Yes, my premise here was a bit of a red herring.

More? How about more introspection. More purpose. More community?

Better? Pay better attention to others. Communicate better, with care and empathy. Develop and cultivate trust.

Start there and you'll make a damn fine software engineer.