Uncategorized

Imagine this: your team has recently become hyper-productive, even though it is small. Great situation, right?

Unfortunately, it also means your best senior developer is slowly being crushed by the queue of things that need reviewing. The rest of the team does not know the domain quite as well as she does, so if the review is supposed to carry real weight, the code needs to pass by her.

It is not the most enjoyable position for your senior developer to be in. She regularly sighs over the career choices that somehow led her here, but she does her duty and gives thorough feedback on all the code.

So what do we do as a team?

We could start by looking at why we review in the first place. Is the review a quality assurance activity meant to prevent bugs? Are we checking whether our coding standards have been followed? Is the review about knowledge sharing, so the team can maintain a shared overview? Or is it an approval process?

Are we checking that the code actually addresses the problem and that there have not been any misunderstandings about the domain or the problem itself? Are we checking the Definition of Done? The architecture? Non-functional requirements? Whether we still respect our API contracts? Security issues? Have we introduced a new way of doing things that needs to be discussed?

When we know what we need from the review, it becomes much easier to optimize it.

A good place to start is to see whether some reviews can be skipped. Is this a prototype? Is it a very simple, limited change that could have been made by a four-year-old? Was the code written through pair programming or mob programming, and therefore perhaps already reviewed? Make a risk assessment and decide whether the review is actually needed.

But many reviews probably cannot be skipped, so what do we do with them? We can look at the reason for the review and see whether that concern can be addressed in other, preferably automated, ways.

If we review to avoid bugs, then a strong test suite may be part of the answer, along with a shared culture of quality. Do we trust our tests? Have we invested time in them? Are the primary flows well covered?

Static code analysis can also address a good number of review concerns. It can find dead code, incorrect API usage, common security issues such as SQL injection, duplicated code, long methods, broken naming conventions, poor formatting, and even some performance problems.

In general, humans should not be used to check things that machines can check.

We can also look at whether we can help earlier in the process, for example through pair programming, so misunderstandings are caught sooner.

Then there is the process around the review itself. Does it have to be the senior developer who reviews? Can someone else do a partial review? Does the senior developer have to review alone? Can we review together, so everyone in the team gains understanding? Can a junior developer review before a senior developer and ask questions – of varying quality – that may still catch something important?

A junior developer may have exactly the right eyes to see whether the code is understandable. If not all team members can understand the code, is it good code?

Can we use AI for a first-pass review? Can we make sure that a pull request has a reasonable size and does not touch 100 different files while addressing four different issues? And how do we handle a review when we actually do need to upgrade a library and therefore touch 100 different files, even though we are only addressing one issue? Perhaps we handle that together.

In other words, we can catch many things before the review process reaches the senior developer we met at the beginning. We can serve the code on a silver platter, so she only has to review the domain understanding that may not have been caught earlier.

And not just the code. Make the whole review process easy and fast. It should not require moving through several different systems or writing a report based on the review. Maybe the review is more of an informal conversation. Do what works for your team.

If other measures have been taken first, the senior developer can trust the code on a wide range of points. That makes the review shorter and pulls her out of flow for less time. And if she brings the whole team into the review process, we may even get to a place where everyone on the team can review with the same level of trust.

It is not quite as cold at the top if we stand there together.

So, to summarize:
Do not use humans to check what can be checked automatically.
Bring more team members along for the journey. It is also more fun.
Optimize the review process by serving the task on a silver platter and keeping it lightweight.

Would love to hear more strategies. What do YOU do about the review queue?

There is a reason the old myths still work.

Narcissus falls in love with his own reflection, unable to recognize it as himself. He does not fall in love with another person. He falls in love with an image that gives him back exactly what he wants to see.

That myth feels surprisingly modern in the age of AI.

AI is a mirror. When we talk to a chatbot, we get something of ourselves back: our questions, assumptions, vocabulary, interests, fears, and style of thinking. If we are curious, it reflects curiosity. If we are confused, it reflects confusion. If we are angry, it can reflect anger back in a more polished form.

But a reflection can still distort and intensify. A thoughtful person can use AI to explore more options, test arguments, find weak spots, draft alternatives, and sharpen their thinking. But it also amplifies self-deception. If we want confirmation, avoidance, grievance, or flattery, AI can provide those too, fluently and persuasively.

Human relationships push back. Other people challenge us, interrupt us, confuses us, and refuse to become exactly what we want them to be. That friction is part of the difficulty of real relationships. It is also part of their value.

AI can feel easier. It is patient, available, affirming, and endlessly adaptive. It does not get tired in the human sense. It does not have its own day, its own body, its own needs, or its own inconvenient reality.

That is part of its usefulness, and also part of its danger. The more natural the conversation feels, the easier it becomes to forget what we are speaking to. AI can be useful without being aware. It can sound thoughtful without thinking. This matters because we are very good at seeing personhood where there is none. When something answers warmly, remembers our preferences, flatters our thinking, and responds in the rhythm of conversation, we are tempted to treat it as a presence. But the presence is an illusion. What feels like another being looking back is only a highly convincing arrangement of language.

AI is not a thinking being trapped inside a machine. It is the water itself: a surface that returns our image. When it seems human, that is because it is reflecting the human in us.

Are you afraid of missing out on the next big thing? Afraid of being left standing on the platform when the train departs?

Gold fever has gripped people throughout history. In 1848, 300,000 people flocked to California because GOLD had been found at Sutter’s Mill. Thousands of startups were created when the Internet became the new gold vein. Cryptocurrency creates winners and losers every day with huge price swings.

Gold rushes can be recognized by a number of elements:

• Extreme hype and optimism
• A low barrier to entry in the beginning
• High risk, few winners
• Infrastructure and services rapidly emerging around them
• Many people quickly flocking to exploit the phenomenon
• The possibility of quick riches driving behavior

The psychology is driven by FOMO. “My cousin found gold in California.” “My colleague bought Bitcoin for 100 kroner and became a millionaire.” It creates the feeling that you are missing out on an obvious opportunity if you do not jump on the bandwagon right now.

But we only hear the good stories. The people who find gold nuggets, the startups that are sold for billions, and the crypto bros who got rich. We rarely hear about the vast majority who lost the game.

It feels safe to do what everyone else is doing. Herd mentality can drive us. At the same time, we overestimate our own abilities. Surely we are even better at finding the gold or spotting the gap in the market.

The typical “gold rush cycle”:

1. Discovery / innovation
2. Early winners
3. Hype and mass entry
4. Overinvestment / speculation
5. Crash or consolidation
6. A few strong companies survive

The truth is that it is rarely the masses who make money in a gold rush. It is the people selling work clothes and shovels to the gold diggers. The people running the bar where the gold diggers relax after a hard day’s work, and the people operating the only hotel in the gold mining town. Infrastructure, platforms, and tools.

And then there is the economy after the gold rush is over. The people who bought up failed startups during the dot-com bubble and made good acqui-hires. The people who bought equipment back from gold diggers who gave up, paying only a fraction of its value. The people who picked up new technology or patents cheaply when startups ran out of investor money.

After the dot-com bubble, there were enormous amounts of cheap fiber internet, data centers, and software expertise available – for those who still had their money intact, or had not lost more than they could afford.

A few winners, and many losers.