caines.ca

It's hard for me to believe that many developers are doing what I'm hearing they're doing: token-maxxing, running agents overnight, and (especially) running 10+ agents at once.

With agents, automated coding often seems like a solved problem.

Agentic development is bringing a resurgence of "the specification".

I've got a skill that drastically improves code quality and architecture and it's powered by defects.

Here's a question: if you were told you were going to get the biggest, worst codebase that you had to work on, sight-unseen, but you could magically apply one refactoring to it, what would that refactoring be?

One of the main reasons I see people getting poor results from agentic coding is that they're not managing their context properly.

One thing I've noticed when working with others while coding with agents is that many people are still working at too low of a level by default.

Steve Yegge shipped 225,000 lines of Go code he's never read.

My software engineering background colors my management style in many ways.

(special thanks to Deepa Joshi for her input!)

(special thanks to Deepa Joshi for her input!)

(special thanks to Deepa Joshi for her input!)

(special thanks to Deepa Joshi for her input!)

I’ve stumbled upon a style of estimation that I’ve seen be pretty successful.

It can sometimes feel like TDD is pretty dead in 2022.

How you do QA is probably terrible.

I’ve seen this pattern a number of times in my years as a software developer, and it’s always hard to watch: (1) “We don’t need automated tests on this stuff.

I think that the most important thing I've learned while trying to improve my abilities as an organizational change agent (read: a programmer that likes to get his way), is to never ever present some idea as a best practice.

Evergreen Update ( 2022-01-35 ): After some time working with Typescript, I'm actually completely sold on its usefulness and value, which I certainly was not at the time of this writing.

I've always worked most heavily with dynamically-typed languages.

One of my favourite ways to tackle tech debt is to fix it as I work through product requirements.

In my experience, cross-functional teams align people to business goals best, and so they can get to real results much faster and much easier than teams made up of a single function.

Too often when I see a team trying to replace a bad/old/deprecated pattern that is widespread in a codebase, they default to what I call The Hero Solution: One person on the team goes through and fixes every case of it themselves.

I always try to think about what exactly it is about experience that makes a software developer better.

The 4th criteria of the Joel Test of quality on a software team is: Do you have a bug database?

I've had a chance to get back to coding after a couple of months' hiatus so I thought I'd write about something a bit more fun and way down in the details.

I've been developing software for a few years without doing much estimation at all, and the estimation I've been doing has been really vague, eg "You know that feature is a lot of work, right?".

I've recently seen a case of spontaneous waterfall-style development emerging where the team was generally empowered to avoid it or at least to correct against it, and certainly wanted to, and yet did not.

"Engineer" really is a very silly term for people that make software.

Special thanks to my friends Deepa Joshi and Sam DeCesare for input/feedback!

Special thanks to my colleagues Sam Chaudhary, Lexi Ross and Stuart Reavley for feedback/criticism!

A lot of engineering management and product development process conversation tends to be based on a fundamental assumption that product quality and development speed are always opposing forces.

One pattern that I've seen work well in software development management is one I call The Atomic Team pattern.

Obviously from the title, I think software engineering management is in a Stone Age.

(Thanks to Chris Frank and Sam Decesare for the feedback!)

Last week I had the pleasure of being on a panel about Continuous Testing put on by Electric Cloud.

It's been over a year since I've been on a team that does Sprints as part of its engineering process, and I've really changed my mind on their usefulness.

This is the last part of my 3-part series on production-quality node.js web applications.

This is the second part of a three part series on making node.js web apps that are (what I would consider to be) production quality.

I've been working on production-quality node.js web applications for a couple of years now, and I thought it'd be worth writing down some of the more interesting tricks that I've learned along the way.

I've been reading the 37 signals book Remote lately and it's got me thinking a lot about the advantages and disadvantages of working remotely.

So you’re thinking about versioning your web API somehow.

If you’ve ever seen a laundry list of the types of non-functional requirements like testability, accessibility, reliability, etc, (often called “ilities” because of their common suffix) you probably haven’t seen “rewritability”, but I really want to add it

I once asked an interviewee “Ever work on a high-performing team?”

First a little background I’ve always been a big fan of REST the way Roy intended it for two major reasons: It uses HTTP the way HTTP was intended, playing on its strengths and not wasting any time re-inventing what HTTP already has.

I’ve seen these anti-patterns in a lot of web APIs, so I thought I’d detail why they’re bad and what to do instead.

If you consider the number of packages on pypi, npm, and rubygems, and the release dates of python (1991), ruby (1995) and node.js (2009), it looks a lot like those communities are getting new packages at the following rates, per year: python: 29,720 pack…

If you’ve developed SaaS in a large organization (or even a small organization that acts like one), you’ve probably seen some of the symptoms of fear of releasing software: Off-hours deployments and weekend deployments Infrequent releases extended code-fr…

Version control branches come with costs.

Let’s just forget about story points, pigs, chickens, daily stand-ups, burndown charts, sprints and scrummasters for a second.