Gotta test that workflow from the iPad! This works through the magic of WorkingCopy!! Write in Obsidian, push via WorkingCopy… and boom, you’ve got a new note on the site. I’ve also modified the template used when auto-creating the new note to set a Unix flavoured timestamp as the name. These notes are intended for quick publishing!

These short notes are my first moves into POSSE - Publish on your Own Site, Syndicate Elsewhere. I’ve made it easier to post by having Obsidian as my editor and a convoluted build set-up with GitHub actions moving content around. Next steps are to fix up my site theme and then work on the syndication over ActivityPub (+ other API).

This is a quick note written in my (current) favourite note-taking app Obsidian and published out via Hugo to my site. More details on the set-up to follow.

Once you’ve worked on a few different software projects, you notice that different processes tend to work better for some and not others. For example, you may have experienced the pace and immediate feedback of working on a brand-new capability, made possible by the seeming lack of process and a focus on writing “just enough” code to make the feature a reality. In a different software project, you may have spent time sweating the details and producing code with a perceived high level of quality.

There are so many great books that I could recommend for a new manager. Narrowing down the list has been challenging! We’re fortunate that much is written on the practice of management. In addition to that, many Engineering Managers have detailed the specifics of working with technology teams. However, this makes it difficult to know what to focus on first. I’ve picked the first 10 I would recommend to a new manager.

Recently I was asked what resources I would recommend for someone moving from an engineering role and taking on a management role. Many people become a manager without clear training and development plan in place from their employer. “Congrats - you’re now a manager. Good luck!”. In this environment, finding your own sources for development is critical, yet, there’s so much out there that it can be challenging to know what to prioritise.

Life is weird right now. It’s like nothing I’ve ever experienced before and everyone reading this is likely to have undergone significant changes to the way they live, work and play. I started at Stash a week before the UK lockdown was announced. Stash took the decision the week before to move all their staff to remote work, so for the first time I’ve been through a remote onboarding process. This has continued, and as I write this, I’m half-way through my fifth week of working 100% remote.

This week, after over 3 and a half years, I left Alfresco. The decision to leave was a difficult one, but ultimately, it’s the right move for both the company and me. My connection with Alfresco goes back further than the recent years working for the company. Back in 2010, while working at Yell, I was part of a team tasked with creating a knowledge base based on (the now deprecated) Alfresco Web Content Management.

In many organisations, the request for feedback comes as part of a performance review cycle. During this process, an individual will review their goals, assess their career development plan and reflect on feedback from their peers. As humans, we have a bias to want to be near people that look and work as we do. This bias means that we tend to notice when people act or behave differently from the way we do.

Recently I got into a conversation about measuring the performance of Engineering teams. The teams in question are following the Scrum framework and have decided to use story points for estimating the complexity of the work. In the conversation, we were talking about the validity of measuring individual team performance and whether one should use this data to compare the performance across teams. Now, for anyone that’s even taken more than a passing glance of any of the literature surrounding agile development, Scrum or estimation, the idea of measuring team performance and comparing performance between teams is a clear anti-pattern.