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

Dear technical lead

I don’t know how you got your promotion, but I hope you’re a little scared. If you’re not, there’s a good chance that your arrogance will be your downfall.

If you got the job because you want what’s best for the team and the project, then congratulations and welcome to your new challenge.

Your job is still to produce the best product you can, but your toolkit has expanded. It’s no longer just about the code you write, it’s about helping the team produce the best product. It’s about developing processes, building a framework for everyone to work in, whether technical, social, procedural, ethical, anything that’s required.

You’re not doing it alone. You need a good relationship with your PM, your product owner, whatever role your company has.

Relationships are key to your new role. One-to-many when discussing the strategy for the project to the team, and one-to-one discussions with the developers and the stakeholders. Those relationships are the key to your expanding toolkit.

Learn about your team, what are their motivators, strengths and weaknesses. Give them autonomy to work, but be aware of what choices walk the trade-off between upskilling the team and delivering the best product sooner, because upskilling the team helps you deliver vNext, so your horizon has to be beyond this sprint.

Be a mentor.

Be decisive, even if others disagree. And stand by your decision until a better one emerges.

The next project you work on is likely to be the best learning experience you’ve ever had. Enjoy the opportunity. Seek and take advice.

Listen.

You got this.

Categories
development programming ux

In the beginning… was the conversation

The history of computing has been an evolution of conversation between us and machines. Single-purpose machines were built to be talked about, not communicated with. Even a hoax like the mechanical Turk.

But then the punched cards of the loom and Ada Lovelace’s ideas of a general-purpose computer started to become real, and we needed a language. At first, it was a language based on mathematics, the language of log tables, the language of angles, and then the language of letter frequencies. But soon we got more advanced, we got to the language of logic. Decision making, and computers, were open to working on anything.

And that’s where software engineers, programmers and developers enter the story. The medium of communication between the world of humans and the world of logic (because there has been no greater fallacy in human endeavour than to assume there is a complete overlap between the two, despite how many Nobel prize winners in economics have tried to prove otherwise).

The story of computers since then has been the story of building layers upon layers on top of machine logic to bring machines closer to humans. The command line, high-level languages (when C was considered a high-level language), graphical user interfaces, and the emerging field of voice and text conversation epitomised by Alexa and but Google and Facebook bots, but also the first line at the call centre, the first responder on live chat.

There has always been a conversation, and there’s always been a mismatch between our words and our intent.

As developers, our job is to derive intent from those words and the actions. Traditionally, offline in workshops and focus groups, but increasingly in real-time, teaching the machines to understand users and adapting conversions, websites, and apps, as we detect errors and confusion, as our data tells us users are unable to complete their goals.

There has always been a conversation. But this new conversation is with the users, and the machines, and the stakeholders, in real-time. With incomplete and biased data.

Be forgiving in your conversations. No one knows what this global conversation is like. But we know from social media and the news that not everyone in the conservation is pursuing truth and simplicity. But that is the only logical route, and behind all the facades is whatever truth you’ve built into the system. Are they the truths you can stand behind? Are those the truths that help and empower people?

Communicate your truths clearly and without favour, because this conversation is never pure or simple, and we have unearned power to control and shape that conversation. I don’t know if anyone would have chosen to give power to the developers and make us responsible for the truth, but in an information economy, that’s where we are. All these conversations are our conversations.

Tech is not neutral.

Speak your truth and recognise your responsibility.

Further reading

Neal Stephenson – in the beginning… was the command line

Conversation is the command line of tomorrow

Categories
development programming

Don’t be a speed shaver

CW: description of blood.

There’s a deadline looming, and your estimates show the project coming in late. Very late.

You need to claw it back. Drop the ballast and become a lean mean coding machine.


You have a plane to catch. You look at your watch and you’re going to be late. Very late.

You need to cut corners. Shave as you shower. No time for shaving foam in the mirror.

The first cut is annoying. Your cheek stings in the heat, but you keep going.

A second cut, right on the chin. That one hurt. And it’s dripping rather than seeping.

But you need to finish. You don’t have time for this. Keep going.

Missed a bit, back under the chin.

4 cuts. 3 seeping and one dripping.

And the heat keeps them open.

So you patch it over with tissue once you’re out of the shower, try and clean it up to see what you’ve missed. And then you have to go back in and finish the job with cold skin, so more nicks, and more time is taken.

Aftershave to help seal and clean. That’s sore. That’ll sting until you get on the plane.

More tissues, and then plasters. Trying to get dressed without getting any blood stains, so that’s slower too.


Every shortcut you take has consequences. Technical debt pays interest, and sometimes it’s eye-watering. The debt exceeds the functionality and the project takes longer, and even longer than that. And so you have to make more cuts and ensure more pain. And still, your clients can see it’s held together with plasters that are already starting to peel.

Don’t be a speed shaver. You don’t have enough time to do it quickly.

Categories
development leadership

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.

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”