Documentation as low hanging fruit I lean towards the view that “even bad documentation is better than no documentation.” The number of times I find an open-source project I want to use and it has no documentation is unfortunately high. Anyone for whom the complexity of your project is beyond their technical capabilities is likely just to give up and find an alternative. Good documentation makes your project approachable, and writing documentation is often an easy way for contributors to approach your project.

If you’re new in your tech career through to making your first move into a senior engineering or leadership role then I am open to chat and mentoring on Merit. I’m happy to talk about the industry, career transitions, learning new skills, and/or connect you to other resources where that could be helpful.

In Part I of this series, I talk about shaping the role and how to think about who to hire. In Part II, we’ll cover how to hire and what to ask to ensure you make the best possible hire. Competencies In Part I we discussed what an EM role is shaped like and what competencies we expect candidates to have. These cover both leadership and technical skills. Our final list looked like this:

I do a lot of hiring, internally and as an advisor and consultant. I also read a lot about recruiting, and OMG, there are so many opinions about how to hire engineers. Everything from the interview process to take-home tests to the validity of whiteboard coding exercises has been explored and litigated. Some of my work also focuses on hiring engineering leaders for existing teams or the first engineering leader hired for an organization.

I have a lot of Bash/Zsh/Fish shell aliases. I’ve carted around a collection of dot files across laptops running both Linux and macOS and for use on systems I’ve managed. I’ve shared some of these, specifically for Docker, in the past. I wanted to do a post detailing some of the other aliases I have in case they are helpful to folks and talk through how to create and manage your aliases.