My team just speed ran 2yrs worth of work in about 9mos. I’m split-brained about it. On one side it’s remarkable achievement. On the other, I see how it can be done even faster/better.

Difference? Deciding which parts of software development requires preciousness. Fewer the better.

“bro, I have a brain”

This is going to save us.

Delivering a company’s product, and refactor existing systems is complicated and has little to do with deadlines or tech debt. We revert to “more devs” and that’s more complexity. Instead? Ignore hype. Frequent small changes. Solve your problem not others. Don’t ask permission. Do this Everyday.

I’m increasingly confused that folks continue to believe that AI will build all sorts of software, and by folks with no dev experience. I mean - how will those folks know? How will they know AI has given them “software” that runs? Or is correct/scalable/testable/deployable? They’ll learn how?

GenAI for programmers == expensive auto complete.

I’m growing more convinced the biggest attractions for AI is its ability to “search” and its ability to create “integrations”. Both are table stakes in SaaS products today. Neither of these is innovative.

Content creation will become increasingly problematic and I suspect less interesting.

In all the AI hype, an important awakening is happening related to data.

Just because you have it does not make it valuable.

Data in the right context, at the right time, for the right users is the value.

Everything else is parlor tricks.

There is a point in time in which the software you’re writing needs to be less-than-perfect in order to scale and be manageable. No API or framework makes this better. Your scale is not my scale, and these things can’t be homogenized. Learn to recognize this moment and you’ll have more success.

I’m convinced the best software engineers have one common skill. They learn to learn. In my 20+ years of writing code - this is the one skill that helped me the most.

The problem with this however is that it presents as “not knowing what you’re doing”. And that is used against you in interviews.

There is a stage in software startups where it feels like “we need more devs”. That is the moment good startups say no. Instead they move to find really talented devs who start and create a culture of quality. If you go the other way you’ll prolong quality and you’ll find most of the tech debt.

Like other crafts, continuous learning is a critical skill in software engineering. However it’s usually not a new “fundamental concept” but instead it’s someone else’s opinion about an existing concept. Frameworks and abstractions often force learning extra stuff that doesn’t port anywhere else.

Of all the concerns for using AI to build software the one that has the biggest impact is the potential to stifle learning the craft.

If we stop learning we’ll never understand when/where/how AI is failing us.

An idea we’ve had at work is to assess whether our tech debt is “contemporary”. Two things: contemporary tech debt is made from framework lock-in and the other is made from old domain context. The latter is more important to pay down but only if you avoid the former.

I’m convinced in a near future we’ll experience the backside of this AI hype cycle as a time where companies will say “we need humans to unwind our AI.” Forgetting that it’s the humans that made the AI.

But what do I know. Maybe computers will become sentient.

Keep learning, we’ll need it

I’m convinced that if engineers were held accountable to the profit/loss of the business, many architectures would be thrown out with prejudice. It’s my experience the closer they are to financial impact the better they build. Make money to make time for innovation. Anything else is rare.