4 ms·

The problem in this scenario is not letting the developers use whatever they wanted. The problem is hiring the wrong developers, ones that use that freedom irr

The problem in this scenario is not letting the developers use whatever they wanted. The problem is hiring the wrong developers, ones that use that freedom irresponsibly. Keeping developers on a short leash doesn't solve that problem, it just covers it up. And it becomes a self-fulfilling prophecy, because any developer capable of making their own decisions won't work there, so what you end up with is people that need that level of micromanagement. (Yes, this is a form of micromanagement.) And that's what I read in the whole article: an inexperienced CTO who has shaped his policy based on his own limited experience, not acknowledging that that vision is heavily influenced by his own weaknesses. He is projecting his own attitude as a developer on all developers, and extrapolates from there.

stephenr 11y ago
I've met far more developers who would add some extra tech to the stack without a lot of deep thought about the actual consequences of doing so, than those who would either not do that, or discuss it with peers/senior devs/mentors etc. If you give developers carte blanche permission to add whatever they feel is necessary, you're using your business success/failure to teach them. That is wrong. As the CTO, the author's primary responsibility is to make sure the right tech decisions/solutions are made. It sounds to me like he's doing exactly that. If an experienced, "responsible" developer thinks they can make good use of tech X, surely he/she will understand that there is a standard process to have this new thing approved for use, and then it can benefit the entire company. If you can't identify to someone else why you think tech X should be used, what problem it solves, what process it makes more efficient, etc, then you're probably the wrong person to be making a decision about adding new software to the stack. Any "engineer" (I really bet actual engineers love how software developers have co-opted that term) who is "responsible" as you put it, and wants to add software to the stack, will surely discuss that plan with at least someone, right? Or maybe not. Maybe you think every developer should be allowed to make grand architectural changes to a platform worked on by 200+ other staff at their own discretion? If so I suspect somehow, that your reply is just a knee-jerk reaction to a place that expressly prevents cowboy-developer antics before they begin.
- makeitsuckless 11y ago
  Yes, I've also met far more irresponsible, unprofessional developers than responsible, professional ones. As the CTO, my first responsibility is to hire the people that make the "right" decisions/solutions. Of course they discuss those decisions with their coworkers and me. That's just common sense. Sure, I'll make the odd hiring mistake, but that's no excuse to create and entire culture around the assumption that every developer I hire has the maturity and professionality of a teenage sociopath. My reaction is a knee-jerk reaction to a culture of distrust, bureaucracy and micromanagement. The alternative to letting the inmates running the asylum is not to lobotomise the inmates, it's to not turn the place into in asylum in the first place.
- fsk 11y ago
  >If you give developers carte blanche permission to add whatever they feel is necessary, you're using your business success/failure to teach them. That is wrong. Also, many developers will use whatever tools they feel like padding their resume with, instead of what is best for your project.

stephenr 11y ago

I've met far more developers who would add some extra tech to the stack without a lot of deep thought about the actual consequences of doing so, than those who would either not do that, or discuss it with peers/senior devs/mentors etc. If you give developers carte blanche permission to add whatever they feel is necessary, you're using your business success/failure to teach them. That is wrong. As the CTO, the author's primary responsibility is to make sure the right tech decisions/solutions are made. It sounds to me like he's doing exactly that. If an experienced, "responsible" developer thinks they can make good use of tech X, surely he/she will understand that there is a standard process to have this new thing approved for use, and then it can benefit the entire company. If you can't identify to someone else why you think tech X should be used, what problem it solves, what process it makes more efficient, etc, then you're probably the wrong person to be making a decision about adding new software to the stack. Any "engineer" (I really bet actual engineers love how software developers have co-opted that term) who is "responsible" as you put it, and wants to add software to the stack, will surely discuss that plan with at least someone, right? Or maybe not. Maybe you think every developer should be allowed to make grand architectural changes to a platform worked on by 200+ other staff at their own discretion? If so I suspect somehow, that your reply is just a knee-jerk reaction to a place that expressly prevents cowboy-developer antics before they begin.

makeitsuckless 11y ago
Yes, I've also met far more irresponsible, unprofessional developers than responsible, professional ones. As the CTO, my first responsibility is to hire the people that make the "right" decisions/solutions. Of course they discuss those decisions with their coworkers and me. That's just common sense. Sure, I'll make the odd hiring mistake, but that's no excuse to create and entire culture around the assumption that every developer I hire has the maturity and professionality of a teenage sociopath. My reaction is a knee-jerk reaction to a culture of distrust, bureaucracy and micromanagement. The alternative to letting the inmates running the asylum is not to lobotomise the inmates, it's to not turn the place into in asylum in the first place.
fsk 11y ago
>If you give developers carte blanche permission to add whatever they feel is necessary, you're using your business success/failure to teach them. That is wrong. Also, many developers will use whatever tools they feel like padding their resume with, instead of what is best for your project.