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

Advertisement

How to make mistakes

Nobody is perfect. If you tell me you’ve never made a mistake in your career, not only will I not believe you, I won’t be able to trust you.

In a safe and functioning team, we can accept our mistakes, discuss them openly, learn the lessons, improve our system, and move on.

Without that, we’re trapped not by our mistakes but by our fear of making them and our fear of the consequences when our mistakes are inevitably surfaced. And “our” mistakes quickly become “your” mistake. Not a failure of the team, not a failure of the system – the processes, the automation, the communication, and the rest – but a fault of the most vulnerable and the most exposed. “It’s always the intern.”

No one makes the intern pilot responsible for a jet plane. They start in small props and in simulators. They are supported and mentored. They are given space to practice, and to fail. Because what really makes the difference isn’t avoiding mistakes, it’s recovering from them.

Build for failure

Test-first, red-green-refactor: every new feature starts with a failing test which we then fix. Make failures part of the process, small and recoverable. Expected.

Build for backup, rollback, recovery. Test for failure continually. And recover automatically if you can.

Plan for failure

Be agile. Try new things for a day, or a week, or a year. Decide in advance what success and failure look like and monitor them. Adjust course if things aren’t working. Celebrate what you learn either way..

Move fast and bend stuff, don’t break it. Do and succeed, or do, fail and recover.

The longer a decision takes, and the more you invest in it, the harder it will be to change it, and the bigger a mistake it will become. So make it quick and don’t make it permanent.

Lead for failure

A leader needs to set a clear direction. To resolve conflicts by stating strong opinions and sticking to them. It makes conflicts easier to resolve. Until those opinions need to change. Maybe the mistake is yours, maybe it’s wrong because other things have moved on. It’s ok to change your mind, so long as you can explain it.

And then go read about why Cognitive Dissonance makes all of this so hard, by reading “Mistakes Were Made”

Ideas for a second coding project

You’ve done the tutorial, what to build next?

Maybe one of the following:

• To-do app
• Shopping cart (up to the point of collecting payments)
• Bouncing balls

Don’t worry about building something unique. If you’re building something with lots of examples, you’ll have something to refer to when you get stuck.

Find something you know. Something where you can write down 5 requirements now without research because it’s something you use or an itch you have. And then you can work back from those requirements to the features you need to build. That’s the heart of programming. Not writing for the computer, but translating from human to machine, breaking things down and formalising them into simple rules.

And that’s when you realise programming usually doesn’t involve maths. It’s about thinking logically. What are the mechanics of the feature?

It’s not: I want list of tasks. It’s:

• When I open my tasks, then I can add a new one or mark an existing one as complete.
• When I type in a text box and hit Enter, then a new task is added to the list.
• When I click the checkbox next to the task, then the task is removed from the list.

There’s an action and a reaction that the machine understands. There’s choices of actions that the user can make.

Use what you learned in the tutorial to translate those actions into simple functions, and to translate the choices into a user interface, whether web, native, command line or API. Then look at it, and make it easier, faster, more secure, or add more features.

The goal here isn’t to learn a specific language, although it will help you do that, it’s to think about how to take an idea, or a requirement, and translate it into something the computer will understand. I think this is the hardest part of the journey, but it’s the most important. I’d also recommend trying programming challenges such as Advent of Code or Project Euler to get practice of writing and thinking.

Good luck on the next, biggest, step of your programming journey.

“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

How to debug

Congratulations on your first day on your first software job.

Like many of your peers, you’re starting on support. Because reading other people’s code gives you a great feel for what’s nice to work with and what isn’t, and dealing with customers helps you understand what’s important and what isn’t. You will write better software knowing both these things.

But as this is day 1, we’re not going to expect you to rush in and fix everything. Take your time to look around and understand things. Your first bug fix is as much about learning the process as it is about fixing the problem. Because the process exists to help make sure this bug is fixed now and forever, and that this fix doesn’t break something else.

You wouldn’t fix a smoke alarm by removing the batteries, although that will disable the alert. Let’s find the root cause and fix that instead.

From experience:

1. Treat it like science : have a hypothesis and test it. Don’t just randomly change things.
2. Make notes on every hypothesis, test and discovery. One of them will be important but you likely won’t realise it at first.

From experience:

1. Treat it like science : have a hypothesis and test it. Don't just randomly change things.
2. Make notes on every hypothesis, test and discovery. One of them will be important but you likely won't realise it at first.

And once you've fixed it, do self-retro.

— craignicol 😷 💉💉 (@craignicol) August 31, 2020

And once you’ve fixed it, do self-retro. What went well, what didn’t go so well, what do you wish you knew, what are you going to research to prepare for next time, what are you going to publicise about this fix for the next person to sit in your seat?

Well done on fixing this bug. There’ll be another along in a minute.

How will you write your next feature to make this easier next time? How will you write it so the next time is less frequent? How will you pay things forward to help the next developer, who may well be your future self?

No politics at work

No politics at work.

We’ve got these tabulating machines to send to Hitler.

Talking politics doesn’t get us paid.

There are plenty of companies withdrawing into their shells of privilege because the founders are scared of getting uncomfortable.

If you want a more uplifting picture of what happens when you talk politics at work : you save lives.

Whatever the antecedents of the recent wave of decisions to ignore people’s lives by “not talking politics”, the effects are defiantly anti-union, anti-women, anti-BLM, anti-trans and pro-christian-conservatism.

Even at companies who may have introduced these policies as a reaction against actual fascist viewpoints on their internal discussion boards (which I haven’t seen is the case, but I have heard some justify it that way), banning all politics supports the fascists.

It chills the speech of the oppressed, and gives fascists ammunition that “our free speech is under attack”.

There’s plenty of policies that allow you to talk about maternity leave and single payer healthcare without allowing blood and soul nationalism.

Companies that ban all politics are companies that have weak leadership who only want to align with the prevailing winds, in the most conservative way possible.

Companies, especially tech companies, can change the world. But too often they just reinforce the status quo.

Even companies that want to liberate us from the office, or liberate us from fossil fuels, or liberate us from Earth, still reinforce the power structures that led to the problems they claim to want to solve.

To summarise this, and other points,

“we’re uncomfortable with you having a life outside work”

---

No politics at work.

We've got these tabulating machines to send to Hitler.

Talking politics doesn't get us paid.

— craignicol 😷 💉💉 (@craignicol) April 26, 2021

It's frustrating reading that after I reflected last year how disconnected the agile signatories were from the problems of inclusion in tech, and then thinking from their book that they had a better way. 🤬https://t.co/5LbbWUBIir

— craignicol 😷 💉💉 (@craignicol) April 26, 2021

omg that basecamp post is really smth

[image— repost with alt text of @freezydorito’s very accurate interpretation, original qt’d] https://t.co/h5NyJ80tvS pic.twitter.com/rvYkjRaVEa

— Lauren Kelly ✨ #UnsafeToBeMe (@thejsa_) April 26, 2021

To summarise this, and other points,

"we're uncomfortable with you having a life outside work" https://t.co/ZL3Br8jOwK

— craignicol 😷 💉💉 (@craignicol) April 26, 2021

return Task vs return await Task

The asychronous pattern in C# is great for simplifying the boilerplate of dealing with threads. It makes things look simple, but as with all abstractions, there are leaks.

In most cases, when an async method calls another and there’s no chain (e.g. public method calling a private method directly) return Task is fine, and avoids the overhead of the await state machine for that method.

BUT never do inside a using, or other scoped construct where the object required by the inner call requires context to successfully complete.

In the following example, the first variation, without the await, returns a database call that escapes from the context of the database connection at the end of the method, so when the call is made, the database connection has been closed. You need the await in the second example to postpone the disposal of the database connection until the GetUserAsync call returns.

In this example it’s fairly obvious, but the same pattern can cause threads to unravel far from where this fray was introduced.

class UserDetailsRepository
{
    public UserDetailsRepository(IDbConnectionFactory dbConnectionFactory)
    {
        _dbConnectionFactory = dbConnectionFactory;
    }

    public Task<UserDetailsResult> GetUserDetails(string userId, CancellationToken cancellationToken = default)
    {
        using (var dbConnection = _dbConnectionFactory.CreateConnection())
        {
            return GetUserAsync(userId, dbConnection, cancellationToken);
        }
    }

    public async Task<UserDetailsResult> GetUserDetailsAsync(string userId, CancellationToken cancellationToken = default)
    {
        using (var dbConnection = _dbConnectionFactory.CreateConnection())
        {
            return await GetUserAsync(userId, dbConnection,  cancellationToken);
        }
    }
}