I found this in a back issue of Communications of the ACM. I shared it because, frankly, I could see myself in part of the story. I see some limitations of the article: (a) I suspect the tone may grate on some people – including myself; (b) the label of “hazardous enthusiasm” seems problematic and perhaps conflates too many other issues; and (c) as would be expected, it shares just one viewpoint around a particular kind of contributor.
In any case, I think it might be a useful starting point for discussion, even though it leaves out some pretty big facets of the issues involved.
I’ve definitely run into a few devs of this type — not in the open-source world, but at work.
This company (no longer my current employer) was started by a CEO who could “write a bit of code”. He hired a couple more devs to get things over the wall into production, and the company was quietly successful for the next 5 or 6 years, then it started getting big fast, had an IPO, acquired a bunch of companies, started up a bunch of new products, etc. — but the main revenue source was still the codebase that the CEO had started on day one, which was getting pretty scary and fragile. It was ugly, but it worked. There was a Big Rewrite project, but it didn’t succeed until after I was gone.
Anyway for several years I was pretty much in charge of the care and feeding of that app, and I was pretty decent at it, managed to keep it running in the face of way more traffic, and even add new features. Management, of course, always wanted me to have more devs, so that they could have more new features. So we hired, and some were dull, and some were bright, as it goes. But I learned that being bright wasn’t enough — some of the brightest ones just could not engage with the code on its own terms. It was too different from anything they’d dealt with. If you tasked them with adding a checkbox to a form to control a new user preference which had to be honored in a certain place, they would come back with a plan to refactor this, rewrite that, and extract such-and-such into a new service written in Clojure. Noble, and sometimes with good ideas behind it, but not practical. If you asked them to stick to getting the job done, their brains would lock up. We would send them off to another team working on a greenfield project with a sexy tech stack, and start looking for a replacement.
I found this in a back issue of Communications of the ACM. I shared it because, frankly, I could see myself in part of the story. I see some limitations of the article: (a) I suspect the tone may grate on some people – including myself; (b) the label of “hazardous enthusiasm” seems problematic and perhaps conflates too many other issues; and (c) as would be expected, it shares just one viewpoint around a particular kind of contributor.
In any case, I think it might be a useful starting point for discussion, even though it leaves out some pretty big facets of the issues involved.
I’ve definitely run into a few devs of this type — not in the open-source world, but at work.
This company (no longer my current employer) was started by a CEO who could “write a bit of code”. He hired a couple more devs to get things over the wall into production, and the company was quietly successful for the next 5 or 6 years, then it started getting big fast, had an IPO, acquired a bunch of companies, started up a bunch of new products, etc. — but the main revenue source was still the codebase that the CEO had started on day one, which was getting pretty scary and fragile. It was ugly, but it worked. There was a Big Rewrite project, but it didn’t succeed until after I was gone.
Anyway for several years I was pretty much in charge of the care and feeding of that app, and I was pretty decent at it, managed to keep it running in the face of way more traffic, and even add new features. Management, of course, always wanted me to have more devs, so that they could have more new features. So we hired, and some were dull, and some were bright, as it goes. But I learned that being bright wasn’t enough — some of the brightest ones just could not engage with the code on its own terms. It was too different from anything they’d dealt with. If you tasked them with adding a checkbox to a form to control a new user preference which had to be honored in a certain place, they would come back with a plan to refactor this, rewrite that, and extract such-and-such into a new service written in Clojure. Noble, and sometimes with good ideas behind it, but not practical. If you asked them to stick to getting the job done, their brains would lock up. We would send them off to another team working on a greenfield project with a sexy tech stack, and start looking for a replacement.