The one in my previous job, which was an admin board for a market intelligence application. Ultimately, the reason it was good was because the engineers had zero ego on top of having excellent skills. The team that set the codebase were basically 4 seniors and 3 principals (the client actually did pay for top talent in this case) so not only everything was based on industry standards, written elegantly and organized perfectly, but every time some new requirement came up, these senior / principal engineers would discuss it in the most civilized matter I have ever seen.
E.g, "we need to come up with a way to implement X". Person A gives their idea, person B gives another idea and so on until everybody shared their thoughts. Then someone would say "I think what person C said makes the most sense" and everybody would agree and that was it. 30 minutes to hear everybody out, 3 minutes to discuss who will do it and when and the meeting was over.
I think the biggest testament to this code base was that when junior members joined the team, they were able to follow the existing code for adding new features. It was that easy to navigate and understand the big picture of.
This is the approach I tried to take as an IC frontend on a building management system dashboard about a year ago. It was basically me and one other frontend, one full-stack, and a QA or 2, plus a manager. My manager I guess had written a lot of the code we'd be interacting with, and I guess was somewhat protective and reluctant to delegate authority over decisions around it. It was a big refactoring project, and I just encouraged my colleagues to take the things they wanted, like rebuilding the state management system. We'd discuss the requirements and why it was necessary, and I'd look for reasons to agree rather than disagree, then we'd be off. Something burnout has taught me is that the marginal differences between one implementation detail or another are not worth getting hung up on unless they pose a real problem, especially when someone else gets to decide that doing it fast is priority (sprints).
> Something burnout has taught me is that the marginal differences between one implementation detail or another are not worth getting hung up on unless they pose a real problem, especially when someone else gets to decide that doing it fast is priority (sprints).
I think this is true. And a self-imposed problem (should a problem arise) is much less frustrating to fix than one that came from a decision imposed by someone else, even if the latter avoided loads of other problems. Sometimes it's better to let people make mistakes (as you believe them to be) and correct them later.
Otherwise known as "you are not your code" and "you are not your ideas." Essentially, criticism against your code is not a personal attack (and other corollaries). Its definitely something I aspire to, but its surprisingly hard to get right.
What is development if not communication? Between the clients, the coworkers, the users, and the computer
I'd take a mediocre dev with no ego and ok social skills on my project any day over an egotistical genius who can't work with other people or effectively communicate their ideas
E.g, "we need to come up with a way to implement X". Person A gives their idea, person B gives another idea and so on until everybody shared their thoughts. Then someone would say "I think what person C said makes the most sense" and everybody would agree and that was it. 30 minutes to hear everybody out, 3 minutes to discuss who will do it and when and the meeting was over.
I think the biggest testament to this code base was that when junior members joined the team, they were able to follow the existing code for adding new features. It was that easy to navigate and understand the big picture of.