←back to thread

205 points bsoles | 1 comments | | HN request time: 0.211s | source
Show context
0xbadcafebee ◴[] No.41909738[source]
There appears to be a lot of hate towards this in the comments (because it's not perfect?), but I feel strongly that we need explicit bodies of knowledge, along with certifications for having been trained on it.

Every company I go to, the base of knowledge of all the engineers is a complete crapshoot. Most of them lack fundamental knowledge about software engineering. And they all lack fundamental knowledge about the processes used to do the work.

That's not how engineering should work. If I hire an architect, I shouldn't have to quiz them to find out if they understand Young's Modulus, much less teach them about it on the job. But that's completely normal in software engineering today, because nobody is expected to have already learned a universal body of knowledge.

I get this thing isn't perfect. But not being perfect isn't a rational argument for not having one at all. And we certainly need to hold people accountable to have learned it before we give them a job. We need a body of knowledge, it needs to be up to date and relevant, and we need to prove people have actually read it and understood it. If this isn't it, fine, but we still need one.

(this is, by the way, kind of the whole fucking point of a trade school and professional licensing... why the fuck we don't have one for software engineers/IT, boggles my fucking mind, if this is supposed to be the future of work)

replies(8): >>41909853 #>>41910131 #>>41910397 #>>41910615 #>>41910691 #>>41910982 #>>41911740 #>>41927142 #
1. yowlingcat ◴[] No.41927142[source]
> I feel strongly that we need explicit bodies of knowledge, along with certifications for having been trained on it.

...

> That's not how engineering should work. If I hire an architect, I shouldn't have to quiz them to find out if they understand Young's Modulus

Why do you feel strongly about it? Why isn't that how software engineering should work?

While I don't disagree with your belief that improved software engineering skill foundations would be better for the industry as a whole, I find your conclusion unpersuasive because it seems to imply that "something is better than nothing." But as this sibling comments alludes to (an ACM rebuttal to SWEBOK):

https://news.ycombinator.com/item?id=41907822

https://web.archive.org/web/20000815071233/http://www.acm.or...

I find the ACM's argument more persuasive:

```

The SWEBOK effort uses the notion of “generally accepted knowledge” as a cornerstone, specifically excluding “practices used only for specific types of software.” We believe very strongly that, for software, this is approach is highly likely to fail and that the opposite approach — primarily focusing on specific domains — is far more likely to succeed. The central reason is that software engineering addresses a much broader scope than traditional engineering disciplines. ...

```

And I tend to agree with their conclusion:

```

Overall, our assessment has led us to the conclusion that the SWEBOK effort is geared aggressively towards trying to define an overall level of professional practice for all of software engineering that would implicitly provide assurances to the public. Furthermore, we believe strongly that it will fail to lead to an achievable level of professional practice in a reasonable time and that, in failing, it may lead to a situation in which the public is provided with false assurances of the quality of software systems ...

```

To conclude, I'll address a point you raised which I have a hunch could be the root premise of your argument:

> Every company I go to, the base of knowledge of all the engineers is a complete crapshoot. Most of them lack fundamental knowledge...

If this is what you've seen at every company you go to, it could be that the common thread is you. I've worked at a variety of companies over my career, and quite a few suffered from the issue you mention. But on the whole, at least half of them (and by proxy, the engineers and engineering orgs I've worked in) have been the exact opposite. The technical bar is very high, the body of knowledge is established, clearly defined, and rigorously enforced; in doing so, these organizations were able to ship durable, high quality code with high velocity and a low defect rate even as the business expanded dramatically and we experienced setbacks and false starts. While I don't think my experience is universal, I also don't think it's unique either.

My unsolicited advice to you would be to try and find a company that has the technical bar you would like to see and work there for a while. Failure is a much poorer teacher than success. There is certainly room for software engineering to evolve as a practice, but for the aforementioned reasons (articulated by folks in far greater, well thought through detail than I have), I don't believe SWEBOK holds the keys.