Is that supposed to help someone? I fail to see how telling someone "just ignore the stuff that irks you that you have to spend 40+ hours a week dealing with. You are overly sensitive and your concerns are irrelevant" helps anyone. Even if it was true, it was delivered in such a ham-fisted manner that I can't imagine anyone taking it to heart.

I sometimes have a tendency to focus only on the negative aspects of some things, while ignoring that all in all, those things are fine. I don't think I'm alone in that, certainly not in our line of work.

A call to "snap out of it" seems that it can help in such situations. Python is not a programming language that should make people burn out or angry. Very few languages should be capable of that, so I think this issue goes deeper than just flawed tools.

I find that the only way not to go nuts in this profession is to ignore most of it and most of it is really not relevant to building good software. There are just too many tools and always searching for the perfect tool is a recipe for being unhappy.

The programming language is one of the central tools though, the very language in which you express programs.

If you don't care about that, caring about "building good software" feels hollow.

The key point is that there are many languages that are more than good enough for almost any kind of problem solving.

Building good software is firstly about process and skills.

>If there's one thing wrong with our profession is a lack of ethics and accreditation - we're essentially letting random people build critical infrastructure and utilities.

https://ncees.org/ncees-discontinuing-pe-software-engineerin...

There was a license for a professional software engineer; they're discontinuing it, apparently due to lack of demand.

If folks wanted to get a "software people taking the FE" study group together, I'd join up.

As someone with a P.E. license that spent hundreds of hours studying and had to sit for that excruciating 8-hour exam twice, I don't think even 5% of the software developers in the US could pass an equivalent exam. Granted, I think the sector I took it in has a harder test than some, but it is a weed out test for someone that already took 4 years of Engineering school.

Some takeaways from this: 1.) I learned a little bit from studying, but overall even though it was hard, I would've learned a lot more by getting a Master's degree. 2.) The test isn't good at determining if you're good at your job or honestly even minimally competent in your area. For example, even in a specialized field (power systems engineering), there are thousands of diverse jobs (power generation, distribution, electrical contracting, power transmission operations, power transmission planning....etc etc) so the test only had a few questions on my particular area. 3.) There are a lot of amazingly smart people working in software, but the skill range seems to be bigger than in traditional engineering fields where most engineers are fairly similar in skillset (there are some outliers) as they all generally have to pass the same courses if their university is accredited (talking about USA here). In the software world, you have software engineers and computer science doctorates mixed with someone with very little training that is trying to wing it. That means the dataset has a far greater range on skillsets. One employee might have had a class on compilers while another just learned what a for-loop is. In engineering, we generally all show up to the first day of work with the same building blocks (thermo, statics, Dynamics, circuits, differential equations, stats, calculus, basic programming...etc). The only difference between me as a senior engineer and a new hire is 9 years of experience, knowledge of the business and tools and ability to get things done without oversight. It makes a big difference, but I wouldn't expect them to be lacking any of the tools or training that I have picked up (ok...maybe databases).

I'm struggling a bit to convey the overall message that software engineering seems a bit different and licensing would therefore need to be different if done. Perhaps you could have licensing for individual subjects? For example, you could pass a basic test on relational databases where you prove you can do basic operations such as select, where clauses, joins, updates, exports...etc. Then you'd have another to prove you were minimally competent in Java? Would that be of any value to an employer? I don't know. I'm guessing someone already does this for Oracle and Java too.

so I am studying for the FE (I need a lot of math before taking it is realistic) mostly 'cause it gives me this broad feel for things Engineers all know. (I will take the 'other disciplines' - mostly because I want this to be as broad as possible; being broad but shallow makes it a lot easier for me, too, but for me, it being broad is an advantage in other ways, too.)

I personally find tests to be way easier than school, and the schools with reputations that are worth something are... pretty difficult for people like me (who weren't on the college track in high school) to get into. (and there is something of an inverse correlation between the prestige of a school and how flexible they are about scheduling around work; especially for undergrad)

From what I've seen of the test, it does provide some foundational ideas of what engineering is about. Like, it goes a lot into figuring out when things will break - something I haven't really seen a lot of in software engineering.

What I'm saying here is that I dunno that an optimal SWE PE would test you very much on the specifics of Java or SQL or what have you. I mean, from my experience with the FE, at least, they give you a book that has most of the formulae you need... and you are allowed to use a copy of that book during the test, you just need to be able to look it up and apply it. Seems like they would do the same with Java or SQL.

(I mean, to be clear, to apply the formulae, you still need to have more math than I do. I imagine the same would be true of sql or java, only I'm pretty good with SQL, having 20 years of propping up garbage written by engineers who weren't.)

From what I've seen of the software engineers, Most of the time, the software guys throw something together, toss it over the fence and move on. Clearly, they didn't do any analysis to figure out how much load the weak point in the system can handle, or even what the weak-point was. It's incumbent upon me (the SysAdmin; usually the least educated person in the room) to feed load to it at a reasonable speed and to back off and figure out what happened when the thing falls over.

I mean, I think the real question people are bringing up here is "what if we treated software engineering, or at least some subset of software engineering more like real engineering?" - like clearly sometimes you can slap together something over the weekend and it's fine, but... if you are building a car or an airplane or a tall building or something, you probably want to put in the time to make sure it's done right, and for that, you need rules that everyone knows; the PE system, I think, establishes rules everyone knows, while I think software engineering mostly works on the concept of "it worked for me"

Wait...are you studying for the FE without getting an engineering degree? Props to you. One thing to keep in mind though is that there is a morning and afternoon session that are both 4 hours iirc. The first session is always a general session which covers the absolute basics of Engineering math, circuits, thermodynamics, statics, Dynamics, chemistry, and physics. It really is very easy if you remember the classes. Some of the circuits problems can be done in your head and the statics problems might have the resultant force being part of a 3-4-5 right triangle (again, it shouldn't take much thought). The purpose of this is to ensure you learned the absolute bare minimum in these classes. One reason the general questions have to be easy is that depending on your course schedule, it might have been two years since you took a course (Ex: you might have taken only one thermo class as an electrical engineer during your sophomore year). The afternoon test is either also general or specialized to a discipline (Ex: chemical engineer) and are much more difficult in comparison. I barely studied for the FE and felt I knocked it out of the park (especially the morning session). I spent months of all my free time studying for the PE and failed the first time...it is difficult. Keep in mind that both of the tests have a lot of breadth, but little depth. Going into an actual Engineering curriculum will teach you a whole lot more. MIT used to (might still) have a circuits Edx class online for free which covers the first out of 3 circuit classes a EE will take...that should help a little with the scale.

Software is weird as the hardware, languages, and frameworks are always changing and the optimal work done on any project seems to be just enough to keep the customers from going to a new product and not necessarily the best or even a good product in many cases. There are cost constraints in Engineering as well (good, fast, & cheap...pick 2), but it still feels pretty different to me than software engineering where something breaks all the time in any non mainstream software I've ever used.

Yeah, they'll let anyone with a couple hundred bucks sit for the FE. The chances of getting a PE or even an EIT, though, without a degree are... slim to none. But that's not really my goal? (I mean, it would be if it were just tests) Mostly I just want to know those 'absolute basics' of which you speak, and I like to have a test to study towards.

I'll check out that edx class, thanks, that sounds like my thing.

It's a vicious circle.

Our industry's working in a survival of the fittest mode, where fitness is almost exclusively measured through profit.

I dunno, man. I own a bunch of stock in BA right now. I bet that the idea of spending twice as much on software engineers and hiring licensed folk to write their software is looking pretty good to Bowing execs right about now, even from a plain profit and loss perspective.

(of course, a lot of professional engineers were involved in building that plane... but it's pretty unlikely that there were any PE software engineers involved, just 'cause there aren't many. Would that have helped? maybe, maybe not. to the detail that I've studied (not.. really all that much) it sounds like they made some really basic mistakes, like relying on a sensor that wasn't redundant, and those mistakes should have been caught by the other engineers. I don't know that it was entirely a software engineering problem. )

As software mistakes get more and more costly, it starts making more and more sense for execs to hire people who are properly licensed to supervise the project. (I mean, assuming such people exist, and for software engineering, right now, you could say such people don't exist.)

Oversensitive? Is the contractor who chooses a Dewalt or Ridgid over a Ryobi for daily work "caring about irrelevant stuff"? A drill is a drill right? Why is it different for us in software?

Maybe. (and I thought festool was the new hotness? I thought that at least rigid and ryobi had been devaluing their brand by selling cheap junk under their brand? But I'm solidly in the 'prosumer' and not 'real contractor' end of the market, so not an expert or even close observer, really.)

But I think the point OP was making is that contractors have a licensing and training program, and if you hire someone to put a roof on your house, they either have to go through that process or work under someone who went through that process. I mean, choosing the right tool is a small part of that, but someone in the chain of command is gonna have words with you if you bring your Xcelite screwdriver and try to use it on the roofing job.

That's not true almost anywhere in software, and that probably makes a big difference.

(I mean, not being educated myself, i personally have mixed feelings about licensure. But it's a good discussion to have, and I think that there should be something like the PE for software engineers (and there was, in texas, but it will be discontinued this year. )

I don't know anything about those brands you mentioned, but a programming language is more complex than most (all?) mechanical tools, it's designed over years and continues to change over decades.

It's impossible to do a perfect job under such conditions, and it's anyway impossible to please everyone.

Hey I like my Ryobi drill. :(

I love my Ryobi tools too! Just, I've assumed given their price-point, they aren't built for day in and day out needs of a contractor.

> Over-sensitive individuals are hard to please and often unhappy. That's more of a personality flaw than a flaw with the current state of software engineering.

Ah yes. Just remove the part of myself that got me into software as a child, and proceed robotically.

Why didn't I think of that?

> If there's one thing wrong with our profession is a lack of ethics and accreditation - we're essentially letting random people build critical infrastructure and utilities.

Spot on. Leftpad (and perhaps the whole js ecosystem) are good examples.

There are objective differences between languages. Examples include performance and compile-time checking. These differences are not irrelevant.

Alternatively, if you believe the differences between languages are irrelevant why do you not program everything in assembler?

Those differences don't matter much when it comes to building software that fulfills specific requirements.

I am a big fan of compile-time checking, but there's a lot of good software built without it and sadly there's also a lot of successful slow software. These are disadvantages, not an impassable barrier.