That is definitely not what software engineering is. It requires translating requirements and ensuring that the code is maintainable in the context of a team and the product's lifecycle.
If you still disagree, point me to a place where I can find some coders
https://www.socallinuxexpo.org/sites/default/files/presentat...
After reading the whole thing I'm not sure how the title describes the presentation.
>Programming should be thinking followed by coding.
Maybe if nouns were switched, i.e. Programming Isn't Coding, will've been better.
> The professional title "engineer" is legally protected under the German Engineering Act [0].
[0] https://verwaltung.bund.de/leistungsverzeichnis/EN/leistung/...
People protecting titles by putting an arbitrary barrier associated with possessing a piece of paper rather than actually having skill and knowledge should be treated with scorn in my opinion.
[1] “Heaviside step function” and the “Coverup” method for partial fraction expansion when doing integrals are among his discoveries. https://en.wikipedia.org/wiki/Oliver_Heaviside
You should also have mentioned that: "This riled Heaviside, who asked Thomson to sponsor him, and along with support of the society's president he was admitted 'despite the P.O. snobs'".
What’s your solution then? No attempt at providing professional standards at all?
Systems made by people will always be flawed. That is the reason for and criticism of certification and regulation.
Like, you’re developing some land, and it turns out you need a geotechnical engineer. The engineer you hired is certified, their plans get put on file with government records office, and the contractors you hire are responsible for following those plans. Among other things, it creates a paperwork trail to figure out who gets the blame if your building collapses and takes out three neighboring apartment complexes with it.
I think we should have these kinds of rules for people who design bridges, medical equipment, and passenger airplanes. I don’t think we should have these rules for people who design hard drive controllers, compilers, and physics simulation software.
You mean the hard drives that are storing inspection records for those bridges, and the compilers that were used to build that medical-equipment software, and the physics simulation software that was used to verify the required load strength of that passenger airplane?
Verified programming languages and compilers for safety critical systems are a thing. Khronos even has some APIs for use in safety critical applications.
IMHO by doing this and going against quaternion he has hindered much progress in EM for more than century since that's what being taught in textbook, and most people including EM engineers don't care to look what's available beyond the run-of-the-mill textbooks.
There's a very famous saying by Einstein, make it simple but not simpler, and in this case Heaviside's "Vectors Versus Quaternions" paper and related advocacy has caused more harm than good to the math, science and engineering of EM based system by doing simpler than simpler (pardon the pun).
I have also a hypothesis that perhaps someone can research into, if Einstein is exposed properly to quaternion based EM, and using it he would have solved the general theory of relativity much earlier than he took of 10 years after the special relativity discovery. The quaternion form of relativity has been even presented by L. Silberstein in 1908, just three years after the discovery of special relativity [3].
It is a shame that even today apparently the Wikipedia entry of both special relativity and general relativity do not even mentioned quaternion (zero, nada, zilch) as if it is a taboo to do so, perhaps partly thanks to Heaviside of his seemingly very successful propaganda even after more than century of progress in math, science and engineering.
[1] Vectors Versus Quaternions (1893):
https://www.nature.com/articles/047533c0
[2] General relativity:
https://en.wikipedia.org/wiki/General_relativity
[3] Quaternionic Form of Relativity. L. Silberstein (1912) [PDF]:
https://dougsweetser.github.io/Q/Stuff/pdfs/Silberstein-Rela...
I fixed this for you.
"I disagree with the sentiments, there is no societal need for gatekeepers in most professions. The engineer title rarly comes with legal liabilities. It’s not necessarily just about gatekeeping. Of course it often becomes misused as well."
Would you say the same about a medical degree ? How do you judge skill and knowledge in medicine without a professional association ?
Software engineering is lucky not to have the shackles that medicine had here. The door is more open. We still require people to prove their capabilities but we don’t allow organisations such as engineering or medical associations to add limits.
https://www.bma.org.uk/advice-and-support/international-doct...
It's very HN and self-aggrandizing to act like the software 99.9% of us are writing is so important that it needs gatekeep credentials. And the important software that does exist already needs its own processes for quality and safety, not depend on software engineers having some feelgood credentials.
If its status you want, then just get a higher status tech job.
The response given to Heaviside does suggest that snobbery was a more likely reason for refusing his membership, but that's just my impression.
As a fun bit of trivia: entwickeln also means to unravel, with ent=un and wickeln = to ravel.
So you'd better err to the side of being a software developer, because you'd always be telling the truth (and hope your subtly arrogant German engineer colleagues don't pick on you).
I've been to work social events where all the alcohol was provided by the company, but they still had to hire a bartender. You'd pick up a drink, hand it to the bartender, and they'd open it and give it back to you. It sure seems like a stupid, wasteful ceremony; that is, until someone is on their way to getting blackout drunk and the bartender can start refusing to open more drinks for them. They can even use the line "I could lose my bartending license if I keep serving you." The requirement for a licensed bartender was not to make sure someone knew how to open the drinks, it was to make sure someone had the authority and accountability for keeping things under control. (Not to mention making sure everyone was over 21.)
Requiring a stamp from a licensed professional seems pointless up until it prevents a big problem. I'm not opposed to requiring that a Licensed Software Engineer (or whatever) sign off on the software running on chemotherapy machines, as long as that licensing is all done in good faith.
The number of PEs in the US seems to be around 500,000 per NCEES. That represents way more than 1% of all "engineers" -- there are not 50 million "engineers" in the US, unless Subway has started calling their employees "Sandwich Engineers" now. What are you counting as an engineer, if not a PE? For this discussion, an engineer would be someone working in a profession where a PE license is available, matching their day-to-day work. You could say "what about software engineers?" but that will skew your numbers, because we don't know how many SEs would be licensed PEs if a licensing program was available (which is kinda what we're discussing here).
The question is: for those professions where a PE license is available, how many get it? This is a number that seems a bit hard to find, but the consensus seems to be around 20%. So you're off by a factor of 20x. Please don't just make up random stats, or you will be contributing to the misinformation in the world.
I also don't care about the numbers of an organization who has a conflict-of-interest in the matter. I teach graduate level engineering classes and I know for a fact that almost nobody in my classes goes for the PE license. That is representative enough for me over the years.
It's like telling Eric Clapton, Jimi Hendrix, George Benson, or Wes Montgomery that they're not qualified to teach at a music conservatory because they lack formal diplomas. Sure, technically they're not "certified," but put them next to your average conservatory professor and they'll play circles around 99.99% of them.
Same goes for brilliant coders versus formal engineers.
The only ones I can think of are folks who are self-taught, e.g., Bill Gates, but he famously noted that he had read the three (then extant) volumes of Knuth's _The Art of Computer Programming_, sometimes taking an entire day to contemplate a single page/idea/exercise (and doing all the exercises) and then going on to say that anyone who had read all three volumes (and with the unspoken caveat of "also done all the exercises") should send him a Résumé.
My best friend in high school was a self-taught guitarist, incredibly talented, he also had perfect pitch, and a wonderful insight into what a given piece of music was expressing.
All? of the original self-taught programmers were in an academic context, no? Even those who aren't have either read or researched a great deal, or they have laboriously re-created algorithms and coding concepts from first principles.
Maybe this is just another example of how society has not yet mastered the concept of education?
>There are masters of a thing, and then there are masters of a thing.
Where the difference is, some folks can do, but can't teach/communicate what they do or how they do it, while other folks have both mastered a skill, and are able to raise others up in how to also learn that skill.
My guitar-playing friend also would wear out cassette tapes and records playing back specific sequences working out how they had been played, and perfecting his technique....
You also don't always get a say what they put in your sig or on your business card (and I think internal names would not matter anyway).
Each impressive in their own way, but clearly there is a difference both in terms of the skills required and the outcomes enabled.
I think the specific term used matters less than the ability to distinguish between different types of building things.
If you want to build a bridge, you’re not going to hire the sand castle builder if sand castles are all they have built.
Many of the people there technically program for a living, because some of their models rely on Python scripts.
They are not software engineers. These aren't programs designed around security issues, or scalability issues, maintainability issues, or even following processes like pull requests.
>They are not software engineers. These aren't programs designed around security issues, or scalability issues, maintainability issues, or even following processes like pull requests.
That's been the obvious problem for a while now.
These are the people whom software engineers need to be cheerfully working for.
Any less-effective hierarchy and they'll just have to continue making progress on their own terms.
Nope: We are equals with very different goals.
I (a software engineer) happen to work on a product, with customers. Modeling stormwater is part of the product. Within my company, the people who do modeling are roughly equal to me.
In the past, I've built products for customers where the products do not provide programming / scripting tools.
> That's been the obvious problem for a while now.
A script that someone runs on their desktop to achieve a narrowly-defined task, such as running a model, does not need to handle the same concerns that I, as a software engineer, need to handle. To be quite honest, it could be awful spaghetti code, but if no one else will ever touch it once the model is complete, there is no need for things like code reviews, ect.
I think it would do most developers a lot of good if they were to pretend like they were a servant class to the customer & team for a period of time.
They will hopefully learn that a contest of egos is not enjoyable at scale over long timeframes. A happy customer provides a much bigger dopamine rush than getting some smart-ass jab in on your coworkers.
A job done right and seeing the recipient legitimately happy about what's been done for them should be the #1 goal of a person who identifies as being a fucking genius with computers. Most people suck at this and you should be helping them out, not competing with them in some bullshit heirarchy that only exists in your own head.
This is what I like to do, and it really is worth putting in the effort so that you end up really liking to do it.
I've been on both sides of the coin, building engineering labs for petroleum or chemical engineers who are going to spend more expert effort on the data than it took the labs to creatively collect what was needed.
Then more often eventually building and adding capabilities to chemical labs where I have some leading data insight for the clients myself. Either way fresh engineers and chemists often have to really start from scratch if they want to become industrial workers, and that's going to take more than a year right there.
It's the same amount of work in the lab, but the engineers' output is the product of the engineering outfit, while OTOH the data itself is the product of an analytical lab.
Technical contributors work way better together when they are equals in key disciplines.
I think when software is done right it can be a lot more organized than many other technical efforts or engineering tasks too.
I also think it's a good idea to tailor the organization differently when software is the actual salable product versus when it is a component of a fairly dissimilar revenue source.
Look for instance at multi-purpose solvers like FreeFEM or FEniCS, or the distributed parallelism linalg libraries like PETSc or MUMPS, or more recent projects like OCCA. These are not small projects, and they care a lot about scalability and maintainability, as well as some of them being pretty "CS-y".
At its simplest:
"Engineering Software" is what people who build software products do.
"Science with a Computer" is something that people doing real calculations, simulations, etc do.
I, too, forget that the tools we use to build complex solutions can still be used by people who don't live in a text editor.
Computer science is the science of computation. It's more to do with theory of computation, information theory, data structures, algorithms, cryptography, databases.
"Science with a computer" is experimental physics, chemisty, biology, etc.
"Computer Science" != "Science with a Computer"
"Computer science" (in contrast to software engineering) is the science that looks into the properties of computers and thing related to it (algorithms, database systems). E.g. examining those systems on a scientific level. Depending on how abstract that can have more or less direct input on how to engineer systems in their software/hardware implementations.
"Science with a computer" on the other hand are usually (in terms of majors/academic disciplines) taught in the adjecent subfields: Bioinformatics, Chemoinformatics, Computational biology, etc.. Of course basic computing is also on some level seeping into every science subfield.
As long as it never gets to "grokker" (I've never heard the term "grokker", just saying) . I can not stand the term "grok". I don't know why but it just grates on me
English has a lot of words from different origins that are more or less synonyms and one of the most common time wasting behaviours i’ve seen is people endlessly trying to categorize those words in endless debate.
The web is full of endless slideshows with titles such as ‘the difference between management and leadership’ or some such. One’s a latin word and the others german for basically the same concept and since english has both (it steals from every other language without care) you’ll find a million slideshows people have created on the differences between the words. This whole thread is yet another example of this behaviour and if you’re aware of it you’ll very quickly tire of every fucking ‘the difference between [english loanword from latin] and [english loanword from german]’ thread you’ll see.
― James D. Nicoll
English doesn’t have a lot of duplicate words because of some aggressive vocabulary-stealing nature. It has a lot of duplicate words for the same reason modern Nahuatl has a lot of loanwords from Spanish: England was colonized and ruled for centuries by non-English-speaking people.
It also feels like something of a straw man -- in reality, you have junior programmers/coders and senior programmers/coders and they get better over time.
In real life, they aren't two distinct activities. People write code to get things done, and as they get better they are able to write code that is faster, more elegant, or more scalable. But premature optimization is also the root of all evil, as one saying goes -- plenty of code doesn't need to be faster, more elegant, or more scalable. It just has to work and meet a deadline. And there's nothing wrong with that.
You speak of programmers getting better over time. The point is to break that improvement down into distinct categories.
Of course they're idiosyncratic definitions. He's attempting to make a distinction which he feels is useful. He needs words to communicate that distinction.
Generally people invent new terms by combining words, or call them programmers of "type 1" and "type 2" or something.
Using existing term that are synonyms, and inventing a distinction between them, is unusual, unhelpful, and confusing.
It's like me saying that sofas are always better than couches because sofas are designed with comfort in mind while couches are intended to maximize manufacturer profit. Huh?
I guess the alternative would be terminology such as "writing code" versus "designing software"?
But nobody misunderstood a message, which was clearly communicated in the talk. The response was to a talk title, and titles often just try to be catchy.
> In real life, they aren't two distinct activities. People write code to get things done, and as they get better they are able to write code that is faster, more elegant, or more scalable. But premature optimization is also the root of all evil
It's nothing to do with optimisation or elegance but about the process of writing software that does what it's intended to do, and a way that "gets things done" more easily in some situations. It's fine if you don't want to watch this interesting talk by one of the world's preeminent computer scientists, a Turing-award-winning expert in software correctness, but this discussion about the talk's three-word title is pointless.
For every person who spends an hour listening to the full talk, hundreds or thousands will see the talk title, and decide whether to watch based on the title.
It's even more important to be clear rather than confusing in your title. Not less. Titles matter hugely. They determine, to great extent, whether someone will even listen in the first place.
It's meant to differentiate human "programmers" from AI "coders". Ever since LLM showed up there has been a noticeable urge to redefine the value proposition of software work to be less about what LLMs can do (write code) and more about what humans can do (write programs).
We’ve been having this debate for my entire career (since at least 2010). The suits have always misunderstood what programmers/engineers do and we’ve always pushed back explaining that it really is closer to city planning than to brick laying.
The agile manifesto (2001) was in large part a response to these pressures to think of programmers as the people who “just implement” what the smart suits have already figured all out.
They are different and they absolutely do matter.
DateTime.Now() is a perfectly valid thing to write while coding. Unless you are in a distributed system, where 'now' doesn't exist, so all source code using 'DateTime.Now()' is automatically suspect. How do you know if you're in a distributed system? That's a programming question, not a coding question. And from a lot of the microservice push-back you get here on HN ("just use a single DB instance - then your data is always consistent",) a lot of devs don't realise they're in a distributed system.
"Backtracking", "idempotent", "invariant", "transaction", "ACID", "CAP", "secure", "race condition", "CRDT", are all terms that exist at a programming level, but they don't show up in the source code. A single effectful statement in the source code can be enough to break any of these quoted programming terms.
Except we're talking about a talk title. Lamport explains what he means in the talk. What I responded to was a comment on the content based entirely on the title.
> It's trivial and it doesn't matter, and specifically using language to highlight that difference is pointless.
Sure, and that is precisely Lamport's point. You really need to watch the talk. He shows how abstract algorithms cannot be fully described in any language that is intended to be executed by a computer.
> Similarly, it's annoying and pointless to pedantically argue that "well actually that's not programming, that's coding".
And Lamport is not doing that. You're arguing over a pithy title to a rather deep talk.
Bad analogy because accountants need to be qualified by a centralized body.
We are already calling procedures "functions". So it's kinda game over already unfortunately.
lol what?
In fact, many cows are not used for milk at all. Some breeds make for great dairy; some breeds make for great beef; but few are great for both... Dexter cattle maybe.
(Nobody's out here clamoring for Black Angus cheese and absolutely nobody likes Jersey steak. While a Jersey cow or Holstein cow may be valued in part by the milk they produce, a Japanese Shorthorn or Belgian Blue cow is valued by the muscle tissue she produces and the genes that cause her offspring to produce similar muscle tissue.)
Your comparison is a category error. The trait "is valued for milk production" does not pertain to the superclass of "cows" but only to the subclass of "milchers."
"Coder" : code :: "milcher" : milk.
Pointing that my specific example has some error does not detract from the main point and diving into the specifics of cow breeds or whether all cows are used for milk or not is irrelevant imo. The cow-milk analogy was just an example that could be replaced for any other.
The distinction is important because how you make the computer do things is important in many cases. At one end of the spectrum, your wasting resources if you have a software engineer working on a program that will be used for 5 years. At the other end of the spectrum, you're setting yourself up for pain if the program is going to be in use for 30 years (or is safety critical, or must produce verifiable results, or ...).
This isn't to say that the "hierarchy" should reflect some sort of software developer social class. It's just different skill-sets for different purposes.
Coder, programmer, software engineer call yourself whatever you want, the point is to make a computer do what you want it to do.