4 ms·

No offense, but it's not my responsibility to make sure you have job satisfaction. It's my responsibility to keep the lights on and your paychecks coming in. T

No offense, but it's not my responsibility to make sure you have job satisfaction. It's my responsibility to keep the lights on and your paychecks coming in. This is a public company and I have compliance requirements to meet or I am personally liable or face jail time. And with thousands/tens-of-thousands of engineers, your tool choice and lack of streamlined repeatable systems is costing us millions of dollars in profits every year and keeping your pay and the value of your equity down. If you're going to depend on collectivist systems to provide you a stable livelihood, don't be surprised that the collective doesn't reward your individuality and entreprenureal spirit. There are other organizations that value that. Go work for them.

ngrilly 4y ago
Do you know each other?… As a matter of fact, many listed companies reward an entrepreneurial spirit and value employee satisfaction, because that’s usually linked to sustainable growth.
ouid 4y ago
Millions of dollars is worth sacrificing the job satisfaction of tens of thousands of engineers? Just because you can't measure job satisfaction and report on the value that it provides to your company doesn't mean that it doesn't exist, or isn't doing that. If you divide the two rough numbers that you provided, you get hundreds of dollars per engineer. This is not very much money. It sounds like you think that because you can't measure it, you are legally obligated to assert that it is zero. You are bad at your job.
cjk 4y ago
I think you seriously underestimate the value of job satisfaction and its effects on productivity. I would also say that dev environments can be “streamlined” and “repeatable” while allowing for personal choice of editor and whatever other ancillary tools the developer is productive with. They’re not mutually exclusive.
taeric 4y ago
I'm not sure why you think I am questioning your responsibility? My observation has been that teams that don't have tool choice almost always lost it because they had an overly specified build environment. Often under the guise of "streamlining" the setup. And this is why they have that particular build server still sitting around that only the head developer is allowed to modify. In what should be a straw man argument, I've seen this go so far as folks not knowing how to even try to build their software on anything other than the sanctioned IDE with them having to use the mouse to click the "now build" button. Which is all to say, my argument is intended to be that you do need a repeatable and streamlined build system that is tested and run in a variety of environments. The more diversity in where/how it is run, the more trust I have that the team actually understands how it works. Especially as a whole. For the personal control, letting the devs accomplish onboarding in a way that they control empowers them to make the changes to the setup that help make that happen, and gives more autonomy to them. Giving them autonomy means they can fix things they see. And you want that, as they will see far far more of what is happening than board level management will. Does this mean you can't/don't meet compliance? Of course not. Most compliance can be tested. And it should be tested. Again, this testing benefits from diversity of execution, as well, such that a test that can pass on a variety of environments and toolsets is far more trustworthy than one that can only pass on a particularly sanctioned setup. Now, pulling this back from a straw man argument. I accept there are situations where this level of freedom is harder to achieve. If you take my argument as absolute requiring that the entire team supports every possible variation of tool that could be thrown at them, please walk it back some. That isn't my intent. I just get scared by efforts to unify it all down to one, as well.

ngrilly 4y ago

Do you know each other?… As a matter of fact, many listed companies reward an entrepreneurial spirit and value employee satisfaction, because that’s usually linked to sustainable growth.

ouid 4y ago

Millions of dollars is worth sacrificing the job satisfaction of tens of thousands of engineers? Just because you can't measure job satisfaction and report on the value that it provides to your company doesn't mean that it doesn't exist, or isn't doing that. If you divide the two rough numbers that you provided, you get hundreds of dollars per engineer. This is not very much money. It sounds like you think that because you can't measure it, you are legally obligated to assert that it is zero. You are bad at your job.

cjk 4y ago

I think you seriously underestimate the value of job satisfaction and its effects on productivity. I would also say that dev environments can be “streamlined” and “repeatable” while allowing for personal choice of editor and whatever other ancillary tools the developer is productive with. They’re not mutually exclusive.

taeric 4y ago

I'm not sure why you think I am questioning your responsibility? My observation has been that teams that don't have tool choice almost always lost it because they had an overly specified build environment. Often under the guise of "streamlining" the setup. And this is why they have that particular build server still sitting around that only the head developer is allowed to modify. In what should be a straw man argument, I've seen this go so far as folks not knowing how to even try to build their software on anything other than the sanctioned IDE with them having to use the mouse to click the "now build" button. Which is all to say, my argument is intended to be that you do need a repeatable and streamlined build system that is tested and run in a variety of environments. The more diversity in where/how it is run, the more trust I have that the team actually understands how it works. Especially as a whole. For the personal control, letting the devs accomplish onboarding in a way that they control empowers them to make the changes to the setup that help make that happen, and gives more autonomy to them. Giving them autonomy means they can fix things they see. And you want that, as they will see far far more of what is happening than board level management will. Does this mean you can't/don't meet compliance? Of course not. Most compliance can be tested. And it should be tested. Again, this testing benefits from diversity of execution, as well, such that a test that can pass on a variety of environments and toolsets is far more trustworthy than one that can only pass on a particularly sanctioned setup. Now, pulling this back from a straw man argument. I accept there are situations where this level of freedom is harder to achieve. If you take my argument as absolute requiring that the entire team supports every possible variation of tool that could be thrown at them, please walk it back some. That isn't my intent. I just get scared by efforts to unify it all down to one, as well.