Thinking outside the box: the difference between constraints and perceptions

You need an app.

The constraint is that it has to be accessible.
The perception is that it has to be screen reader friendly.

But… That excludes deaf people who miss the audio cues in the app
… That misses the option to add voice control. If it’s a booking app, why not talk through the booking?

---

The constraint is that users need to be notified (it’s a legal requirement)
The perception is that only one channel is acceptable (must be post, must be a tracked email)

But… each user has their own preference, or accessibility baseline. Post only may help, or hinder, victims of abuse. I can’t guarantee that you’ve read a letter, but I can guarantee you’ve hit the “I read this” button.

---

The constraint is that you need to mark and control personal and sensitive data because of GDPR, and you need informed consent to do that

The perception is that making users click “I agree” is informed consent
The perception is that gaining consent absolves you of responsibility to mark and control personal data “because they agreed to our terms and conditions”
The perception is that location data isn’t sensitive, even though Google knows your home and work address, and the address of the abortion clinic, the LGBT nightclub, the local mosque, the local love hotel

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

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.

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.

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

How to onboard yourself onto a new project

In a well-managed software environment, you’ll have a mentor to help you get up to speed with a new project. But that doesn’t always happen. So here’s some tips I’ve picked up about how I onboard myself onto a new project.

Always ask questions.

That’s how to understand documents and code. If it seems like something obvious, ask a rubber duck first, but on my team, I always prefer the developers who ask for help when needed than the ones who struggle along in silence.

For big documents, always expect to send a clarifying follow-up. Write notes and questions as you go through. Some things will be answered, even if not in the order you expect, but reviewing the document shows you’re taking it seriously, and you’ve taken time to process it.

Rewrite it on your own terms

I’ll tend to write notes about the business domain, possibly a glossary, as well as key concepts that will inform how it needs to be built, such as the main user flows, any special rules around security or performance, or specific highlights that meet the project goals (i.e. the high-level view of what must the project have to be successful. Sometimes it helps me to draw diagrams for the flow, or for the connections between different parts of the system.

Ask more questions

For other questions, a good rule of thumb would be if you can’t figure it out yourself or via Google (or project docs) within 30-60 minutes, ask someone else.

Blank slate

I’m a fan of the original Sherlock Holmes books, and there are a few things in them that talk about an enlightenment way of thinking that’s useful for a developer when gathering requirements (whether tomes, user stories, backlog ideas,etc), writing code or approaching debugging.

Today I want to talk a bit about A Study in Scarlet, and the early conversations between Holmes and Watson before their first case together, because they capture the essence of his enlightenment thinking very well.

Ignore Irrelevant detail

Watson tells Holmes that the sun rotates around the earth, as he is surprised that an educated man does not know this. In reply, Holmes says,
“That’s very interesting, I will now do my best to forget it”

It’s not an important factor in any of his cases, it doesn’t affect his work, so it’s not a fact he needs to record. He accepts it but has no way to act on that information, so he dismisses it.

It’s something that is often hard to do in requirements gathering and may need to be done retrospectively after you find out whether Andy from finance’s love for Richard Branson is just infatuation, or it means that every call to action across your site will need to be red.

It’s also something to apply more generally, choose what to ignore, don’t learn every new JS framework. Don’t expect to be an expert in everything. Be content with being T-shaped, and become an expert in solving problems and focusing on the right details.

The Book of Life

” it attempted to show how much an observant man might learn by an accurate and systematic examination of all that came in his way.”

The truth is never simple. Whatever you build will be part of an ecosystem comprised of other software, of manual processes, of fallible humans, and the winds of fate.

Gather whatever information you can, in whatever detail you can. Organise it and understand the bigger context.

The Phoenix Project has a great understanding of this in the discussion of the SOX-404 audit, where the IT department are busy worrying about controls on software without understanding the manual processes surrounding the software and how that fits into the compliance picture.

Speculation

On their journey to their first case together, Watson is keen to speculate about the motives and means that led to the crime, extrapolating from what little information they got from the initial introduction.

Holmes quickly and sternly cut Watson off from that line of thinking. He was clear that he would also base hypotheses on the causes and consequences once he had evidence before him to narrow down the possibilities, removing the impossible.

Speculate make hypotheses on why the system failed, on what will improve sales, on what the performance bottleneck is really going to be. Without data or a way to test them, they are useless for reaching understanding. Sometimes the beauty of a forest can only be appreciated by the birds.

Remove your preconceptions and bias from judgement by understanding what they are. Follow the data instead of your gut.

Work hard to make things simple

Bowling Alley

“Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius — and a lot of courage to move in the opposite direction.” ERNST F. SCHUMACHER

"Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius — and a lot of courage to move in the opposite direction." ERNST F. SCHUMACHER

— Quite Interesting (@qikipedia) January 8, 2018

It’s easy to write software. Ask users what they want (or even better, observe them and discover their problems), find a clean, user-friendly solution, build it and deliver it, for free, with no ads.

And you make a success of it, so you add more features to see off the competition, or to disrupt a new market. Google built Gmail, then added automatic categories, and Smart Replies to make it easier to process your messages. And they also added Wave, Buzz, Google+, Talk and others, to demonstrate other ways to connect and communicate, for places where email doesn’t work so well. So many new features, new things to learn, spinning out from that new core.

And yet Gmail remains popular, the rest, not so much.

It’s easy to add features. With a bit of work, you can even add them seamlessly without adding another menu option that your users will never see.

But what’s your plan to remove options, to streamline your code? How do add a new feature that’s easily discoverable and useful? How can you be smart and subtle?

What is your simplification strategy?

The frustration of confounding expectations

Spoons in the microwave

After years of being told no metal in microwave, it still feels too weird to follow the instructions on my new microwave to use a spoon when boiling water. There’s a sticker telling me I have to add a spoon when microwaving water but I don’t see myself ever doing that because the “no metal” is so ingrained, and I’ve seen plenty of lightning videos from people who have done it.

Abstraction in lift design

This picture is from the lifts at the local hospital. You press a floor number (rather than up/down) and the display responds with a letter telling you which lift to catch. This additional abstraction confuses many users, as I discovered helping people use them as I was taking a coffee break.

I see the same thing on a lot of websites. Those “cool” websites that break scrolling by moving things sideways or zoom in as I scroll down. SPA sites that break the back button. Using outlook web access on a mobile browser is painful. I keep getting the “Are you sure you want to resend?” or the login prompt when I try to go back to my message list from an email.

I’ve never been a great visual web designer, I’m definitely a function-over-form type, but I’ve always started with the principles that came to be known as progressive enhancement. Make it work in the simplest way, and add the bells and whistles on top of a strong, accessible foundation. That foundation has shifted from HTML, to HTML+CSS+JS, to TSX in my latest projects, and from desktop to mobile throughout, but it is always based on the basic principles of text and forms : easy to read, easy to follow, and works the way you expect it to.

If you’re trying hard to stand out by breaking expectations, what are you trying to hide?

De-pluralisation: strategic blinkers

The process of de-pluralisation takes all your existing problems and combines them into one simple manageable problem: “it’s JavaScript”, “it’s Windows”, “it’s the CDO” with a simple manageable solution “kill it”. Like all simple solutions it’s almost always wrong.

“People aren’t complying with our data quality. Users keep putting in wrong email addresses.”

“The new computer system will fix that”

“Users complain that there’s too many steps to sign off expenses”

“Each step will be faster in the new computer system”

“Staff have low job satisfaction”

“New computer system!”

“Our users aren’t interested in that new feature”

“New computer system!”

“We’ve been hacked with a social engineering attack”

“NEW COMPUTER SYSTEM!”

Changing one thing is rarely the answer. There are many pain points and problems we all face day to day. It’s tempting to try and fix them all together, but unless you understand why the problem exists and what the parameters are to fix that problem, you can’t fix it.

Sometimes New Computer System (TM) will fix multiple problems, if they’ve been defined and the system has been designed to do so. But don’t expect it to fix everything because it’s new. That’s how to make people disenchanted.

If you think one system will rule them all, you may as well throw your team in the fire now before you waste time and money on a misguided transformation.