Hacker News Reader

Comment by mstade | Hacker News Reader

I used to work with a fella that wrote code similar to this. To him, code seemed to be a scratchpad, a place to jot down ideas and try them out. Once an idea worked out, he shipped it. Done.

Impossible to maintain, but damn if he couldn't churn out some quality works. Bug laden, sure, but the core ideas were great – at times even brilliant. There was a certain beauty to the chaos.

Prettier wasn't around then, and code for matters weren't much of a thing at all really. Can't help but think if that would've helped or stymied his process. Certainly would've helped the rest of us though!

View on HN

> Impossible to maintain, but damn if he couldn't churn out some quality works. Bug laden, sure

That doesn’t sound like quality work.

I’ve had colleagues like that, they’re a pain in the ass because they look productive at the cost of everyone else holding the bag, and while they’re useful for exploratory or prototypal work it can be difficult to make the stakeholder understand that no the bug-ridden mess with an injection per SQL query is not going into production ever.

I’ve wondered if forcing them to use a very restrictive langage could help channel the mess somewhat.

> I’ve wondered if forcing them to use a very restrictive langage could help channel the mess somewhat.

StyleCop in C# (and ESLint/Prettier to a lesser extent in JS land) works extremely well for this. It's very quick to red squiggle your style problems when you're writing, can often automatically fix the problem, and keeps everyone committing code that looks one way.

It drove me nuts when I started doing work in a team, but I got used to it quick and we rarely bikeshed now.

> difficult to make the stakeholder understand that no the bug-ridden mess with an injection per SQL query is not going into production ever.

Why do you bother saving the stakeholder from themselves?

Usually because you will inevitably get tasked with fixing something in that mess, and will have to slowly sacrifice your soul to get into the warped brain of that 'prodigy' coworker to understand the code if you don't.

Often these people are clients, so it's partly the team job to save them from themselves.

Because the stakeholders often don't have the wherewithal to understand the difference so we shouldn't let the charlatans and terminally flawed take advantage of them.

There is an interesting difference in philosophy in this and the parent. One is the mindset that engineering is a profession and the other something of a market will sort itself out approach.

Unfortunately we’re living in a world where the doors are coming off airplanes mid flight.

Is that not considered part of a developers job?

Reply on news.ycombinator.com