4 ms·

That's where we differ on the cause. > "And they took it, and I got back amazing works of art that created all kinds of discordance with our longer term archit

That's where we differ on the cause. > "And they took it, and I got back amazing works of art that created all kinds of discordance with our longer term architecture and vision" I interpreted this part as you attributing the cause to the talented folks creating the discordance in your team. For me, it's the reverse. That shows insufficient technical leadership from the top. It's the job of the Tech Lead to convince and ensure good architecture. If the Tech Lead get "amazing works" that are "all kinds of discordance", it's the failure of the Tech Lead. People don't believe in the architecture/design. They see flaws. As I mentioned above, it's the signal that you may have a weak TL. I would focus on improving that aspect first.

zmmmmm 5y ago
I think you're probably right and that's definitely part of the issue. However your assumption that people can all be convinced to agree on the technical architecture is part of the problem here. There are so many areas of software engineering where "reasonable experts" can disagree. Static vs dynamic typing, functional vs object oriented, loose coupled messaging based flows vs tightly coupled APIs etc. Successful systems can be built in all these ways as long as one is chosen and there is some consistency. But it is hard to be successful if they are built in all different ways at the same time. So inherent in this picture is that you will have people with irreconcilable differences about how things should work at a fairly deep level. Acknowledging your point however - part of what I say my mistake was in not "intervening" was to do more of this advocacy proactively, and flush out earlier on - can these individuals be convinced or is the difference irreconcilable. An example, if it helps, is in one instance one of the team was tasked to implement a particular feature, and they found that the implementation was too slow when written in Python. So without consulting they selected a different language that is not in use or understood by anybody on the team at all, and then developed this whole critical subsystem in this language. Meanwhile there were many alternatives within the team's chosen tech stack that could capably solve this problem with adequate performance (even Python if properly utilized). The solution was an amazing work of art (although quite buggy as it turned out). But it was a disaster for the project and actually sank the delivery of it.
- analyst74 5y ago
  If a piece of work is buggy, hard to maintain AND failed to deliver, I'm not sure if it can be described as amazing engineering. It sounds like you might have a team of talented and enthusiastic junior/mid-career engineers who lacked the experience and vision to see the bigger picture and long term future of their work.
- sgerenser 5y ago
  Don’t be afraid to say it, the language was Rust wasn’t it? Although Rust usually replaces C or C++, so maybe in your case Go is more likely. In all seriousness, seems odd that they were able to go so far down this road without anyone throwing up red flags.

zmmmmm 5y ago

I think you're probably right and that's definitely part of the issue. However your assumption that people can all be convinced to agree on the technical architecture is part of the problem here. There are so many areas of software engineering where "reasonable experts" can disagree. Static vs dynamic typing, functional vs object oriented, loose coupled messaging based flows vs tightly coupled APIs etc. Successful systems can be built in all these ways as long as one is chosen and there is some consistency. But it is hard to be successful if they are built in all different ways at the same time. So inherent in this picture is that you will have people with irreconcilable differences about how things should work at a fairly deep level. Acknowledging your point however - part of what I say my mistake was in not "intervening" was to do more of this advocacy proactively, and flush out earlier on - can these individuals be convinced or is the difference irreconcilable. An example, if it helps, is in one instance one of the team was tasked to implement a particular feature, and they found that the implementation was too slow when written in Python. So without consulting they selected a different language that is not in use or understood by anybody on the team at all, and then developed this whole critical subsystem in this language. Meanwhile there were many alternatives within the team's chosen tech stack that could capably solve this problem with adequate performance (even Python if properly utilized). The solution was an amazing work of art (although quite buggy as it turned out). But it was a disaster for the project and actually sank the delivery of it.

analyst74 5y ago
If a piece of work is buggy, hard to maintain AND failed to deliver, I'm not sure if it can be described as amazing engineering. It sounds like you might have a team of talented and enthusiastic junior/mid-career engineers who lacked the experience and vision to see the bigger picture and long term future of their work.
sgerenser 5y ago
Don’t be afraid to say it, the language was Rust wasn’t it? Although Rust usually replaces C or C++, so maybe in your case Go is more likely. In all seriousness, seems odd that they were able to go so far down this road without anyone throwing up red flags.