141–150 of 170 posts
A competing and altogether more entertaining and comprehensive body of knowledge: https://grugbrain.dev/
A core of the matter here is that good software development is heavily involved with _wisdom_, and in some sense, wisdom can not be stated badly, but must be oblique.
Earlier quoted context omitted.
There are three absolutely key differences here. The first is that, if you get a four-year college degree in mining or civil engineering, you will not spend much of those four years studying management practices; you will spend it studying geology, the mechanical properties of rocks and soil, hydrology (how water flows underground), and existing designs that are known to work well. You probably will not build a mine…
And as a side note, this is why LLMs are such a huge sugar rush for large companies. The performance of LLMs is directly correlated to capital investment (in building the model and having millions of GPUs to process requests). Software rarely has a system that someone cannot under cut in their bedroom. LLMs is one such (where as computer vision was all about clever edge finding algorithms, LLMs are brute force (for t…
Earlier quoted context omitted.
There are tons of physical engineers working on safety critical hardware that are not required to have some BS piece of paper that says they're safe. You do not need a credential to work on EV charging infrastructure, rockets, crew capsules to ferry astronauts to the ISS, or many, many other things. That's how you know, because those fields are not less safe. It's an easy comparison.
> work on EV charging infrastructure Could you expand on that? Are you saying that you don’t need a licensed electrician to connect a new EV charging terminal at installation time?
I am talking about engineers who design the EV charging terminal.
Earlier quoted context omitted.
Let me hear your pro-stagnation argument
Code that changes introduces new bugs, new bugs can be new security issues. A lower velocity would hopefully mean less changes but higher quality, more thoroughly tested changes.
Strongly agree that fewer changes equals fewer bugs, it just comes down to trading that off with shipping value in your product.
Earlier quoted context omitted.
Credentialism creates a false basis of trust and an arbitrary reference point. You're just arguing that you want to outsource your own decision making. You actually should interview your candidates before hiring them, whatever credential they have, because it actually is your job to ensure you work with high quality individuals. Credentialism basically allows the sort of low effort that you're describing and causes m…
Credentialism is for more than employers. When I need an electrician or other tradesperson to work on my house, credentials are beneficial. When plans are drawn up for a deck or extension to my house, credentials are beneficial when getting an engineering signoff. Knowing that the local medical facilties employ credentialed doctors is great when I need something done. Etc., etc.
Credentials are insufficient for all of those. A credentialed plumber or electrician could flood or burn down your house and it might be hard to figure out the root-cause, so the credential slips. You still have to do due diligence to find competent people.
I'll admit that for certain things which are easy enough that you can write down procedures for them that a credential can be valuable, but there are a reasonably small number of those things in the world and even when you do write the procedures down you're usually significantly constraining the type of project that individuals in that field can undertake. That constraining is a very important trade-off to consider when thinking about whether a credential is helpful.
Runtime errors surface when a program runs into an unexpected condition or situation such as dividing by zero, memory overflow, or addressing a wrong or unauthorized memory location or device, or when a program tries to perform an illegitimate or unauthorized operation or tries to access a library, for example. The programs must be thoroughly tested for various types of inputs (valid data sets, invalid data sets and…
Earlier quoted context omitted.
On the contrary, I am fully aware that there exists no field where a test or piece of paper guarantees excellence. But I am also aware what the lack of it does. It leads to buildings falling down or burning up [with people in them]. This was a common occurrence 100+ years ago. You know what made it less common? Standardization. Building codes. Minimum standards for engineers and the trades. Independent studies have a…
> It leads to buildings falling down or burning up [with people in them]. This was a common occurrence 100+ years ago. You know what made it less common? Standardization. Building codes. Minimum standards for engineers and the trades. To me, this is a more interesting comparison. Is it PE certification and contractor licenses that led to this or is it building codes, construction inspectors, occupancy permits? I will…
100%
Earlier quoted context omitted.
You are under this illusion about other fields like architects because you don't work there and you can't tell. You don't know how the sausage is made. Historically I have tended to learn about a new field WAY too much before I tried to hire people in these fields. The truth is, that makes it hard to hire people (but for good reason - depending on your needs, you need to pass on a lot of people). More recently I have…
On the contrary, I am fully aware that there exists no field where a test or piece of paper guarantees excellence. But I am also aware what the lack of it does. It leads to buildings falling down or burning up [with people in them]. This was a common occurrence 100+ years ago. You know what made it less common? Standardization. Building codes. Minimum standards for engineers and the trades. Independent studies have a…
The failures you're talking about with SCADA and security breeches will not be solved by some licensing where you check a box saying "thou shall not use default passwords", they'll be solved by holding companies responsible for these failures and having good safety/security requirements. A class isn't going to fix any of that. It's a ridiculous notion.
Earlier quoted context omitted.
What exactly is wrong with it? That is a definition fit for someone who does not have prior knowledge of what a runtime error is. It might be boring to us, and I might word it a little different, but it's fine.
A lot of things are wrong with it. > Runtime errors surface when a program runs into an unexpected condition or situation such as dividing by zero, This implicitly asserts that dividing by zero is always unexpected, that all runtime errors are unexpected, and that dividing by zero always causes a runtime error. None of these are true. Dividing by zero is very frequently not unexpected (it's utterly commonplace in 3-D…
>This implicitly asserts that dividing by zero is always unexpected, that all runtime errors are unexpected, and that dividing by zero always causes a runtime error. None of these are true.
You are assuming basically all of that stuff. Dividing by zero is almost always an error, is usually unexpected, and is a suitable example of a runtime error. Just because it may not be unexpected sometimes does not make it an unsuitable example. If I said "Taxable events surface when a person conducts a taxable transaction such as sale of goods or labor" does not in any way imply that all sales of goods or labor are taxable. It is implied in the sentence that the examples refer to common errors.
If you talked to 100 programmers and asked them to give an example of a common runtime error, I think conservatively at least 95 of them would spit out "division by zero" or "stack overflow". The audience of this book may conceivably not know what a stack is yet, so "memory overflow" conveys that you have used more memory than expected.
I don't have enough patience right now to shred the rest of your "analysis" but I can tell that you're the type of person who used to get pissed off at textbooks in school because they never mention air resistance. You probably got pissed off at that sentence because you once saw a textbook that did say "ignore air resistance" lol
Earlier quoted context omitted.
A lot of things are wrong with it. > Runtime errors surface when a program runs into an unexpected condition or situation such as dividing by zero, This implicitly asserts that dividing by zero is always unexpected, that all runtime errors are unexpected, and that dividing by zero always causes a runtime error. None of these are true. Dividing by zero is very frequently not unexpected (it's utterly commonplace in 3-D…
You're reading WAY too much into it. Sometimes things are meant to be simplified, and this is one of those cases. We are essentially talking about a brief description of something in a textbook. >This implicitly asserts that dividing by zero is always unexpected, that all runtime errors are unexpected, and that dividing by zero always causes a runtime error. None of these are true. You are assuming basically all of t…
I do agree that a division-by-zero exception is a good example of a runtime error, and—as I said in the comment you are purportedly responding to!—that the examples are intended to refer to common errors. (However, most of them fail to do so, evidently due to the ignorance of the authors.)
I would get pissed off at physics textbooks that said air resistance didn't exist, but I haven't ever seen such a bad physics textbook—and I've seen some pretty bad physics textbooks!
The rest of your comment is completely incorrect, and the personal attacks in your comment do not rise to the level of discourse desired on this site. It seems like you missed the main points of my comment, in several cases responding to my reasoned arguments with simple contradiction, and are unaware of the intended audiences of the SWEBOK.
Simplification is not only fine but a sine qua non for high-level summaries of a field. And simplifications are always in some sense erroneous. But the objective of simplification in a summary is to lead the reader toward the truth, even if you can't quite reach it—you can formulate the ballistics ODEs including air resistance much more easily once you've learned to handle the simplified version without. However, when someone doesn't understand the field, they often produce a "simplification" that includes lots of incorrect unnecessary detail and which is broadly misleading, and that is what happened in this case, as I explained in detail in my comment above. Someone who knew nothing about runtime errors would know less than nothing about them after reading that "simplification".
And the document goes on for hundreds of pages at this atrocious quality level.