Issue n. 3
Main Thread is a curated newsletter by https://alediaferia.com. You will find interesting articles, tweets and even podcast episodes about software engineering with a focus on startup engineering and practices.
Definitely not a juicy one this week, real life has been busier than usual. Still, I tried to share a few thoughts of mine I hope are going to be useful to you. Hope you’ll enjoy!
Fostering and maintaining a culture of continuous improvement is hard. It requires, unsurprisingly, a continuous effort. If you’re working at a startup you might find it challenging to carve time to improve the tools and processes that enable your work. After all, though, you would have a much harder time building the software and products you are building, without those tools and processes. Don’t think of them just as enablers, they can effectively be multipliers. But as your company grows and adapts so must your processes and tools. Review them continuously: they might have made perfect sense at the time but might actually be a bottleneck for you now. Rethink your pipelines and infrastructure and build them in an evolutionary fashion. This week I had the opportunity to reflect about the importance of creating the time and space to perform this reevaluation exercise as part of your work of building software. Community of practices are a great way to facilitate this. It’s often hard to see the benefits of doing things that are not strictly related to the value stream for your customers, like instrumenting your own SDLC tools, but that is an effective way to evaluate improvement opportunities. Set up recurring reevaluation meetings, make room for slack time so that people can spend time researching improvement opportunities, set up clear ownership boundaries so that teams can take care of what they own.
This short post explores the issue with collective code ownership: when everyone owns the code, no one owns the code. Learning from Conway’s Law, the organization and structure of your teams is the first place to start from when you want to achieve a desired type of architecture for your software.
Getting your work recognized
In this old but gold post by Julia Evans she goes through the importance of keeping a document of your achievements. Even if the organization tries to maximise for work visibility there might always be the chance that even important work goes unnoticed. This is not necessarily anyone’s fault: not everything is captured by a ticket on a board, you might forget you have contributed to something important, your manager might have missed something that you have done, and so on. Keeping a log of achievements is something useful that will help you negotiate a promotion or will help your manager negotiate a promotion for you. This is sound advice by Julia Evans.
Interesting Podcast Episodes
This episode by ThoughtWorks features Pat Kua. He will give some great insights about the role of tech leads and the different meanings it can assume from company to company.
Thank you for making it this far!