2022 reflections

2022 seems to have been a strange year for a lot of people. There’s a lot of bloggers I follow whose output dropped a lot this year, myself included. Some of that I’m sure is a seeming loss of community, with changes to Twitter and Facebook, and I’m sure Google’s AMP as well, there’s been less drive-through traffic and less engagement.

I also think online discourse in many places is following the lines we see in politics where subtlety and nuance are increasingly punished and every platform is pushing shorter form content. We’re not giving ourselves time to digest and reflect.

And we should.

The pandemic is still here, but we’re adjusting, working from home is a natural state for many of us in tech, although that’s not an arrangement that plays to everyone’s strengths, so let’s make space for different companies with different cultures. There’s new ways of working to explore (hello the UK 4 day week experiment), people have moved jobs to take advantage of the change and create more family time.

But we can’t escape the world outside tech, and many of us are burning mental cycles on disease, on the massive weather events from climate change, on war, on the continued assaults by the far right, and watching inflation tickling upwards. It’s not an environment that leads us to our best work. It’s not an environment that helps us be in the moment.

Through 2016-2021 the world stared into the abyss of the rise of the far right, and the dismantling of certainties, before we were all thrown into lockdown. We were hoping for a turning point this year, but our leaders were lackluster in improvements, pulled us further to the right or were just plain incompetent. Instead of hope to counter the dispair, we got indifference at best Rather than turning away from the abyss, we collectively chose to build a car park next to it.

The greatest minds of our generation are building pipelines for ads for things we don’t need and can’t afford, whilst the AI engineers are building complex transformations that churn out uncanny valley versions of code, of mansplaining and of other people’s art. But of course the AI is built on a corpus of our own creations, and I don’t think we like the reflection looking back at us.

Ethics in technology isn’t just about accurately reflecting the world as it is, or how the law pretends it is (or seeks to adjust what is), STEM at its most important shows us the world as it could be. An airplane isn’t just a human pretending to be a bird. A car isn’t just a steel horse.

Yes, these advances in AI are cool parlor tricks, and they will lead to great things, but just like drum machines didn’t replace drummers, we need to get past the wave of novelty to see what’s really behind the wizard’s mask.

AI is dangerous. Look at how machine learning projected racial predictions on zip codes based on historical arrest data. Look at how many corrections Tesla’s “Self-Driving Mode” requires. Look how easily ChatGPT can be manipulated to return answers it’s been programmed not to. But, with the right oversight AI encompasses some very useful tools.

Let’s get out of the car park and look away from the abyss. What does the world AI can’t predict look like? After years of despair, what does a world of hope look like? What does the world you want for your children, grandchildren, nieces and nephews look like?

Land on your own moon. What’s your 10 year plan to change your world?

Advertisement

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.

Are Gen Z less technical?

Scott Hanselmann had some thoughts on Gen Z and their knowledge of technology – is their knowledge less advanced than the previous generations?

@shanselman

#stitch with @glittering_ghostwriter is this generation less tech advanced than the last?

♬ original sound – Scott Hanselman

It depends what you mean by technology.

I get that understanding files and folders are useful right now for understanding software and that part of our job is to teach that. But are they dying out?

My dad, as a Chartered Electrical Engineer, was a dab hand at valves, capacitors and a bunch of electronic circuitry which has mostly been made obsolete by embedded systems using old CPU designs and lots of C. It’s not just that there’s missing levels of abstraction, that layer doesn’t work like that anymore.

And in the web and big data era, I’m not sure we can say the underlying structure consists of folders and C drives. Web pages, social media, political movements, note-taking apps, presentations and APIs are built on relationships and multiple facets, not hierarchy and The One True Way. I loved delicious and GMail. Despite growing up on DOS, and later Windows and Linux, tags always made more sense to me than folders (heck, I even built a proof-of-concept of a tag-driven file system based on how I used delicious).

And as all the major languages embrace more functional composition over object hierarchy, will the structure of code itself follow? Look at how we’re starting to compose web applications, there are hierarchies of visual components, but the new ECMAScript is modular, and uses URLs instead of hierarchies to organise code. Microservices are loosely coupled and have no concept of hierarchy between them.

Well-architected systems these days have service buses, temporary storage, network queues, and caches. There’s an asynchronous, distributed world that all the code lives in. That’s a very different technology to what I grew up with and started developing in. But it’s very similar to a world where kids communicate primarily by text, 1:1 or in group chats, where people post on social media and don’t know who sees it, where live streams become YouTube videos, where Slack, Discord and others make chat searchable and allow people to catch up in their own time. Where people have to track multiple channels asynchronously to keep up to date with their friends.

The generation of developers who will build the next serverless and distributed applications, the fediverse generation, the XR voyagers, and the web3 generation – whether or not web3 itself becomes the next big thing, may find that those who think in terms of folders and hierarchies are limited in their ability to grok the systems required. Moderation in a hierarchy has failed multiple times. Twitter’s latest problems are not the only example. Amazon famously prefers small autonomous technical teams instead of big central planning. Google tried to get rid of managers, until they realised managers have a role beyond supporting the hierarchy.

Yes, Gen Z have limited knowledge of some of the foundations of the technology we use today, but that’s just because those abstractions aren’t useful anymore. I’m sure some will embrace those abstractions, just as some embrace chiptunes and C64 restorations. But the foundations of yesterday’s technology will seem as archaic as valves or punched cards to whoever the next tech billionaire is.

Are we going to be the dinosaurs, as the next wave takes over? We’re the generation who let go of memory management, semantic line numbers, and significant whitespace. They may well let go of hierarchies, disconnected machines, and object-oriented thinking.

The future is here, it’s distributed, it’s asynchronous, and it’s theirs.

Name your problems

A rose by any other name would smell as sweet.

Names matter. Names are a container for all we know about a person or a thing. Names give us a reference that allows us to abstract the detail to whatever level makes sense today.

And big hairy problems will be referenced a lot. Big hairy problems will turn up at retrospectives where you can look at the detail and stand-ups where you can’t. They’ll manifest as bugs in some parts of the system, workarounds in others, and sometimes features in other places. They’re problems that aren’t one fix, they’re code and infrastructure and process changes.

Sometimes the problem has an optimistic name: “Project Nightingale – to make data sing” because it’s much nicer to work on that than the “our charts are fundamentally broken and everyone hates working on them” problem. Sometimes it’s a description that helps visualise the issue: “the pinball routing problem” when the redirects in your webapp fill up your network, and it’s hard to see which page to show for the current state “Am I adding strawberries to my shopping cart, or am I paying for them separately?”

A good name helps keep everyone focused and provides a focal point that everyone understands.

I know naming things is hard, but naming hard things makes them easier to work with. And it doesn’t have to be a descriptive name. If you’re struggling, name them after hurricanes, or characters from Glee, or Tour De France winners, so long as they’re unique enough that you won’t get 2 of them confused.

Name your problems. And conquer them.

The conscious machine

This is a fantastic explainer of the threats and risks, and opportunities of AI. Thinking about the nature of consciousness. Can we ever say truly what a machine consciousness is, or how it feels?

Max Tegmark – When Our Machines Are Smarter Than Us – Clear+Vivid with Alan Alda
Up until now, we’ve been smarter than our tools. But that might change drastically sooner than we know. Isn’t it time to think about that?

As a white man, I have no idea how it feels to walk this world in darker skin. I can understand fear, but not the constant fear of being stopped by police, of watching my back.

I can understand what is happening, and fight to change it, but I’ll never understand how it feels to be in that position. Equally, a machine will never be able to understand how that feels, although it may be able to approximate the behaviours expected of someone who does.

AI is being built with a Western and a Chinese perspective. We cannot understand what a conscious machine will be like, or how it feels, but we can understand the environment it is created in.

In the USA and in China, it’s an environment where the ruling party actively dehumanise sections of the community, particularly Muslims at the moment, and black skin for centuries.

That environment is the context under which these consciousnesses are created. And whether the engineers agree with the government bias or not, their data will always be informed by it, especially where that AI is trained on historical data, news or social media.

How deeply will that consciousness embed the ideas of division and hatred, that one group is better than another, that one group is less than human? And if that’s its world view, what decisions will it make?

And it’s not theoretical. We know machine learning algorithms routinely discriminate against black skin, non-European names, female job applicants, and more.

Without active anti-discrimination training, all these algorithms will build these white supremacist biases in, and that will be their world-view. Their water will be division and discrimination and they won’t be able to see it.

Because those who train them are unable to see it.

Machines don’t have to be smart to be dangerous. But a machine that embeds that bias into its own world-view can do it opaquely, just as systemic racism doesn’t have to use discriminatory language to prevent black kids from getting to university.

Just one nudge after another to say “you don’t fit”, “this isn’t your world”, “try something else”, “behave more white”, “look less black”. (Why I’m No Longer Talking To White People About Race has a great section on a hypothetical black kid growing up and these barriers)

If you’re not actively building anti-discrimination into your AI, you are perpetuating white supremacy.

You are supporting fascism.

How will you be anti-racist today?

Why is CSS hard?

CSS is a real language, and you need deep technical knowledge to understand it. But plenty of software developers hate it and look down on it. It’s a good, if incomplete, tool for what it does. But I think it scares some of the gatekeepers who were drawn to software before the web.

It can’t be unit tested. It’s a language that only exists in a domain that stretches multiple sizes, multiple devices and multiple renderers. There’s more than 1 way to do things. And some of the biggest challenges with CSS are human. It’s the paintbrush for the bike shed.

https://twitter.com/craignicol/status/1074330589107507200?s=19

Funny how many hard problems in computer science, including cache invalidation, are about users.

If it hurts, stop doing it: the wrong process

If something is painful, should you do more of it? Not if it’s painful because you have the wrong tool.

Sometimes though, it doesn’t matter what the tool is, there’s something more fundamental at play. A process that exists only because one thing went slightly wrong years ago. And rather than implementing a process to correct mistakes, somebody tried to prevent them.

Just like technical debt, this process debt adds pain to every feature, every bug fix, or every release. That pain can be removed by removing the process.

It’s painful because you shouldn’t be doing it

Does your test plan or your requirements sheet still specify IE as a supported browser? If Microsoft doesn’t support it why should you?

Are you spending all your time monitoring your staff, making sure they’re working when they’re not in the office? Do you struggle getting the right reports? Do you feel resentment from your staff even though it’s in their best interest? Or have you tried trusting them?

Is every release delayed because the database team and the security team have to review all code, and they’re already overstretched? Have you asked them how to provide confidence with less manual intervention? How to minimise the impact any change could make? How to add automation for common areas? How to train the developers to fix common issues upstream before it gets to the frontline teams?

Have you ever thought about deleting a process that isn’t adding anything? About making things simpler?

`The Untapped science of less : Inquiring Minds podcast’

If you truly want people to be creative and innovative, take them off the clock

That doesn’t mean no deadlines, but no timesheets – don’t justify every 15 minutes with a project, because the next ideas aren’t about 1 thing, they’re about connecting multiple things.

They’re about taking time to pause and thinking about the bigger picture: what problems are you seeing in multiple places? Where else would that new thing you’ve built be useful? What are multiple clients asking for?

Mise en place architecture

I love working with smart people. I learn a lot and it gives me energy.

I hate working with smart people who aren’t motivated. They’ll either get sloppy, get a new job, or get creative with their code design. The kind of creativity that makes you curse when you’re debugging a production incident at 3am.

The best creativity happens in a constrained environment, which also happens to make the easiest debugging.

Sure, we could let the developers figure out the best way to do something for every component, and there’s sometimes a benefit, but for every hour they’re spending figuring out how to solve a problem that didn’t need to be solved, or figuring out an unusual design, or evaluating a logging package, or writing boilerplate, there’s an hour not delivering value.

When an architecture is designed to put everything right where it should be, where decisions that have already been made are baked into the code and the tools, where a developer doesn’t have to think about how to structure their solution, the code is easier to write, easier to review and easier to debug.

Chefs like to follow mise en place. Everything in its right place. Before preparing a dish, prepare the workspace, the knives, and the food. Everything you need for the task and nothing you don’t. Everything is in a predictable place. Because then you can concentrate on the dish, instead of the kitchen. Good preparation helps every task fall into the pit of success, and makes it easier to recover if something goes wrong.

The more steps you have to complete a subtask, the easier it is to make mistakes. You might forget what the previous step was, you might walk to the fridge and then have to return to your workspace to remember what you need. Multitasking adds friction and adds opportunities for error.

That’s why we want encapsulated classes and single responsibility. One change updates one file, as far as possible. Although one feature may cover many changes in order to make it possible. Isolate your code from the data store, isolate the public API from your code, parse don’t validate.

Keep smart people working on solving new problems, and keep them consistent, because that’s the way to get the best from the team at all times, especially when you have a Priority 1 to update a logging framework at 3am.

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

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.