Hacker News Reader

Comment by meric | Hacker News Reader

Civil engineers also use same common brands of cement and standard steel girders. They also often re-use the same blueprint for multiple buildings. The creativity isn’t in the form but the ordering and process in which a given form is constructed over a particular piece of land - this one.

The same applies for software engineers. The method of using the common tools is identical across many web applications - the creativity is in which of these tools, for which set of subtasks are selected for this set of requirements.

View on HN

That might be the most depressing thing I've heard all day.

You get to be creative today. Which package manager are we going to use on our new project: npm, bower, or yarn?

Whoopty freakin' doo!

It's even worse.

As an engineer, it's not your job to be creative. The only creativity that happens in the company is that of C-suite people (who first comes up with what you'll build) and that of the sales staff (who figure out how to turn those half-baked ideas of the C-suite folks into something that can be sold).

Over the past months I've been having this crushing realization that - at scale - you can be either a creative manager or an assembly-line developer. You can't be a creative development. There are few R&D jobs here and there where the people with technical skills get to be creative, but they're scarce.

But do you really want to be the developer who has to debug 'creative' code after the original dev has left? It may not be as much fun, but I don't think that assembly-line development is entirely a bad thing. Even something minor like style conventions: far better to fit into the assembly line of your team's style guide than produce a project where every file is written in a slightly different way. Is this particular variable supposed to be const b/c it is all caps, or not? The last class followed that standard, but who knows? Small example, but can be applied to larger things as well. Last month I had to 'maintain' an application for a small business that had seen too much creativity from contractors over the years, and it seemed like every single one chose a different language.

Or we can just abandon practice of referring to development as engineering, and treat every project like artisinal craft work.

The package manager you get to use today depends on variables that are totally independent from your own creative process. Perhaps it’s the one that supports some tooling used by infra or security or whatever. Unless it’s an ungodly train wreck of a tool that is significantly interfering with your output, it’s not your job to reinvent package management. I’d scream to the high heavens if I’d have to resolve these problems every other project I take on - incidentally, stacks and platforms are such a moving target that I often have to do so anyway.

I've never seen a project live or die by package management[0], and I've never seen automated tooling come close to solving the real problem facing most developers: irreducibly complex business logic. Every once in a while one gives you a good head start on the boilerplate around the business logic - Rails a while back, React now - but it's far from solving the "every business is a little bit different" problem.

IME, the easier the scaffolding gets, the more creativity offered to the business. That's how I see my job as an engineer/systems designer: enabling the business to try new things more quickly.

[0] I've seen a lot of engineers justify rewrites because "these better tools will let us make a cleaner codebase" but if done with a focus on the tooling, instead of a focus on the coding implementation choices that led to a messy codebase in the first place, it often just burns a lot of money replacing an old messy codebase with a new messy codebase.

Reply on news.ycombinator.com