Breaking Down Lessons From One Of The Coolest New Engineers In My Team

I work with a super cool new engineer. I am very very happy and excited to have him on board. We are very honoured and privileged to have him here. For the purposes of this blog I will not say anymore as my colleagues’ privacy is extremely important to me and I intend to keep it that way. But we have been chatting online and he has taught me some really cool new lessons.

I would like to do another mini series. This mini series will be breaking down all of the really cool lessons he taught me in one really productive afternoon. I will try and do as much of it as possible today. As I am working from the train. But let’s see

I ran out of other work to do that I don’t need really good internet on my laptop for

So what will be the main themes of these blog posts?

• Breaking things down (part 1)
• Externalisation and Verbosity (part 2) 
• How to write a good PR description (part 3)

But I wonder if I could make these any smaller. Let’s go go gooo

Because when I get sad I stop being sad and I write about software instead 

I want to make parts 1-3 smaller

• Part 1: breaking down tickets as small as possible
• Part 2: make commits as small as possible
• Part 3: make one file change per commit - but what does he mean by this I wonder 
• Part 4: externalising things part 1: make tickets as verbose as possible 
• Part 5: externalising things part 2: making commits externalised by using verbose commits
• Part 6: writing a good PR description part 1: writing a short paragraph explaining the why
• Part 7: writing a good pr description part 2: writing a short, bullet pointed, descriptive list
• Could also be parts 1a-c, 2a-b, and 3–b

But I am also trying not to work outside of hours 

BONUS EDIT: Part 8, or 3c as it turns out could be based off a cool slack message my colleague sent me - about a sweet spot between writing too much and not thinking about it at all. I'll pin this message. Thanks.