How To do __ Right Way?

Documentation is a vast area. It can be done in lots of different mediums, describing  many different aspects of software for various stakeholders. Here, we focus on how  developers can use high-level documentation to communicate inside a team, and with  direct stakeholders. All of these are things that can complement the documentation  already provided by code, scripts, and tests. 1. Create a common understanding I often catch myself working under the assumption that everybody on the team has the  same understanding of what we are doing. “Surely the view of the architecture in my  head is clear to everybody?” That would imply we don’t have to write these  seemingly obvious things down or have a sketch on the wall. This is a fallacy that, especially more tenured developers on the team are prone to. Architecture show-and-tell To verify how accurate our assumptions about common understanding really are, you  need to get each team member ...

A Day With Leader. The leader 's responsibilities are not too different from any other developer on the team. In fact, if you’ve been working as a software developer for a few years, chances are you’ve filled the role of tech lead/ team leader at some point. Perhaps not officially, but most of us have, at anytime, called the shots on important pieces of work or been the go-to person on a particular project. Most ‘true’ leaders are “de facto” tech leads- leaders in all senses of the word, but without the fancy title. In teams that contain few people who satisfied different meanings of the tech lead/team lead role, with one who excelling at organization and big vision, another at right execution and day-to-day engineering, and another at better architecture, teaching, or getting stuff deployed smoothly. What does day look like? With wearing a leader’s crown, This is good for the team, but it adds challenges to scheduling time due to much of day is interrupt-driven wit...