Comment by pjlegato | Hacker News Reader

Comment by pjlegato | Hacker News Reader

Parent Full thread

Yes, or more accurately a large new generation of coders is entering the workforce who know how to code only in a superficial sense and think this is a good thing.

Programming, and especially startup programming, is being taken over by people who are primarily technicians rather than engineers. They want to assemble prefab components in standardized ways rather than invent new things. They are plumbers who know how to install from a menu of standard components, rather than civil engineers desigining purpose built one-off aqueducts.

It is the inverse of the "not invented here syndrome." The technician-programmer is trained to minimize time spent thinking about or working on a problem, and to minimize the amount of in-house code that exists. The goal is to seek quick fix solutions in the form of copy/paste from StackOverflow, libraries, and external dependencies to the greatest extent possible.

In house coding should, they believe, ideally be limited to duct-taping together prebuilt 3rd party libraries and services. Those who want to reinvent the wheel are pompous showboating wankers (they believe); creating your own code when you don't absolutely have to is a self-indulgent waste of time for impractical people who just like to show off their hotshot skills and don't care about getting things done. Move fast and break things and all that.

This began with stuff like PHP but really got going with Rails, which preached convention over configuration as a religion, and supplied a standardized framework into which you could easily fit any generic CRUD app that shuttles data between HTML forms and a database (but is painful if you want to deviate from that template in any way.) Note that Rails doesn't use foreign keys and treats the relational database as little more than a glorified persistent hash table.

This set the stage for Node.js (why bother learning more than 1 programming language?) and NoSQL (why bother learning how database schemas work?)

an engineer is more like a plumber than an inventor though.

you don't need to design a new type of screw to make a one off aquaduct, you don't need to design new bearings to make a gear box, you don't need to design a new opamp to make an amplifier, nor do you need to design a new MVC framework to make a one off CRUD app.

You use off the shelf parts and combine them with your knowledge and skills to produce and effective solution for your constraints. If you can't do it with existing stuff, then you design something new that can do it.

The point is that for most things, there were no such off-the-shelf parts in software engineering until recently. You had to invent each screw and bearing yourself, because you couldn't just order a bunch of screws and bearings. Nobody sold them.

Moreover, the difference is that today's technician-programmers don't know how screws and bearings work at all. The engineer who uses prefab screws and bearings still understands them in detail and knows when to deploy them and when not to. Rather than understanding what bearings are for, the technician-programmer has a problem X, reads a blog post that says, "I solved Y by adding some bearings," and thinks, "gee, X is similar enough to Y that adding some bearings may work."

They add some random bearings, some screws, some cams and driveshafts here and there, without any deep understanding at all of why you ought to use these things in a design... and over time build a Rube Goldberg monolith with 10,000 moving parts sticking out randomly that nobody actually understands at all, so as a result everyone is terrified to work on any part of it for fear of inadvertently breaking the other 60 hidden dependencies of that piece.

Bravo. Saving this comment.

For substance: Consider how this is all part of the effort by management to make programmers feel as interchangeable and insignificant as possible.

And it's not even in the name of quality. Plenty of software out there breaks because of its multiple single points of failure in the form of dependencies.

Yes, totally. I can understand why management does this. Coders have a very high turnover rate as a profession. When your genius Clojure or Rust programmer leaves, it's much harder and more expensive to find a replacement than when your PHP or Rails programmer quits.

This then incentivizes new coders to take up one of the popular languages, because that's what most of the advertised jobs are for, creating a self-reinforcing positive feedback loop.

The thing is, it actually doesn't matter. No one needs to be a certain way. Cool things will be done by people that can and will do those cool things. In the end the prescriptivity of this whole space is only ascribed by people internal to the whole system: externally nothing is 'supposed' to be done. This is just a symptom of more people programming.

The thing that will speak the loudest is actions and results. If people don't like depending on modules, don't. If you do, do. Eventually everything will be lost and forgotten like teardrops in the rain.

This "that's just like, your opinion, man" attitude may be fine if you have no worldly goal affinity and are planning on spending the rest of your days in a remote mountain monastery. If you don't care about achieving any particular goal, then yes, all possible attitudes are equivalent. But that sort of handwavey quietism is not actually relevant to almost all people's situations.

If you do have specific short term goals -- such as, say, "building a profitable software product before we run out of money" -- then all methods of approaching the task are demonstrably not equal. Some will work much better than others in terms of achieving that goal.

We can study the empirical results of the numerous attempts already made by other people and thus avoid repeating their mistakes.

This makes sense. But I don't think the two are mutually exclusive. I think goal-motivation is different from goal-attachment. Being attached to "I will do my best to make x happen" rather than x itself focuses on actions and growth (within realm of control) than consequences (often outside of realm of control). Like a product failing because people are just not into it.

I think we can avoid those mistakes but what I see here is people telling other people what to do in a way that sounds unconditional: "x is better regardless of your situation." Some techs are better for x, other for y. Merging someone else's experience tree into your own is good, but it must be contextualized by their perspective--they're working on mobile embedded soft vs. you are on web, maybe, for instance. Or games vs. databasey things. Or their job is a performance engr but you are UI...

What would you recommend to a junior CS major to avoid falling into this pattern?

Specialize. Pick a subfield of CS that you really enjoy, that really resonates with you -- machine learning, NLP, algorithms, whatever -- and become an absolute expert at it. Know your subfield inside and out.

Start thinking about what specialty you want now, today. Do some research, talk to professors and other students, etc. By the time you are a senior, you should know what you want to specialize in and be well on your way.

Then, you can get a job that actually requires deep knowledge. Since you actually care about this, you'll quickly become bored and frustrated if you take a standard startup code monkey job where you are expected to write Rails or PHP code all day, but then that's the only experience you'll have. You'll also be competing with less well educated programmers who are willing to work for less.

Reply on news.ycombinator.com