You need a manifesto

My software engineers’ manifesto:

1. We write software to solve problems, not to create them.
2. We write software for everyone.
3. Those who don’t write software have things we can learn from.
4. Always leave the project better than you found it.
5. Sometimes the best contribution you can make is not writing code.
6. Sometimes the best contribution you can make is deleting code.
7. Sometimes the best contribution you can make is by talking to someone.
8. Software is inclusive. Women broke the Enigma code, and black women got us to the moon.
9. If you don’t hate in 5 years what you’ve written today, you haven’t learned enough.
10. If you don’t have compassion for whoever wrote that code 5 years ago, you haven’t learned enough.
11. If anyone can’t use your software, that’s a bug. Prioritize accordingly.
12. Overtime is a bug.
13. Debug your processes with as much attention to detail as you debug your code.
14. Asking for help is a sign of strength.
15. Work with the best. Don’t lower your standards to only work with straight cis white men.
16. 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

Advertisement

If it hurts, stop doing it : the wrong tool

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. And it 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.

Stop working when you’re ill

Want to stop people from working when they’re ill?

1. Pay them.
2. Warn them if you find they are working. The culture should expect everyone to recover before working.
3. Encourage everyone to have an illness plan – where can anyone find what work needs to be covered, and who’s best placed to cover it.

See also: working when children or parents are ill.

Processes upon processes: the JIRA trap

It is fashionable to hate on JIRA for software developers. Project Management made spaghetti. It has its faults, but the biggest issue is what it allows. It’s not opinionated, so any user can define any process to follow. It’s a perfect machine for generating red tape, or paper clips.

Because every time something goes wrong, the natural instinct is to add a new process, a new safety net, to make sure it doesn’t happen again [see Agile is Dead blog post]. And once added, they’re very difficult to remove.

So we get processes upon processes, the simple rhythm of a ticket lifecycle or of a sprint adorned with Deferents and Epicycles as we try and tame ever-increasing complexity with more text boxes and more statuses.

Complexity cannot fix complexity. But who has time for simplicity? This is the fundamental paradox of enterprise that Agile, and every “new big thing” is meant to resolve: complexity is added to reduce risk, but the complexity itself creates risk, and makes the risk harder to name, harder to spot, and harder to recover from if it is realised.

We have the 5 whys, the blameless retrospectives. And whilst the intention is sound – blame the system, not the individual – the solution is often to add new trinkets around the edges of the system. And reinforce that the system is the only way. They mistakenly put process at the centre, and ask the people to support the process, whereas the process should support the people.

But of course, this creates the shadow IT departments and the “non-compliant” centres. One place I worked had a strict policy that no one has admin rights because that fixed a problem lost to the mists of time. I understand the benefit of the policy, but at the time all our developers were working on IIS and couldn’t develop the websites we were paid for without having admin access on our machines. And so we had dispensations and workarounds until ASP.net core fixed the underlying issue of requiring admin access to serve web content.

Some companies stack procedure on top of procedure because the project is the centre of their universe rather than business value. And every company is in danger of falling into that trap as they treat risk management as risk elimination, instead of mitigation or recovery. They condemn every project to the tarpit of success, sinking below the crushing weight of process where sunlight cannot penetrate.

You will never have a process that prevents the next failure. You need a process to detect and recover, and you need to remove 99% of the “just in case” procedures from your process.

You don’t need to double-check the prime DVD copy before sending it for distribution, because no one has a DVD drive on their servers. You don’t need to change the admin passwords when someone leaves because there should not be an admin account that isn’t attached to a user. Eliminate the process, because every process you have is a process someone can forget. The best process is one you don’t need because the risk it mitigates cannot be represented by the system.

Either accept that you are not the centre of the universe and rewrite your rules to understand that you merely orbit the sun like so many others, or live out the fantasy that you are special, that your problems are unique, and add deferents on top of epicycles when the universe tries to disabuse you of that notion.

You can’t control the universe, only how you react to it. So don’t use JIRA to enforce pi to be 3.2.

No one thinks like you

Don’t make the mistake of thinking you’re the smartest person in the room. You might be the most knowledgeable about your specialist subject, but being a good boolean whisperer does not automatically make you an expert on public transportation, psychology, poverty, history, finance, or any other industry.

I’ve had the privilege of being disabused of that notion very early on in my career, surrounded by statisticians, linguists, psychologists, designers and vets. I do what I do, and let my curiosity take care of the rest.

But there’s a lot of arrogant arseholes in this industry who think they know best. Those who will talk instead of listening, who belittle, interrupt and condescend. They know their domain very well and are quick to criticise others who don’t understand.

But we all have our own models of how the world works, our own coordinates on the axes that describe the world as controlled by us vs controlled by others, whether money or relationships are more important, whether people matter more than animals, whether humanities can survive without science or science without humanities, visual thinkers or verbal thinkers or lingual thinker or kinetic thinkers. We don’t perceive or act in this world in a way quite like anyone else. We all bring unique experiences and perspectives to the table, and we all know something that others can learn from.

So sit and listen in silence. Take in what you can, and when you’re ready, ask questions. Listen to understand, not to respond, not merely to be polite, but because you are interested and you want to learn.

If we could see how others see us? They’re talking. All you need to do is listen.

Managing across distances

As the government is starting to ease lockdown and put together timescales for allowing a return to the office, I thought it was worth revisiting some of the ideas I discussed in cross-country coding to see what applies to the upcoming hybrid world, where we know we’re capable of working remotely.

Obviously there will be done time to adjust as we inevitably feel with the mental health consequences of the anxiety of returning to the office as well as the adjustments we’ll need to add or undo to deal with family life, all the new pets and babies that have joined since the start of lockdown, and the mental space we’ve held for new hobbies, for home schooling, for the new health rules.

So take this as a waypoint on some future journey.

I’m not qualified to talk about the mental distress or whatever changes you need to accommodate in your life, but I want to think about how your employer and the technology may need to work in this brave new world.

• Face to face matters. If you’ve seen someone out breaks down barriers to talking to them. Video beats phone, in person beats video.
• Trusted insiders are very useful, when there’s multiple offices, or a team you need to check in with that you’re not in all the meetings for. There’s always small things that are missed when you’re just looking through the window.
• Invest in video. It needs to be good quality. Get better broadband. Get better webcams. Get better microphones.
• But try and be asynchronous. As soon as there’s friction to synchronous communication, collaboration plummets.
• Reminder that in open offices, people prefer electronic communication. “The impact of the ‘open’ workspace on human collaboration | Philosophical Transactions of the Royal Society B: Biological Sciences”
• Set expectations. Emergent behaviours only happen through observation and feedback, and distance dampens both dramatically

“He never did that to me”

Men,

If you’ve never listened to women on the internet, take the opportunity.

Sleazeballs and fascists may never show their true face to you.

When they show their true face to others, stand and bear witness, or be complicit.

All it takes is for good men to do nothing.

Sure, he’s never like that to you, but where there’s bad words from who you thought were good people, believing good intent and giving the benefit of the doubt can embed their harm in your culture. Call them out. Let them prove good intent by using the experience to learn. If they improve you will see them re-centre the most vulnerable. If not, there was not good intent, just pronouncements from privilege that isn’t prepared to accept fault.

If you want to be good, learn the penguin hustle : keep the most vulnerable in the middle, and those privileged enough to be strong rotate at the edge. So when you feel weak or vulnerable, someone else will take your place. Don’t smother them, and please listen, but the most vulnerable will always suffer a shitstorm of abuse. They need allies to call it out so they’re not drowning in it.

Trust someone on their actions towards towards those who are more vulnerable, not to you who they see as an equal, and maybe a threat. Fear may keep them in place around you, but that’s just a mask to protect who they really are.

And don’t expect others to speak up. For some, simply existing is bringing politics to work.

Men,

If you've never listened to women on the internet, take the opportunity.

Sleazeballs and fascists may never show their true face to you.

When they show their true face to others, stand and bear witness, or be complicit.

All it takes is for good men to do nothing…

— craignicol 😷 💉💉 (@craignicol) June 13, 2021

Be passionate about something that isn’t your job

There’s a recurring trope from the tech Ponzi schemers that you need to hustle in your youth. Work weekends. Work unpaid. Climb the ladder. It’s what they did, so it’s the only way.

It’s not.

Be passionate about your job. Be passionate about solving your customer’s problems. And be passionate about understanding and representing all your users.

But also be passionate about something else. Something that inspires you to leave the office. Something that satisfies a dream. Don’t narrow down your life to just your job.

Go surfing. Play in a band. Crochet. Spend time with your family and friends. Reset your ideas of what’s normal in working life, because the Ponzi scheme relies on you giving everything to your job, and convincing the next generation to do that too. Because the alternative is to look up and look around.

If you feel you need to work for free at the weekends, volunteer at a homeless shelter, not for a corporation.

Use your weekends for hobbies, for relaxation, for catching up with people in other industries and finding out that these opinions only exist in echo chambers.

If you feel you need to work for free at the weekends, volunteer at a homeless shelter, not for a corporation.

Use your weekends for hobbies, for relaxation, for catching up with people in other industries and finding out that these opinions only exist in echo chambers. https://t.co/OwroB6pq5f

— craignicol 😷 (@craignicol) June 13, 2021

Join the conversation on Twitter

Work your brain. Get new ideas. Reset your mind.

Watch TV.

Read books. Walk in the wilderness. Get out of the glare of the screens, and the superstars.

And don’t forget to wear sunscreen.

For more, listen to this podcast on making the most of your leisure time

Non-technical communication

If, like me, you love talking about tech, you may find it hard to speak to clients and managers who don’t. So I try and follow one simple rule.

Let go of the detail.

Have a summary that skips over it, because generally the people you talk to trust you on the detail. If you’ve ever had a boiler installed, they’ll never tell you what pipes they’re using, how it’ll context to the power supply. You agree on the boiler model and the installation date, and let them worry about the detail.

Sure, record the detail for yourself and your team, but make it available on-demand, not as a fire hose.

TL;DR; everything

Things I don’t know as of 2021

Things I don’t know

Last time round, I stated the things I didn’t know. Whilst the technical list hasn’t changed much, there’s a new set of skills I want to talk about for this year, as these are the things I want to know.

How to build a diverse team

I’ve worked in plenty of diverse teams, and I’m proud that we managed to build a team from all male to 50% female in the 2 years I was at my last job, but there was a lot of unique features about that job that makes it harder to replicate elsewhere. And some of the groundwork was laid before I joined.

How to be a good mentor

I started mentoring via coding coach last year, and I’ve had to tune my approach to each individual, but I’m still not sure the best questions to ask, and what’s the best structure. If I find out, I’ll share it here.

How to get a sleep routine

Sleep is important. But between the existential crisis of a global pandemic, with the subsequent upheaval of work processes, and the constant desire to get more done, I don’t always timebox what needs to be done, and things fall, including my blog, and my fitness. I have thoughts on how to prioritise and plan better, but I can’t control for external factors.

How to work remotely

Whilst I’ve been used to sort periods of working from home and working with teams spread across multiple offices, this COVID lockdown is different.

I’ve learned how to work asynchronously, but there’s no good replacement for the serendipity of a chat grabbing a coffee or over lunch. Whilst I’m cautious about returning, even when we can, I definitely look forward to seeing people in the flesh again. Even if we’re wearing masks.

Is there a better way to work?

Whilst trying to find how to work “like this, but over video”, I’ve started looking at how properly remote-first companies do it, reading DHH and Reinventing Work, and thinking if there’s a better way of organising work completely. Asynchronous, pull-driven, self-organised. How do open-source and open-contribution (e.g. Wikipedia) work, and are there lessons we can learn there to make companies more effective, more value-driven and more scalable?