Hacker News Reader

Comment by jes | Hacker News Reader

I did not know of this document before today. I think it's valuable and I'm glad the link was shared.

The value for me, I think, will be this.

I'm an older (61) software engineer. A document like this can serve as a starting point for discussion in the software group of which I am a member. It can be something like a reference design for software practice within the group.

By reference design, I mean, something that the group considers or consults when discussing or designing how its own practices should be.

I'm thinking about facilitating some short (15 minute) discussions within our group to introduce the document and its contents, and then see if people think it would be worth our time to consult it when designing our own policies and procedures.

Thoughts?

View on HN

I only skimmed it and I couldn't find anything practical enough that would help me in my day to day work.

For example it talks about design patterns but only in an abstract way, not what pattern could help you solve certain classes of problems (2.3.3).

Or API design, great that's a constant source of contention, again, nothing meaty to reference in a discussion either (2.4.1).

I'm probably grossly misunderstanding the purpose of that document. I was hoping it to be more similar to the OWASP cheat sheets [0] but more general.

[0] https://cheatsheetseries.owasp.org/

Yeah, it's definitely not gonna be that explicit. There's a section under Cover called "Introduction to the Guide" that explains their objectives.

Anyways, this doc is gonna be useful for me because while I took computer science & engineering as a major in college, I never ended up taking a course that taught me how to holistically look at software engineering as a discipline and all the terms that come with it.

The purpose is simply to define a minimum baseline of knowledge that every professional software engineer should memorize. It's kind of like having a common vocabulary so that we can hold productive discussions rather that wasting time defining basic terms. It isn't intended as a guideline to follow in daily work.

> The purpose is simply to define a minimum baseline of knowledge that every professional software engineer should memorize.

That may be a bit much. It covers a lot (300+ pages just to identify and describe each area of study), and many people can and will go entire careers without needing to know about certain things, and be very effective software engineers (knowing more about compilers is useful in many ways, but by no means required to be an effective programmer in many areas).

I would say it's good for finding gaps in your knowledge in areas that you have contact with, and as a good syllabus if you are branching into something unfamiliar. Would a person be served well by reading through this entirely and at least having been exposed to certain topics once? Yes. Should they necessarily have studied every topic? No. The field is to wide to expect everyone to know everything. This helps with that though, since it lets people identify gaps in knowledge that are currently important that they can then research more.

The SEBOK is really for setting the stage, agreeing to practices and framing approach to the problem.

All good stuff to ensure as a baseline for people working on projects you're on. Working with someone on a project that can't sort a requirement from a spec can be problematic.

I think it's a great read.

Analogous to this is the PMBOK which is required reading for PM certifications.

Reply on news.ycombinator.com