3 ms·

Different developers have different values. It is clear in this case these “smart” devs have different values than you. It sounds like they are engineering tow

Different developers have different values. It is clear in this case these “smart” devs have different values than you. It sounds like they are engineering towards a view of “elegance” of the solution, what is the most compact and DRY way to accomplish a result. You appear to value simplicity over elegance, which makes sense in the brief context you’ve provided. Convincing them to switch values may take a long time (or never), but in my experience you need to repeatedly stress the values you want the system built on, and give concrete examples of why whenever possible. Give practical reasons why simplicity is better (system stability, debugging, maintenance, etc). But recognize that for some “smart” people this will be “boring”, and they will never do well. It reminds me of a manager I had ages ago who preferred C++ to Java because his C++ solutions required huge amounts of brain power for anyone to understand, where as the Java solutions could be understood even by dullards like me.

chunk_waffle 4y ago
This is the comment I was looking for, it appears to me to be a difference of values and it will likely continue to cause tension( unless someone's values change.)
semitones 4y ago
When I first joined the company I'm currently working at, I was a bit too focused on elegance, "proper" tooling/structure, and "doing things the right way", etc. For example, I couldn't _believe_ that we used raw SQL in our endpoints instead of using some fancy state-of-the-art ORM. The company is a start-up, and my previous job was as a SWE at Google, so naturally a lot of design decisions felt shocking to me. I definitely spent a lot of energy thinking about how we needed to "change everything". Over time, I learned more about the history of our company + the projects I work on, and why they have come to be this way, which has helped humble me a bit, and in turn make me more effective on the team. However, what has _really_ made a difference w.r.t making me more effective, is a recalibration of my incentives - rather than focusing on personally "creating impact" and "enacting change", I shifted my focus to "what does this company need to be successful, and to go public". This significantly changed my thought process when it came to prioritizing work, and has made me easier to work with. Counterintuitively (to me), that shift has done more to make me a better engineer, than perhaps increasing my technical expertise would have.
alocasia-1 4y ago
> [...] the Java solutions could be understood even by dullards like me. This is 100% the type of person that came to mind when I read the OP. I'm sure we're all sick of the term "gatekeeping" but when folks consider it a plus and not a minus when their code is intimidating to others, it's really appropriate.
atomicnature 4y ago
This seems like the correct diagnosis to me. "Deeply held beliefs" are at play, at all levels and activities of the organisation, from coding practices, to hiring and marketing. The almost unstated, invisible beliefs destroy collaboration, since it is natural for them to come in conflict. In a way, if we go deeper into why a religion works, and enables collaboration among large number of people, it is because it homogenizes "deeply held beliefs" through various shared literature and practices. By extension, if an engineering team must work together in more cohesive ways, "the engineering religion" must be more explicit and there must be higher levels of bonding, more explicitly stated "deeply held values". It is difficult, since it requires excavating deeply held beliefs from individuals, finding common ground, or "installing" at a deeper level beliefs beneficial to collaboration.

chunk_waffle 4y ago

This is the comment I was looking for, it appears to me to be a difference of values and it will likely continue to cause tension( unless someone's values change.)

semitones 4y ago

When I first joined the company I'm currently working at, I was a bit too focused on elegance, "proper" tooling/structure, and "doing things the right way", etc. For example, I couldn't _believe_ that we used raw SQL in our endpoints instead of using some fancy state-of-the-art ORM. The company is a start-up, and my previous job was as a SWE at Google, so naturally a lot of design decisions felt shocking to me. I definitely spent a lot of energy thinking about how we needed to "change everything". Over time, I learned more about the history of our company + the projects I work on, and why they have come to be this way, which has helped humble me a bit, and in turn make me more effective on the team. However, what has _really_ made a difference w.r.t making me more effective, is a recalibration of my incentives - rather than focusing on personally "creating impact" and "enacting change", I shifted my focus to "what does this company need to be successful, and to go public". This significantly changed my thought process when it came to prioritizing work, and has made me easier to work with. Counterintuitively (to me), that shift has done more to make me a better engineer, than perhaps increasing my technical expertise would have.

alocasia-1 4y ago

> [...] the Java solutions could be understood even by dullards like me. This is 100% the type of person that came to mind when I read the OP. I'm sure we're all sick of the term "gatekeeping" but when folks consider it a plus and not a minus when their code is intimidating to others, it's really appropriate.

atomicnature 4y ago

This seems like the correct diagnosis to me. "Deeply held beliefs" are at play, at all levels and activities of the organisation, from coding practices, to hiring and marketing. The almost unstated, invisible beliefs destroy collaboration, since it is natural for them to come in conflict. In a way, if we go deeper into why a religion works, and enables collaboration among large number of people, it is because it homogenizes "deeply held beliefs" through various shared literature and practices. By extension, if an engineering team must work together in more cohesive ways, "the engineering religion" must be more explicit and there must be higher levels of bonding, more explicitly stated "deeply held values". It is difficult, since it requires excavating deeply held beliefs from individuals, finding common ground, or "installing" at a deeper level beliefs beneficial to collaboration.