It sounds like you enjoy writing code itself more than the process of building software. I get the same sense of wonder and excitement when I get an app to successfully do something I thought up in my head whether it's just attaching up a Google API to get a map or location picker integrated and working or if I'm coding out the whole feature myself.

I have a lot of respect for hardcore "coders" (I feel like that term has a pejorative connotation in tech, but I don't mean anything bad by it). But I think there are plenty of people out there like me as well. I consider myself an engineer, not a programmer. I solve problems and build things. Writing code is just one of the major tools in my arsenal to get things done.

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.

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 :)

It's because programming has evolved. More business owners are also already tech savvy because they grew up with a computer, Ipad, and phone.

In the beginning, programming was more fun. No oversight, bosses that don't really know what you are doing, programming at one point in time was treated like magic.

You glue together other pieces of code because in most cases, because the wheel has already been invented. This really was the dream of open source and with all of the free software and libraries out there, it's becoming a reality.

It's also going to drastically reduce the wage of a programmer over time. Most businesses don't need to hire an engineer to create a complicated library. They can hire someone with much less skill to use an already existing library to get what they need done.

Since the skills to get the job done will decrease, the supply of potential developers will increase and wages will decrease.

I suspect that the jobs are just changing, without a significant impact on wages, at least for the average Joe. Consider this analogy:

If everybody has to re-invent the wheel, you have to put all your resources toward getting someone to invent the wheel for you, so you can compete with all the other businesses using wheels.

Once everybody can re-use an existing wheel, you can aim higher, and put the same amount of resources toward getting someone to combine existing wheels and other parts to make something much more efficient and tailored to your business. And you need to do this to compete, because it's what everyone else is doing now, and a simple wheel just wont cut it.

So yes, someone with the skills required to invent the wheel becomes less in demand, but I would argue that someone who can turn existing parts into a working and customized whole requires just as much, if different, skills, with a roughly equal supply and demand ratio, thus able to demand a similar wage.

My argument that it requires as much skill stems from what others have pointed out. There may be a tool for everything, but it takes a lot of experience and ability to find an acceptable tool for each task amid a sea of tools of varying use, quality, documentation, etc. And it is rare that you can get maximum business efficiency from something cold off the shelf, without someone skilled modifying, configuring, tweaking, combining, etc.

If only there were wheels available. I like wheels, and I know what to do with them. I trust that they will work as specified. The problem is that with software nowadays, the components available are far more complex, and the true costs of using them are not obvious at the beginning of the process. More like Takata airbags.

Heheh, fair enough. I was intending my analogy to refer to high level tools in general. But yes, this illustrates my point, that there is and will continue to be a demand for highly skilled engineers who can identify and dismiss the Takata airbags and locate the parts that best match their employer's business.

Particularly outside startup world. Established businesses in competitive fields are constantly trying to maintain or gain their edge, and don't have time to build from scratch.

This isn't showing to be true despite proliferation over the last twenty years. Most kids don't want anything to do with programming because to most kids, it's a lot like doing math all day. Even as programmers become more enabled to solve more problems, the pace of problems being created is far outstripping the human race's ability to create (or inspire, whatever) programmers to solve those problems. I am willing to put a paycheck on a bet that no sane, knowledgeable person will ever be able to say that "we have enough programmers in the world".

Just wait for all the boring parts of programming to be automated. Then it is likely thay we'll have enough or more than enough programmers.

When the "boring" parts of programming can be automated, so can the "fun" parts, and AI will have "taken our jobs" just like they did down at the toothpaste factory. I'm not concerned about that. When it happens, that's fine by me. I have other skills to fall back on.

It won't happen all at once. There will be a long process of elimination of more and more layers, leaving more and more developers available for the work on the less automatable (more fuzzy and chaotic) side of spectrum. It will take years. At the end all of them will go home and do something else, of course.

Facebook and Buzzfeed sound like awfully solvable problems. Just install Leechblock and set a block for them during work hours.

The rest sounds like mis-management issues, which I think has more to do with lack of analysis than programming itself.

Porting Agile or Scrum to an organization and not checking whether that port breaks things is absolutely insane, but it seems par for the course nowadays (imagine how much shit a sysadmin would get for setting up Apache and his setup refused all requests...ah well).

Same goes for pair programming. Does it work better than the alternative? Yes? Great. No? Knock it off then.

What are PC unit tests?

Code reviews seem like a great thing IFF they work properly. Proofreading, style compliance, teaching, catching errors, etc. If none of those things happen, they are pointless. Might as well swap the company cars with wheel-less Tesla's or something.

It just sounds like you've got the management equivalent of a bad sysadmin going.

>>> same goes for pair programming. Does it work better than the alternative? Yes? Great. No? Knock it off then.

I've worked at small and large companies and I've had the same experience with pair programming. It's done as a means to supplant actual, formal training. It's utilized as a shortcut to get a dev vaguely familiar with the architecture of your system and do rudimentary tasks so they can jump in and start working in a day or so.

The painful downside of not adequately training your developers is tasks take longer, other more experienced devs are sapped by helping other devs who continually ask them questions and keep them from getting their stuff done because they can't find something, or simply don't know the proper process.

I've been on both sides and seems like proper training is really a thing of the past. No company wants to invest the time in their developers to give them the tools and knowledge to really do their job well. As a replacement, you get "pair programming" as a substitute to proper training program.

And yes, I know this isn't the point of pair programming at all. But lately (last three years or so), this is how the companies I've worked at use it.

The ironic thing is several of the companies I worked at had a two to three week sales training which culminated in a test to make sure you knew the companies products inside and out. Developers? Maybe a lunch with a lead dev, or a twenty minute whiteboard explanation about their system architecture.

I'll take pair programming over sitting in a classroom listening to an instructor drone on any day. The one time I joined a pair-programming shop, I thought diving in and being productive on the first day on the job to be pretty great.

Usually I get neither and have to figure it out from the code. I've found that writing documentation for the next person as you figure it out to be a nice way to get started.

I understand (though don't necessarily agree with) most of this perspective, but not the knock on code reviews. I think they're awesome - what could be more fun than reading and discussing other peoples' approaches to problems?

It's a very useful thing to do. Except that most of this discussion should be a design review much earlier in the process.

Design reviews are also awesome! I'm not sure I agree with your use of "most" - I would say that most things discussed in code reviews I've participated in would not have made sense in the design phase. Also, code reviews are as much for the reviewer's knowledge as for the author's.

It seems like you don't like to work with other people. There's a limit to the kind of software you can build entirely yourself.

Yet, this limit is far higher than most people tend to think.

all those things (agile etc) are better than working on waterfall style software with 5000 other programmers at microsoft and massive teams of PMs to coordinate it all. That was awful.

Oh, god. Here's the thing. You are the most right person on this entire page. Programming big projects in the days of yore was awful! It was AWFUL! And the worst part is that the whole waterfall thing is totally wrong. The original paper provided the waterfall as an example of how not to write software! Yet the whole industry suffered for thirty years. And still do, in some shops! Ugh!

really? developing repetitive stuff is fun? I want to re-write low-level mouse driver.

Find good libraries and mash it up to your heart's content!

Repetitive? No. Low-level? Yes, it certainly can be. Engineering a working application by shuttling data between a bunch of pre-written libraries can produce a satisfying result, and it's usually the smart way to design something.

Personally, I enjoy the process of building a clean abstraction more than using someone else's abstraction. If there's a system that doesn't have a mouse driver, then developing one sounds like it could be fairly interesting.