3 ms·

There's a big difference between "rely on" and "be considerate of". I'll take from the recently-created throw-away account that you know this already, and, bas

There's a big difference between "rely on" and "be considerate of". I'll take from the recently-created throw-away account that you know this already, and, based on this interaction, I don't think I mind not having a place in your team.

throw4950sh06 2y ago
As a manager of a large engineering organization, I'm unfortunately forced to not be considerate in order to make the org scale to dozens/hundreds of people. Proper usage of tools is crucial and I spend considerable resources to teach the engineers in my org about the tools we use. We took a great deal of effort to make the dev experience full featured, accessible and universal. You click a button and get a web browser based IDE where you have everything ready, connected to a cloud computer with a full dev env that mirrors our prod env; that from any branch and the button is right there in pull request UI. There is no reason why someone in this org should require everyone to write double letter iterator var names just because they couldn't be bothered to play the video where I taught how to use the advanced code search and the feature could be available to them in less than a minute of fooling around if they tried. On this scale, following standards is absolutely necessary. If my engineer has to stop and think "but wait, in this company they do it differently" - this times 150 people I currently manage - then I failed at my job. Some devs hated me when I came into this (much smaller back then) company few years ago and the first step I did was to put a global linter and formatter there. They were angry about how they would format it better than the formatter. Well that's nice - but that doesn't scale to hundreds of people. People make mistakes, stop caring, have different opinions... And all these questions in their minds are again my failure at my job. It's my job to answer these once and forever and to make it easy to follow the rule. While this is a personal anecdote, I was a large corporate principal engineer for many years and I am mirroring what I saw working there. I can't say this approach to making software engineering work at scale is uncommon. Please note that here I'm talking about working at a job, usually for very good money. Nothing of this applies to personal projects, most open source projects and so on. In these cases I'm very much on your side.

throw4950sh06 2y ago

As a manager of a large engineering organization, I'm unfortunately forced to not be considerate in order to make the org scale to dozens/hundreds of people. Proper usage of tools is crucial and I spend considerable resources to teach the engineers in my org about the tools we use. We took a great deal of effort to make the dev experience full featured, accessible and universal. You click a button and get a web browser based IDE where you have everything ready, connected to a cloud computer with a full dev env that mirrors our prod env; that from any branch and the button is right there in pull request UI. There is no reason why someone in this org should require everyone to write double letter iterator var names just because they couldn't be bothered to play the video where I taught how to use the advanced code search and the feature could be available to them in less than a minute of fooling around if they tried. On this scale, following standards is absolutely necessary. If my engineer has to stop and think "but wait, in this company they do it differently" - this times 150 people I currently manage - then I failed at my job. Some devs hated me when I came into this (much smaller back then) company few years ago and the first step I did was to put a global linter and formatter there. They were angry about how they would format it better than the formatter. Well that's nice - but that doesn't scale to hundreds of people. People make mistakes, stop caring, have different opinions... And all these questions in their minds are again my failure at my job. It's my job to answer these once and forever and to make it easy to follow the rule. While this is a personal anecdote, I was a large corporate principal engineer for many years and I am mirroring what I saw working there. I can't say this approach to making software engineering work at scale is uncommon. Please note that here I'm talking about working at a job, usually for very good money. Nothing of this applies to personal projects, most open source projects and so on. In these cases I'm very much on your side.