Hacker News Reader

I think what you are struggling with is not "developer" vs "production line worker," but rather "artist" vs "engineer." I'd go so far as to say artists don't belong in most development groups, engineers do.

What sets them apart is not necessarily creativity, but rather consistency, quality, and a set of ethics. An engineer has to ensure that what they build works, is robust to bad inputs, robust to errors and failure situations, and is maintainable by others. Consistent practice and tools is key to this and software is only starting to catch up to other engineering practices.

However, many developers see themselves instead as artists, and your comment is a classic example. You want to "create novel things," "ideate," and essentially produce pieces of unique art. You want to be the hero, with irreplaceable skills. This isn't a bad thing, there is always a place in the world for artists. We need artists!

However, art is not engineering, and it shouldn't be too surprising that the big companies want engineers, not artists. They want people who can build things reliably, predictably, work on a team, and yes be replaceable. These days it's more likely that you have to replace an engineer because thy leave for new work rather than are fired.

Both art and engineering are great professions, but different.

And I'm sure it WILL be replaceable because we are increasingly surrounding ourselves with these uniform ways of doing things.

The tension between creativity and conventions is fascinating.

I recently read a book about writing (ostensibly editing) called The Story Grid:

https://storygrid.com/

Here's a video summary:

https://www.youtube.com/watch?v=y3-dw9cIx2o

It argues that the most important thing for an author to understand is the genre they're working in because the genre gives the author conventions. Violate any of them and you're setting yourself up for failure.

The best authors find creative, non-obvious ways to innovate conventions while still adhering to them.

Although some will view this advice as sucking the creativity out of the writing process, the author argues it does exactly the opposite.

Frustrated authors find the idea of genres and conventions stifling. These are the ones who abandon conventions altogether. They are punished by pouring heart and soul into a work that doesn't sell and which they themselves often know doesn't work but can't explain why.

I like this idea. I think a good analogy is creativity being like a raw force, and a set of rules and conventions giving it direction so that it can be focused into a jet that can be pointed at a specific place and be really useful, rather than just spraying randomly around and probably not being all that useful.

I think a great example of this philosophy in music, is Jack White with the White Stripes. He held to a very rigid set of rules which resulted in very simple, straightforward songs. What was great about that was that it gave him a platform at live shows to perform amazing virtuoso solo stuff on top. The platform, with its simple rules and structure, allowed him to perform those solos. Had he come on stage and just randomly started playing solos from start to finish, it wouldn't have the same effect and would probably just be quite aimless and noisy.

It's true in software too. When building a web app tools like webpack et al exist to solve boring, routine problems in a standard way that you don't have to spend much time worrying about (webpack config issues jokes aside) so that you can focus all your creativity on what actually matters and what is interesting and unique - what your app does!

I'm currently reading "Story: Style, Structure, Substance, and the Principles of Screenwriting" https://mckeestory.com/

I think it agrees on your point.

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.

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!

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.

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.

Are you still programming everything in ones and zeros in a tape to be run by a Turing machine? If not, you're using tools to get your job done. It turns out that most tools allow you to get your job done quicker so you have more time to focus on other things.

I fully agree with you that there is a lot of wheel reinvention in JS, but given that you can use React to build native/mobile/web apps it means that people are empowered to build tools higher up the abstraction layers (see SICP) without needing to peek down below (until the abstraction leaks, and they always do).

That said, most software projects I've seen have been held back by human issues, poor communication of business needs or API design. Automation won't fix that so most your production line developers will still have a gig while human-written software is around.

Thankfully, they're also well positioned to transition into fixing the automators which will have bugs. :)

Turning developers into production line workers is precisely what needs to happen. The way we produce code is so ruinously expensive that nearly everyone in this industry accepts the tradeoff between developer velocity and product quality. The only way out of this is to automate programming so thoroughly that only the creative necessities remain.

> The way we produce code is so ruinously expensive that nearly everyone in this industry accepts the tradeoff between developer velocity and product quality

I've seen too much over engineered crap to believe this. In many case the over engineering was an attempt at making us more like production line workers in the first place with the "architect" breaking things down into cookie cutter steps.

There is also the problem with user expectations, there are several "production line" like environments available but no one likes the trade off of inflexibility.

> Turning developers into production line workers is precisely what needs to happen

I actually agree with this sentiment, although many others to hate on you on this thread.

And it will happen, just like what happened to labor workers who used to make a good living working for Ford at production line. You can already see plenty of evidence when you see how all developers are forced to use package managers and follow "coding guidelines", and so forth. These efforts will all lead to a more and more structured way of building things, which then can be replaced by machines.

And these naive and passive programmers who thought they were set for life by taking a coding bootcamp and getting a programming job will suddenly find that it's not as lucrative anymore.

The point I was trying to make was: Don't be these people who live a passive life and do what others say, thinking just because programmers make a lot of money, all you gotta do is "become a good programmer" and you'll be set for life. You should have a meaning in life. Otherwise you'll find yourself in the similar situation as these Ford production line workers.

Expensive in comparison to what exactly?

The only other science that's cheaper is math. Now I know plenty of human endeavours that bring absolutely nothing of value, and only serve to concentrate wealth, and cost everyone worldwide billions of dollars.

Are you aware of the military budget of the greatest country on Earth?

Ruinously expensive - what an apt description, just not for computer science.

In comparison to virtually any other design work. The most expensive commercial buildings ever constructed are in the neighborhood of 5-15 billion USD. Developing a Linux distribution from scratch would probably exceed $10 billion in developer costs [1]. Just think about that. Linux, not even the largest codebase known, compares with the most expensive civil engineering projects in history.

Code is phenomenally expensive.

[1] https://www.linux.com/publications/estimating-total-cost-lin...

That sounds extraordinarily cheap, actually. The most visited mall in the world has something like 80M visitors/year. Linux has literally billions of daily users, and it powers everything from their phone to the public transport network they use.

Software development scales poorly. This was noted a long time ago, an I’ve not seen anything that fundamentally falsifies the Fred Brooks view. So to make the expected cost of software lower, shouldn’t we be looking to smaller-scale, more individualistic ways of working?

Uhm, sorry that’s a bit too paranoid. The existence of ISO/IEC, DIN and the plethora of standard bodies haven’t made Engineering less creative or remunerative. Sure, you can’t craft your own custom bolt but you also don’t have to every time. Which is a good thing also