Pretty archaic. It stops just after version control, code builds and testing. Nothing on devops - deployments, kebernetes, containers, monitoring, release management, environments (prod, non-prod) etc. All this should be part of "development tooling".
It seems to be an introduction, so just covering the basics is ok. We're still very close to the IT stone age and the IT industry is still quite archaic, so teaching archaic basics isn't that bad. In a lot of areas it's still best to just write your own tools from scratch...
You're not really a professional in 2025 if you do not approach development with a devops mentality, with due consideration given to concerns like deployment, scaling, and observability.
i've been in the industry long enough to know that the devops promise that developers can do operation is essentially fantasy.
i mean don't get me wrong, some statistical outliars certainly can, or they can as long as they outsource a lot of the actual work (look at heroku/vercel and similar platforms). or if they have an infinite budget.
but at the end of the day software development and system administration are two very different skillsets in the practical side of the field of computer science.
particularly nowadays, you'd be surprised how many engineers don't know shit about what's outside their favourite language runtime. i see developers reinventing the wheel almost every month because they're unfamiliar with many of the underlying linux/unix systems capabilities.
> The third, Build, will teach you about how to reliably build your software with Make.
Make? In 25 years as a professional developer I have never encountered make in the enterprise.
At least cover the various generic _models_ behind a few of the modern build tools so students can understand both the commonality and the differences between say NX, NPM, Maven, Gradle, go build etc.
Makefiles are a perfect abstraction over proprietary CI/CD DSLs and commands.
As a polyglot, having to remember and the difference is awful - so I make(ha!) local Makefiles that invoke the relevant tool, the same routine concepts (lint, build, or run tests) may be "yarn foo -arg1", "npx -foo", "go bar" depending on project and tool, which gets annoying when you're frequently switching between projects.
Big tech with monorepos solve this cognitive effort using a unified build system (blaze, buck, buck2). IMHO, Make makes a decent glue system at smaller organizations lacking a compiler/build/tooling team.
...I'd be curious if anyone has went through _both_, unlikely as that may be, and could give some comparison :P
that's not really development, that's operations.
i mean don't get me wrong, some statistical outliars certainly can, or they can as long as they outsource a lot of the actual work (look at heroku/vercel and similar platforms). or if they have an infinite budget.
but at the end of the day software development and system administration are two very different skillsets in the practical side of the field of computer science.
particularly nowadays, you'd be surprised how many engineers don't know shit about what's outside their favourite language runtime. i see developers reinventing the wheel almost every month because they're unfamiliar with many of the underlying linux/unix systems capabilities.
Make? In 25 years as a professional developer I have never encountered make in the enterprise.
At least cover the various generic _models_ behind a few of the modern build tools so students can understand both the commonality and the differences between say NX, NPM, Maven, Gradle, go build etc.
Maybe a class on CI/CD pipelines, too.
I don't want to .. but people keep using it because it's simpler than other build systems.
Many UI tools based on eclipse use make under the hood.
Many recipes used by Yocto just use make to build the software and then install the output somewhere.
It all depends what you're trying to build and where you work.
It notionally focuses on make but the concepts apply much more broadly than the one specific tool
As a polyglot, having to remember and the difference is awful - so I make(ha!) local Makefiles that invoke the relevant tool, the same routine concepts (lint, build, or run tests) may be "yarn foo -arg1", "npx -foo", "go bar" depending on project and tool, which gets annoying when you're frequently switching between projects.
Big tech with monorepos solve this cognitive effort using a unified build system (blaze, buck, buck2). IMHO, Make makes a decent glue system at smaller organizations lacking a compiler/build/tooling team.