Known Unknowns with Henrik and William

Steve Faulkner is really into accessibility.

”That’s all I’ve been doing for the last 20 years.”

Steve has been an accessibility engineer since 2001, first with Vision Australia and currently with The Paciello Group. He has a hand in developing HTML5 and WAI-ARIA specifications as a member of W3C working groups, and is the editor of W3C specifications on HTML5, Using ARIA in HTML, accessibility APIs, and text alternatives.

Or, for short – he’s been part of building the very foundation of what we call accessibility on internet today. So, what are the most common mistakes a11y noobs do when starting to care about accessibility? What was all the conflicts surrounding HTML5 all about? And why does Steve get so wound up when talking about the document outline algorithm?

Those things, among lots of other fascinating things, is discussed in this episode!

Links:

Have you ever applied to a job as developer and ended up with a bunch of ”code challenges” or ”tasks” to solve on your own and submit? One day, William had a brilliant idea; after participating as co-interviewer in a traditional interview with a candidate, he asked: ”How about we have a mob session instead of just sending [the person] an arbitrary code challenge?”

Henrik was, obviously, overwhelmed with excitement. And so was the Engineering Manager in charge of hiring! A few months later, mob interviews is gaining both ground and traction, becoming a thing within our organization.

In this episode, we explain what it is and how to apply it.

”Mob sessions and mob interviews are really focused on collaboration, working together. If that's the sort of thing you appreciate in your company, I suggest you try mob interviews. They are much more qualitative than just giving a person a code challenges. If thats how you going to do things in your organization... are you going to give a single developer a task and give that person a week to complete the task? I mean yeah, sure. Then you can give them a code challenge the traditional way,” William explains.

”Or if you're going to let that person work in a team in the agile way which involves working together, then you might want to try this as a way to see how that person would work in the future. Because that's what you want, right? You want the forecast of how this person is going to work for your company,” he adds.

Links:

What is the difference between self-organizing teams and self-managing teams? What did Henrik and William learn about the updated Scrum Guide during a recent ”Scrum beer” with Swedish agile experts? And why on Earth is this episode titled ”The yellow meatball episode”?

”Words, they do matter. That's also why we talk about self-organizing or self-managing, even though I can't tell the difference right now, spontaneously. The concern I have when it comes to autonomy is the extreme form of autonomy, which is basically anarchy. Like, 'as long as we don't have to talk to anyone else we're autonomous, but once we have to ask someone else for advice or guidance or assistance, as soon as we have to communicate we're not autonomous anymore. The bastardization of autonomy. Basically, when I say that I don't really like autonomy in teams, what I'm saying is that I don't like to default into miscommunication or getting rid of communication,” Henrik explains when being under scrutiny from William. 😉

”If you have a company where everyone is keen on working in a very agile way, cell-based architecture could help you define as a PO what we want to do, give you the words that you need. In our organization, there's no end to the amount of people you could talk to. You don't want to waste time not communicating and you don't want to waste time over-communicating with people who doesn't know what you're talking about. Sometimes in the large companies it feels like we're building these cells but we're tying them to people,” William philosophizes in response to a discussion about the possibility of combining cell-based architecture with capability team principles.

And yes – we will definitely make a future episode about cell-based architecture. So stay tuned!

Links:

Why is it important to embrace and celebrate failure? And why is it important to foster a culture in a workplace where you are allowed to fail?

When Skolplattformen, a digital platform for schools in the Stockholm Region, was launched in 2018, it had already cost a staggering €100 million (roughly $120 million) of tax payers money – and the release was anything but successful. Bugs upon bugs, soon followed by critical security breaches. Out of pure frustration, developer and entrepreneur Christian Landgren (who also happened to be a parent forced to use the digital platform) decided to start an open source project fixing the most severe issues with the user interface as ”a Christmas gift” to all the ailing parents and teachers.

Little did he know that it would grow into an open source movement – and that by February 2021, it would result in a mobile app that within hours was the most downloaded paid app in Apple's iOS App Store.

”The feedback has been astonishing. I actually read a Facebook comment that said 'God bless them, they saved my life!'” says Johan Öbrink, digital strategist at the Swedish bank SEB, longtime friend of Christian, and one of four core programmers (together with Christian, Erik Hellman, Rickard Natt och Dag) of the Öppna Skolplattformen mobile app.

So... why did they decide to make it open source? How do you ensure stability and sustainability without any enterprise grade tooling and people behind an open source project? How do you, as an open source crusader, compete with inferior approaches?

”We like open source, we want to promote open source, and we especially want to promote open source for all code written by tax money. In this case it is not tax money, but it was important to have that part of the project as a vehicle for that discussion,” says Johan Öbrink.

”We have actually taken it so far that we are now kind of going out in podcasts and media saying that these projects should stop. Whenever you have that idea that we should start a big project, stop. And also, if you can, stop digital IT projects that have already cost €10 million. And that's overall, every part of society. You should never do those type of projects. If they cost that much, stop them”, says Christian Landgren.

Links:

After mentioning the word ”culture” approximately a million times throughout the season, it's finally time to dedicate an entire episode to corporate culture. And since both Henrik and William are somewhat obsessed with collaboration, the focus is pretty obvious: How do you foster a collaborative culture within you team, workspace, or company?

Throughout this highly cultivating episode (pun intended), William shares an anecdote from a former workplace, raises the curtain behind the fluffy word ”collaboration”, and talks about a new experiment doing a mob session challenge instead of a traditional code challenge after interviewing a couple of candidates for recruitment. Also, he reveals that he was almost pissed-off at Henrik after the pair's first few interactions.

”There were no Jiras. I was like, 'this is not getting anywhere.' And the irony of that was that I said 'I have to get to work because otherwise nothing's gonna happen.' Now we're doing things and I'm like 'damnit, we didn't need Jiras – I thought we needed Jiras!'”

Henrik shares an example of toxic culture and really bad communication, talks about his experience as a hackathon facilitator, and why the lack of communication is the equivalent of failure.

”When we talk about collaboration, one of the things I often notice and get annoyed with is the mixup between the word 'collaboration' and 'cooperation'. For Christ's sake, a perpetrator could cooperate, you know. You could be a suspect cooperating with the police. That's not the same thing as collaborating. It's a totally different thing.”

About the mob session code challenge: If you're interested in trying it out yourself, we recommend Cyber-Dojo:

In this episode, we're moving away from philosophical and organizational discussions and into some nitty-gritty technical details: Monorepo (mono repository), a single repository that stores all of your code and assets for every project. So, what's the difference between a monorepo and a monolith? What are the pros and cons of going mono? When and why should you use a monorepo instead of split repositories? Acting as the devil's advocate, Henrik tries his best to throw the full-fledged monoist William off his game.

”I like the monorepo way of doing things together, solving issues once instead of in all these different repositories,” William bluntly states, also taking the opportunity to coin a new term: Multi-package repository.

”Multi-package repository is more accurate and self-explanatory. A mono repository sounds like you're taking the monorail and you don't really know it means.”

Show notes: