8LU - Are we *really* engineers? by Hillel Wayne

Absolutely! Some companies are great at this but most (from my experience) use the term but there's 0 'engineering' involved - it's just hacking bits of code together and hoping it lives long enough for a customer to sign off on UAT. There was a good talk on this subject last week - here's the recording if you're interested [VIDEO]

I used to think this, and then I interviewed people who did both traditional and software engineering professionally, and now I'm not so sure. I did a first draft of what I learned here: [VIDEO] I'm hoping to have a written version by the end of September.

I really think you should read Dan's post in full . Because you really did make the error him and Hillel discuss. I think it'll also help interpret my point and the gp to my comment. We're not thinking in a framework where CS and Eng are all that different. Or skip to this part of Hillel's video[0] I've been an aerospace engineer. Worked there before coming over to CS. And I can certainty tell you that yes, someone may ask you to split a floor in half. There's nothing really preventing you from doing this. There's buildings with more levels than there are ordered floors. It's a 15 floor building, but you label your floors 1-14. Such an area can be used for things like running conduit or even just as a fire break. Hell, there are even split level homes, you know those ones where you walk in the front door and either go up or down? There's also things like scissor flats. So yeah, you are making the mistake because your example belies you. It illustrates that you aren't aware of the complexities and abstractions in the engineering job. It's okay to have only a rudimentary understanding of engineering, you've spent your time learning other things that are more valuable to you. But that doesn't mean you should assume things are simpler than they are. The truth is that any job, has depth and far more complexity than appears at the surface. While in many jobs you can get away with only doing the simple part, there's still more depth than is actually being utilized. Likely for the sa

> and I have experience with construction as well. Just so we're clear, construction isn't engineering[0]. The difference does matter specifically in what we're talking about. > If your implication was followed in software (i.e. try to predict the future and introduce hidden floors, service floors and such) — and it sometimes is — we really end up with worse, more complex software that has technical debt built in from the start. But again, I think this belies you. Yes, I've made the assumption that you either didn't read Dan's blog in full or listen to Hillel's video, but can you blame me? This sentence is something they both explicitly discuss. You don't have everything figured out in engineering. Frequently you are doing your designs and then get them built by a manufacturer and then reiterate. This is very much akin to writing code, running tests, and rebuilding. Hillel discusses this right here[1] (this also addresses your last line) >> The idea that software is inheriently unpredictable and you're always doing completely new things all the time. While engineering is basically doing the same thing over and over again. Umm... yeah... so... this is probably the only question I got where people would start laughing at me when I asked it. Or from Dan, not far in he says >> And, of course, only someone who hasn't done serious engineering work in the physical world could say something like "The predictability of a true engineer’s world is an enviable thing. But ours is a world