Author
I typically share insights on System Design & Go at Devtrovert. Feel free to check out my LinkedIn Phuong Le for the latest posts.
The following content delves into a controversial topic, please read with an open mind and be kind to different views. Let's talk about it nicely :)
Over the years in programming, I've often been guided by what many call "best practice". But with every project I tackled, a question kept coming up: is sticking to these best practices the only way?
These ‘best practice’ or ‘convention’ guidelines, recommended by experts or built from extensive research, seem to promise optimal results.
However, as I've navigated team dynamics and projects, I've realized that these practices, while valuable, are not always universally applicable.
Understanding Your Team
Teams, much like individuals, have their own identities: their strengths, weaknesses and rhythms.
Each team's distinct blend of personalities, skills, and experiences shapes its unique way of approaching problems and crafting solutions, what works marvelously for one team might be an obstacle for another.
Convention and Its Limitations
One fundamental aspect often overlooked when applying 'best practices' or 'conventions' is the context in which a team operates.
Consider the Golang programming community as an example.
Yes, Go has a widely accepted naming convention, which serves many developers well. But what if a different approach aligns better with your team's unique dynamics and experience?
A new developer walks in, fresh with Go conventions, and throws it into your team's face: “You guys are doing it all wrong! This isn't how Go's naming convention works!”, while they might be right by the book, but reality often tells a different story.
There’re various reasons:
The team might be working with legacy code that was written before certain Go conventions were established or widely adopted.
While deviating from the Go standards, their own convention make more sense to them and facilitate smoother collaboration.
If a Go project is closely integrated with systems written in other languages, it might make sense to adopt naming conventions more consistent with those systems to reduce cognitive load for developers switching between them.
For teams transitioning to Go from other languages, there might be an interim period where they use conventions familiar from their previous experiences to make the learning curve less steep.
The team might value flexibility and pragmatism over strict adherence to conventions. As long as the code is readable, maintainable, and efficient, they might prioritize getting things done over following every convention to the letter.
…
Conventions should adapt to teams, not the other way around, their real worth is gauged not by how popular they are, but by how effectively they serve a team's specific needs.
“But what if that convention is great for my team and I want to change it?”
The bad thing you will do is, change it without notifying EVERY member of the team even if that convention makes you feel like a world class coder for following the standard (I admit I used to think this way).
The solution is to discuss the proposed change with your team and get input from all members. Explain your rationale for wanting to modify the convention, but also listen sincerely to any concerns or counterarguments others may have.
"What if everybody agrees?"
Well, that’s great. But will you change the legacy code to adapt to the new convention, or just apply it to the new code?
The second option means temporarily keeping two co-existing conventions and this takes extra coordination and documentation on when each applies. More critically, it causes cognitive overhead for developers switching between the two conventions.
One more convention = one more confusion
…
“Can I adopt idiomatic or standard conventions for a new project/ codebase?“
Yes, that’s great too. Yet, consider answering over these questions first:
What exactly does your convention involve? Is it purely about coding aspects like naming, or does it also change models or HTTP Responses?
Does this new project have any connections or shared aspects with older ones?
Are there any systems that will engage with both projects and could be impacted by these changes?
If a system interacts with both projects, and they employ different conventions, it might sow seeds of confusion. In such cases, I'd advise caution and perhaps retaining consistency.
Similarly, the broader concept of 'best practices' arises.
The Nuances of ‘Best Practice’
Best practices are often hailed as tried-and-true methods that promise consistency and success. Yet, just as with conventions, they can't be applied universally without considering the team's unique dynamics.
Let's look at Scrum's sprint cycle as an example, a small team in a startup might need to change things often based on what their users say. So, a two-week sprint might not be the best for them.
But some people, after learning about Scrum, might say, “We have to do two-week sprints because that's the Agile way”, this misses the main idea of Agile, which is to be flexible and fit the team's needs.
Every team is different.
They have different sizes, types of work, challenges, and ways they talk to each other. Using Agile without thinking about these differences can cause problems.
Don't just be professional, be an essential part of the team.
Top comments (0)