This is a technical article - bear with me for a short analogy.

I spent a lot of time playing pool in bars when I was younger. I loved being on the coin table where I could meet a barrage of different people. After a while I got quite good and could immediately recognize the skill of my opponent. The lowest skilled could barely shoot and would often miss their target ball. Or not even have a target and just smash the cue into a group of balls. This is called playing “slop.” The next level were what I called the “shooters” who could accurately put a ball into the pocket they were aiming for. A big step up from there are the players who could plan making multiple balls in a row, let’s call them the “planners.” This requires being able to make shots in a variety of ways with different spin and speed on the cue to set yourself up for the next shot. The best players will have a plan for running the table (making every ball and winning the game) on every shot. They often don’t succeed, but the best get close more often than not. Let’s call them the “owners” because they’re the ones that you see owning the table all night. There are a lot of other skills to be a great pool player, but I promised a technical article…

I see these same level progressions in developers and you’ll probably recognize some of them as well. The slop developer makes random changes to the code hoping it’ll work, if it does, they ship it. These are the coders who copy/paste straight from Stack Overflow without even reading the post or the code. Those same people are probably much more productive now doing the same thing using an LLM. These developers would do themselves a great service if they just took the time to understand exactly what the code others have wrote is doing. If they don’t and they don’t get some mentorship, it’s easy to get stuck at this level for years. These developers are the reason for whiteboard code interviews because many are great a faking the general knowledge questions but fall apart if they have to write a bit of code.

Equivalent to the shooters are developers who can successfully complete their sprint tickets most of the time. They can fix bugs reliably and understand the changes they’re making. Like the opponents you’ll see at a bar pool table, this is most developers. These are great reliable teammates. The weakness is not being able to see the bigger picture. Often when a developer at this level misses a sprint, they miss it badly. It’s often because sprint after sprint they’re not realizing they’re painting themselves into a corner. These developers need to learn from their failures. Often it’s fixing too many small issues while deferring obvious technical debt or design issues.

The planner level dev is making sure they’re mixing in those bigger changes into the routine. They’re being more proactive about thinking ahead and the consequences to the larger project and future productivity. These devs almost never miss a sprint deliverable and even hit larger project deadlines on-time. These devs are fantastic but might still get tripped up by unexpected changes to plans or projects. They also may not be able to handle when other teams on a project don’t deliver on-time or with the unexpected scope changes.

The last level (for this post anyway) is that owner dev who can handle whatever shows up and doesn’t break a sweat. They’re somehow delivering on big projects on-time and even when things don’t go right, they’re back on-track quickly. They’re not pulling all-nighters but somehow managing to get everything done. It seems like magic, but it’s not. These developers always have a plan, but they’re willing to change it immediately when new information arrives. Nobody has a crystal ball and we can’t know exactly what will happen during execution. But with some effort we can make good guesses in the center of the probable outcome. With a big enough project, some things will be late, but others will be early. If you only change your plan when things are late, you’re always going to be late. Take advantage of the knowledge gained as well - there are almost always optimizations to make during the plan that can make up for other components that are running later than expected.

It takes a lot longer to get to this high level than it does to get good at pool. And, like pool, it’s generally a progression where you have to master the previous level to get to the next. Not everyone can get to the next level but it’s guaranteed you won’t if you don’t spend time thinking about your performance and failures to correct for them the next time. That will train yourself to think farther ahead and the different paths you can take to get to your goal. With hard work, you’ll be running the table.

Obligatory Expanding Brain Meme