RU version is available. Content is displayed in original English for accuracy.
Advertisement
Advertisement
⚡ Community Insights
Discussion Sentiment
58% Positive
Analyzed from 2358 words in the discussion.
Trending Topics
#software#engineering#engineers#engineer#courses#computer#more#science#where#don
Discussion (51 Comments)Read Original on HackerNews
A most rational stance. One we should enforce here in the US.
Edit: Yes, I'm arguing that Software Engineer should be a licensed profession, but programmer shouldn't, and would be a fine substitution in the cases where you didn't need rigor.
--
If I were an engineer, there's no way I would trust any interface to a control system for a water purification plant that connected to the internet and allowed for ingress of control. Just as an example.
The OPM hack of 2015[1] is the worst case, in terms of national security, that clearly proves no Engineers were involved in the design of their computer system. Ingress of control should be absolutely prohibited, and it wasn't. I don't know why that database was ever put into a computer, instead of filing cabinets in a vault, nor why it was ever connected to any other system, and not completely air-gapped in said vault, with manual controlled exfiltration of data upon request.
[1] https://en.wikipedia.org/wiki/2015_Office_of_Personnel_Manag...
The revelation came up when my Granddad reminisced laughing at the absurdity of my Dad being promoted to a "Senior Software Developer" at the age of 28.
So yes, from very early in the design process.
it's probably just convenient because there's no auth or VPNs required. yippee!
American employment licencing needs urgent review, and fewer licenced professions, not more.
It seems reasonable to want licensure on the belief that it raises quality.
It seems unreasonable to expect people to conform to your language preferences.
In an overwhelming majority of cases, I've found the root cause is simply Doing The Right Thing Costs More.
It isn't "filing cabinets in a vault" that costs more. It is hiring the people with the requisite experience, expertise and soft skills to navigate those conversations. It is pushing the technical boundaries so these decisions are automatically made upon the metadata carried along by the pieces of infrastructure we're pushing around the table. It is putting in place the appropriate regulatory frameworks with auditing enforcement that halt overzealous KPI-chasing executives from overriding the caution signals raised within their own organizations, without stifling innovation.
And many other prudential measures set aside for "move fast and break things". Which unfortunately in so many cases boil down to "externalize my costs onto someone else who hasn't yet figured out they're the patsy" in a massive shell game of "Don't tax you, don't tax me, tax that fellow behind the tree" attributed to long-serving U.S. Senator Russell B. Long of Louisiana.
> I don't know why that database was ever put into a computer, instead of filing cabinets in a vault, nor why it was ever connected to any other system, and not completely air-gapped in said vault, with manual controlled exfiltration of data upon request.
I suspect this is not because of the fake engineers but rather because other forces, e.g. management wanted more efficiency and security was the last item on the list. I don't see how changing job titles would change anything here
Calling yourself a „dipl. Ing. <X>“ would be a crime if you don’t possess the appropriate degree.
Is it a surprise the complexity crisis continues? Dependencies rage out of control in modern systems, creating all sorts of havoc, including security issues. The academy seems to have little interest in this.
https://www.hillelwayne.com/tags/crossover-project/
the tl;dr is that for the most part, modern software development is very similar to engineering
It was two years longer than computer science, and all of those extra courses were with the “mainstream” Engineers.
There's a chapter on this in McConnell's Professional Software Development: Shorter Schedules, Higher Quality Products, More Successful Projects, Enhanced Careers.
His example of software _engineering_ was McMaster University in Canada, where the graduate could achieve licensure by taking and passing the appropriate exams. Courses include materials, thermodynamics, electricity and magnetism. His example of _software_ engineering was based on (an older version) of the program I went to at RIT, which covered courses in software project management, software engineering process, and a lot more software systems design. Both had similar math, computer science, and software development courses, but I suspect McMaster would have courses in linear algebra and multivariable calculus that I didn't have.
Are American developers missing something? We missed out on the opportunity to get licensed in the mid-2000s and 2010s. People who went to _software_ engineering programs probably couldn't pass an FE exam unless they took (and remembered) a bunch of courses that have little to do with building software and would fall outside their normal academic program. I'd say that the software _engineering_ programs that don't get into the nuances of how to manage organizations and teams building software systems are the ones missing useful knowledge.
In the past it was not uncommon for every 'engineering' degree to require the basic sophomore level classes for mechanical and electrical engineering. (inThePast = years<1990)
You imagine wrong. Everyone I know with a software-engineering-type degree took a mandatory ethics course.
Computer Science is a science. It is not focused on building things; rather on learning things.
The "dot com boom" and subsequent 25 years had such an employment need that everything turned into "programming means FAANG means I am rich"
Business Data Processing and Management Information Systems is more applicable to a majority of the 'software engineers' today.
Wishful thinking and brand inflation. Same thing that makes machine learning artificial intelligence.
The biggest thing I noticed was that, even though there was an acknowledgment of the lack of a singular definition of engineering, the definition used throughout was tied to a linear model of innovation. I've been able to trace this thinking to the 1920s, with a growth in popularity in the 1940s and 1950s. A prime example is Vannevar Bush's Science: The Endless Frontier. Although the report had some good outcomes, like leading to the establishment of the National Science Foundation, Bush's own autobiography acknowledged that this model was a disservice to engineers and engineering, as it led to many engineering accomplishments being touted as scientific achievements and scientists getting credit for the work of engineers in popular literature and the press.
There aren't too many other views of engineering out there. A handful of contemporary authors keep coming up: Florman, Vincenti, Ferguson, Koen, and Petroski. Most other things I've read tend to cite one or more of these authors and continue to build upon their foundations.
Picking up any one of the other perspectives on engineering would let you make another connection to the 1968 NATO conference. There were really three camps that offered definitions about what software engineering should be. People like Dijkstra, Hoare, Naur, and Wirth focused on applying mathematics and computer science and on theory building. McIlroy, Bauer, and Bemer looked at how software development could learn from industrial engineering and mass production. David and Ross emphasized practical problem solving. By the 1969 conference, the practical problem-solving piece had dropped out of focus, even though this is very closely related to how other engineering philosophers looked at engineering.
Another aspect from some of the engineering philosophers is the craft roots of engineering. This also tends to disprove the linear model of innovation. Engineering existed well before modern science, and there are several cases of engineering development without a robust scientific understanding of the principles that enable it. Modern science became a tool in the toolbox of modern engineers, but it's not a precursor to engineering. The craft roots have been there all along and were part of engineering education up into the early 1900s. This can tie back into Agile Software Development and the software craftsmanship movement of the 1990s and early 2000s.
The paragraph about application programming being removed from the debates in the 1960s misses a key point. In the 1960s, "software" was shorthand for "systems software", or the stuff provided by computer manufacturers to allow people to make their computers do stuff. Application programs were not really considered software until at least the 1970s. It's a bit nuanced, but there's a reason for excluding this group of people: it was seen as a different thing entirely.
Finally, no mention of Margaret Hamilton. Failing to even mention Hamilton and her use of software engineering as an aspiration to elevate programmers to the same status as the other engineering disciplines on the Apollo program misses a huge moment in the development of the idea of software engineering.
Did you mean "were not"?
Which is strange since the original "computers" were predominately women[0] and I find writing software has much in common with activities that were historically at least coed, such as creating recipes or sewing patterns.
Yet we never hear of "software chefs" or "software tailors". Given how little many titular heads of software companies understand their product, "software nanny" would also be applicable.
[0] https://www.smithsonianmag.com/science-nature/history-human-...
Obviously, what matters is where the term was coined, but I'd certainly suspect it has nothing to do with any gender bias and is instead about parallels to civil construction: architects design, engineers make it work and possible for builders to build. If anything, with LLMs, software engineers more closely match up to construction (as engineers rarely lay a single brick).
"Programming" is the creative tinkering aspect where you start from scratch and approach a problem from a new light. This is how Unix was born. It is the 1000-line program that is composable, fun to read and write and will last a long time.
It's easy to overengineer in software because the marginal cost of materials and logistics is ~$0. Overshooting by a mile is free. That doesn't discount the value of proper software engineering.