Over the years, I encountered Agile methodologies or their different implementations in as many teams. With time passing, it's interesting to live, hear and read about success and failures and the (often) inevitable push-pull between "business" and "engineering" when those are seen as different and in opposition. So this week,
As many articles I have read last week pointed out : managing people, leading people relies a lot on caring for them. (check some of those links in Episode 10 of "Through the stack [https://blog.imfiny.com/through-the-stack-01-10-week-15/] "). I wanted to unpack a bit more this idea and explain how
Even when we were not all working remotely we had them, but remote work has made the use of design papers to prepare, discuss and structure major engineering initiatives even more useful. This is a brief overview of the approach, from a simple one to a very structured one. The
Building a styleguide, a set of guide lines, establishing ways to monitor and know how the product runs, automating what can be, hosting and running the product, all these are key elements to build a technical culture within a technical company.
Aside of performance metrics one important thing to keep an eye on for your production environments is the number of errors they are throwing and what's going on in the logs.
Gone are the times where we would host our websites in our dorm, garage or office on a klinky server with the electrical plug scotched to the wall with a big "do not unplug" sign on it.
Many battles are to be fought in projects so it's key to choose your battles and avoid as many as you can. Styleguides and guidelines are, as we saw previously, key to ease the day to day work by avoiding extra work.
Once the team has started to adopt even an embryo of styleguides it's time to move onto the meatier things. Again, it helps to put some guiding lines for the team to see how and where to go.
Code does not evolve in a vacuum. It does not appear from nowhere, it does not just run on the developers computer and it does not just end in the code repository. Let's see how to keep an eye on the impact of changes.
It all start with style in which one writes code. It's the form, not the function that is first apparent when one looks at a code base. This form is the style used by the authors of the code base : the specific way to write using the programming language(s), the way to name and organize files.