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.

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.

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

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”

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.

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?

Java without semicolons

When I was a tutor at university I remember one student who I only saw towards the end of the year. I think computer science was their additional course. They came in after apparently spending the best part of a year learning Java, and sat down to complete their assignment.

It didn’t take long before I was called over to help. Their code wouldn’t compile. A fairly standard console application, with some output. And no semicolons.

I was incredulous, and as a young eejit, I’m not sure how well I hid that. I couldn’t believe someone could have completed the lectures, read the books, and completed the previous 29 assignments without using semicolons.

How could they spend a year on a Java course and not learn anything?

Regrettably, I refused to help them and pointed them towards the obvious and clear error messages that they’d obviously been looking at before they called me over.

I wasn’t going to build it for them. I couldn’t teach them 1 year’s coding in 15 minutes.

And yet, they turned up. They asked for help instead of struggling on. Exactly the things I’d wish for in my new starts when I started leading teams and onboarding staff.

They knew the shape of the solution and they knew where their talents were. If I’d been a little more patient, I could have nudged them gently on. But I don’t know if that would have been enough.

If you are mentoring or leading developers, are you stepping in early enough? Are you praising effort and being vulnerable enough to ask for help? Can you see their strengths and weaknesses? Are you giving yourself enough time with them?

Are you being the senior that you wish you’d had when you were a junior?

Ask Your Mentor These 40 Questions : about me (Q31-40)

Lifehacker suggests 40 questions to ask your mentor. So that I don’t have to repeat myself, I’m posting the answers here in 4 chunks.

31. What’s the greatest obstacle you’ve overcome?

I was a terrible communicator. Very wordy and imprecise. I started to give presentations, I started writing a blog, forcing me to condense my thoughts into a clearer, simpler form.

32. What’s an obstacle you couldn’t overcome?

I’m terrible at understanding emotions. Working with clients, I can’t tell the cues that help adapt what I’m saying to avoid conflict. I struggle to pitch at the right level of detail. I can communicate a lot clearer than before, but as soon as there’s non-technical issues, I absolutely need an editor. Sometimes that’s a PM, sometimes it’s another technical person. Just another perspective before I put my foot in it.

33. What’s the most unexpected obstacle you’ve had to face?

I’ve done a lot of recruitment over the years, and sometimes I have to reject someone either because someone else was a better fit, or because they failed on some criteria that’s not on the list (such as the guy who, when interviewing with me and 2 female colleagues, only answered questions to me).

Whilst I’ve always been clear that the decision was the right one, explaining that decision is the hardest part about the job. Whilst I want to be direct and honest, I know that my default approach is not appropriate for people who don’t know me well, and so I struggle massively writing, re-editing and phrasing things before talking to the candidate. It’s easily the most stressful thing I have to do.

34. What’s a good thing to be afraid of?

Causing harm.

I’ve worked with a lot of people who are motivated by the knowledge that whatever they build will be used and will make people’s lives that little bit easier. But it’s easy to let oversight or acquiescence let in features or bugs that will cause frustration or actual harm, whether by discrimination or universally.

Never underestimate the power you have to make or ruin someone’s day.

35. What’s been the most exciting point in your career?

Becoming a lead. Because letting go of having to do everything freed me up to think about how to make things better outside of the code I was writing. And suddenly everything was new and there were no easy answers, no red-green-refactor and no acceptance criteria for what makes a team work.

And I’m still learning.

36. Do you find any utility in holding onto regrets?

No. Never.

Regrets imply that you don’t like where you are now. And you have the power to change that.

Are there things I wish I’d done differently? Absolutely. And some of them I can’t even blame hindsight. I knew what would happen and I did it anyway for reasons that I couldn’t even justify at the time.

Know thyself. Learn the lessons. And move on. We all have professional as well as technical debt. Acknowledge it. Work with it.

37. Where do you think you could’ve done better, had you known what you know now?

I would have spent more time exploring at the start of my career. I got lots of opportunities, but the switch I made to a product company, which was also a lot smaller, taught me a lot more about myself. If I’d known how much I didn’t know, I would have jumped sooner.

38. Which values got you to where you are today?

“Don’t be irreplaceable. If you can’t be replaced, you can’t be promoted.”

So I document, I simplify. Any call I get out of hours or on holiday is a failure on my part, a bug in the system. If anyone has trouble following me in a project, I make fixing that bug my top priority. Don’t be a gatekeeper, don’t keep it to yourself, don’t be a bottleneck. Remove yourself from the bus factor.

39. When did you know you’d “made it” and were where you wanted to be?

The first time I got paid for writing software. Everything since has been an iteration on that. Review, reflect, improve.

40. Has your definition of success changed over the years?

It’s simplified. When I’m doing consultancy work, which is what seems to suit me best, success consists of 2 things, in this order :
1. Is the customer happy?
2. Did we make money?

The first is how to keep the lights on next year. The second is how to keep the lights on until then.
Everything else is just a way to break those down into smaller chunks.

Ask Your Mentor These 40 Questions : introspection (Q21-30)

Lifehacker suggests 40 questions to ask your mentor. So that I don’t have to repeat myself, I’m posting the answers here in 4 chunks.

21. If you were me, what’s the single most important question you would ask you?

Are the experiences I’m talking about typical for all, or do they exhibit a white cis male bias that I need to correct for?

22. If you were me, what’s something you’d aim to change immediately?

It’s never too early to practice your people skills. If you can’t put yourself in someone else’s shoes, you’ll never write the best software for them.

23. How can I tell I’m not cherry-picking which feedback I accept about myself?

In my experience, it tends to be the opposite. People pick out the negatives and ignore the cherries. The best way to keep yourself honest is to set it your own goals, and honestly reflect to yourself how you did, good and bad. Write it down in advance, and as you go, and look for opportunities to improve.

24. Is there a strategy to unlearning behaviors that are holding me back in this field?

Coding challenges are a great playground for behaviours and techniques. If you find a behaviour you want to change (e.g
too procedural, not enough functional), then challenge yourself to solve 5 puzzles without that behaviour, see how the new behaviour feels, and see if the old behaviour is sometimes useful.

25. Do I exhibit any warning signs that indicate this field won’t be right for me in the long run?

If all you care about are the technical aspects, you will limit yourself. Your job is solving problems, software is a tool. You need to know the technical, but you also need to understand elements of psychology, ethics, politics, economics and others. If you’re planning to stay within your bubble, new ready for an escape plan when your skills bedtime obsolete

26. When is it time for me to contemplate changing career paths?

When you stop caring about doing it right. Maybe it’s time to change jobs, but if the whole routine of requirements and coding and testing just grinds you down, get out whilst you still have passion. And follow your passion somewhere else.

27. How do I ensure I’m prioritizing the right things?

Always provide value. Sometimes the value is direct (e.g. a new feature), sometimes it’s indirect (e.g. refactoring before a new phase of work). If you’re not sure, ask. Either ask the team, the product owner, or all your future self what you wished you worked on.

28. Where do you feel I fall short?

That’s for you to answer. Ask for honest feedback and take it in the spirit it is offered. We always reflect on the sprint for ways the team could improve, and always there are things we can do better. There are axes to sharpen, new skills to learn, new people to teach and lead. Pick your favourite retrospective format and apply it to yourself.

29. How am I perceived by those around me?

See my previous answer.

30. What should I do right now to improve myself and my career prospects?

Figure out what your 5 year plan is. Once you know which direction you want to travel, the first step is much easier to decide.

Has blogging changed my career in a positive way?

As part of my mentoring, I was asking a question about this blog, and I thought the answer was worth repeating publicly.

The question was:

“I am interested in learning whether blogging changed you career in a positive way?“

It’s been helpful to me, and I know it’s been mentioned in a couple of job interviews, but for me the benefit was more about the discipline of writing and using it to clarify concepts that have been bouncing around in my head. I’m not always the best at writing clearly and cleanly, so blogging has been my way of practicing that.

I guess it’s a matter of what you want out of it. I don’t believe you need a blog to get a better job for example, there’s plenty of ways to that goal.

On another note, I’m not following John Sonmez any more after I saw him bullying others on Twitter. That’s something important to remember if you’re blogging – anything you make public you’ll be judged on, so be the best version of yourself when you express yourself.

Good luck,
Craig