The funny part here is that in many cases it is still far easier to build stuff from scratch than to glue someone else's poorly documented shit together.

Yes. So many libraries are engineered to solve everyone's problems, you can spend hours, or days, figuring out if it is engineered to solve your problem. It's like searching for a needle in a haystack you aren't sure has your needle.

EXACTLY. In a previous HN comment I ranted about this exact topic. My threshold for adapting something very general to my specific case is now much lower than it had been.

To restate my position using your terminology: I prefer programming (creating from scratch) to engineering (integrating) because the components that a software engineer has to work with are so often unusable. To repeat a rant from an HN comment of a few weeks ago: I am working on a system involving Jetty, Postgres, and a connection pool. The first two components are pretty solid, and there is no shortage of Java connection pools to choose from. But getting them to all play together defeated me. Documentation for Jetty and for the connection pools is just terrible, and highly version specific. The APIs keep wiggling around as the versions change. I finally gave up on doing things the "right" way (configuring everything in XML), and also gave up on integrating a connection pool. I wrote my own very simple one.

I don't really see how this means things are worse now than they used to be. You can still write things from scratch now (just as you did). But "back in the day" you had much more limited options for libraries, so you were not always able to glue stuff together, and often forced to write things from scratch. I'd argue that means it's better now than it used to be.

It's a matter of expectations. Working on my own projects, I can rewrite and ignore existing software to my heart's content. If I am working with others, there is a very strong expectation that 3rd party software will be used whenever possible, and that I will participate in other engineering practices/fads that are judged to be beneficial. I don't mind doing things that have a good rationale for the problem at hand, but very often a team will do X because X is supposed to be a good thing to do. Cargo cult engineering, if you will.

> It's a matter of expectations. Working on my own projects, I can rewrite and ignore existing software to my heart's content. If I am working with others, there is a very strong expectation that 3rd party software will be used whenever possible, and that I will participate in other engineering practices/fads that are judged to be beneficial

Isn't that just part of 'being a professional' tho?

Being a "professional" means thinking. There is much unthinking adoption of the popular tools and approaches.

You cannot avoid using all those convoluted, unnecessary layers in many cases, even if you really want to. In JVM you're confined right on a top of a horrible pyramid. And in web it's even worse.

I think the reason such rants pop up occasionally and are often criticized is because the field was started by what you call "hardcore coders" - people interested more in the building part (and tweaking, and adapting) - but as it became more and more profitable, it got co-opted by the people who are more interested in getting stuff built, without paying much attention to how its built.

Or the way I look at it, it was once nerds' playground, and those nerds are now an unwanted minority of the growing software field. Hardware is going through the same thing now, with hardware hackers getting replaced by startups.

Now, I don't mean that in an offensive way. It's simply a clash of two cultures co-existing within the same field. There's lot of misunderstanding because of that. For instance - I work in a software company; there are 30 programmers on my floor alone, but only around 3 or 4 I'd consier "my kind" of programmers. The rest think I'm the office nerd, who likes weird shit (electronics? Lisp?) and for some strange reasons likes to (omg!) code after work, instead of running or going to a concert. When I first learned programming, pretty much every programmer I knew was like me. Now we're the minority.

> Or the way I look at it, it was once nerds' playground, and those nerds are now an unwanted minority of the growing software field.

I assume you have to be talking about some very specific subfield, because the practice of 'writing software in exchange for money' is over half a century old.

It seems to me that people doing software for money back then were "different breed" than those coming to the field today, now that software is suddenly hot and an easy career choice.

Software has had plenty of "hot" years tho and I'm not sure I can remember when it wasn't an easy career choice except maybe in the depths of some of the busts.

> I think there are still tons of options out there for people who like writing lower-level code, but it's moved into areas like embedded systems and scientific lab tools. All the coding work for most of the common stuff has been basically commoditized already.

If that were true, there wouldn't be new JS frameworks coming out every month. Those "hard core" coders are also the ones making the frameworks. Which isn't a bad gig, especially when you can sell educational materials to teach people the framework you made. :)

Hardcode coder is an oxymoron; coders are the ones attending an 8-week bootcamp then cutting and pasting Javascript from Stackoverflow. Hacker is probably what you mean.

Yeah, that's the connotation I was trying to avoid, that's what I was talking about...

>It used to be that your computer had a compiler, and editor, and a shell, and you would go to work, writing code.

By "hardcore coder" I just mean someone who thinks ^that^ sounds like a lot of fun.

And it does sound like a lot of fun.. I just prefer to be able to augment it with StackOverflow/Google :)