DEV Community: Craig Nicol (he/him)

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.

The conscious machine

Craig Nicol (he/him) — Wed, 22 Feb 2023 11:56:00 +0000

This is a fantastic explainer of the threats and risks, and opportunities of AI. Thinking about the nature of consciousness. Can we ever say truly what a machine consciousness is, or how it feels?

Max Tegmark – When Our Machines Are Smarter Than Us – Clear+Vivid with Alan Alda

Up until now, we’ve been smarter than our tools. But that might change drastically sooner than we know. Isn’t it time to think about that?

As a white man, I have no idea how it feels to walk this world in darker skin. I can understand fear, but not the constant fear of being stopped by police, of watching my back.

I can understand what is happening, and fight to change it, but I’ll never understand how it feels to be in that position. Equally, a machine will never be able to understand how that feels, although it may be able to approximate the behaviours expected of someone who does.

AI is being built with a Western and a Chinese perspective. We cannot understand what a conscious machine will be like, or how it feels, but we can understand the environment it is created in.

In the USA and in China, it’s an environment where the ruling party actively dehumanise sections of the community, particularly Muslims at the moment, and black skin for centuries.

That environment is the context under which these consciousnesses are created. And whether the engineers agree with the government bias or not, their data will always be informed by it, especially where that AI is trained on historical data, news or social media.

How deeply will that consciousness embed the ideas of division and hatred, that one group is better than another, that one group is less than human? And if that’s its world view, what decisions will it make?

And it’s not theoretical. We know machine learning algorithms routinely discriminate against black skin, non-European names, female job applicants, and more.

Without active anti-discrimination training, all these algorithms will build these white supremacist biases in, and that will be their world-view. Their water will be division and discrimination and they won’t be able to see it.

Because those who train them are unable to see it.

Machines don’t have to be smart to be dangerous. But a machine that embeds that bias into its own world-view can do it opaquely, just as systemic racism doesn’t have to use discriminatory language to prevent black kids from getting to university.

Just one nudge after another to say “you don’t fit”, “this isn’t your world”, “try something else”, “behave more white”, “look less black”. (Why I’m No Longer Talking To White People About Race has a great section on a hypothetical black kid growing up and these barriers)

If you’re not actively building anti-discrimination into your AI, you are perpetuating white supremacy.

You are supporting fascism.

How will you be anti-racist today?

Why is CSS hard?

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

CSS is a real language, and you need deep technical knowledge to understand it. But plenty of software developers hate it and look down on it. It’s a good, if incomplete, tool for what it does. But I think it scares some of the gatekeepers who were drawn to software before the web.

It can’t be unit tested. It’s a language that only exists in a domain that stretches multiple sizes, multiple devices and multiple renderers. There’s more than 1 way to do things. And some of the biggest challenges with CSS are human. It’s the paintbrush for the bike shed.

https://twitter.com/craignicol/status/1074330589107507200?s=19

Funny how many hard problems in computer science, including cache invalidation, are about users.

If it hurts, stop doing it: the wrong process

Craig Nicol (he/him) — Tue, 07 Feb 2023 11:57:00 +0000

If something is painful, should you do more of it? Not if it’s painful because you have the wrong tool.

Sometimes though, it doesn’t matter what the tool is, there’s something more fundamental at play. A process that exists only because one thing went slightly wrong years ago. And rather thanimplementing a process to correct mistakes, somebody tried to prevent them.

Just like technical debt, this process debt adds pain to every feature, every bug fix, or every release. That pain can be removed by removing the process.

It’s painful because you shouldn’t be doing it

Does your test plan or your requirements sheet still specify IE as a supported browser? If Microsoft doesn’t support it why should you?

Are you spending all your time monitoring your staff, making sure they’re working when they’re not in the office? Do you struggle getting the right reports? Do you feel resentment from your staff even though it’s in their best interest? Or have you tried trusting them?

Is every release delayed because the database team and the security team have to review all code, and they’re already overstretched? Have you asked them how to provide confidence with less manual intervention? How to minimise the impact any change could make? How to add automation for common areas? How to train the developers to fix common issues upstream before it gets to the frontline teams?

Have you ever thought about deleting a process that isn’t adding anything? About making things simpler?

`The Untapped science of less : Inquiring Minds podcast’

If you truly want people to be creative and innovative, take them off the clock

Craig Nicol (he/him) — Fri, 03 Feb 2023 11:52:00 +0000

That doesn’t mean no deadlines, but no timesheets – don’t justify every 15 minutes with a project, because the next ideas aren’t about 1 thing, they’re about connecting multiple things.

They’re about taking time to pause and thinking about the bigger picture: what problems are you seeing in multiple places? Where else would that new thing you’ve built be useful? What are multiple clients asking for?

Mise en place architecture

Craig Nicol (he/him) — Tue, 31 Jan 2023 11:52:00 +0000

I love working with smart people. I learn a lot and it gives me energy.

I hate working with smart people who aren’t motivated. They’ll either get sloppy, get a new job, or get creative with their code design. The kind of creativity that makes you curse when you’re debugging a production incident at 3am.

The best creativity happens in a constrained environment, which also happens to make the easiest debugging.

Sure, we could let the developers figure out the best way to do something for every component, and there’s sometimes a benefit, but for every hour they’re spending figuring out how to solve a problem that didn’t need to be solved, or figuring out an unusual design, or evaluating a logging package, or writing boilerplate, there’s an hour not delivering value.

When an architecture is designed to put everything right where it should be, where decisions that have already been made are baked into the code and the tools, where a developer doesn’t have to think about how to structure their solution, the code is easier to write, easier to review and easier to debug.

Chefs like to follow mise en place. Everything in its right place. Before preparing a dish, prepare the workspace, the knives, and the food. Everything you need for the task and nothing you don’t. Everything is in a predictable place. Because then you can concentrate on the dish, instead of the kitchen. Good preparation helps every task fall into the pit of success, and makes it easier to recover if something goes wrong.

The more steps you have to complete a subtask, the easier it is to make mistakes. You might forget what the previous step was, you might walk to the fridge and then have to return to your workspace to remember what you need. Multitasking adds friction and adds opportunities for error.

That’s why we want encapsulated classes and single responsibility. One change updates one file, as far as possible. Although one feature may cover many changes in order to make it possible. Isolate your code from the data store, isolate the public API from your code, parse don’t validate.

Keep smart people working on solving new problems, and keep them consistent, because that’s the way to get the best from the team at all times, especially when you have a Priority 1 to update a logging framework at 3am.

You need a manifesto

Craig Nicol (he/him) — Fri, 27 Jan 2023 11:53:00 +0000

My software engineers’ manifesto:

We write software to solve problems, not to create them.
We write software for everyone.
Those who don’t write software have things we can learn from.
Always leave the project better than you found it.
Sometimes the best contribution you can make is not writing code.
Sometimes the best contribution you can make is deleting code.
Sometimes the best contribution you can make is by talking to someone.
Software is inclusive. Women broke the Enigma code, and black women got us to the moon.
If you don’t hate in 5 years what you’ve written today, you haven’t learned enough.
If you don’t have compassion for whoever wrote that code 5 years ago, you haven’t learned enough.
If anyone can’t use your software, that’s a bug. Prioritize accordingly.
Overtime is a bug.
Debug your processes with as much attention to detail as you debug your code.
Asking for help is a sign of strength.
Work with the best. Don’t lower your standards to only work with straight cis white men.
Be pragmatic. Shipped code is far more useful than perfect code, but if you can have both, future you will thank you.

Inspired by: You Need A Manifesto https://pca.st/episode/33cb401f-a028-4de2-b20d-ec2c96f2b019

If it hurts, stop doing it : the wrong tool

Craig Nicol (he/him) — Tue, 24 Jan 2023 11:17:05 +0000

There’s a theory under agile, lean and similar methodologies that if something is painful, you should do more of it. If releases are infrequent and error-prone and once a quarter, do them 10 times a day and they’ll get easier.

Same idea with performance reviews, customer feedback, and security audits. If it’s a good idea and it’s painful, practice it and refine it until it’s natural and mostly painless. And the pain that’s left is manageable. Roll back the release, and have another catch-up tomorrow once tempers have dampened.

I’ve seen people make the mistake of assuming that it should apply to everything. Every pain point is a gathering, a thing to be controlled, minimised and made less painful, by repeating it over and over again. After all, if it works over there, it should also work over here.

But not all pain is equal.

Remember, focusing on doing something more means that we deal with the pain by eliminating it. We automate releases so we can throw out that painful checklist. We give small, actionable feedback at the time, rather than a sucker punch that brews for months until it’s released in the appraisal.

But don’t mistake pain for discomfort. Making big improvements will mean transitions that are scary and uncomfortable. And what’s painful for someone else might not be painful for you. That doesn’t mean the pain isn’t real and it still needs to be dealt with.

Here’s a few things that are painful because you shouldn’t be doing them. These are the pebbles in your shoes that you need to remove.

It’s painful because it was never built for that

I know there’s a lot of hate for JIRA. It’s the tool of choice for “Safe Agile” enterprises. Andit gets a bad rep for being an overcomplicated monstrosity.

I was a JIRA admin once, bringing the tool into our enterprise. There were things I didn’t like about it on a technical level, but the central tool, with the defaults, isn’t terrible. But it’s so customisable, that you can codify any corporate process you like. And when it causes frustration, people blame the tool, not the admin. When the tool is the process, it makes concrete what people could fudge, and suddenly everyone has to work the way of the manager who needs to show their impact.

Start with the people. Don’t build a process around what people should do. Find out what they actually do and build from there. Some of it might be wrong, but find out why, and help them fall into the pit of success.

Don’t blame the tool for a broken process.