Taking a list of well defined test cases that you need to pass and writing some code to pass them is not hard. If that is all you can do, then yes, the frustration-bait on X or Twitter about AI taking your job might actually be real. That level is uni-student-doing-LeetCode-basic level.

In my opinion, the real skill comes in being actually on the tech side (so knowing what’s going on, and what work is good, and what work is bad) and being able to do the work yourself but:

• Being able to actually understand what’s needed
• Knowing how to insert it safely into to a complex system that is currently in production, and
• Being able to say “no, but how about this instead?” to requesters that are well meaning but not fully understanding

After a bad period marked by:

• Distractions
• Excessive non-effective communication and meetings, and
• A lack of accountability

, I recently got a bit more control due to some pressure my boss was under which allowed him to buy the team some breathing room from said distractions and I started:

• Emphasising the need for tasks to be ready before developers were assigned, and ……
• Actually getting them ready myself

To be honest, I felt like I didn’t want to give some of the tasks up to other developers when I got them ready.

Why?

Because they’re good. They’re the sort of stuff I want to work on.

How?

• There’s actually instructions for what needs to be done (within reason)
• There are test cases or hints at test cases
• There’s a clear start
• There’s a clear end
• When I feel like I’m done, I know I’m actually done

Stuff like this is good for your mental health at work. It makes people happy to have clear definitions of success and failure, and to be able to know they’ve actually succeeded at something, rather than them being stuck with vague ever shifting requirements.

So I think as a lead developer for now on, I am going to think about the following priorities:

• Getting things ready
• Maintaining standards

I am still going to work on:

• Automated testing
• Critical processes, and
• My “babies” I’ve worked on before (or that I really really don’t want to burden others with)

But I think this is the way to go.

It’s easy to work within clear guidelines, with a clear start, a clear end, and a definition of success.

But I proved in my past jobs that I work well in fuzzy, badly defined chaotic environments. But it is taxing. And it isn’t performant in large groups.

And I should use my skills in actually navigating that space to help the team perform better.