Tim Schraepen's Blog Yet another developer blog.

The Lead Developer Conference - Day 1

29 Jun 2016 • 13 min. read • Read the comments Tagged Experience Report

The Lead Developer what now?

The Lead Developer conference, or at least the one I went to, was held on the 23rd and 24th of June 2016, in the Queen Elizabeth II Centre in London, during the Brexit vote.

It’s a conference mainly about “that other part” of a job as programmer, namely working with people.

I can highly recommend this conference to anyone. It’s not just for developers; scrum masters, managers, and other roles can all learn from the abundance of information shared at this conference.

All the slides can be found on the conferences website, but I link to the specific slides (and my notes) in the short bits I write about the talks below.

Note: not all slides are online yet, but they’re getting in when the speakers have taken the time to share them

A word of thanks

Thank you to my faithful travel companions and colleagues Jan Sabbe and Bart De Neuter.

Thanks also go out to our employer, Cegeka, who paid for travel, accomodation and the entrance fee.

Thanks to the organizers, White October Events, who did an amazing job at making everyone feel at home and for being super friendly people in general.

And thanks to Meri Williams, with her witty announcements, for being the perfect host and an inspiring example to us all.

Scribblings of a madman

Based on my notes, I’m sharing the most important things I learned in every talk I watched. So, you can decide if it’s interesting or not.

I’m also turning this into 2 blog posts, because after writing Day 1 it already was a lot.

Day 1 

Patrick Kua - What I wish I knew as a first time tech lead 

Using his fantastic art in his slide-deck, Patrick Kua (@patkua) gave everybody some pointers on the path to a wise lead developer.

He mentioned some recognisable things such as: trust your team, delegate to it, provide guidance, don’t write code all the time, don’t make all the technical decisions.

But the coolest thing I learned was that there are certain skills of yourself (as a leader) that can be represented by archetypes or personas. Patrick identified the Coach, Shepherd, Shaman, and Champion.

The Coach

The Coach (e.g. in a soccer team) personifies the part of you that tries to keep the team together and motivated.

The Shepherd

The Shepherd is the part of you that guides individuals back to the team, or guides the team to a shared goal.

The Shaman

The Shaman is your story telling skill. I thought it was so cool that this is important enough to validate turning into a persona. I never thought of it that way but it sure is refreshing.

The Champion

And finally The Champion, is that part of you that can Lead by example your team to a higher level.

We all carry all of these personas with us, it’s certain situations that will call these out at times.

Patrick closed off by saying that our role as Lead gives us greater impact. And instead of becoming the 10x Dev, we can grow the individuals in our team so that the team becomes the 10x Dev.

This keynote really set the tone for the talks that we’d see over the course of the next 2 days.

Slides / Notes

Heidi Waterhouse - The 7 righteous fights 

The 7 righteous fights… you should be fighting.

Heidi’s (@wiredferret) talk was mainly about making sure your application adheres to Localization, Security, Extensibility, Documentation, Affordance, Acceptance and Accessibility. If you don’t take these into account, you’ll build up compound technical debt.

I learned that Affordance is about nudging your users so they use your application correctly.

About Security she had a lovely quote:

Internet is not a series of tubes connected to hackers wearing hoodies.

That got a good laugh. :)

About technical debt in general she said if it’s already in a release, you’ll get more resistance when trying fixing it. She made the fitting analogy by saying that trying to fix stuff in a codebase after its release is ​like trying to pound chocolate chips into an already baked cookie​.

Slides / Notes

Mike Gehard - Moving from Monolith to Microservices 

Mike (@mikegehard) went so fast through his presentation, that it’s gonna take me at least a second viewing to really understand all the things he was trying to say.

The way Mike approached moving from a Monolith to Microservices is by starting from a monolith and then move towards Microservices, instead of trying to guess which microservice to distill from your application and do trial and error from that position.

Why Monolith first? Because it’s safer to learn about your domain and it’ll cost less to change Bounded Contexts.

Basically what he was saying was Use the benefits that immersive design provides.

  1. Write API level tests
  2. Arrange/Organize your application so you can see your domain (and Bounded Contexts)
  3. Break out components
  4. Promote one of your components to a microservice (here you’ll also build the minimum required infrastructure and test it out)
  5. Continue promoting microservices

As you might notice from the lingo, Mike is a big fan of Eric Evans’ Domain Driven Design (he even made the same jokes that go along with it). He also didn’t fail to mention Simon Brown’s component structuring. This made me feel right at home. :)

Slides / Notes

Lorna Mitchell - Wonderful world of webhooks 

Lorna (@lornajane) gave a lightning talk about why WebHooks are cool.

I remember that Webhooks are less chatty, and that its content is usually large (coars-grained) because you want to push the information that’s useful to 80% of the use cases to stay as least chatty as possible.

Slides / Notes

Dan North - How to make a sandwich 

Dan (@tastapod) North, the man, the Legend, gave a really great talk about Feedback.

He first talked about Feedback in the context of Systems Theory, which he does a way better job at explaining than I ever will, so watch the video.

The most important thing I picked up about this part is that there are different motivations why one would offer feedback. And that when you notice you would be offering feedback to control the one you’re giving feedback to, you should just walk away.

In the next part we learned about how to deliver feedback using SBI, Situation Behavior Impact.

And different ways of structuring feedback, e.g. the infamous Sandwich model.

To receive feedback there is only one rule: Always say Thank You. Even if the feedback you got made you angry. Because it shows your appreciative of getting feedback. Try to map that feedback you got to SBI yourself (how was the other person thinking about giving you feedback).

Great talk to start off the lunch. :)

Slides / Notes

Duretti Hirpa - How to get engineering team to eat their vegetables 

To stay in the food analogies after a very nice lunch, Duretti’s (@Duretti) talk about how teams operate had some really great one liners.

My favorite ones being (Acceptance of) vulnerability leads to a learning culture, Coordination IS competitive advantage, Productivity is a measure of comfort.

She noticed what qualities a good team shows:

  • A good team wants you to win
  • Has a sense of togetherness
  • Has a place for vulnerability.
  • Is psychologically safe
  • Has empathy

Nice talk with a whole lot of truth bombs. Worth watching!

Slides / Notes

Katie Fenn - Writing Modular Stylesheets with CSS Modules 

Katie Fenn (@katie_fenn) took the stage and talked about how CSS Modularization is sensical because along with making components in JavaScript, you also want the same for your CSS.

CSS Modules is the way to achieve this fairly easily. I think it makes the most sense when you work with JSX components like you do when you use ReactJS.

Other than the various JS loaders, you can also use it with both Sass and Less.

Slides / Notes

Yasmina Banaszczuk - I know just the right person 

After that short technical talk, in came Yasmina (@lasersushi), ready to blow us all away with refreshing german directness and delicate, yet powerful tone of voice.

Her talk was all about how our (personal) networks can influence hiring and retention in the tech industry.

After laying out studies and papers about how we really hire “People like ourselves”, we delved deeper into the motivation behind it.

She gave a hilarious example of how the name Kevin has (had?) a bad connotation in Germany, which even lead to a word called Kevinismus, and the entire floor laughing out loud when she visibly felt embarassed about all the Kevin’s in the audience, and the continued, emboldened laughter after she exclaimed There’s actual research in that!.

At the end of her talk we got a nice summary:

Check your processes, your networks and yourself.

Are they varied, do they have same educational background, do they spend their nights gaming, or do they speak or dress the same way?

Then your network might be too homogeneous.

This might turn your networks into gatekeepers instead of welcoming, open gates.

A very refreshing and interesting talk, with a very smart and very fun to listen to speaker. Definitely watch her talk.

If you’re interested in more of her research, definitely check out her website. She’s currently working on a series of articles on The Habitus of Tech.

Slides / Notes

Joel Chippindale - Telling stories through your commits 

One of Joel Chippindale (@joelchippindale) was preaching to the choir (at least on my part) about how The key challenge as lead dev is managing complexity and how Naming, code design, refactoring and automated tests are all about communicating the intent of our software.

He then went on to say that VCS (like Git, Mercurial, SVN, …) is underused in this regard.

To have every line of code always documented, he presented us with the 3 principles he adheres to.

  1. Make atomic commits; What’s the smallest useful change u can make to ur codebase?

  2. Write good commit messages (on his website he links to Chris Beams’ How to write a good commit message)

  3. Revise your development history before sharing. With git rebase.

The biggest motivator to a team on using these principles is that all of them have the benefit of making commits simpler, and also easier to think about.

Absolutely loved this talk. It amazed me how much information he was able to cram in a relatively short talk.

Check out his website dedicated to this concept.

Slides / Notes

Sam Lambert - The argument for simplicity 

Sam Lambert (@isamlambert) taught us a bit about how they work at github.

They deploy with hubot in slack so they can easily backtrace what happened before and after in the conversation that is deploying to production. Neat!

If there’s one thing he wanted us to take along it was to get a therapist. People laughed awkwardly, but he was dead serious. It was great to see this taboo being taken down.

At the end, in stead of mentioning his own internet location he shared some people he wants us to look up, so here are the ones I managed to note down: @ihavenotea, @jessfraz, @eanakashima.

Slides / Notes

Nickolas Means - How to crash an airplane 

Jezus christ, how do I even begin summarizing this talk.

Nickolas (@nmeans, glorious beardy man, airplane afficionado, …) left the audience mesmerized and awe struck after channeling his inner Shaman, telling us a story about how a horrible plane crash could’ve turned out even worse if it weren’t for Cockpit Resource Management. And making the analogy to what makes up a good team.

If there’s one presentation you should watch of this conference, it’s this one.

A grasp out of some of his quotes:

Cooperation over Heroics

Everyone has a voice.

As leaders we need to avoid teams to develop dominant voices, especially our own. Use your authority to ensure every voice is heard.

Software is a team sport.

Slides / Notes

Day 2 

Continue reading Day 2!

Related Posts