Agree fully...I have found working in corporate America, that it is quite effective at stripping off branching talents or 'non-core' skills of a bright person and making them form a lane of specialization. Essentially stunting their natural curiosity and desire for more knowledge, malforming them into a one trick pony.
Woe is me, I’m a cog in the machine but I want to be the machine itself. I think the technology industry is detached from the rest of the world.
Programmers and mathematicians train to be “the utmost correct” and everyone thinks they figured it out. On this quest for hyper-optimization, hyper-correctness, and so on, EVERYONE has become ridiculous.
Designed a bridge that injures no-one and collapses a few hours later? 5 year suspension.
Programmed a faulty flight control system that kills hundreds of people and ground all planes that use it for nearly two years? Probably a promotion, if I had to guess.
Can someone remind me why software engineers can't be held to higher standards?
Because they would involve holding the entire managerial chain to that standard too. Plus, it’s slower, and we can’t miss those product metrics, right?!?
It can be done. Places like NASA do it. For JavaScript too even.
…but it has to be a culture thing. Either by choice or by regulation. Because otherwise it ends up being about shoveling crap as fast as possible.
I have an acquaintance who works for one of NASA's laboratories as a technician.
The simplified distinction as he explained it to me is:
Engineers are the guys who painstakingly design things, with reams of university degrees as appropriate for their credentials.
Technicians are the guys who painstakingly implement the engineer's designs on paper into physical things. Academic credentials not necessarily required.
The vast majority of the people who call themselves or are called "engineers" should not be called engineers.
There is also the subset of actual software engineers (incl. degrees) that are hired to rapid fire features. In fact most engineers are hired to do this, because move fast and break things. Usually telling a PM that feature X needs proper analysis and design and that can take multiple sprints, they go “how can we break it into smaller pieces so we can deliver each sprint”. Sometimes you can’t do that. You engineers simply get into developer mode.
This is a good argument for protecting titles like "engineer". Programmers love calling themselves engineers, but they'd better be careful in places where there are consequences attached to the term.
The system is useless without protections in place to prevent it from becoming a racket, but I'm not opposed to such a system.
It *is* protected where this fellow practised. It's also a 5yo story. You can't be an engineer in Canada without being held to the same values (it's a regulated title[0]). Much to the chagrin of boot-camps, and US employers.
Also we also have pEng which means professional engineer. Most of the Software Engineers in Canada (even though with actually engineering degrees) are not professional engineers.
Do you think normal engineers have any more power than a programmer? In the end, they're employees for a business, with a boss breathing down their neck to just sign off already.
All at will employees have the power to refuse to implement something when ordered to by their PM. Quit. “I was just following orders” doesn’t even fly for situations where refusal can get you strung up for treason.
I have in the past successfully pushed back and refused to work on projects I thought were ethically fraught. Problem is, your company will just say "Sure! No problem! We take care of our developers here at Initech! Jimmy, two desks down, would be happy to write that code!" So the problematic software always gets implemented, despite one person's objection. Because we have jerks like Jimmy.
> Programmers love calling themselves engineers, but they'd better be careful in places where there are consequences attached to the term.
At least in the US, you can refer to this case where the state of Oregon tried to be as anal about the word "engineer" as you suggest and got slapped down. The whole case was a lot of fun because not only was the engineering board using unconstitutional restrictions of free speech, they were on the provably wrong side of an engineering argument while doing it, demonstrating just how stupid the attempted restriction of speech was in that case.
I suppose it can't work in the USA, then. The American idea of freedom of speech is pretty unique, though, so it shouldn't be that much of a problem in most of the (free) world.
Ironically, the (electrical) engineer who had his free speech rights protected in the case was Swedish. And the (correct) argument he was ultimately allowed to make in Oregon triggered an update in international guidance on traffic light timing. So the rest of the (free) world will actually benefit regardless!
Software "engineers" refuse to believe somethings is their fault, and push responsibility to everyone else but the "engineer".
My professors had no qualms about failing people because if you are not good enough to pass an exam, you are not good enough to be trusted with peoples lives.
> Can someone remind me why software engineers can't be held to higher standards?
because most of the time, civil engineers employ proven techs to solve problems that have been solved 100 or 1,000 times already. software engineers, I mean real engineers, face completely new issues in every aspect of the job on daily basis.
just remind me how much changed for civil engineering in the last 20-30 years? how is that compared to software engineering? let's just be honest, those people shouldn't be called engineers, they are more like technicians, as most part of their jobs don't involve anything new.
Because their employers want them to "move fast and break things". Demanding documented requirements and a tight change process is something that's more likely to get a SE fired than be appreciated.
> every state regulates the practice of engineering to ensure public safety by granting only Professional Engineers (PEs) the authority to sign and seal engineering plans and offer their services to the public.
There's a big difference between the typical so-called "software engineers" and actual Professional Engineers that are qualified to put the P.Eng. designation next to their name.
I thought the root causes of 737 Max failure is (1) marketing’s choice to make a new plane that pilots with existing 737 certificate can fly with little or no training (2) the lack of a third sensor.
2. The installation of the AOA sensor apparently didn't check for proper operation
3. The MCAS system was connected to only one of the two AOA sensors
4. The MCAS system had too much authority
5. The LA pilots did not think to turn off the stab trim system when it ran away
6. The EA pilots did not receive, read or remember the Emergency Airworthiness Directive sent to all MAX pilots after the first crash that basically said to turn off the stab trim when it runs away
7. The first MCAS incident was when the crew simply turned off the stab trim and landed safely. The information about the faulty sensor was not passed on to the next crew, who crashed.
Well the root cause of this bridge failure was (1) the municipality’s choice not to pay for a geotechnical investigation and (2) not using extra helical piers, so why is this failure the structural engineer’s fault?
As part of my undergraduate engineering course work we had more seperate threads and more exams than almost every other degree on campus including law and medicine.
Part of that was civil, part electrical, part electronic, part mechanical, part drawing, part on site saftey, part drawing, etc.
Another key part, critical to passing, was ethics, civil responsibility and a roll call of great engineering screw ups that killed people as case studies of how badly things can go wrong.
If Software Engineering were to become an equivilant then a study of when software goes fatal would be mandatory.
I disagree. I've always found HN to be a great place to discuss things like this. In fact, HN sometimes feels like one of the only places I can discuss things like this without being downvoted to hell and back.
The software dev job market is cooling down. Making good choices on what to build experience in is more important than it has been in recent years.
I think many companies, including mine, are thinking they have only a few spots to fill and a lot of candidates to consider. I know we consistently say things like “who will be productive quickly?”
I honestly think that if you have a short enough runway that "who will be productive quickly" is a prime concern, it may be time to consider hiring nobody and figuring out other ways to save money and extend runway. And if you aren't that desperate, then you should stop asking this question and instead ask "who will be a good investment longer term?".
Alas, that's not how the market works, unless you can pay top of market. So for FAANG, that works, but for startup #293928293 that won't work. They need to ship more features asap (an orthogonal discussion about building the right features is a different matter), and for that they don't have time to bring someone up to speed, only for them to jump to a better paying role once they've upskilled.
I've worked at all different kinds of companies, and I don't think this is the way it works at well managed startups.
The model I've seen at startups is an approximately two-year cycle of 1. raise money against a couple year plan of milestones, 2. hire quickly on the back of that raise, 3. use that personnel growth to hit those milestones, 4. go back to 1.
Importantly, the large bulk of the hiring happens around those post-raise points, when there is a couple years of runway. And the idea of startups is to be ambitious and forward-looking, not myopically churning on short term features.
I would submit that it's even more important for startups to be focused on investing in the right team during those scale-up periods, because many of those people are going to be the leaders during the next round. You want people who are going to be strong stewards of your business as it grows, not just people who see themselves as "react devs" or whatever.
