4 ms·

Introduction to Software Development Tooling (2024)

123 points by vismit2000 10mo ago

tempest_ 10mo ago
Not enough yaml in the schedule
- tekknolagi 10mo ago
  The schedule is generated from a Python script, but doesn't involve YAML
azhenley 10mo ago
[flagged]
- dhruv3006 10mo ago
  looks sweet. gonna look into this.
ausbah 10mo ago
man this would’ve been great to take when i was at neu
zkmon 10mo ago
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".
- badatlife 10mo ago
  this is meant for freshman/sophomore cs students i think its a reasonable start
- adornKey 10mo ago
  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...
- znpy 10mo ago
  > All this should be part of "development tooling". that's not really development, that's operations.
  - zkmon 10mo ago
    The article is not about "development". It is about "development tooling".
  - bitwize 10mo ago
    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.
    - znpy 10mo ago
      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.
- deleted 10mo ago
  [deleted]
- tekknolagi 10mo ago
  It's a "teach people how to teach themselves to fish" class
dragochat 10mo ago
obligatory link to the famous very similar resource - MIT's The Missing Semester https://missing.csail.mit.edu/ 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
pards 10mo ago
> 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.
- webdevver 10mo ago
  makefiles and shellscripts are still knocking around in systems programming world, which i think is the world OP comes from
- tekknolagi 10mo ago
  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
- wojciii 10mo ago
  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.
- overfeed 10mo ago
  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.
- ahoka 10mo ago

123 points by vismit2000 10mo ago

tempest_ 10mo ago

Not enough yaml in the schedule

tekknolagi 10mo ago
The schedule is generated from a Python script, but doesn't involve YAML

azhenley 10mo ago

[flagged]

dhruv3006 10mo ago
looks sweet. gonna look into this.

ausbah 10mo ago

man this would’ve been great to take when i was at neu

zkmon 10mo ago

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".

badatlife 10mo ago
this is meant for freshman/sophomore cs students i think its a reasonable start
adornKey 10mo ago
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...
znpy 10mo ago
> All this should be part of "development tooling". that's not really development, that's operations.
- zkmon 10mo ago
  The article is not about "development". It is about "development tooling".
- bitwize 10mo ago
  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.
  - znpy 10mo ago
    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.
deleted 10mo ago
[deleted]
tekknolagi 10mo ago
It's a "teach people how to teach themselves to fish" class

dragochat 10mo ago

obligatory link to the famous very similar resource - MIT's The Missing Semester https://missing.csail.mit.edu/ 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

pards 10mo ago

> 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.

webdevver 10mo ago
makefiles and shellscripts are still knocking around in systems programming world, which i think is the world OP comes from
tekknolagi 10mo ago
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
wojciii 10mo ago
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.
overfeed 10mo ago
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.
ahoka 10mo ago