Hacker News Reader

Comment by mdaniel | Hacker News Reader

No one asked me, but my taxonomy is

* coding = typing or clicking to have computers do stuff

* programming = knowing how to type or click to make computers do stuff given knowledge of the SDK, libraries, toolchain, and _ideally_ how to communicate effectively with the IDE

* software engineering = knowing when _not_ to program, knowing about components and the implication of their boundaries and contracts with the things outside of that component's boundaries, which in my world includes but is no limited to other methods in that same module, other modules in the same deployment, internal consumers, and most importantly any promises the code (or management) have made to _external_ consumers

---

* coding = able to use a hammer

* programming = able to assemble an Ikea cabinet, sometimes without the correct tools or complete instructions available

* software engineering = able to design an Ikea cabinet for others and striving for a very low RMA rate

View on HN

This is so dumb. I'm sorry but I've been doing this for over 24 years now and this kind of over simplification resume-building keywordy teenage fuckery makes me sick to my gut.

If you're a good programmer, you know how to find your way out of the forest without knocking all the trees. Call yourself coder, programmer or engineer I don't care your leetcode scores and your fizzbuzz one liners, and the amount of stickers on your overpowered laptop.

You're there to make the computer do the damn thing you want it to do with the least amount of resources. And of course it has to be maintainable, this isn't your bedroom.

So respectfully, sir, take your taxonomy and pipe it straight to where the light don't shine. /s

> You're there to make the computer do the damn thing you want it to do with the least amount of resources. And of course it has to be maintainable, this isn't your bedroom.

That's engineering. That you don't want to care about terminology doesn't change that.

The point is that these labels don't matter. Your response that something "is engineering" misses the entire point. You have not shown why it matters that we call this "engineering".

I'm happy to agree that the terms have some fuzziness and that they're frequently misused, but no, words do still mean things.

>words do still mean things.

They don't if there's no consensus

And I'm sure you ain't got the authority needed to affirm that those definitions are commonly used in those ways

you're all going to upset the actual professional engineers

It seems to me that a key requirement for engineering would be that there are formal design specifications for the system (such as a car or bridge) as well as its constituent components. There are also usually mathematical models of the system that can predict its behavior and performance as accurately as needed for the application.

Many modern software systems seem to lack such specifications or models. In these cases software development seems more like tinkering than engineering.

It's also programming, and coding, and developing. They're all synonyms.

Or rather, they're used by different companies for the same type of jobs, some people make distinctions that other people don't know about, terms go in and out of fashion. They're all essentially synonyms because if there are differences, nobody agrees on them and there is no context in which they matter.

Same for junior, medior, senior, et cetera.

Except for architects. They're ex programmers.

> It's also programming, and coding, and developing. They're all synonyms.

The way I see it, these three all refer to the same things, but "coding" is hobbyist and "developing" is professional. "Programming" is somewhere in between / for both.

curious why it bothers you so much that someone else has a taxonomy? they didn't say you have to adhere to it. your opinion to just call all of it programming is fine too! but it's just an opinion

It reeks of tiktok popculture bs. It also doesn't matter.

I deleted tiktok some months ago so I missed this reference. Is there something going on now that defines a taxonomy of things?

“Sorry but”? “Respectfully”?

Don’t care how many years you’ve been “doing this” for, you clearly haven’t spent enough time sorting your own shit out.

On the contrary I think I have my "shit" sorted out.

The industry is sick. So much money has flown into it over the years without anyone battling eyelashes at the sheer waste of resources, and I mean this both from the body count as the cpu cycles.

I look at most products built today that cost millions to get off the ground and you have buttons busting out of windows, incoherence everywhere, 5 seconds to start the said product, and 2 seconds between 'pages'. Every version increment is a slow decent to hell.

It all starts with the industry self-reinforced pumped-up resume culture, with hell holes like linkedin."Engineers". Please, have you met a real engineer? One that can do the maths, the design and build of a product? You need to wake up, engineering isn't writing docker files, cobbling python scripts copy pastes together and claiming that yaml is clean code.

Do they even know how to yaml without complaining?

If you do, you should get some professional help

Take a breath and maybe step away from the computer. You're not fighting the "industry" or "waste"; you're just getting into an argument with a guy on HN with a fun classification scheme.

Fair point, thanks.

Thank you for this.

God that was so funny. I'm that hammer guy you talk of!

I know you can assemble at least a thousand Ikea cabinets while I hammer away on my carefully designed cabinet made from trees I've chopped down myself and nails I've forged. It fits perfectly with the table made by my great grandfather.

By the time you've assembled 5000 cabinets they collapse as fast as you assemble them but you need 50 000 so you have to hire 300 people mostly to talk about how it is going, document the process etc. Ikea switches to THEIR new cardboard line that is both cheaper, faster to assemble and last even shorter. You get an even larger building and hire 100 more people. Then you put stickers with advertisement on the cabinets because woah the operation is getting expensive!

You put cameras on them cabinets to track the user. Everyone is doing IoT now, you cant fall behind. You launch an app to open, close, lock and unlock the cabinets again with in-app advertisements and purchases.

Ikea goes out of business etc

I look at you, and back at my cabinet, and at you again... I have no idea what it all means. I wish I was the one to think of cardboard cabinets... or do I? I'm not Ikea, no one would have cared for it? I try to convince myself that building my own cabinet was a poor choice only to end up rubbing it with oil and carving Suum Cuique into its ornament.

> and nails I've forged

What? a true carpenter joins wood without fasteners /s

I have never found much value in these distinctions or analogies, particularly because the top tier is usually 'software engineering' which I find to be largely self-congratulatory given there are basically no requirements around ethics or rigor to claim oneself as an 'engineer' (at least outside of Canada who ruled recently that software engineers aren't engineers, IIRC - read that article a while ago).

Depending on the province, "Engineer" and/or "Professional Engineer" are legally restricted titles.

You can't use the title (neither can your employer) unless you are licenced to do so.

What people from Canada told me, they just add "B" in front of "Eng" which is a valid claim for someone working in tech with an engineering degree even if they aren't licensed (and what would they even license them for?).

I forgot the place I read this:

Software development ("programming" in your taxonomy) is a solitary activity. Software engineering involves multiple people and the explosion of complexity involved.

I do like your point about knowing when not to program. Will keep that in mind next time I think about this.

Ah, yes, I forgot about that axis. I'd have to think more carefully about the distinction between "programmers who just happen to be in a google of other programmers" versus "software engineers in a team"

A lot of my software engineering mantras are centered around empathy management, both of internal consumers (future you, your colleagues, etc) and 100% unquestionably for external consumers (heh, "future you in 6 months" and folks that are forced to use your software, people who you want to renew). The world sucks bad enough already: don't swallow error messages and voluntarily tell your users the equivalent of "have you tried turning it off and on again?"

I use software development in place of software engineering. To me software engineering involves more measurement and pre-planning than most developers use, even if they're working in large teams.

I call that first one ("typing or clicking to have computers do stuff") "typing."

The taxonomy is missing "designing," "architecting," "crafting," and more things people like to say they do. To feel important. More important than someone(s) else.

And I often call myself a "professional typist" because the whole taxonomy is pompous BS.

I get paid to solve business problems.

>I get paid to solve business problems

That's far more pretentious than any of the things you listed.

I wouldn’t say so. In essence, every employee is paid to solve business problems.

How is it pretentious? I feel the same way. When people ask me what programming is like, I tell them it is 50% understanding the business problem, 49% problem solving, and 1% writing code.

Because first, it's trite: literally every person in the organization is hired to "solve business problems". Second, I think it's pompous to elevate one's position to some sort of strategic "problem solver" role when, unless you are a consultant, you are hired to translate requirements into working software systems. Your boss would roll her eyes at the "I solve business problems" language. She would say, "Uh-huh. You do that - solve the business's problems. Just make sure you close your Jira tickets while you're doing it."

"translate requirements into working software systems" demonstrates fundamental misunderstanding what programmers do. It is a decades old and rather common misconception. It is why there is "mythical" in the Mythical man-month book (1975).

More https://news.ycombinator.com/item?id=35297082

That’s literally what it is though.

My own version of that goes like this: the difference between being able to code and being a programmer is like the difference between being able to write and being a writer. One is a fairly simple skill you can teach to a child, the other is an art and a craft that can take a lifetime to master. Just because you can write doesn't make you a writer, and just because you can code doesn't make you a programmer. Inspired by a certain team member who believed that writing some code, that sometimes even worked, makes him as much a programmer as anyone else in the company and used to bristle and get defensive whenever someone tried to discuss finer points with him. "It finishes executing eventually, doesn't it? Just wait and stop wasting my time", while ignoring the fact that our administrators wanted to lock our team out because his script was putting so much load on the database.

I've gone by a similiar taxonomy:

- Coder: Can change scripts, HTML/CSS, SQL queries etc.

- Programmer: Can write scripts, small programs, declarative queries etc.

- Developer: Can write one or more of [applications, games, web sites, services] etc.

- Software engineer: Can create complex software with many moving parts.

I go by the title I'm given. My job has been remarkably similar from company to company despite them all using different verbiage.

In my experience, job titles and capabilities rarely goes hand in hand. Seniority (junior, senior, principal) is sometimes projected to titles (web dev, developer, engineer) making it all the more confusing.

Where I come from, certain braches of industry have simply made it illigal. For example, a nurse cannot call themselves doctors. It pertains to most knowledge-based branches of industry here, except for software development.

There is one more:

- Bug-fixer: Deals with problems that four others will end up ignoring because they all moved on to other jobs creating new systems filled with more bugs that will be fixed 5 years down the road. Bug-fixers can like the work, but it's not glamorous because a lot of the time, it doesn't introduce new value.

They say people are good as their last project. It has rung true for me for years. I have become the bug-fixer again in my new project. But, it usually includes trying to come up with incremental improvements if there result of the issue was direct or indirect lack of something else.

Reply on news.ycombinator.com