Not to mention the move away from actual planning documentation or estimating capabilities because they are so worthless.

Yeah your bridge architecture blueprint is still useful 100 years later. Your application architecture diagram is useless within a few months.

"Oh yeah we changed that a while back."

"Ignore those pages."

"I'm not on that project anymore. Can't really say what they changed."

"Sorry you spent 2 days beating your head against the wall. Next time just go straight to the source to be safe."

I once signed a 6 figure deal with a company whose founder was one of the agile manifesto signatories.

The only official documentation of what we were going to do was "launch a website".

I think that "engineer" implies a sense of standards, and most importantly, a contract of liability. Samsung phones had a few burning batteries, the phones were removed from the US market. BP paid for the oil spill. If the Burj Khalifa was built like software...

Contrast to the typical hack. It would be one thing of Tom Ptacek went rogue and broke your locked down database with zero-days, but with the current standards, Snoop Dogg could take a 10 minute break from rapping and smoking weed, do a quick google search on cracking dat webdiggity, and take down half the internet.

The leaked passwords, exposed privacy details, and identity thefts cost American's billions of dollars a a year, yet the companies doing a shoddy job protecting this data is not held accountable. Companies aren't getting sued, no one is covering the costs, and people, for the most part, aren't losing their jobs.

I may be overstating the importance of "engineer" in all of this, but I think it's best to approach what we are doing with humility and perspective.

job question - if working with a recruiter means i never have to network, and they get paid from the company while i get my normal salary, what are the downsides exactly?

You don't know what opportunities the recruiter isn't putting you in for, their success revolves around them finding people jobs, not necessarily you jobs.

They are mostly slimy scumbags. Any company you get placed at is going to be paying them a percent on your salary which makes you more expensive, which in theory means that you'll have a harder time negotiating a salary. They will lie to you about companies, and lie to companies about you. They will encourage you to lie.

I have used recruiters in the past - hell, I got my current job through one. But yeah, I kinda hate em.

I love recruiters. Whether or not I'm looking, every (local) recruiter that contacts me with a job I respond with a copy/paste that basically says in business speak "Whats the most top talent would get offered for this position, I'll need a number from you in your next response to move forward" and about 1/2 of them give me some very useful data. Obviously I don't respond to non-local recruiters.

What do you think typical non-software engineers do?

No one's calling all devs engineers. And calling anyone who doesn't deal with engines an engineer is already a concept creep and that's how languages work. As for the importance, top-tier software developers (outside of which the phrase software engineer is not that common) are generally paid better than non-software engineers and are held in higher regard anyway. The comparison here is more flattering to non-software engineers than to software engineers.

Not exactly - "developer" and "architect" aren't native to software development either - they come from real estate development and have unfortunately led to a situation where some senior technical people use the metaphor to act like programming is something beneath them. "Engineering" as a term to encompass both activities is at least partially an attempt to acknowledge that implementation and design aren't easily separated in software development, especially at higher-levels of practice, and that implementation isn't naturally a lower-tier job than pure design/plan/architecture work. It's born out of an "MTS" way of thinking to create a flatter technical environment where decisions are made based on facts, not seniority.

I don't understand the distinction here - if the burning batteries were due to a software defect, would they not have replaced/removed the defective software?

Practically all physical locks sold in the market aren't secure by this standard and as far as I know, they are not held accountable for the inevitable thefts that occur as a result of their lack of security. Even in computing, secure computing at the hardware is something that has been possible for a long time but practically all hardware that's actually available on the market is insecure garbage.

Legally what that guy is doing and a software developer calling himself an engineer are completely unrelated. He is an actual engineer, didn't get in trouble for calling himself an engineer, but discussing electrical engineering issues without a license. It's likely that the law is on his side in any case, but he's in trouble for practicing something without a license, not calling himself something he's not. A legally similar case would be something like some repairman getting in trouble for calling himself an appliance doctor.

Engineering is not pure math - it's a discipline that's primarily concerned with practical usefulness, not rigor for its own sake. Trade-offs and constraints are actual things and real-world engineering is about optimizing within the constraints given, not being rigorous.

If what you're doing can kill people, whether you're writing software or designing hardware, you'll be required to be extremely conservative and there will be lots of procedures around your work to ensure that you don't kill people. If time-to-market is important and iterative design makes more sense, the balance will shift in the other direction.

Well at least in one sense, unproductive software developers working very slowly on legacy software are closer to engineers and superstars working on the cutting edge stuff are closer to craftsmen. Yet in another sense, it's the reverse.

More suzzer story time.

When I worked for Quest Diagnostics we created a PDF version of a lab report that could be viewed or downloaded from our app. The official lab reports are printed off from a big dot-matrix roll with the tearable side thingies - and mailed to doctors. For most of the life of the app - our web version was only viewed by people at drug companies to see how the study was coming along. IE - there was no chance a doctor would use the web/PDF version to make a diagnosis.

Right about when I was leaving they decided they wanted to open up the app to doctors. I had to raise a gigantic stink to point out the lab report hadn't been validated to that level. It's real damn easy on the web and PDF to cut off a digit in a column. So instead of 0.9 for Creatine or something, a doctor might just see 0. In theory, worst case scenario, someone could die from misdiagnosis.

I seemed to be the only one overly concerned about this. I finally convinced them we needed to do a hardcore validation against a bunch of printed lab reports. And what do you know - we found bugs.

You know how your last 2 weeks is usually total blow-off? I spent the last two weeks, and even the last weekend after I was supposed to quit, feverishly working on this validation. I didn't trust that it would get done if I left. No one else knew the PDF generator (XSL:FO) at all. I didn't want some dead person hanging over me.

Funny thing is when I interviewed at business.com, while this was going on, the interviewer asked me to name a time when I had to make an ethical decision. Well boom, of course this popped into my head. She seemed to really like the answer as it never occurred to her a computer programmer could be responsible for life or death. I saw her like 10 years later at a reunion and it was the first thing he brought up.

And of course now at my current job, and side job, I do **** all for months at a time and have gotten so damn lazy I may be ruined.

Another thing I like better about "engineer" vs "architect" and "design" vs "architecture" is that I feel something about how these words sound - architect and architecture - drives people towards complex, grandiose solutions whereas "engineer" and "design" drive people towards simpler, practical solutions.

Based on old memory and some quick googling - it is mostly true in Ontario. Its based on provincial laws, so it would be at least some-what different in other provinces

So, its probably not allowed... but its not really clear how it plays out in practice. Seems some people think "Software Engineering" is ok as a job title but Software Engineer isn't. Shrug.

At one point Microsoft backed off on the use of Engineer in their certification here, and then they went back to using it. My guess is because they have lots of well paid lawyers that would argue that their use of the title would not be confused with someone practicing professional engineering. I don't actually know what the current situation is.

My best guess is that the Engineering body for enforcing this would only go to court for egregious cases and in most cases a 'cease and desist' approach would be enough.


Edit: I think a lot of the people saying this are repeating things they've been taught in school. But, of course, the school needs the program to be accredited by the relevant Engineering bodies and is made up of Professional Engineers, and so they're probably going to overstate the case against calling yourself an Engineer.

Totally agree. But architect sounds like someone who is allowed to have a salt & pepper beard (or salt & ginger in my case), whereas engineer can be any bright kid.

I mean if you have a bad architect, your whole system could fall apart at the foundation. That's bad. A bad engineer is just some bad code. No need to put up with some grumpy old fart stuck in his ways to avoid that risk.

I think I have new advice for people who want to do a career change to programmer/do a bootcamp.

It would be to go ahead and do App Academy, Hack Reactor, possibly others if you get in (not the really bad ones), but to fully expect to spend about a year unemployed, and to continue to work hard learning on your own for those 6-9 months post-bootcamp, plus applying. This was already the case to a lesser extent (I worked fairly hard learning on my own for 2-4 months post-bootcamp depending on what you count as learning), but it should be anticipated now going in.

"In my day", we all expected that we were basically in like Flynn as soon as we got that acceptance into a top bootcamp. All we had to do was complete the relatively minor pre-course work, show up on Day 1 prepared to have little free time for 9 weeks (a trivial sacrifice that was never an issue for most of us) and we were "guaranteed" 6-figure jobs.

As long as people are going in realizing that that isn't the case anymore, then go for it. Barring extreme social awkwardness or a massive crash that lasts many years, you'll make it in eventually if you keep putting in the work. There's definitely some % of [unlucky or lazy] people who would take even more than the year though.

freecodecamp.com looks really good (they have you work on real things for non-profits apparently) and so really part of the recommendation would be to see if you can get by on your own with some trial weekends dedicated to that site. If you find you can self-teach and debug things without instructors present, that's an obviously cheaper path than an $18K-$40K bootcamp.

The point isn't about software per se, but about the liability and responsibility. If a software error causes a plane to go down or a rocket to explode, you aren't upgrading the software after the fact, but the companies are insured and liable for neglect.

Everyone picked on Sony for it's less-than-stellar security gaffs. I doubt many self-proclaimed software engineers described Sony's practices engineering, and this is the danger of terminology: If you can swap labels when it is convenient, then you can offload responsibility when it can cost money or credibility.

There are many fields that require accreditation or licenses to practice, and it happens that engineering and architecture are two that require stringent license and testing. Anyone who openly neglects the standards risk losing their profession, can face fines, and go to prison. If software engineering was held to this standard, then MongoDB would be considerably different.

FWIW, locomotive engineers have to go through a lot of training, be licensed, and meet federal guidelines.

http://study.com/articles/How_to_Bec...r_Roadmap.html

http://www.slate.com/articles/news_a...hat_train.html

Anyone who's had their house robbed will tell you that the door handles weren't used.

This isn't true. It needs to be better than other options, which are mostly horrendous in countries without strong ID (which is a necessary item for e-voting).

I think there are some engineers and some programmers. But I really enjoy the discussion that has spawned.

This isn't even remotely close to true. Autopilot is a human assist program. If run out as an actual SDC the death toll would be astronomical. (Check the California records for driver interventions for do some math for their lovely demo. I was much more of a fan and still think they have some structural advantages, but purely based on the numbers they are way way way behind everyone else.)

https://www.recode.net/2017/2/2/1447...disengagements

Here's a quick lay press piece discussing the topic.

Engineering has standard processes and guidelines for how to build structures. Processes that are constantly reviewed with new technologies and that grew out of experience gained through decades of real world use. When you hire an Engineer that is what you are hiring. That is the rigor that software development is no where near, and won't be for a long time. Each team that writes software uses their own process, sometimes it's even repeatable, but mostly it's not. The easiest way to see that software development is not equivalent to Engineering is the amount of education required and the licensing required. You don't see "self taught" Engineers building tunnels and no one is talking about Electrical Engineering bootcamps leading to quick EE jobs. I think you can even use the massive 10x productivity difference between rock star developers and average developers as an indication of the immaturity of the Software Development discipline. I'm not saying you or anyone else in this forum isn't a good software developer and I really don't care what you call yourself, I'm just saying software development has a long way to go before it is actual "Engineering."

Civil engineering is not the only type of engineering... There are far fewer ”standards” if we start taking about mechanical engineering instead. And just because software engineering is a younger field and moves more quickly doesn't preclude it from being engineering.

To see all the requirement to be a PE in California:

https://www.upwardlyglobal.org/skill...al-engineer-pe

California licenses Professional Engineers in the following engineering disciplines: Agricultural, Chemical, Civil, Control System, Electrical, Fire Protection, Industrial, Mechanical, Metallurgical, Nuclear, Petroleum, and Traffic. Structural, Geotechnical and Soils engineers are considered subspecialties of Civil Engineer and have extra requirements for practice.



1. Register for and pass the the Fundamentals of Engineering Exam (FE)

2. Apply for and receive Engineer-in-Training Certification

3. Accumulate 6 years of qualifying experience

4. PE licensing application

5. Pass PE exams (plus California Civil exams if civil engineer), receive license

Mechanical may be less stringent than Civil Engineering, but it's far beyond anything a bootcamp student is doing.

At the bottom of this page:

http://www.bpelsg.ca.gov/consumers/lic_lookup.shtml

License Types

AG - Agricultural Engineer
C - Civil Engineer
CH - Chemical Engineer
CO - Consulting Engineer
CR - Corrosion Engineer
CS - Control System Engineer
E - Electrical Engineer
EG - Certified Engineering Geologist
FP - Fire Protection Engineer
GE - Geotechnical Engineer (Soil or Soils Engineer)
GEO - Professional Geologist
GP - Professional Geophysicist
HG - Certified Hydrogeologist
I - Industrial Engineer
L - Land Surveyor
M - Mechanical Engineer
MF - Manufacturing Engineer
MT - Metallurgical Engineer
NU - Nuclear Engineer
P - Petroleum Engineer
PS - Photogrammetrist (Photogrammetric Surveyor)
Q - Quality Engineer
S - Structural Engineer
SF - Safety Engineer
TR - Traffic Engineer

No one thinks bootcamp students are writing great software either.

Would things be that much better if a Licensed Software Engineer had to affix their stamp to code before it got released for certain projects or whatever the equivalent to how this works in other fields would be?

That sort of licensing would give a much more well-defined professional status/mastery but I'm not sure that it would be a net positive for the industry.

There would be a lot more testing done at least....

you dont need a PE to work as an engineer.

This is a better question than what people who write software call themselves. Is the field ready for self driving cars? Do we need two classes of software one life threatening and on non-life threatening that require different standards than we currently have? You can't build much of a building before you need plans that are approved and inspections to make sure codes are being followed. Is software getting close to that that level?

History has shown that the industry has zero awareness of or desire to implement security into it's newest inventions, do we need some standards bodies to start making sure someone didn't mix units in the code for software that automatically lands aircraft? What would that have to look like? To what extent is it possible and who would pay for it? Is there any way this happens before a bug kills a lot of people?