In Part 1 of this article (link to part 1 here), I talked about organizing the code itself: architecture, Clean Code, and SOLID. But well-written code isn't enough if the team around it doesn't have a clear process for versioning, documentation, and workflow. That's what I want to talk about now.
I Had Been Doing It for a While — I Just Didn't Know the Name
I remember a coworker asking me to "create a feature branch off of develop." I did it almost without thinking, since it was exactly what I'd already been doing for years. But that's when it hit me: "wait... does this have a name?"
That's how I found out that "automatic" workflow I'd been using — stable main branch, feature branches, isolated hotfixes — already had a formal name: Git Flow.
And that wasn't the only time. Earlier in my career, it was common to follow instructions ("do it this way," "follow this pattern") without understanding why, or even knowing there was theory behind it. Practice arrives before the name, and only later — out of curiosity, or in a conversation with another dev — do you discover the formal label for what you were already doing. It's not a lack of competence, it's just the natural order of day-to-day learning.
I think that says something about how we pick up good practices — and sometimes bad ones too 😅
We often internalize a behavior out of necessity, and that doesn't automatically make it right or wrong — only later do we chase down where it actually came from. It's normal to take time connecting "the name to the thing." And it's worth being careful here: it's easy to assume a process is correct or a best practice just because someone told you to do it that way, when really you might just be holding onto a habit. Staying curious, researching, and studying alongside hands-on experience is what builds real clarity over time — and lets you explain the process clearly to whoever joins the team next. Sharing technical knowledge about the project you're working on is also part of your responsibility, which is exactly why it matters so much.
Documentation: The "Clean Code" Nobody Reads But Everyone Misses
Documentation tends to get treated as a second-class task — until the day someone new joins the team and has no idea how to set up the environment or why a certain architectural decision was made. A well-written README, a few strategic comments (not excessive ones), and recorded architecture decisions save, without exaggeration, days of work over the life of a project.
Scrum, Kanban, and the Right Fit for Each Context
On the process side, I work with a mix of Scrum and Kanban depending on the nature of the project. For deliveries with clear deadlines and scope, Scrum's sprint rhythm helps create predictability. For ongoing maintenance or smaller squads, Kanban's visual flow tends to fit better, without the overhead of ceremonies that don't always make sense for small teams.
Agile methodology isn't about following a rulebook — it's about creating visibility into what's being done and reducing communication friction between whoever's coding and whoever depends on what's being coded. Many think it's overkill or unnecessary process, but it's precisely in its absence that its value becomes obvious.
In the End, It's About the Next Developer
Bringing both parts of this topic together — clean architecture, SOLID principles, well-defined versioning, documentation, and an agile process that actually makes sense — it all converges into one question I try to ask myself before every Pull Request: if someone else opens this code tomorrow, without me around, will they understand what I did and why?
This topic is broad enough that I'm sure there are other techniques and methodologies out there I haven't come across yet, and I'd love to learn them. So tell me — what did you think? Any tips to add? What are some things you were already doing without knowing there was a technical name for it? 😅
Let's discuss it below 👇
If this content resonated with you, drop a like and share it with someone who deals with this kind of team challenge too. And if you want to follow more of what I'm building, find me on LinkedIn, GitHub, or my portfolio.
Top comments (0)