4 ms·

I've heard it's the computer science equivalent of a plumber or janitor. The job doesn't sound particularly fun, but because of this it's high demand and great

I've heard it's the computer science equivalent of a plumber or janitor. The job doesn't sound particularly fun, but because of this it's high demand and great pay. It's a good job if you accept that work isn't fun, and you don't care about climbing the ladder, you're just looking for a decent, reliable income.

nescioquid 6y ago
An alarming amount of software development, especially now, is little more than plugging part A into part B. The major trend of software development has been to increase the degree of similarity between software developers and plumbers.
- cle 6y ago
  That kind of reductionist argument can be made for any kind of software development...we're all just plumbing bits around at the end of the day. If you're a web dev, you're plugging web tech, if you're a backend dev it's network protocols and storage tech, if you're a kernel dev it's instruction sets and memory buffers. As we build tools to make that plumbing easier for certain use cases, we might move around in the hierarchy to plug different things together, but I don't think anything has fundamentally changed in an alarming way. We're still just moving bits around!
  - nescioquid 6y ago
    Of course, you're absolutely right in your reductive view, but it is not what I was trying to suggest. I remember an explanation that Sussman gave for why MIT retired the SICP course, replacing with it a course in which students program robots with Python. He said (and I'm badly paraphrasing) that one used to be able to scale up your reasoning about how a piece of software works in a similar way to how you do it when looking at a circuit diagram: you have these little components with discrete behaviors and you can simply combine them and be able to predict the result. Today, however, as programmers (to a greater extent than before) we create systems by cobbling together large, opaque, libraries whose properties are poorly described and require one to essentially "do science" on those black boxes. And the trade-off is that we're often better off plugging A into B, and hence there's a lot more of that sort of line work in industry. edit: I should say that I don't much like that sort of work, but it was unwarranted to say it is 'alarming' that the trend has gone this way.
- skulk 6y ago
  So if you're a plumber and you're looking at two parts that don't connect but need to, you're pretty much SOL; you can't fabricate an adapter on the spot. Now, if you're a software engineer and you find yourself in a similar situation, you're expected to "fabricate the adapter." This is why the plumber analogy is fundamentally flawed.
  - swirepe 6y ago
    >So if you're a plumber and you're looking at two parts that don't connect but need to then you force it together with whatever you have at hand, and wrap it all in a thick layer of duct tape. That's exactly like software engineering.
mywittyname 6y ago
It's not a particularly well-paying or common job. I live an area with a large number of insurance companies and banking HQs, so COBOL jobs are a little more common than most of the US. Most job postings are for contractors paying mid-30s to lower 40s per hour, with a handful in the 50s. That's an okay salary in absolute terms, but it's not a great one for a software engineering position. Even in a fly-over state. But taking that job is basically career suicide. After 3-5 years of doing that, you'll be completely unemployable outside of insurance unless you spend time on your own learning useful skills. And if you do that, you're probably starting back down in a junior or mid-level role. Anyone would be much better off getting an AWS cert and learning to write SQL.

nescioquid 6y ago

An alarming amount of software development, especially now, is little more than plugging part A into part B. The major trend of software development has been to increase the degree of similarity between software developers and plumbers.

cle 6y ago
That kind of reductionist argument can be made for any kind of software development...we're all just plumbing bits around at the end of the day. If you're a web dev, you're plugging web tech, if you're a backend dev it's network protocols and storage tech, if you're a kernel dev it's instruction sets and memory buffers. As we build tools to make that plumbing easier for certain use cases, we might move around in the hierarchy to plug different things together, but I don't think anything has fundamentally changed in an alarming way. We're still just moving bits around!
- nescioquid 6y ago
  Of course, you're absolutely right in your reductive view, but it is not what I was trying to suggest. I remember an explanation that Sussman gave for why MIT retired the SICP course, replacing with it a course in which students program robots with Python. He said (and I'm badly paraphrasing) that one used to be able to scale up your reasoning about how a piece of software works in a similar way to how you do it when looking at a circuit diagram: you have these little components with discrete behaviors and you can simply combine them and be able to predict the result. Today, however, as programmers (to a greater extent than before) we create systems by cobbling together large, opaque, libraries whose properties are poorly described and require one to essentially "do science" on those black boxes. And the trade-off is that we're often better off plugging A into B, and hence there's a lot more of that sort of line work in industry. edit: I should say that I don't much like that sort of work, but it was unwarranted to say it is 'alarming' that the trend has gone this way.
skulk 6y ago
So if you're a plumber and you're looking at two parts that don't connect but need to, you're pretty much SOL; you can't fabricate an adapter on the spot. Now, if you're a software engineer and you find yourself in a similar situation, you're expected to "fabricate the adapter." This is why the plumber analogy is fundamentally flawed.
- swirepe 6y ago
  >So if you're a plumber and you're looking at two parts that don't connect but need to then you force it together with whatever you have at hand, and wrap it all in a thick layer of duct tape. That's exactly like software engineering.

mywittyname 6y ago

It's not a particularly well-paying or common job. I live an area with a large number of insurance companies and banking HQs, so COBOL jobs are a little more common than most of the US. Most job postings are for contractors paying mid-30s to lower 40s per hour, with a handful in the 50s. That's an okay salary in absolute terms, but it's not a great one for a software engineering position. Even in a fly-over state. But taking that job is basically career suicide. After 3-5 years of doing that, you'll be completely unemployable outside of insurance unless you spend time on your own learning useful skills. And if you do that, you're probably starting back down in a junior or mid-level role. Anyone would be much better off getting an AWS cert and learning to write SQL.