If you know nothing about Python or coding it is not really relevant as the code is probably read and written more by those who know coding and/or Python?
What do you specifically want to learn? What you need to learn will generally make itself known, if you have some general goal? Just starting at all is the best way to start.
Say I want to learn web scraping. Now if I try to start, I see there are several layers of fundamentals and several potential paths, all of which seem equally important. Where do I start? What platform should I use? Should I start from the DOM and HTML parsing and go ahead from there, or should I start from learning Python libraries built for it as so many books and tutorials advise? Going one layer deeper, do I need to learn data structures before anything else? JavaScript and APIs? The fundamentals of TCP networking? Regex?
Yeah, start from any point A. A suggestion is where you can progress in some way. Don’t make too many decisions. There’s so many viable ways to learn that, just start where it is natural for you. You don’t have to figure everything out or have answers to everything.
I learnt data analytics and SQL for MIS/BI purposes on-the-job as a sales manager. Got pretty good at it too, built several dashboards and long-standing capabilities for my team.
Now, if I say I want to get into this scene for good, I am immediately daunted with a mountain of diverging learning paths to take. Should I take to Python and its massive library ecosystem, or should focus on database fundamentals? In every choice taken there are seemingly infinite branches, and it is rather hard to focus if you aren't even sure you're on the right track.
Last time I sat in an analytics/consulting interview they grilled me on highly specific technical questions on data pipelines and warehousing and testing and other topics that I've never had to worry about before at work. In another assessment, I was grilled on some AWS/Redshift-specific things. In yet another I was expected to know deep learning. It is all too hard for someone not originally with an engineering (or adjacent) background.
Yeah learning to actually use in practice is different from preparing for interviews. I would say continue where you already built some knowledge and branch out when you realize you have to, and then work on learning one branch as you go.
For interviews you may need to lookup what type of questions to expect and memorize details on that, unfortunately. That is not useful in practice but can be necessary for interviews.
It would have zero value in every process of vetting someone. People don’t care about years of verification in the form of degrees, who do you think will care about some “license to fucking code” given for reading some garbage pdf
Well also now entire companies fail quicker instead.
It is useless because no one will read it or use it as any type of benchmark, probably rightly so here. There is a version of this at every company, just more relevant, also already not being read of course.
And this particular document will never be up to date. SWEBOK gets updated on the order of every 5-10 years, so it's always going to be dated. This is one reason it's a poor document for its purpose. If they want it to be relevant it needs to be continuously developed and updated. Hire active editors for the different "knowledge areas" (consider even losing that notion, it's very CMMI which is not something to aspire to) and solicit contributions from practitioners to continuously add to, remove from, correct, and amend the different sections. Build out the document they actually want instead of wasting 5-10 years publishing an updated, but still out-of-date, document.
I think you missed the purpose of the SWEBOK. It is intended to cover basic fundamentals which don't change much decade by decade. Not the latest JavaScript framework or whatever. Just about everything in the previous version from 2014 is still relevant today.
They took 10 years since v3 (over 20 if we count from the start) to include security in their discussions. This is my primary issue with the text: It should be a living document.
Choosing a dead document or "mostly dead" if we're generous (with a new version every decade) for a body of knowledge that is constantly growing and developing makes no sense. If you want to publish it as a PDF that's ok, but it needs continuous updates, not decadal updates.
In 2014 Agile barely got a passing mention in the book, 13 years after the term had come into existence and a decade after it had already made major waves in software engineering (many of the concepts that fell under Agile were also already published in the 1990s or earlier and barely mentioned or not mentioned). OOP gets a more substantive section in the 2024 version than the 2014 version when OOP languages had been out for decades before the 2014 one was published. In their added chapter on security they don't even have references for any of section 6.
All of these are things that can be addressed by making it a living document. Update it more regularly so it's actually relevant instead of catching up on ideas from 2009 in 2024 (DevOps as a term dates at least back that far) or ideas from the 1960s and 1970s (OOP) in 2024.
Practitioners are better off reading Wikipedia than this document. It's more comprehensive, more up to date, and has more references they can use to follow up on topics than this book does.
> Choosing a dead document or "mostly dead" if we're generous for a body of knowledge that is constantly growing and developing makes no sense.
As the document says, it is _not_ the body of knowledge. It is a guide to the body of knowledge. The body of knowledge exists elsewhere, in the published literature.
That's not actually any better, it's worse. A guide that's not updated for 5-10 years means that it's missing 5-10 years of material and newer references. Plus, as a guide it still fails, numerous sections are missing any references to follow, that is: It is a guide that often points you nowhere.
As I pointed out before: It took over 20 years for them to add a section on security. That was a critical issue when it first came out, an even bigger issue in the 2010s when v3 came out, and they only now got around to it. And that chapter lacks references for an entire section. That is not a good guide.
Make it a living document and keep it continuously updated with either expanded or deepened coverage, kept up to date with what's been learned in the industry. Then it will be useful. Otherwise, just go to Wikipedia and you'll get a better resource.
I don’t think anyone mentioned JavaScript frameworks. Yes everything is perpetually relevant if it is made generic enough, but it is harder to be actionable and truly useful.
https://www.computer.org/education/bodies-of-knowledge/softw... - shows a comparison of the TOCs of version 3 (2014) and version 4 (2024). Dates emphasized for my point, it's a decade apart. In 10 years they added 3 chapters and references to DevOps and Agile.
