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.

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’

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

Processes upon processes: the JIRA trap

It is fashionable to hate on JIRA for software developers. Project Management made spaghetti. It has its faults, but the biggest issue is what it allows. It’s not opinionated, so any user can define any process to follow. It’s a perfect machine for generating red tape, or paper clips.

Because every time something goes wrong, the natural instinct is to add a new process, a new safety net, to make sure it doesn’t happen again [see Agile is Dead blog post]. And once added, they’re very difficult to remove.

So we get processes upon processes, the simple rhythm of a ticket lifecycle or of a sprint adorned with Deferents and Epicycles as we try and tame ever-increasing complexity with more text boxes and more statuses.

Complexity cannot fix complexity. But who has time for simplicity? This is the fundamental paradox of enterprise that Agile, and every “new big thing” is meant to resolve: complexity is added to reduce risk, but the complexity itself creates risk, and makes the risk harder to name, harder to spot, and harder to recover from if it is realised.

We have the 5 whys, the blameless retrospectives. And whilst the intention is sound – blame the system, not the individual – the solution is often to add new trinkets around the edges of the system. And reinforce that the system is the only way. They mistakenly put process at the centre, and ask the people to support the process, whereas the process should support the people.

But of course, this creates the shadow IT departments and the “non-compliant” centres. One place I worked had a strict policy that no one has admin rights because that fixed a problem lost to the mists of time. I understand the benefit of the policy, but at the time all our developers were working on IIS and couldn’t develop the websites we were paid for without having admin access on our machines. And so we had dispensations and workarounds until ASP.net core fixed the underlying issue of requiring admin access to serve web content.

Some companies stack procedure on top of procedure because the project is the centre of their universe rather than business value. And every company is in danger of falling into that trap as they treat risk management as risk elimination, instead of mitigation or recovery. They condemn every project to the tarpit of success, sinking below the crushing weight of process where sunlight cannot penetrate.

You will never have a process that prevents the next failure. You need a process to detect and recover, and you need to remove 99% of the “just in case” procedures from your process.

You don’t need to double-check the prime DVD copy before sending it for distribution, because no one has a DVD drive on their servers. You don’t need to change the admin passwords when someone leaves because there should not be an admin account that isn’t attached to a user. Eliminate the process, because every process you have is a process someone can forget. The best process is one you don’t need because the risk it mitigates cannot be represented by the system.

Either accept that you are not the centre of the universe and rewrite your rules to understand that you merely orbit the sun like so many others, or live out the fantasy that you are special, that your problems are unique, and add deferents on top of epicycles when the universe tries to disabuse you of that notion.

You can’t control the universe, only how you react to it. So don’t use JIRA to enforce pi to be 3.2.

Journaling for technologists

I encountered a question online recently about building context quickly, and whilst I thought of the bootstrapping post I made before, I also wanted to take a chance to explore how that plays into continuous practice. I started journaling as a researcher to remind me of all the dead ends and configurations I’d tried. Although I’ve not been entirely consistent in journalling (or sometimes blogging) each day and each new discovery, I think it’s a good practice for technologists to develop. Think out loud, even if it’s to yourself.

When building context on a new project, for example, I often find it useful, as part of discovery, to note what the client (or in very rare circumstances the written requirements) says it does, as well as what it actually does.

And always, always, journal everything. How to get it running locally, how to release, who knows what, who has the admin rights,… Anything that takes more than 2 minutes to figure out.

Sometimes that journal will take the form of shared content to help the next person join the project (and like all good scouts we should leave a place better than we found it), but the important bit is to write it for yourself. 80% of the time future you won’t need it, but that 20% makes the time absolutely worth it.

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

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.

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

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?

Software Development as a Christmas Story

Oh Tanenbaum

We decorated the house for Christmas. A smaller project than most of the software I’ve worked on, but a useful reflection.

The Cost of context switching

Sometimes, in the middle of one task, you need to do another. Either because you were interrupted, or because you weren’t prepared. Consider the tree, a tall tree, one you need a ladder to decorate. But you left the in the attic.

You don’t just have the cost of picking up the star, you need to get down the ladder, fold it up, carry it upstairs, open the attic, unfold the ladder, climb to the attic, find the star, then pick it up and unwind all the other steps just to get back where you stated before you can continue the task of putting the Star on the tree.

It’s just a minute to get the star…

Yak shaving

Sometimes it’s more than just one thing. Sometimes to get to where you need to go, there’s a cascade of other tasks.

You want to put the tree up, but it’s the first time you’ve had a real tree, so you need a new base. It’s bigger than last year’s tree, so your lights don’t fit. So you need to go to the shops. But you need to fill up your car. And the tyre pressure warning light comes on so you need to top them up. And you need to check the tread depth whilst you’re there, and so on.

Programming in a nutshell

Performance at scale

Our tree stood up fine when it was delivered. But as it scaled out and the branches widened, it pushed against the wall, making it unstable in the condensed space. It fell over.

Luckily no lights or baubles were using it at the time, but it’s an interesting challenge holding up a heavy tree in one hand, trying to adjust it’s position with the other hand, as I avoided the puddles of water in the floor as my wife mopped them up. If you’ve ever worked support, this may sound familiar.

Turns out that it was harder to stabilise than I anticipated.

The branches were unevenly partitioned, providing more load on one side, so I had to stabilise it against the wall. And the tree was almost a foot taller than expected, which turned it out to be 2 foot taller than the base was rated for.

We upgraded the base to handle the load. It’s bigger than we need.

Technical debt

I have some old pre-LED tree lights and they slowly fail so each year I replace the unlit ones from the packet of spares but I haven’t been replacing the spares. Eventually, they will run out, and the spares will no longer be available. I’ll have to throw them all out and start again.

The new led ones don’t let me replace them individually. But they last longer and are cheaper to run.

Which debt is easier to live with?

With a big tree, those old lights aren’t long enough. So, do I buy another set for the rest of the tree that doesn’t match them, or throw out the existing ones and buy a longer set? The latter looks better, but throws out the sunk cost along with the lights.

You know computers, can you look at this for me?

No, I can’t fix your tree. I can navigate a garden centre. I know enough physics to keep a tree upright, eventually, and safely put the angel on, but I’ve no Idea how to grow one, or what that weird stand with 17 gears you bought does, or how to assemble your plastic one. And I’ve no idea what that bug in the tree is.

Merry Christmas. Catch you all in the New Year.