> 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.
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.
obligatory link to the famous very similar resource - MIT's The Missing Semester https://missing.csail.mit.edu/
...I'd be curious if anyone has went through _both_, unlikely as that may be, and could give some comparison :P
Not enough yaml in the schedule
The schedule is generated from a Python script, but doesn't involve YAML
[flagged]
looks sweet. gonna look into this.
man this would’ve been great to take when i was at neu
> 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.
Maybe a class on CI/CD pipelines, too.
I develop embedded software. I use make all the time.
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.
You'll never guess what we talk about later on in the unit. Spoiler: exactly that!
It notionally focuses on make but the concepts apply much more broadly than the one specific tool
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.
makefiles and shellscripts are still knocking around in systems programming world, which i think is the world OP comes from
Indeed. CMake is now the gold standard for C/C++ projects. It should be taught especially in an introductory class.
I did, but so what? But make IS the generic model and no one should invent any kind of build system without understanding make first.
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...
> All this should be part of "development tooling".
that's not really development, that's operations.
The article is not about "development". It is about "development tooling".
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.
It's a "teach people how to teach themselves to fish" class
this is meant for freshman/sophomore cs students i think its a reasonable start