The lowest level is the coder who only knows how to code.
When you go higher, you have the more elite "programmer" who does the exact same thing as the coder but is more elite because he calls what he does "programming" instead of "coding"
The next level is the Software Engineer who is even more skilled then the programmer because although he does the exact same thing as both the coder and the programmer he calls what he does "engineering" which he deems equivalent to what rocket engineers do when they "engineer" a rocket that flies into space, but instead of a rocket it's some website. Keep in mind that as amazing as rockets that carry humans into space are, it is not as amazing as some plain website because these "software engineers" likely get paid waay more then rocket engineers.
The final, highest level is the software architect who's power is so high he doesn't even "code", "program" or "engineer" stuff anymore. Instead the software architect has the skill of "big picture reasoning" which is the skill of being able to draw boxes and circles on a white board and also drawing lines between those shapes. This is what we term "software architecture" and this is the epitome of software skill. The software architect is basically a god among software engineers.
My goal in life is to become a master at drawing circles and boxes and lines. I admire these people so much.
> the Software Engineer … does the exact same thing as both the coder and the programmer he calls what he does "engineering" which he deems equivalent to what rocket engineers do when they "engineer" a rocket that flies into space,
While typing this comment, I hit a bug in my browser? phone? not sure which, but anyway, in the year of our lord 2024, showing an onscreen keyboard at the appropriate time is not yet a fully solved problem. Such is the rigor of our “engineering” discipline.
> The final, highest level is the software architect who's power is so high he doesn't even "code", "program" or "engineer" stuff anymore.
Why drive when you can be driven?[0]
> My goal in life is to become a master at drawing circles and boxes and lines.
A previous employer sent me to a multi-day whiteboard training class once. I’m not sure if they were really stupid, or if they just thought I was really stupid[1]. The people running the class were exactly how you would expect them to be.
> showing an onscreen keyboard at the appropriate time is not yet a fully solved problem. Such is the rigor of our “engineering” discipline.
Predating software touch keyboards, I await:
1. The ability to pay for something on the web without a reliably posted critical reliance on not hitting the back button.
Someone should document the 5-why’s to a solution. (It might have ”stacked” up to 50-why’s at this point.)
2. For Apple TV to consistently fill in the about-movie blurb & pic (a few kay?) at better performance ratios than 1:1,000,000 relative to the speed & latency of the associated preview & video streams (geebees and also geebees).
Did you know the casual verbal abbreviation of kilobytes is a tribute to Alan Kay, inventor of the first working ten-bit address register? /h
These are my two long-time favorite canaries for some hoped for future deep software engineering progress.
In the meantime, I try my best to laugh a lot and be grateful for what we have.
> which he deems equivalent to what rocket engineers do when they "engineer" a rocket that flies into space, but instead of a rocket it's some website. Keep in mind that as amazing as rockets that carry humans into space are, it is not as amazing as some plain website because these "software engineers" likely get paid waay more then rocket engineers.
Not all software engineers write websites. I don't understand where in the lexicon this distinction has been lost. Also, there's a wide variety of website, some of which are just user interfaces for very complicated services.
You're talking about those guys who write code for the inside of my car or the person who wrote the software for my smart tooth brush?
These guys aren't called software engineers. Like I said above, we refer to these people as "coders". "Software engineering" is mainly about making a website like petsmart.com or facebook.com.
No, I'm talking about writing an OS kernel, compiler, math library, networking stack, CAD software, simulators, etc. These are engineering heavy challenges and absolutely software engineering. This is exactly what I'm talking about... no one sees the invisible software that rarely ever fails. Yeah, petsmart.com has errors, but it's incredibly unlikely it's due to a routing stack software failure (failure, not misconfiguration).
>No, I'm talking about writing an OS kernel, compiler, math library, networking stack, CAD software, simulators, etc
Oooh. I see what you're saying. But these people aren't called software engineers either. They're called "programmers".
>These are engineering heavy challenges and absolutely software engineering. This is exactly what I'm talking about... no one sees the invisible software that rarely ever fails. Yeah, petsmart.com has errors, but it's incredibly unlikely it's due to a routing stack software failure (failure, not misconfiguration).
Software engineering is about solving problems. For example the problem of attention was solved by people on tik tok. Or the modern dating problem was solved by people who work on tinder. These are what I term "real" engineering problems. Something like CAD software or OS's are more ephemeral stuff that nobody ever thinks about so these kinds of things relegated to programmers or coders.
The underlying sentiment of making these distinctions is that I'm better than you, which is one way to approach everyone else in your
life, but it's kinda odious.
Not all websites are created equal either. Engineering facebook is a lot different than a simple CRUD app. Your ability to write code does not make you a better or worse person, but it may make you a better or worse programmer. This attitude (conflating competence for intrinsic worth) is toxic, but it says more about your frame than mine.
Because websites et al fail a lot and a lot of software that runs invisibly does not. Typically engineering refers to something that works at a particular rate of failure (low hopefully).
Okay, sure, you alluded to that earlier... But who cares? Even if what you say is true, that does not give it significance. You somehow completely missed the question. Let me try again:
> the programmer he calls what he does "engineering" which he deems equivalent to what rocket engineers do when they "engineer" a rocket that flies into space, but instead of a rocket it's some website.
Bingo. The (very American) dilution of the title "engineer" has been sad to see.
>I wouldn't deify "real" engineering like that. It's different, and more regulated, but it isn't all harder and fancier than all programming.
Of course not! Software engineering is waaaay harder than rocket engineering. That's why there's so many rocket engineering bootcamps all over the place. Just grab some book or join a bootcamp and you can build rockets that fly into space in less than 6 months!!
That's what I did, I was a major in poetry and I worked in HR. Then I joined a online bootcamp for rocket engineering and became a rocket engineer for spaceX in less than a year! I got super bored with it and I wanted to try software. When I did the switch to software engineering I couldn't find a single bootcamp in the country. You have to get a PHD in software architecture in order to do this stuff. Super hard! I'm now an expert at drawing lines and circles!
No rocket science is harder due to tiered knowledge. Like physics or theoretical math you need foundations on top of foundations on top of foundations to learn.
Software isn’t like this hence why boot camps are more possible. Advanced concepts in CS aren’t practical. Automata theory? Not needed. You literally don’t even need a bootcamp for software tbf.
It's actually a really dumb post. There's a lot of 'real' engineering in software engineering if you step back from the latest web x.0 trends and go back to traditional software engineering (OSes, embedded, compilers, data structures, networking, etc). The problem here is that we conflate the 'latest app' (which is usually differentiated in its business model, not its software) with software development. Somewhere down the line business creation has become synonymous with software development. Of course, business creation is excellent, but it's not engineering.
> he calls what he does "engineering" which he deems equivalent to what rocket engineers do when they "engineer" a rocket that flies into space, but instead of a rocket it's some website
What if it's embedded software that goes into, for instance, a rocket? Engineer?
Or mechanical engineering that goes into a door knob. Engineer still?
Reminds me of sitting in a draft paper review in my adviser's research group in graduate school when his final advice to the authors was "and you need to add a figure with boxes and arrows in it"
In my experience people who care or get hung up on this term are not people I think are great programmers/coders.
I like programming because it’s easy to ignore labels and just look at output to see if they are terrible or decent. Takes some time to distinguish decent or great, but it’s easy to see if someone is just horrible.
I’ve never cared if I’m programmer or coder or developer or engineer. It’s not like there’s legal differences like medicine or law (some places do have engineer labels, but no states where I’ve worked). I really care about ability to make an impact and compensation. Some of the stupidest titles I’ve had were most interesting work.
It seems odd to try to pick the right term as even for recruiting it’s probably better just to state the label, duties, and skills required in order to attract people.
I know that HN policy is never to ask if someone read TFA but ...
the focus of TFA is much more on how there used to (at least) two distinct tasks which got different names (and had socio-economic and gender implications); following the development of "automatic programming" (what we would call compilation today), this distinction went away, but the two terms stuck around.
I'm with you on this one. I really don't care what my title is or what I'm referred to as long as the check clears. When people ask what I do, I say I'm a "software engineer" because I spent several years getting a BS in mechanical engineering, I've worked in several non-software jobs with "engineer" in the title, and the work is very similar. One could argue that only licensed engineers can actually call themselves "engineers", but that's not the way it works in America.
From what I understand, the work of a licensed engineer is not much different from that of unlicensed engineers, it's mostly a liability and compliance thing. That's not a dig at licensed engineers, by the way. Being legally liable for your engineering work translates to requiring more rigor and attention to detail than it would when you're not on the hook for failures. One of my professors in college was a licensed engineer. He said it was a colossal PITA to maintain his license, so he let it lapse.
>It is a stock element in narratives of 1950s computing to distinguish between programmers and coders, the latter considered a "lowly technician" ....
Actually I think the article is using modern terms, but seems right.
From what I remember from the early days, you had "System Analysts", "Programmers" and "Key Punch Operators". Key Punch and Programmers were considered Low-Level and was not paid much more the the US average salary, Programmers a bit more than Key Punch people. System Analysts was where the money was. But seems during the 80s, the 3 jobs merged into one.
By then, I use to program and work directly with the Business in the 80s and 90s. Sometimes the Business person would be sitting next to me while I showed then the changes and how it worked. Changing the program based upon their comments while they were there. Fun times, and yes even did this directly in production :)
Then it seems in the late 2000s, they started to split again giving us Business Analysts (BA) and Programmers (Coders).
This topic comes up occasionally. These days, people use the terms interchangeably. About 17 years ago, I wrote a post inspired by an article in an Indian Newspaper with more of an Indian context — more about the preference of IT grooms in matrimonial ads. This was a very personal view and lot had changed since.
Is this the same as the distinction between an electrical engineer and a technician? That is, this is less about understanding the difference between coder/programmer, but understanding what people mean when they refer to technicians.
You see similar with cook versus chef. I'm sure the same distinction exists in near any work where a surprising amount of what needs to get done is far more mechanical than people admit.
It doesn't help that it is often loaded with loaded nonsense about worth.
A coder, as the name literally implies, is essentially a human compiler. We long ago moved to using machines to do the coding, so it's not really a thing people do anymore (certainly not as a profession). The term has stuck around in modern times as a pretentious way to say programmer, but means the same thing in that context.
We do seem to have kept a lot of the idea that there are more mechanical parts of most programming jobs than we seem to acknowledge, though? Typically called junior or entry level work.
Do we? Any time I have come across a "junior" programmer, the intent was for them to do the same work, just with recognition that they aren't (yet) very good at it and need more proficient programmers to help guide them.
It is not uncommon for the entry levels to be described much more in terms of "does specifically defined tasks." As you move up, you are expected to work off more and more ambiguous requests.
The "specifically defined tasks" are ultimately the same thing, though, just much smaller in scope. When you're not very good, so to speak, it's best to not cut off more than you can chew. When you're new and still learning it is typical to start with baby steps that (hopefully) see you eventually work your way up to bigger and grander things.
Sorta, they are fully specified tasks that are largely in need of mechanically implementing them. Much like the work a service technician will do at your house. Designing the system and building all of the parts would be engineering tasks. Putting the parts together would not.
Now, agreed in startup land junior members are responsible for design more than people ack.
This historical distinction has nothing to do with today's coders and programmers where a simple calculator does more than the super computers of the early days.
In present times, the complete road map is something like this:
I think coder became trendy more recently and I believe it relates more to working on apps that screw the user. It kind of had that covert sounding ring to it
I don’t think that is the distinction people are looking for. IMO software engineer just has too many pretentious implications…
It is a bit of an interesting observation though. One of the main distinctions that come to mind when thinking of engineers is that typically they belong to professional societies with ethics codes that would seem to preclude working on some of these user-screwing features, if taken seriously.
FFS people, the title includes the word "historical". TFA is not about the use of these terms today, other than tangentially.
Understanding why there even were two terms is actually quite interesting, and of value for all those pontificating on what they think current use of these terms ought to be.
I had a college job in the early 1980s, and my title was "Senior Coder". By that time the purpose of the particular title for my organization was to pay students less than they'd have to pay a "programmer", but if you looked at my job description, I was to turn flowcharts into coding sheets. During my annual review HR asked why I should be "Senior" and I said, "there's no programmer or analyst above me handing me flowcharts; if you want to do a reclassification review please proceed." They decided not to push it, and I decided to stick around for a little while longer because while it paid very little, it was pleasantly anarchic.
There is definitely a difference between “someone who can write a working computer program in a language” and “someone who can design, maintain, communicate, document and own a part of a large software project.”
Whatever you decide to call these two things anyone who has onboarded a new grad/intern has observed this distinction because its a different skill set.
This repeats so frequently I can't believe people still make this mistake. Multiple times i've seen people hire people out of college, give them not well defined work and then get mad that the person can't deliver.
It takes a long while for you to be able to go from fuzzy feature request to fully fledged product, people without experience need A LOT of handholding to be productive and that is fine, no one is born knowing everything and if you're going to hire people without experience you should EXPECT to invest time in training them.
+1 Seen it many times where a new grad / jr. engineer exaggerates their skills to get a job and the greedy hiring manager thinks s/he has scored big time with a cheaper hire. Big mistake on both ends. Be truthful, do a thorough assessment and it will be a good match.
You can absolutely work as a professional writing code for 20 years and never work on a large software project or a project with a large team.
I worked on a small team at a government contractor that never used version control and deployments were an rsync from the lead engineer’s laptop to the cloud, this was in 2020.
There’s a lot of industries like bioinformatics or journalism where there’s people who are adept at writing code but who are not doing software engineering.
I think being a good engineer requires some amount of "soft skills" like project planing, documentation, understanding user requirements. Its more than just being good at writing code (but that's most of it).
Writing a working program of any kind requires those in some capacity. You can do it poorly and minimally, but you can't escape it entirely. Indeed, a highly proficient developer will do those things well.
Theoretically, it's like difference between a race car driver and a pit stop mechanic. However, coding & programming are much closer to each other than many other similarly associated occupations. I would go so far as to say that they rely on the same skillset, but different models and approaches. The practical differences between the two roles usually come down to the associated responsibilities attached to a project and the ability to fulfill them.
Here is a problem that I have. Working on the operations side of things I've seen so many ways software can fail. If someone asked me to design a system, I would draw on my experience, and create a very safe, conservative design. Which would be immediately laughed out of the room. So, I feel stuck in my career and I don't know how to get out of this trap.
There was a time not too long ago where software development was considered an expensive investment. Only companies with crazy deep pockets or passionate engineers with equity promises (think startups) could afford to work in such a profession. It was special. Over the last couple decades businesses have worked hard to commoditize it in every possible way leading to every Tom, Dick & Harry calling themselves an "engineer" and every "company" needing to have a software/web presence. It's become basic - like electricity.
So while your experience in carefully crafting a viable design and erring on the side of caution would have been appreciated decades ago, it's just not the nature of the game today. Just take heart that your approach is that of a true engineer and not someone who will cheapen their work by slapping on something that works in a sandbox type of env.
I mean, EE’s often go and design toys and other little frivolous things that aren’t safety critical. I think we should not pin the Engineer title on something like safety or importance, that is probably why people wanted to be Software Engineers in the first place. Because it sounds important.
Having done the EE curriculum and then gone to program instead (to make my bias apparent), IMO the engineer’s distinction is that they work in a model, the bounds of the model are well known, the model isn’t all of physics, and the model is simplified enough that work can be checked within it. The brilliance of engineering is that you can do productive work, on hard tasks, without being brilliant.
People used to make this claim about the primes all the time. That the reason they are so expensive is that they're rigorous and all that shit. It turns out that Space Shuttle style code means "blows up for all sorts of reasons".
The primes are expensive not because they're rigorous but because they're good at government contracting. They're going to get outcompeted soon. SpaceX and Tesla have shown that there is an opportunity in government contracting. Now, newer organizations are going to be "rigorous" in their own ways.
You publicly make a claim, but when asked for evidence you won't provide any without payment? That's... certainly the boldest response I've ever seen to a request for evidence.
The 'claim' is information freely given. From my point of view, if you choose to believe something I don't think is true, that's a problem for you not for me. If you want me to convince you of something, you have to pay. If I asked someone something and they responded with a rate, I'd pay if the facts were worth it and I wouldn't if they weren't.
I once picked up a theoretical math book about category theory. It's a lot of the mathematical basis behind data structures; and where terms like "class" come from.
Unfortunately, when I was in undergrad, my school and other schools didn't understand that most incoming students needed "software engineering" instead of "computer science." Although there is a lot of overlap; misunderstanding the intention and purpose of students made it very hard to learn the skills we were there to learn.
The people who write code in the demo scene traditionally call themselves 'coders', and those are pretty much the best of the best (and quite a few 'proper' software engineers among them).
TFA is about the historical distinction, which is absolutely not pointless, and has nothing today with demo scenes or modern self-adopted nomenclature.
Are you suspecting your partner of cheating or having an extramarital affair? I’ll advice you to get proof first before confronting him/her. As that could result in unnecessary confusion in your relationship or marriage. it’s always advisable to consult a professional hacker to help you get concrete evidence by discreetly getting access to their phone or computer. he has forked for me a couple of times and he never disappoints. he provides Accurate results and can be trusted for 100% privacy and untraceable.
Contact him via [email protected]
When you go higher, you have the more elite "programmer" who does the exact same thing as the coder but is more elite because he calls what he does "programming" instead of "coding"
The next level is the Software Engineer who is even more skilled then the programmer because although he does the exact same thing as both the coder and the programmer he calls what he does "engineering" which he deems equivalent to what rocket engineers do when they "engineer" a rocket that flies into space, but instead of a rocket it's some website. Keep in mind that as amazing as rockets that carry humans into space are, it is not as amazing as some plain website because these "software engineers" likely get paid waay more then rocket engineers.
The final, highest level is the software architect who's power is so high he doesn't even "code", "program" or "engineer" stuff anymore. Instead the software architect has the skill of "big picture reasoning" which is the skill of being able to draw boxes and circles on a white board and also drawing lines between those shapes. This is what we term "software architecture" and this is the epitome of software skill. The software architect is basically a god among software engineers.
My goal in life is to become a master at drawing circles and boxes and lines. I admire these people so much.