DEV Community: Craig Nicol (he/him)

multiple points of failure – lawnmower

Craig Nicol (he/him) — Fri, 23 Oct 2026 10:13:00 +0000

There are a lot of ways things can go wrong. So you need a lot of levels of safety.

If your production site goes down, it’s always a system failure. Even if the entire system is a bunch of LLMs running on one person’s machine. There’s no reason why anything on your local machine should be able to make changes in production. We’ve had CI/CD pipelines with authentication and secrets management for long enough that it’s a solved problem.

I have an electric lawnmower. It plugs in via a circuit breaker, into a grounded 3-pin plug, attached to a mains unit with another circuit breaker. To start it, after plugging it in (and testing its circuit breaker), I need to push a button with one hand and pull a lever with the other. The motor will cut out, even in that configuration, if the resistance is higher than a threshold. The blades are not visible in use, because the cover completely surrounds them.

None of this prevents me from chopping my toes off with the lawnmower, but it makes it a lot harder.

So a good security system will have multiple fail-safe protections between the developer’s machine and the production environment, and ideally a mix of human and machine checks. Anti-virus, firewalls and network monitoring on the developer machine itself, as well as policies to keep everything patched. Review and limitations on the supply chain via container and package registries. Refusal to run code in a CI build if conditions aren’t met, and refusal to sign and publish until build, test and human review all pass. Refusal to deploy unless there’s a signed build. Refusal to accept any credentials except those in the secure store. Refusal to accept developer credentials to change the database.

Security isn’t easy. You have to win every hour of every day. The attacker only needs to win once. But every failsafe is another barrier they need to pass, and they only win if they can pass them all.

And for your own sanity, keep development and production isolated.

Slow productivity

Craig Nicol (he/him) — Tue, 20 Oct 2026 10:51:00 +0000

Productivity isn’t getting things done. It’s getting the right things done.

The push from so many management books since the rise of Taylorism, and now accelerated by AI, is that productivity is doing. It’s that productivity is not thinking. Productivity is not creativity. Productivity is not connection. Because we can’t measure thinking, or creativity or connection. And in most cases, it’s not even a second-order effect; it’s third order. The connection helps you build the next team which builds the product.

We can measure lines of code; we can measure velocity; we can count closed PRs and track how long a card was stuck in a status. We can build workflows in Jira that ensure the process is followed and every minute is accounted for. And users still want Trello.

The unmeasured work is what gives rise to experiments, or better relationships, or spotting the underlying problem. It makes the doing easier; it helps us find the best thing to do. It builds foundations for learning and for novel approaches to make the doing better. It’s the glue work that makes great managers great, and it is often the work us straight white men overlook because it’s the work that doesn’t show up on the timesheet or the dashboard, and when the people doing that work leave, everything they impact is a lagging metric; it’s the things that fall apart 3 months or 2 years from now because it’s no longer on the horizon.

The meta work is planning, learning, connecting, making space for mistakes; it’s resilience and duplication because we never want to rely on one person for everything. It’s stepping back to make connections, to consider a better way of doing this, to consider if this is still the right team culture for the current work, or the right structure. It’s recruiting now for the work you don’t know you’re going to need yet because by the time you know it’s too late to onboard someone. It’s building the safety nets and the monitoring and the maintenance. And it’s the work you always have to fight to justify because it doesn’t fit neatly into things that can be measured, automated and controlled.

And we’ve never been trained for it, at school or elsewhere. It’s daydreaming, it’s being lazy, it’s a waste of my time. It’s a walk in the woods, a long shower; it’s not moving your mouse despite your manager tracking you on that.

It’s not just slow work; it’s slow meta work.

Job hunter mental health

Craig Nicol (he/him) — Fri, 16 Oct 2026 10:28:25 +0000

Enough time has passed since my last job hunt that I can publish my thoughts to maybe help others, and definitely to talk to hiring managers and job platforms. And with LLM creeping into both sides, I’m hearing that it’s only getting tougher.

I don’t know if LinkedIn thinks it’s being helpful with the weekly update emails, listing 5 of the jobs I applied for a week ago and showing me only 1 was reviewed by the recruiter. And I know that the recruiter didn’t get back to me. I know there’s barrel–loads of spam on both sides of the job hunt, but I’m not sure a reminder of what a haystack we’re in is all that helpful.

With my manager hat on, whilst I always value openness and transparency, there are ways of presenting information which support and respect their mental health, and ways that don’t. And plenty of job seekers will be feeling vulnerable, rightly so, and reinforcing the learned helplessness that no one is even paying attention is really not going to help anyone.

There’s a few other posts going around about male suicide, especially concerning financial pressures. I don’t believe this is a mindful addition to LinkedIn.

I had a Trello board when I was job hunting, and the long list of “applied for” and the longer list of “waited more than 2 weeks/ghosted” were on the hidden end of the board. I should have set up an automatic move from the former to the latter so the only time I looked at them was when I got a response.

I can attest that a “thanks but no thanks” response is better than no response, even if the response was:

We have decided not to go forward for one of the following reasons:

This position is now closed to new applicants

Your CV didn’t contain the words “10 years experience shouting Abracadabra at hippos”

This job description only exists to give our current employees false hope that their workload will be reduced

Our AI has determined that you are a cat

With the “AI will take your job”, “inflation is still rising faster than wages”, “you’ll never afford to retire” stories, it’s a very tough market for job hunters. So recruiters, especially those feeling the pinch themselves, need to demonstrate more human compassion to job hunters. Not “hey, remember these people who aren’t thinking about you”, not a helpful “the green banner is Kryptonite to us recruiter superheroes”, just “this is tough, and the best we can give you is the truth, and a clean break”.

Let’s not make it tougher than it already is.

The product is never as important as the support

Craig Nicol (he/him) — Tue, 13 Oct 2026 10:52:00 +0000

You can’t vibe code your way to a great customer experience.

You need the user flows and the user journeys, but you also need to understand the system the user operates in. How much of their job do they spend in your tools? Is it the essential part of their job that they’ll spend time customising to their needs, or is it the necessary admin they need to get out of the way quickly to get back to what they need to do?

And sometimes the same product can be both, to different people in the organisation, or at different points in the week for the same person. The announcement email for the new product is exciting and gives them purpose; the email with all the receipts for the conference that allowed them to perfect the message is the annoying thing they have to do, especially with all those separate dinners and gifts for the research workshops.

Writing code isn’t a skill everyone has, but working code isn’t the most important thing a developer does. It never has been. The code exists for a purpose and exists inside a system, so the developer needs to know why the code exists and what other code is in conversation with it. We don’t think the carpenter’s job is cutting wood, but without measuring and cutting the wood, they couldn’t get the legs to fit the seat, and without those things connecting in the right way, they couldn’t build a chair for you to sit on.

Some companies have perfected the mass production of the legs and the seats, and they flat-pack them for you to assemble at home, but there’s still a human in the loop to understand how they fit together and provide the instructions on how to do so; there’s a human who understands why it exists and what weight it needs to bear, and how it fits with the table. And if anything goes wrong, there should be a human who can help to fix it, because the human understands that you need that chair for next week when your family are arriving, and there’s not enough space at your dining table.

Products succeed or fail not because of the engineering, or how they’re cut, although that can be a critical part of the success. A product succeeds when it meets customers where they are. And gives them something they didn’t know they needed. And helps them when things don’t go as expected.

Taking the human out of the loop takes the customer out of the loop.

If it hurts, stop doing it: the won’t do list

Craig Nicol (he/him) — Fri, 19 Jun 2026 07:52:47 +0000

We have backlogs to tell us what to work on next. Things that don’t fit in the current sprint, or things we want to work on but are blocked because there are things we don’t know.

Backlogs can also be graveyards, where we hold on to dead ideas because they seemed like a good idea, or we don’t want to disappoint someone, or we’d love to try that new library that came out 5 years ago. Where we want to remember the low-priority things that nag us.

Warren Buffett has an idea that if you write down the next 20 things you want to do, and then highlight the 3 most important, the rest of the list becomes “do not do under any circumstances until those 3 are done” because they become anchors that drag you mentally, that hold space rent-free because they’ve not been done.

Create a won’t-do list, a rejected list, a Pandora’s box, and a someday-maybe list, and throw all those things in there. They’re still safe, you’ll see them again if you want to, but you don’t have to think about them. Put reasons against them if you want; this isn’t a priority because X is more important, or because we don’t know whether A, B, or C will lead the market. We’re not touching things with a bargepole because the ethics team doesn’t trust them; so let’s never add this and tell everyone why.

Put them out of sight and out of mind, and give the ideas you want to work on the space they deserve.

MVP is a game of Jenga

Craig Nicol (he/him) — Tue, 16 Jun 2026 11:52:56 +0000

The M in MVP stands for Minimal. Lots of teams forget.

MVP is not Version 1.0; it’s not the kitchen sink. It’s the smallest thing you can build to answer your next question. Once your questions are answered: “can we, should we, build it, does this solve the right problem?” then build your feature 1.0

Take away everything you don’t need. Sometimes MVP is a paper prototype, sometimes a sign-up form. Lots of edge cases won’t work. It might not look pretty, but it will give you great feedback.

Viable doesn’t mean battle-ready; it just means possible.

The Andy Dufresne project

Craig Nicol (he/him) — Fri, 12 Jun 2026 07:52:31 +0000

Have you ever been stuck on an Andy Dufresne project?

You know the one. You’re trapped because of something someone else did, chipping away at legacy structures with just a rock hammer. And you might even have your own Rita Hayworth poster to hide the refactoring of this debt.

Sometimes that’s agency life. The promise of a rewrite (and your own boat in Mexico) if you can just chip away slowly and then crawl through half a mile of shit. It can be achingly slow progress, trying to get buy-in for your freedom, when the people with the power just want to keep you where you are. You’re trapped because of what someone else did.

And if you stay in that code too long, you’ll get institutionalised and won’t be able to see a better way to fix this problem.

‌How to keep making progress

Firstly, it’s much easier to survive a project like this if you have the right team beside you. People who can accept the faults and accept they’re temporary. You need a team of gardeners, not innovators, who can dig deep and understand what’s actually happening, where the rocks and the edge cases are. And who’ll take a break to listen to music or otherwise relax and take stock and look up.

And you need to understand the progress will be slow, but you can put guard rails in place so that each bit of progress you make has tests and is better than you found it. And sometimes you have to shake the refactorings out as pebbles amongst the other work because management and the clients don’t want to see it.

Never stop asking for freedom to make bigger changes, but always pair it with trust. They’ll listen more if you respect their budgets and their time, and you can explain what’s easier and what’s harder.

The Great Escape

If you do get the chance to rewrite, there may well be external factors at play. Use them. Digital transformation, going mobile, getting AI-ready. If you can tap into the strategy and find ways to align what you want with that, it’s going to be much easier to get approval. Be honest with the proposal, but always keep an eye out for those opportunities.

Look after Red

The only way to get the job done and get where you want to go is to take the important people with you. The ones who can get you a better hammer, or a new cover for the next bit of refactoring. Honesty will always get you further, so long as you know who to trust. Make it easy for them, so they can come with you on the journey.

See you on the beach.

Exes or alumni

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

I’ve seen a few posts on LinkedIn recently about both the mass layoffs done in the worst way and also posts about people wanting a second chance after leaving or turning down a job offer. And I doubt many of the former companies are having those latter conversations.

So how do you treat your former employees and employers? What culture are you showing to your clients, your contractors, your colleagues, and your candidates?

When the relationship ends, do you seek to cut yourself off, like a betrayal, or continue to foster a relationship, even slight, so that collaborations in the future are possible? Are there people and places you’d be happy to return to in the right circumstances, and the ones that got away that you still pine for?

Thinking back on my career, I definitely have a mix, but very heavily weighted towards finding paths back. Indeed, at least 3 roles, and a few interviews on top, have been due to reconnecting with people I’d previously worked with, and rekindling opportunities.

I never want to leave a relationship sour, even when there are cultural differences that mean I wouldn’t want to work somewhere again, there are always people and projects that I’ll keep an interest in.

So, for all those you no longer work with, or never got the chance to work with, are you testing them with bitterness, like the ex you blame for everything that went wrong when you were with them? Or do you feel like an alumnus, a community that grew with a shared goal, and still keeps in touch because your past will always impact your future?

Leave the Door Open for Employees to Return to Your Organization

Cloud thinking : Data in 3rd denormalised form

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

One schema to rule them all and in the darkness bind them.

That’s the SQL way. One schema, many tables, be efficient with space. Join, don’t duplicate. Third normal form and structured data. More structure.

But that’s not always the best way to scale. How important is it that everything is identical everywhere? How important is history? When a customer moves house, do you want to know the difference between the address they want their next order delivered to and the address the last order was delivered to?

When you let go of SQL and joins, and when storage is cheap, does it matter if you have multiple copies, so long as each document has the right copy for itself?

When you aggregate data, when your change log turns multiple orders into 1 delivery schedule for your driver, does it matter that the driver has their own copy for when they lose signal? Does it matter that there’s a copy of the addresses in the route that will be deleted tomorrow because it serves no more purpose?

If storage is cheap and joins and transmissions are expensive, wouldn’t you want to cache data and trade storage for speed?

Shouldn’t you embrace heterogeneous data? The address on your payment looks like the address on the order, but it serves a different purpose, it’s embedded in a different context, and it has a different lifecycle.

It’s sometimes hard to change your mental model, but it can save you from doing the wrong thing.

If it hurts, stop doing it: automating the wrong things

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

Automation is too easy.

Copy every email to Slack, copy every Slack message to Todoist, copy every new task to My Notion inbox, and send an hourly Summary of new Notion inbox items to my email.

And you’ll never look at any of them.

Having a productivity sieve is great, but you need to be intentional.

Every automation should start with Manual intervention, unless the first step is a filter. Star that email, bookmark-emoji that message. Be implicit with your intent. Let the automation copy to the right place and label and find related, but don’t automate the decision, or the firehose.

Be a Centaur, in charge of the Machine, not a reverse Centaur, controlled by it. Filter at the source, or the sewage will overwhelm you. Don’t let your vibe lead to overwhelm.

People before process.

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