[jasode]

>This statement makes me concerned that they have greatly devalued technical skills. [...] When technical ability is devalued so much in a company,

I'm not going to justify their thinking but I'll attempt to explain where it probably comes from.

The context for their perspective is crucial. Notice that their assertion for "less time to develop technical skills" is followed by a sentence praising graduates of "code bootcamps". They also prominently espouse Ember.js[1].

To make sense of that, we can (roughly) divide programmers into two groups: (1) CRUD LOB Line-Of-Business (2) algorithmic/embedded

(1) is programming the enterprisey, forms & fields, "back office" apps. It was COBOL, dBASE/Clipper, Visual Basic, Microsoft Access, C# Winforms, 4GLs like Oracle Forms & SAP ABAP, and now Javascript frameworks such as Ember.js/Angularjs. Basically, slapping a client GUI in front of a database backend. Whether that client GUI technology is Visual Basic, or mobile phone Javascipt, or iOS Swift app... that choice is more about whatever zeitgeist of programming you happen to be living in rather than any inherent difficulty levels between the technologies. The idea is to take the high-level frameworks+libraries and glue them together to deliver value to the business.

(2) is programming of realtime kernel schedulers, complex distributed computing algorithms, search engines, database storage engines, machine learning, ray tracing graphics and physics engines for video games, audio DSP, traversing graph nodes, control theory for drones and Mars Rover, etc. This would be more "engineering" type of coding rather than "integration/glue" coding. Typical programmers we'd think of in this group would be Jeff Dean (Google MapReduce/Tensorflow), John Carmac (Doom), Fabrice Bellard (ffmpeg).

The programmers in group(2) wouldn't say it's easy to take "leaders" and add programming skills to them. However, that sentiment is often expressed by group(1) programmers. I'm not saying it's the "right" philosophy but it's an observation I've seen repeatedly. The CRUD programming is often seen as just a longer more elaborate version of programming the Tivo / thermostat / lawn sprinkler system. It doesn't seem like group(1) is "devaluing" themselves but instead, they honestly just think "programming skill" isn't really a big deal.

[1]http://frontside.io/ember-consulting/

[Domenic_S]

I like this. I'd elaborate on your groups this way:

Group 1's job is to save the company money, or make existing systems easier to use/more efficient. They help increase sales by implementing metrics/ab testing/etc. A top member of group 1 will be leveraging technology to automate costs & complexity away. If the company nets more money because a Group 1 person is employed, they're doing their job.

Group 2's job is to invent core technology, often from scratch. They are well-versed in theory and application, and their deliverables take lots of time. If the company gains a patent because of a Group 2 person, they're doing their job.

Group 1 is business (and sometime public) facing, so soft skills are much more important. Group 2 IS usually the business, so tech skills are #1. The two groups have the same components in their pie charts, just in different proportions.

[clay_to_n]

That's not always true - many businesses make a lot of money with a core product in Group 1.

Group 2 is only necessary for certain companies, where leveraging technical advantages is core for the business. Most startups are not this, though being one maybe helps a startup's chances of success.

[zerohp]

That division of programmers is a very good model. I spent many years as a self-taught programmer of group (1) but I really wanted to do the work of group (2). I found the skill gap to be impossible to bridge on my own and went to college to do so. CS departments tend to focus on group (2) knowledge and only have a few electives for group (1). I've made several friends in their late 20's and early 30's who also went back to school to get out of group (1).

This model also works well for understanding many comments here on HN.

[noname123]

Thank you for spelling this out.

IMHO most of the world runs on project management, social skills, soft skills, "changing the world" by making a better mouse trap, increasing the conversion rate by 0.5%, decrease the customer support response cycle by 2.5 minutes and satisfaction/loyalty survey by 3 points.

I think most people has moved onto (1) because of the universal adoption of the web. (1) makes the most splashes because it's more relatable, accessible and dare I say, more profitable? However (2) still exists, but seems they've declined because in the late 90's, they seemed to be the dominant icons/heroes of computing (Phrack/2600, compare to today's "founders"); it takes more fortitude and individual direction to push yourself to dive deeper into the stack and take on more kernel and distributed computing problems, without the extrinsic reward of money.

In a sense, it's kinda of students choosing business consulting vs. going into (pure science or humanities, not pre-professional) grad school.

[unscaled]

These types of programming are different, but not in the way you describe. It's not the cliche of CRUD LOB vs. "Cool things", but of making apps targeted at the end user vs. creating a shared infrastructure (whether it is a library or a cloud service), and there are many levels down that rabbit hole.

But that being said, Unless you are working for a very conventional small or midsize business with no plans of rapid growth (and businesses of these rarely employ large teams that need leadership anyway), it's never going to be "just CRUD" or just slapping a client GUI in front o a database backend". With large datasets or many users you have to plan your storage and query patterns for scalability, when precision is crucial you have to design for consistency when a real-time response is required you need to reduce latency and when business requirements change often you need to design for flexibility, when your company has multiple clients you need to design a good API, and so on. In most cases you must balance between several requirements, and I haven't even gotten to security yet, which is a too often neglected requirement for almost every system out there. I also didn't touch all the peripheral requirements for having automated tests (and designing for testability), designing a CI pipeline and educating junior devs about revision control workflows and DevOps practices.

Handling all of that doesn't require the same technical skills required for writing kernel code, a ray tracing engine or a database engine (all of them different skills in their own respect), but to be able to design a good system and give guidance to junior developers you definitely need more than 2-3 years of experience.

Yes, many companies choose to ignore what I've just said, and hire low-level programmers anyway, and often put an MBA (who did some formulas in Excel back then) to (micro-)manage them. Of course the products they turn out are buggy, hard to upgrade, fall down to pieces under the smallest hint of load, end up requiring expensive hardware, have gaping security holes and all-in-all cost their failings end up costing the business dearly.

This blasé approach to group 1 development is very common in the so-called "enterprise world", but that's just because the organizational elite over there (as opposed to most of Silicon Valley) is not even tangentially technical. That's understandable: take a CS-driven company like Google or an engineer-driven company like Facebook, and you'll get the mirror image. But there's no cold truth about programming skill not being a big deal here. Group 1 development is at the very least as demanding a skill as plumbing.