Categories
development programming

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?

Categories
.net code data development

CosmosDb in The Real World : Azure Global Bootcamp 2019 (Glasgow)

Thank you to those who came to my talk today about CosmosDb. I hope you found it useful.

If you’d like to review the slides, you’ll find the presentation online here :

CosmosDb In The Real World – GitPitch

If you have any further questions please ask below and I’ll do my best to answer.

Categories
leadership

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
Categories
development leadership

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”

Categories
code development programming

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.

Categories
leadership

“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.

Categories
code development

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.

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?

Categories
free speech leadership

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”


Categories
.net code development programming

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);
        }
    }
}

Categories
development leadership lifehacks

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.

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

Categories
development

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

Categories
lifehacks

Productivity sieve

There’s a lot of information out there. And more generated every day than you could process in your lifetime. So you need to filter out the important nuggets and discard the rest. The most important thing is what you ignore, because you’ll be ignoring most of it.

Many productivity frameworks deal with this problem the same way. Take
the firehose of emails, RSS feeds, Twitter recommendations, that book at the meetup, … and collect them in one place (or, if you really must, 2 – one physical, one digital).

Only add things that look interesting, and be intentional about it. Not every email or every tweet, just the ones you’ve marked (IFTTT or Zapier are a great help here). That’s your first filter.

Then, at a scheduled time, on a regular schedule (weekly or fortnightly) decide what you’re doing with everything in the one place. That’s your second filter.

Then, for the things you’ve decided are important, review them, rewrite them, record them. Your words are the next filter.

And don’t be afraid to rewrite, to delete. I use git for my notes so I know I can keep things clean and look at the history if I need to.

Or, to put it another way:

Put everything in your Universal inbox (Trello, Evernote, Notion, …) – one place for “this looks interesting”, from web, photos, videos, etc. but only what you’ve chosen to put in. Don’t let another person or an algorithm choose for you.

Automate the copying, not the decision to copy.

Each week, for everything in your inbox, make a decision.

πŸ‘‰ Either “this is useful” – archive and tag
πŸ‘‰ Or “this is actionable” – add to task list
πŸ‘‰ Or “why did I bother with this” – bin it

Split tasks into “now and next” and “coming up”

πŸ‘‰ “now and next” is stuff planned until your next horizon (tomorrow, next week, next sprint),
πŸ‘‰ “coming up” is the rest of the stuff important from your latest planning session (this week, this month).
πŸ‘‰ Everything else is unimportant right now, and either is in the ideas archive waiting to be promoted when the project is attached to resurfaces, or is dated to surface at the right time (e.g. annual subscription)

Don’t carry excess weight.