Hacker News Reader

Comment by externalreality | Hacker News Reader

There's a lot of fantasy in this article. Most programmers today do very little actually - we don't wield major influence. We basically glue together a bunch of Free Open Source offerings. The most critical skill is that ability to move fast by practicing with our Free Open Source offering tools. We pay (MS, Google, or Amazon) to host our applications. And we perform maintenance on these applications for years. Nothing special, anyone can do it. More and more people enter the work force every years. Since all things are becoming automated there will be enough jobs for the foreseeable future. We get to wear nerd clothes and act smart but generally all one has to do is be able to read documentation and use a computer. I would reckon that the average 13 year old who has a good reading comprehension can do what most programmers do these days. It's like playing a video game. They would probably be better at it too.

View on HN

What you describe does not look like the typical software developer job at all.

Certainly not anyone can write software. In fact, many who see themselves as "coders" are not very good at it themselves.

Edit:

I've found it's a bit similar to law in terms of skills and mindset. Some people struggle to follow the text of an actual law. Then, drafting an actual law is an even more specialised skill. In both software and law, if you draft badly you will face problems...

I sometimes think drafting laws badly is a feature not a bug - after all think of all that lucrative legal work for other lawyers.

Couldn't the same (IMO flawed) reasoning applied to the topic at hand? "Computers are made complicated on purpose - after all think of all the lucrative programming jobs"

Not in the case of laws :-(

I know of one infamous Pensions case that dragged on for well over a decade in the UK over some arcane legal arguments.

Of course the longer the case went on the more pensioners died

I have a friend who I consider to be tech savvy and very smart. He couldn't get "coding". Dropped the class and switched major (I know this is anecdotal). It's not for everyone [0]. I agree that it has gotten simpler, but it depends on what you're doing. Some developers "glue together a bunch of Free Open Source offerings" and some need to do a lot more than that.

[0]https://blog.codinghorror.com/so-you-dont-want-to-be-a-progr...

> Nothing special, anyone can do it.

That's what I'm thinking every day while I'm working and talking to other developers.

But when I try to teach, or help non-coders who decide to take up coding, I am amazed every time to find out that there's one skill that I don't even think about that seems unteachable: structural thinking.

I can teach a person how to get an input from a user. I can teach a person how to process that input. I can teach a person how to present output to the user. I have not been able to teach a person how to decompose a task "calculate effective property tax rate" (or something similar) into those steps.

I know good software engineers who believe in alternative medicines and doubt the efficacy of vaccines. I’ve met some that don’t even know the basics of how an OS or CPU works.

We’re not special as a group. We’re good at some stuff and also really bad at other stuff. Just like everyone else.

Your comment seems to be written as if it's a counterargument to something I said, but it doesn't contradict anything in my comment and I completely agree with your point.

Do you have some examples of places where you have seen this so I can avoid working there? It sounds incredibly boring.

Pick pretty much any front-end related position.

Half of my career has been spent on such things and ironically this was the better paid one.

Apparently doing interesting stuff comes with a pretty hard penalty in terms of compensation.

> Apparently doing interesting stuff comes with a pretty hard penalty in terms of compensation.

Yup, I'm trying to transition to web development strongly because of the much higher compensation and the ability to work remotely.

I admit developing nonlinear curve fitting frameworks, working with laser physics and doing biomedical algorithms engineering was much more fun and fulfilling. However, it's far more appealing to enjoy more time with my family, work from a peaceful location and never have to deal with traffic.

Though this transition to web development isn't at all helped by the fact that Javascript feels like it was a failed experiment in hell where it was probably deemed to be far too tortuous to be used as punishment; only god knows how Mr. Eich got his hands on it.

(I've professionally written code in Java, Python, Matlab, Fortran, C, Go and assembly and none of those languages come within two orders of magnitude of the disdain I have for Javascript)

You can do frontend webdev and have a lot of fun.

First of all, stop using plain JS and move to Typescript. That'll fix most of your issues with the language itself.

Second, for what's fulfilling, it depends on what you're actually working on. If you're going to just make dynamic menus for a wordpress blog then yeah, your life is gonna be boring. But nowadays "frontend" can mean writing entire apps. My latest site (https://overframe.gg/) is a SPA in React+Typescript and I had a lot of fun writing it. The nitty-gritty of reverse engineering games, simulating calculations, etc; all these are still there.

Its not the same as working at the real bleading edge though which is what the previous couple of posters meant.

I miss working on campus at CIT (Cranfield Uni) unfortunately the pay was abysmal - some realy cool work tough.

While this does sound cool in a sort of abstract way, it doesn't honestly compare to work that is genuinely at the vanguard of human understanding. That's what the person you are replying to was getting at if I'm not mistaken.

So I guess I'll just let GP be miserable in their choices then!

Take my post as advice on how to enjoy something that may not be your passion.

> So I guess I'll just let GP be miserable in their choices then!

Neither I nor GP have said that they were unilaterally miserable, so I'm not sure what you're talking about.

Nope.

Dont know how much experience you have of trying to hire developers, but the majority out there (even the ones with years of experience) don't pass the most basic of criteria for the job.

Our test for hiring is a simple app that can take a value, decrement a balance and show if the new balance is negative or not.

I've seen some of the tests that come in, 80%+ of the applicants fail to do this. A non-neglible amount will send in something that doesn't even compile.

Good developers are rare IME.

Another mate of mine that has to hire developers says he's lucky if 10% of the people who apply and get to the interview turn out they can actually write code.

Sometimes I think the same thing about what I do. Then I work with a junior and appreciate the difference that a decade+ of accumulated knowledge, instincts, and intuition makes. Yes, most of us don't gain ability the way a surgeon or aerospace engineer might, it's not that palpable, but don't undervalue yourself nevertheless. It takes a lot of work and dedication to get to "I can reliably and predictably snap stuff together like legos and make a functional system."

> Nothing special, anyone can do it.

They really can't. What you describe is beyond the vast majority of people. Not the vast majority of well educated people, perhaps, not the vast majority of STEM people, sure. But most folks? They'd take one look and run away from the insanely complex wizardry you seem to be practicing.

Also, as other posters have said - that's your experience, not everyone's. Someone has to write the automation tools. Someone has to write the libraries. Someone has to know how to write a compiler, to write crypto routines. Someone has to create AWS.

There are a lot of paint-by-numbers coding roles out there, sure, but it's far from the whole industry.

I think the problem is mixing terminologies:

• Programmer: glues together existing tools (your example)

• Software engineer/architect: builds/designs systems that can handle large loads efficiently; invents and applies techniques so the systems can become large while keeping them maintainable

• Computer scientists: invents and analyzes algorithms

That said, roles are usually mixed up as well, where a computer scientist in industry can easily spend 90% of their time programming.

I would say a true software engineer is someone that can design a system to meet a SLA, write documents which systematically show how it's measured and specced. Most software 'engineers' (including all but one of them with that title in my company) are just 'devs'.

My feeling is that a software architect is someone who can design something to try to meet an SLA but is too lazy (or too high level) to actually check it.

Most positions I've worked sit somewhere between 1 and 2, involving quite a bit of glue but a good chunk of design work as well. Had there been no design component (glue alone) the produced software probably would have been functional in the strictest sense but would also have been a slow buggy mess.

Not really a mixing of terminology considering that the scientists/engineers are only going to be a small proportion of the coding population.

As others have said, speak for yourself. Sure, there are plenty of "coders" who just bolt together stuff written by others, but somebody has to create the pieces and that takes at least a little bit of real creativity. The problem is that we don't distinguish between specialties and roles. In medicine the division is clear between various surgical and non-surgical specialties, or between physicians vs. assistants vs. nurses. In law nobody confuses contract and criminal law, or attorneys (sometimes even barristers vs. solicitors) and paralegals. But we don't do that. You're slightly right in that there are people who call themselves coders who don't really create code, but real coders aren't fantasy.

try teaching. then you would be amazed at the tiny proportion of students able to do that on their own.

Exactly. As someone who has been asked to teach an IT technician friend how to program, it's absolutely not a trivial task. You would think the problem solving skillset of a technician would help, but nope.

In real life there are still projects that are failing, that are going over time and budget. There are smart guys on those projects with masters in c.s. who are making completely boneheaded calls that will mean they aren't adding any value.

We can talk about how easy software is and it's just glueing a bunch of components together. But whole we do there are millions of devs that are flailing and failing to do that.

One issue I have seen is that when systems should be easy to make - you know, database, data wrangling, rest API - people tend to make it more challenging for themselves.

Case in point: exactly an application like what I just described, but because that was boring and basically the same application as already existed in terms of architecture, they made it a microservices application that was only supposed to communicate via events published on a central event bus. Which can be a good design pattern I guess, but they lacked an architect, formal specifications of said event bus events, and a too quick conclusion of "this needs to be in its own microservice". Tl;dr, after a year and a half they still had nothing to show for but a well put together powerpoint slide deck, and a lot of half-finished components that should in theory sorta work together.

That is, unchecked developers have a tendency to overcomplicate things for their own enjoyment / challenge. I don't know how to fix that, besides having a strong tech lead who is able to rein people in and ground them.

You could make a similar meaningless argument about electronic engineers. Most just solder together ICs, and the IC designers mostly glue together IP blocks. They pay utility companies to provide electricity.

To work at a lower level doesn't mean you're a more advanced engineer, in some ways it means the opposite; working at a higher level usually requires some understanding of what's below.

> working at a higher level usually requires some understanding of what's below.

Maybe what's immediately below. I fervently wish that "higher level" developers did have some slight clue about what happens when they make a call to lower layers, especially wrt storage since that's what I work on, but I've learned not to rely on them having any such knowledge.

Can you give a real world example of glueing "together a bunch of Free Open Source offerings"? I've heard the idea that thats all software engineers really do before but it doesn't seem realistic at all.

I strongly had that feeling when I was still doing Java + Spring; there's a huge ecosystem of well designed (or, at the time anyway) frameworks and libraries, which can all be easily hooked into each other via the Spring framework. The job of a developer was more data wrangling, designing models and relations, and defining the outward REST API. Things like creating database tables, converting to JSON, input validation etc are all handled by libraries, as a developer you mostly have to configure what models should be mapped to the database side, what to the front-end side, write some glue code to convert the one to the other, and write a bunch of documentation for the public API.

Not to disparage this work (my own work) too much, mind you; it's quite challenging to create a proper API, consistent, well-documented, etc.

I really appreciate e.g. a proper OpenAPI spec, because that means I can hit a button and have a front-end consumer library generated in Typescript, which in turn helps me more easily map a user's input (forms) with the expected input.

But yeah, it can get quite tedious / boring / unchallenging if you're not into data wrangling like that.

browsers + javascript + css (frontend opensource) ... to backend , many frameworks for each langauge, many languages all documented ... to persistence layer (mysql , postgres, mssql), and finally server but as OP said thats on amazon, Azure, Dreamhost ... etc

OP is discussing more so the practice of professional dev for 70 - 90% of the devs. Business guys want results , they dont care about scaling and so its about getting it out ASAP. Theres alot of politics, I was taken aback at first, with the idea of CS/software being very technical but it seems that this creates more of a differentiator for political manipulation, cause everyone is already skilled in analytics.

I could go into more detail but basically its all there and a search away (google). In fact there is a term in the industry called "google-fu" (like kung-fu) which means the number of searchers you need to perform to get an answer.

Its a double edge sword. All devs are on their own for learning, but all the info is out there, you just need to be willing to search and learn.

Sadly many people are not like that, and that seperates the good dev from the bad dev (besides the politics).

I assume its the same for being a surgeon, that all you have to do is study and learn the info and you can do it. But having a steady hand is very important. And sadly , if everyone had a steady hand , you'd still have the same amount of surgeons. Those who can do. You want to be a dev, open up the next tab and type into your tool bar "how to learn javascript". Realize that devs created this tool for you, and if you are not a dev its because you dont want to be. Its all there, the web is your oyster.

> browsers + javascript + css (frontend opensource) ... to backend , many frameworks for each langauge, many languages all documented ... to persistence layer (mysql , postgres, mssql), and finally server but as OP said thats on amazon, Azure, Dreamhost ... etc

All of that requires a significant amount of engineering and coding to get working. Just using a frontend framework does not give you a working application, you still have to code that application.

> to backend , many frameworks for each langauge,

As somebody who develops storage systems, I'll bet that what you consider "back end" is still multiple layers "front" of where I sit.

> server but as OP said thats on amazon

You do realize that Amazon employs thousands of coders to create that platform, right? And "borrows" code written by even more thousands, from firmware and kernels up to databases and similar? I'm sure they're still far outnumbered by the front end glue-writers, but there are still enough to create a culture worth writing about.

I think you are describing the work of a junior software engineer. Sure a junior engineer can do "google-fu" and glue together a working application but there is so much more to being a software engineer than that. Here is just a sample of the kinds of things a more seasoned engineer has to consider when developing an application. Note that none of it can be solved by simply googling and glueing in another open source piece of kit. It requires careful consideration and knowledge/experience that lets you make these decisions.

Frontend:

- Should I use a frontend framework with backend API for a single-page application? or use a standard web site with no distinction between frontend/backend.

- How will I handle mobile responsiveness of the html/css?

- How will I server css & js assets? Use a CDN or host them locally?

- Will I minify css & js?

Backend:

- What business requirements will I take into account when choosing a language/framework?

- Is speed and concurrency a must (perhaps choose Golang)? Or rapid prototyping and complex business logic (perhaps Ruby on Rails or Django)?

- Will I write a monolithic application or go for microservices?

- How important is security? Will my framework prevent vulnerabilities like XSS and SQL injection automatically?

- What web server should I use? What kind of scaling requirements do we have?

- How will we handle version control? What processes need to be put in place around deployment?

- How do we handle deployment?

Database:

- Relation SQL database or NoSQL?

- Are there any cases where I will want to de-normalise my data right away or should I wait

- How can I design my schema to be flexible yet still scalable?

- What columns need to be indexed?

Hosting:

- Use a cloud host? (AWS, Google, Azure...)

- Do we need dockerized deployments?

- Should we use kubernetes or a more managed solution?

- How important is vendor lock-in?

- How do we handle config secrets (like API keys)

- How do we handle changes in configuration (i.e. use Chef/Ansible/Terraform etc.)

"all documented" ROTFL what world do you live-in

Sure, a 13 year old could write a web ui and crud back end for a $20 IoT device. And you're correct, that's not that difficult. And while a lot of HNers live in the web world, not all of development has to do with the web. There are lots of development jobs that are much more difficult and take more skill. They don't pay FAANG money so they don't get the attention on HN, but they do exist.

I'm not going to tell you you're wrong (plenty of other people did that) but I'm wondering what experiences you've had that makes you believe the average 13 year old could pick any task and just "glue together" libraries to solve it?

You are assuming the eveyone has your /our skills here.

usually when something becomes so mechanical it is automated and the job is eliminated

Speak for yourself.

If what you are doing can be done by a 13 year old, that is your reality.

What I do requires years and years of experience/study, and 90% of the 20 year olds cannot do it, and that is being very conservative.

Of course you are talking about the average developer. But your average health personnel aren't doctors, they are nurses or assistants. And there is nothing wrong with that.

Reply on news.ycombinator.com