DEV Community: Craig Nicol (he/him)

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

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.