I have a great job! I get to work with a lot of young people and get to train developers in the early stages of their careers. It’s absolutely amazing to see people develop in these early steps of their career.

But it also creates a weird feeling for me - since I, to them, comes out like an old sage telling stories that are long-forgotten about how the web was when the world was forged. Back in 1996 and stuff. I feel both a bit like Gandalf - both in age, length, and how I’m addressed.

It’s scary. Because, if we’re going to be a bit more serious, I realize that I become a role model for some of them. How to behave, act, say, and think about our work. This is especially real when we talk about agile practices and techniques, that has a lot of principles and thinking patterns in them.

This made me think about my own early influencer in this industry. And I realized that I never said thank you to them. And that many of them probably have no idea what working with them meant to me.

So, this is the first post in a series of “thank you”-notes to my early role models. Today it’s Staffan Rolfsson - one of the first.

At </salt> we have a lot of labs and tests. Last time I counted we just passed 100 repositories. And it’s dawned on me that all of those need some love and attention from time to time. Stuff moves pretty fast in the JavaScript world and dependencies might start to act up etc.

At least you’d want to check out the code, do an installation of dependencies and then run the test and see that you get the expected behavior. Preferably you’d also wanna see that we don’t have deprecated dependencies or broken stuff. And probably check this, at least once before each course.

This is what scripts are made for, right? Automate the boring stuff.

The only problem is that since we are teaching a lot of different technologies and tools, not two repositories are the same; this one uses Docker and this is actually just text, and over here we have one that is purely for CSS-stuff. In one repository we should have 4 failing tests but no linting errors. In the other, we need 42 linting errors but no failing tests. Etc, etc, etc. It’s nigh on impossible to write a script that checks this for me. It’s pretty much custom code and checks in every repository.

This problem pushed me to investigate how we could automate this process with bash scripts. I learned a lot and wanted to share a bit.

At School of Applied Technology, our accelerated career program is running in small teams, using Mob Programming. We have found that this gives us the most and best learning in a short amount of time. In this setup the tight group that you are in becomes both your best teachers but also, from time to time, you will be the teacher others in the group.

In these very strange times, we see a lot of change; some are really sad, devastating, and depressing. While others are encouraging and celebrate humankind’s will and capacity to survive and overcome.

Others still, are just interesting to observe and learn from. These last weeks I’ve noticed two new realizations about two of my favorite topics; feedback and transparency. They too, it turns out, are affected by the changes in our ways of life due to the corona pandemic we are living under now.

This post reflects a few thoughts and ramblings that I’ve had in my head for some time. I’m not hoping to solve world problems here, but just get some reasoning down.

I’ve just experienced something fantastic and a real testament to what amazing people can do when given the room to be amazing (and have an apparent and real reason to do so)

A week back, our accelerated career program; School of Applied Technology - the world’s toughest coding bootcamp were running five mob programming teams (that we call mobs) in two locations. This is how we teach and it has given us amazing results so far.

But it’s not cool being the “let’s sit as close together as possible for 8 h per day”-teacher in times of Covid-19 infection spreading across the world.

So in the middle of last week we started to make plans. Last Friday we had a “just in case”-lecture on tooling for our 5 Amsterdam mobs. Then during the weekend, things escalated in Sweden and we decided to move over the 5 Stockholm mobs as well (yes, without training them). Monday, 6 days ago as I write this, we had moved everyone into our remote-only platform.

And you know what? Just about everyone found it not only useable but actually very useful and, in some reports, even better than before.

In this blog post, I wanted to share our suggested platform setup and some findings that our mobs shared in our weekly retrospective/demo session last Friday.

And before I write a word more: this was not my doing. It was the amazing instructor team of Salt (Mies, Zach, Daniel, Levy, and Adam) setting the stage and then the brilliant developers of Salt building their own applied practices on top of that. Yes - just about every mob did it differently and I loved it.

My current role is awesome - I get do do some agile coaching, quite a lot of teaching, reading up on new tech and from time to time some programming.

Yesterday evening someone just blurted out: what if all of us died at once?! All the code and documentation would be hidden in a cloud somewhere and we will not be able to get it.

That cloud is GitHub and I’m sure it would be safe and that the risk that we all die at the same time is relatively low. Then again - I have booked a raw chicken tasting for our next offsite …

Just kidding - but when that was said my programmer-self sprung to life and I device, in my head, a simple script to make an offline copy.

This post describes that script. Oh - I only had 30 minutes spare time to do it in. That was my timebox and I actually managed to pull it off. The finished script is about 5 lines of code… but I’m still proud.

I got a question, on twitter, the other week about how to handle a long list of backlog items on a kanban board. Here’s the original tweet:

Hej @marcusoftnet. Vi sitter med en backlog med 300+ o-organiserade och o-prioriterade stories som ska passera vår #Kanban board närmaste 10 månaderna.
Hur kan vi "gruppera" stories för att förenkla refinement och beroenden mellan stories?
- under epics?
- funktionella områden?

— Tvivlarn (@MeChristensson) February 9, 2020

And my adequate translation. The tweet by “The Doubter”

Hey @marcusoftnet. We got a backlog of 300+ un-organized and un-prioritized stories that will pass through our #kanban board the coming 10 months. How can we “group” stories to simplify refinement and dependencies between stories?

– by epics? – functional areas?

I got his permission to respond here on the blog. It’s a response and not an (and even less the) answer.

The other day we started a new course here at </salt> And the first day we are used to seeing some confusion from the developers and the odd strange, wrongly configured computer (by us). But the error in the title of this blog post:

 getcwd: cannot access parent directories: No such file or directory

had me scratching my head for quite some time. Until I realized that the error message states what was wrong.

In the </salt> accelerated learning program we emphasizes learning in groups throughout the entire boot camp. We do this through the use of mob programming that is not only a great way to solve problems together but also puts learning front and center. I’ve yet to sit down with any mob and not learn a new thing (I’ve tried 40+ so far.)

But there’s a thing that needs to be in place in order for the learning to be allowed to flow freely; psychological safety. We try to create a psychological safe space through two tools:

• Trust
• Vulnerability

Let me, very briefly, expand on how we use this in our training.

I work for a developer accelerated career program. I have (together with Jakob Leczinsky) created a training material that takes people with no professional development experience into professional developers in 3 months. We have now run 4 courses and found jobs for about 100 people. All of them have got rave reviews from our clients, top-line software companies in Stockholm.

But how?! This is quite provocative, even for me. I spent 4 years in university (Go DSV!) - surely you can’t learn as much in 3 months.

How can this work? Because it quite obviously does. I have 100 devs telling me so.

I was pondering this as I picked up the book Antifragile by Nicholas Nassim Taleb for a reread. And things clicked. Our method is antifragility applied to training. And we create antifragile developers.