Wesley Reisz talks with Jessica Kerr about her focus on developer productivity. Topics include her work at Atomist building Slack Chatbots, an approach to categorizing Yak Shaving (in an effort to prioritize and automate development dependencies), how an innovation culture drives diversity, and, finally, the role of 10x developers in the lifecycle of a company or product.
Key Takeaways
- There are five kinds of Yak to shave
- Atomist uses a Slack chatbot to automate and track commits, builds, push requests etc.
- Agile retrospectives are a great way to encourage an innovation culture
- Diverse teams flourish in innovation cultures
- 10x developers are great for launching products, but teams are needed as products scale up
Subscribe on:
Show Notes
- 1:20 - Jessica Kerr is a developer at Atomist, and is known for blogging, speaking, and podcasting on functional languages and git.
What are you working on at Atomist?
- 2:10 - My vision is in line with Atomist’s vision - changing the way we develop software; to add another level of automation.
- 2:30 - At a high level, we’re automating the way we write code, by automating code changes (not through code generation).
- 2:50 - The second half of Atomist is automating co-ordination processes - most of the work we do isn’t typing, it’s co-ordinating with others.
What happens through chatbot AI?
- 3:10 - A lot happens through Slack.
What’s the one line elevator pitch for Atomist?
- 3:20 - Atomist is a programmable Slack-bot backed by a graph database, which tracks commits, builds, deployments.
- 3:40 - You get a single message saying when a push happened, and it updates when it has been built, or when it has deployed, instead of a stream of such messages.
- 4:05 - There are also buttons to take actions, like restarting the build if the build failed.
What have you been working on?
- 4:20 - I’ve been working on parsing the build, in order to identify and classify the failures, like a lint failure or a test failure.
- 4:50 - If we can get to the point where we can identify most of the common causes of errors, and prevent having to scro-o-o-o-oll to the end of the build log, that’s a win.
- 5:00 - Most speedups come not from doing things faster, but by avoiding doing work in the first place.
- 5:05 - The tiny little things we don’t have to do let us keep our concentration.
What made you decide to use Slack as a chatbot?
- 5:40 - We don’t want to have one extra place to see all of your information - issues are going to be updated in an issue tracker, for example.
- 6:00 - If you’re already in Slack, we want to bring correlated information from multiple places into your feed.
- 6:20 - We can also bring actions - Slack allows messages to be tagged with buttons, which can trigger a call to a website.
- 6:50 - This allows us to hook into commands you can type and display actions alongside notifications, like having a merge button next to a pull request message.
What’s the tech stack behind this?
- 7:15 - Our little programs (rugs) are written in TypeScript and compiled to JavaScript.
- 7:30 - We run the JavaScript in Nashorn on the JVM, along with Java, Clojure and Scala.
What about the rest of the stack?
- 7:45 - We’re running in Amazon, which has Slack integration, and we use Kubernetes and Docker.
- 7:50 - Maven builds Docker containers, pushed to a docker registry, and we have some Kubernetes agents that allow us to deploy from within Slack.
What did you learn about building a chatbot?
- 8:25 - We haven’t developed conventions and customs (as an industry), such as what channels matter.
- 8:45 - I have a personal notebook for my personal stream, which no-one else is expected to follow - it’s my personal stream.
- 9:50 - There’s an engineering channel, which allow to share questions or discussions.
- 10:30 - The next level up is for stand-up; a quick summary or blockers.
- 11:00 - There’s a low volume ‘what happened?’ channel - such as when we’re an official Slack application.
- 11:50 - When you have these different levels of context, you can pick up after a break and know what you can ignore and what you can’t.
What is yak shaving?
- 12:15 - It means that everything that you’re doing in order to get to the thing that you’re wanting to do.
- 12:30 - For example, if you want to make a change to something, but you need to set up your environment first, and then discover that there’s no test - so you start writing a test, and then realise that in order to write the test efficiently you need to refactor this code …
What are the different type of yaks?
- 13:30 - In my blog post [https://the-composition.com/a-taxonomy-of-yak-shaving-102da591308b A taxonomy of yak shaving] I introduced five types of Yaks: Black, Imperial, Trim, Royal and Golden.
- 13:50 - We can categorise the different types of tasks that you find when trying to fix the problems.
- 14:10 - The Black Yak is the tasks you have to get past - the build is broken, I can’t even run this etc.
- 14:30 - We can track when these types of issue occur, and find out the root cause - for example, is the build broken because the lint check keeps failing, can we automate running the linter?
- 15:00 - One technique is to use a different kind of emoji to classify each failure, which makes it easier to summarise at the next retrospective.
- 15:30 - You can try experimenting with techniques - but since you don’t have a control, you can perform a scientific experiment.
- 16:10 - One advantage of having a persistent a Slack record is you can analyse it retrospectively.
You said: sometimes you aren’t shaving the yak, just combing the hair in a different direction - what did you mean by that?
- 16:50 - Now we’re talking about Trim Yaks, where you’re trying to make the code prettier or adding layers of abstraction, such as refactoring.
- 17:30 - The power in refactoring is that if you’re not familiar with the code before, you know it after refactoring.
- 17:30 - The biggest factor in not causing problems is how well you know the code - your mental model of how it works.
- 17:55 - However, refactoring breaks the mental model of the other members of the team.
What are Royal Yaks?
- 18:30 - Royal Yaks are talking to people - we feel like if we’re just chatting, we’re wasting time.
- 18:40 - I disagree. We’re forming bonds with another person - part of the mental model we need is not just the code, but the mental model of others on the team.
- 19:20 - The chatting opens the communication lines and allows others to share their knowledge and experience.
- 19:30 - Possibly the biggest benefit of paring is that you know you are transferring mental models.
How can being a 10x developer undermine productivity of a team?
- 21:10 - When is a 10x developer great? Understanding the individual system, and those that we wrote are both in the computer and in our heads.
- 21:40 - That really is 10x more productive than building on a system that you didn’t write, and where a bunch of other people are working on and making changes at the same time.
- 22:05 - That can be great, especially when you have an early phase company and you need to be fast.
- 22:20 - When you want to make something bigger than one person can maintain, or to reduce the single-person risk, you have to have a team, and then you’re going to pay the cost.
- 22:30 - You aren’t going to be getting the same per-developer productivity that you once had - even if they’ve been pairing, when they are working alone, they’re going to be working over each other.
But can you have a team of people with higher overall productivity than a single developer?
- 23:30 - When you have a system that is too big for a single person to maintain, you have to move to a team.
- 23:35 - You need to reduce the friction between people in the team.
- 24:00 - You need to introduce psychological safety - allowing people to say what they really think.
- 24:05 - Their ideas are going to be appreciated and their concerns are going to be welcomed, and not shut down.
- 24:30 - You can grow as a team and grow faster.
- 24:50 - I try to thank people who point out that something is wrong; I try and avoid words like ’trivial’ and ‘simple’ - something that is easy for me isn’t necessarily easy for them.
- 25:10 - When you know much more about a system than someone else, it’s really easy to accidentally make them feel stupid.
- 25:30 - Assume good intent - that is a great rule to follow.
The last Yak is the Golden Yak - what is it?
- 26:40 - There are some frictions that when we solve them it opens up whole new ways of working - like Slack, in fact.
- 26:50 - One of the things with remote work - you have to be deliberate about communicating.
- 27:10 - When you record all your meetings in a Slack room, you then end up with the ability to search and process them afterwards.
- 27:30 - Git and CI are both Golden Yak - when you can get your tests green automatically, your pace increases.
- 27:50 - Git is the same - you have local changes and branches, and you can roll back quickly.
What about diverse teams?
- 29:00 - Diverse team can be more powerful - in some cases.
- 29:30 - For example, innovation team culture - whether people think their ideas about how to improve the team’s work will be appreciated and implemented.
- 30:00 - If your team doesn’t want ideas, you don’t want diversity - it decreases communication and reduces velocity.
- 30:15 - If you do have diverse teams with an innovation culture, then team communication goes up - and having those extra ideas and a sense of identity can form the team.
- 30:45 - It found a positive effect of diversity in a high innovation culture.
- 31:00 - I personally want a high innovation culture - diverse or not - because if it’s a very rule-based approach, then I don’t want to be on that team.
How do you create an innovative culture?
- 31:20 - You encourage people to ask and have new ideas on the team.
- 31:30 - Agile is a way of encouraging innovative culture - a retrospective is a way of asking for ideas to improve the way things are done.
- 32:00 - The retrospective is about reflection and improvement.
- 32:15 - When someone offers an idea you don’t agree with - instead of saying ‘no, that’s stupid’, ask ‘can you explain how that will help?’
- 32:45 - Worst case- you’re proven right and you wasted fifteen minutes. Best case- you’ve got a great new idea.
