Forem: Craig Nicol (he/him)

In case of failure

Craig Nicol (he/him) — Fri, 22 May 2026 10:34:00 +0000

A catastrophic failure is always a system failure.

It could be the intern, it could be Your Plastic Pal Who’s Fun To Be With, or it could be those login details that you thought were secure on your help desk software. If you lose your production database, it’s not the fault of an individual, a robot or a third party.

There should be multiple points of protection between you and your data. The code should be tested, the logins should be secured, rotated, MFAd and audited, and admin access should be off by default.

It’s not another procedure on a document that no one reads or remembers; it’s a gateway that no one can forget. It’s not connecting from a developer machine; it’s a pipeline that only runs in a trusted environment after appropriate checks are made, and makes backups before making changes. It’s testing your backups.

It’s not about nottrusting your team. I trust mine, but sometimes they get tired, and sometimes they get stressed, and I want them to burn whatever cycles they have onproviding business value, not walking tightropes.

What system failure are you blocking today to save you tomorrow?

If it hurts, stop doing it: the wrong person in the wrong place

Craig Nicol (he/him) — Tue, 19 May 2026 10:18:00 +0000

Have you ever taken your goldfish for a walk and tried to play fetch?

They’re rubbish at it, you know. Complain all the time about the lack of “the environment”, like water is important to them or something. They don’t run. They don’t pick up sticks, even when you try to accommodate them with tiny twigs. Useless. No one should have one as a pet, no drive.

Dogs though. They walk, they run, they swim. They don’t need “accommodations” like a fish tank. What an ego, to put their name on their safe space. And then to tell me to stay out because I’m “toxic”, when they’re the ones who put something in there so I can’t breathe.

Fish! Honestly!

Know your worth. Know your strengths and your weaknesses, and don’t let someone else tell you you’re useless just because your way doesn’t align with theirs. Or because you have a different skill set.

Dear managers. Don’t judge your customer support teams on sales metrics. Don’t let your best people languish in a job that doesn’t suit them because you can’t think outside the box you put them in. They’re hurting. And it’s hitting the team. Know your gardeners from your innovators.

Sometimes the best fit for a person is a different company. That’s not a loss unless they’re stuck where they are (and please, let’s make sure there’s support and a safety net for people who have to leave before they find the right fit).

If it hurts doing what you’re doing every day, figure out what you should be doing. Or where you should be doing it. It’s not about avoiding stressful situations or being uncomfortable, but it is about avoiding burnout and aggression. You know your place, and if this place is your place. If it hurts, stretch it, move it, try something else.

Know thyself

responding to change over following a plan

Craig Nicol (he/him) — Fri, 15 May 2026 11:02:00 +0000

Failure to plan is planning to fail.

Things change. I might not trust change, but I accept it and allow for it. But there’s always a direction, a star to follow.

Plans provide a common direction and steps to get there. Agile just means the steps aren’t always the right ones, and the goal may change, but you should always have a goal and next steps.

Question the plan, agree on a new plan and agree to follow it. It’s worse than not having a plan because if you don’t follow the agreed goal, especially in silence, you are actively hostile to the success of the team.

Some deadlines don’t change. If you’re in retail, you’d better be ready for Christmas. If you’re a business, you’d better be ready for the end of the tax year.

Keep your plan visible, and keep your plan flexible. It will change, but without a plan and a reason for the work, you’ll never know what you should be saying no to.

Don’t send me Easter emails

Craig Nicol (he/him) — Tue, 12 May 2026 10:09:00 +0000

Ever got the “please don’t send me Father’s Day emails”

I get the sentiment behind emails like this, but it feels like doing it in the moment keeps it raw. Ask just after I sign up if there are any sensitive dates, at the same time as asking me if I celebrate Christian or Muslim holidays. (No, I don’t know any website that does that)

Consent, at least under the GDPR, should be obtained in advance, freely given, and without prejudice. So why do you need to email me to ask if I want no emails? Ask me up front if there are any important dates, any birthdays, and include a list of common ones from the Christian, Sikh, Jewish, Muslim, Buddhist and other calendars. Include dates related to my country. Thanksgiving Day is different for the USA and Canada. And there are a lot of Independence Days.

Sure, folks won’t want to fill it in unless they see a benefit, but that’s what consent is. It’s more work up front and ongoing, but in return, you get trust, a much stronger relationship and the person feels more respected. This is a rare phenomenon in consumer data these days.

Consent matters. Informed consent in advance demonstrates commitment.

customer collaboration over contract negotiation;

Craig Nicol (he/him) — Fri, 08 May 2026 10:57:00 +0000

No great software was written without collaboration. And the best collaboration is always as close to the end user as possible.

But contracts are your safety net, especially in consulting. They’re your agreement up front of “this far, but no further”. Money is the engine of trade, but contracts are the heart of capitalism. They define your scope, your compensation and your boundaries. Without them, the loudest voice will always win.

Contracts protect you, but don’t let them smother you. They’re the foundation and the backstop to the project. They should never be the start of a discussion, but they can be a very useful end to one where customer collaboration becomes scope creep, taking advantage, or communication fails. It protects people from power.

Negotiate your contract carefully, but always start your conversations in the spirit of collaboration.

working software over comprehensive documentation;

Craig Nicol (he/him) — Fri, 01 May 2026 10:54:00 +0000

Good code documents itself.

But there’s a lot of context outside the code that informs it. There’s architecture and design decisions about which language to use, about whether it’s micro services, monoliths, containers, clouds, or mobile apps.

There’s legal frameworks and security certifications.

Code determines how. Tests determine the what. But documentation tells you why and when. Documentation supports future you or the next team member to understand what the reasoning behind that code was. It gives your present self grace for what you know now and don’t know yet.

Document the requirements in just enough detail, but document the decisions in depth. Working software, that’s suitably readable, is the best way to describe what it does. But understanding how that code came to be has a value you only understand after you forget how it came to be.

Document why you built this, but not that. What was the experiment? What was the context? Is it time to experiment again? Is it time to chalk the experiment up to experience and move on?

Be nice to yourself. Comprehensively document decisions.

If it’s hurts, stop doing it : you don’t need to know everything

Craig Nicol (he/him) — Tue, 28 Apr 2026 10:02:00 +0000

The best managers are great at delegation.

Micromanagement is exhausting. It’s stressful. And it creates delays and bugs because you become a black hole for ideas and improvements. You end up working longer hours. The job becomes painful.

So save yourself. Teach your team how you want feedback. Teach them what documentation makes sense. Make sure they highlight problems. And I’ll always make sure I’m available to answer questions in the stand-up, but 7 times out of 10, someone else beats me to it.

I don’t know everything, and I shouldn’t. A good manager is a catalyst for communication and generates questions to help. They’ll connect the problems with someone who can resolve them, and save some time to learn about the next problem.

Don’t be a bottleneck. Don’t be a critical path. Be a gardener and help the team grow. If it hurts, you might be strangling the team. Trust them and share the load.

Delegate, but make sure the important knowledge doesn’t go on holiday when your staff do.

individuals and interactions over processes and tools;

Craig Nicol (he/him) — Fri, 24 Apr 2026 10:47:00 +0000

Good processes and tools support teams. Bad ones destroy them.

Individuals are good, but if you look at the world through a post-meritocracy lens, you understand that individuals aren’t the primary driver of success. Everyone needs to work well and drive the project forward, but everyone also needs to work to move the team forward.

There are plenty of Theory of Constraints examples where individual progress can be at the expense of team progress, because they use their own code style, or they don’t have time to document or coach, or when there’s a queue for testing, and the rockstar developer is too precious to do QA and unblock the release.

Good processes help the team work together. They provide guidelines for the team, like a code of conduct, a standard operating procedure or a definition of done. They describe how things are done here so everyone has a shared expectation and a shared goal. That’s how agile teams become more effective.

Processes serve the people and the interactions, not the other way round, and should be open to extension or modification when they no longer serve them.

Good processes help individuals fall into the pit of success, whether documented or automated. Static code analysis helps every reader and avoids those subtle mistakes. Conventional commits help whoever is tracking down a production issue at 3am.

We don’t want heavyweight processes. We want them small, adjustable and easy to follow. But we want processes that support everyone on the team. Make all meetings online in a hybrid team. Have a set of standard criteria and questions for interviewing potential new team members. Reduce the bus factor with documentation processes so team members can have medical treatment, or visit family abroad for an extended break, or support extended adoption leave for new parents.

Don’t let an individual bend the team. Let the team embrace the individuals. And build whatever minimum process keeps those individuals supported.

Large Language Models and the Chinese Room

Craig Nicol (he/him) — Tue, 21 Apr 2026 10:08:00 +0000

It’s very easy to fool humans. We love to fill in gaps.

We see patterns and assume intelligence. We saw regular pulses from stars and called them Little Green Men. We see faces in cars and washing machines. Our brains fill in gaps when our eyes saccade.

And when we see a string of text that is coherent and reinforces our bias, we think that what produced it must be intelligent.

The Chinese Room is a thought experiment about artificial intelligence. The set-up is simple. Imagine there is a room with a letterbox and a massive stack of books. A human who does not speak Chinese is put in the room and told that for every Chinese message posted through the letterbox, they look up the symbols in the stack of books, copy out the response symbols, and post them back. Any Chinese speaker posting messages into the box would think they are talking to someone who understands Chinese, but the person in the box is just looking it up.

A large language model works the same way; it breaks the message into tokens, looks up the tokens in its database, and then looks up what the most likely next token will be based on the billions of tokens that were used to train it. And then adds a bit of randomness by sometimes choosing the 2nd or 3rd most likely.

The LLM then posts the response back, and the human outside the box starts to think that the box is intelligent. And some psychologists look at it and say it’s a prediction machine, and so is the human brain, so they’re the same thing.

But it’s not thinking, even if the chat box says it is. It’s not reasoning, even if the model has reasoning in its name. It’s just figuring out the next word. Sometimes it will figure out the next 10 words, like a Chess Grandmaster scanning the future moves, but it’s not got motivation. It’s not got self-reflection. It does not feel pain or remorse; it just keeps playing its own version of Scrabble until it draws a blank or runs out of tiles.

The thinking didn’t happen in the box. It happened in all the brains in all the people who wrote the words to put in the box, and it happens in all the brains posting things into the box, longing for connection or looking for a minion to help them steal the moon.

Humans love to find intelligence and faces in places where they don’t exist, because our brains are wired to find potential mates, friends and foes. A statistical model is none of those.

Dear friends, and especially your children

Craig Nicol (he/him) — Thu, 20 Mar 2025 16:30:53 +0000

This is a submission for the Future Writing Challenge: How Technology Is Changing Things.

The latest version of AI is everywhere. You might have heard it called Generative AI, or LLMs. And you've been told that it will take your job, or this is Skynet, and there won't be any jobs for your children. And anyway everything they're learning in school is useless. You're scared, I know.

This isn't the first AI revolution. You might remember when Kasparov lost a chess tournament to a computer. Or when Alexa was released and could understand most of what you said, and get things very wrong elsewhere. Just like autocorrect on your phone.

And that's really what this is. It's an autocorrect that understands that most people who type Taylor then type Swift, that lots of people have pictures of cats, so it can predict what a picture of a cat can look like.

But it isn't a decision or a reasoning engine, despite what the marketing money says. And there's still far more humans in the loop than you've been told. The party trick is built on huge amounts of energy - just look at how much money OpenAI loses - and huge amounts of human capital in places where labour is cheap. Categorising pictures, filtering out uncommercial content (not just nsfw but anything that might be controversial enough to scare advertisers).

Meanwhile those same people are wildly underrepresented in the outputs of these models. Because when all your input is WEIRD (White, Educated,...) then so will you output be. Because internet life, like popular culture it grew on, is still heavily biased.

The future isn't AI suppressing us, it's the billionaires using AI to reinforce bias and undermine labour power. But whilst they misdirect us by looking to an AI that doesn't exist, they can continue to exploit the rest of us (and the marginalized most of all) without oversight. And without respecting our privacy, or our copyright, or our humanity.

The future will have more AI, but a future run by AI is a future that won't be a future for the majority of humans. The time will pass, and we can help it pass, and technology still has a big role to help our future, but only if we remember that we are in control. A future where more technology is controlled under laws like GDPR, where companies are controlled and monopolies are harder to form, and a future where technology might help us connect but doesn't meditate our social life. Be defiantly human, and make technology work for you, not the other way round.

Are Gen Z less technical?

Craig Nicol (he/him) — Tue, 11 Apr 2023 10:59:27 +0000

Scott Hanselmann had some thoughts on Gen Z and their knowledge of technology – is their knowledge less advanced than the previous generations?

@shanselman
#stitch with @glittering_ghostwriter is this generation less tech advanced than the last?
♬ original sound – Scott Hanselman

It depends what you mean by technology.

I get that understanding files and folders are useful right now for understanding software and that part of our job is to teach that. But are they dying out?

My dad, as a Chartered Electrical Engineer, was a dab hand at valves, capacitors and a bunch of electronic circuitry which has mostly been made obsolete by embedded systems using old CPU designs and lots of C. It’s not just that there’s missing levels of abstraction, that layer doesn’t work like that anymore.

And in the web and big data era, I’m not sure we can say the underlying structure consists of folders and C drives. Web pages, social media, political movements, note-taking apps, presentations and APIs are built on relationships and multiple facets, not hierarchy and The One True Way. I loved delicious and GMail. Despite growing up on DOS, and later Windows and Linux, tags always made more sense to me than folders (heck, I even built a proof-of-concept of a tag-driven file system based on how I used delicious).

And as all the major languages embrace more functional composition over object hierarchy, will the structure of code itself follow? Look at how we’re starting to compose web applications, there are hierarchies of visual components, but the new ECMAScript is modular, and uses URLs instead of hierarchies to organise code. Microservices are loosely coupled and have no concept of hierarchy between them.

Well-architected systems these days have service buses, temporary storage, network queues, and caches. There’s an asynchronous, distributed world that all the code lives in. That’s a very different technology to what I grew up with and started developing in. But it’s very similar to a world where kids communicate primarily by text, 1:1 or in group chats, where people post on social media and don’t know who sees it, where live streams become YouTube videos, where Slack, Discord and others make chat searchable and allow people to catch up in their own time. Where people have to track multiple channels asynchronously to keep up to date with their friends.

The generation of developers who will build the next serverless and distributed applications, the fediverse generation, the XR voyagers, and the web3 generation – whether or not web3 itself becomes the next big thing, may find that those who think in terms of folders and hierarchies are limited in their ability to grok the systems required. Moderation in a hierarchy has failed multiple times. Twitter’s latest problems are not the only example. Amazon famously prefers small autonomous technical teams instead of big central planning. Google tried to get rid of managers, until they realised managers have a role beyond supporting the hierarchy.

Yes, Gen Z have limited knowledge of some of the foundations of the technology we use today, but that’s just because those abstractions aren’t useful anymore. I’m sure some will embrace those abstractions, just as some embrace chiptunes and C64 restorations. But the foundations of yesterday’s technology will seem as archaic as valves or punched cards to whoever the next tech billionaire is.

Are we going to be the dinosaurs, as the next wave takes over? We’re the generation who let go of memory management, semantic line numbers, and significant whitespace. They may well let go of hierarchies, disconnected machines, and object-oriented thinking.

The future is here, it’s distributed, it’s asynchronous, and it’s theirs.

Name your problems

Craig Nicol (he/him) — Fri, 07 Apr 2023 10:52:00 +0000

A rose by any other name would smell as sweet.

Names matter. Names are a container for all we know about a person or a thing. Names give us a reference that allows us to abstract the detail to whatever level makes sense today.

And big hairy problems will be referenced a lot. Big hairy problems will turn up at retrospectives where you can look at the detail and stand-ups where you can’t. They’ll manifest as bugs in some parts of the system, workarounds in others, and sometimes features in other places. They’re problems that aren’t one fix, they’re code and infrastructure and process changes.

Sometimes the problem has an optimistic name: “Project Nightingale – to make data sing” because it’s much nicer to work on that than the “our charts are fundamentally broken and everyone hates working on them” problem. Sometimes it’s a description that helps visualise the issue: “the pinball routing problem” when the redirects in your webapp fill up your network, and it’s hard to see which page to show for the current state “Am I adding strawberries to my shopping cart, or am I paying for them separately?”

A good name helps keep everyone focused and provides a focal point that everyone understands.

I know naming things is hard, but naming hard things makes them easier to work with. And it doesn’t have to be a descriptive name. If you’re struggling, name them after hurricanes, or characters from Glee, or Tour De France winners, so long as they’re unique enough that you won’t get 2 of them confused.

Name your problems. And conquer them.