5 ms·

It's thinkpieces like this that make me believe that IT professionals specifically and white collar workers generally would benefit greatly from a mandatory 24

It's thinkpieces like this that make me believe that IT professionals specifically and white collar workers generally would benefit greatly from a mandatory 24 month stint on a construction crew. One of the most important lessons any job foreman can learn is that every crew needs at least one lame duck. A single talented carpenter with an energetic but otherwise totally unskilled helper can accomplish more in a shift than two talented carpenters together. If you don't have someone to run to the truck for nails, hold shit, move ladders, etc. productivity suffers because your talent is wasting time on menial tasks. Same thing applies to IT departments. The folks the author is busy sneering at are at least as valuable as the engineers they're actively trying to retain because (among other things) they soak menial tasks that would otherwise cut into their rockstar's productivity.

cannonpr 3y ago
Yet I’ve worked in two types of places, the ones that had a lot of menial labourers and thus lots of shuffling of stairs and carrying of nail buckets, and in places that had very few to no menial labourers and just automated away the menial tasks or designed the systems to never need menial labour in the first place. If you want to keep the metaphor some plasterers use ladders, others use stilts. In any case plenty of ways to skin a cat and people adapt to the workforce available to them.
- deleted 3y ago
  [deleted]
iwontberude 3y ago
Fuckin’ A man… fuckin’ A. I actually have no idea what working construction is like, but I imagine it’s hell. I hear about jackhammering causing permanent damage to people’s nerves and all sorts of random accidents.
- forgetfreeman 3y ago
  Having worked extensively in construction and IT (including a couple decades spent writing code) I have to say construction is a much more enjoyable and rewarding career. Pay and benefits are horrible though.
- DiggyJohnson 3y ago
  You get used to it much faster than you probably are imagining. I construction job on a decent project with a decent supe can result in a very satisfying workday.
lolinder 3y ago
This hasn't been my experience—the truly talented developers that I've worked with do more of the foundation tasks than the "salt" developers do. They're the ones who upgrade libraries when it's time, fix Jenkins when something goes wrong, and respond to a page and solve it, on top of the rest of their work. Meanwhile they're also automating the repetitive tasks in order to free up their own time and make it possible for them to move on to other things. Automation is so easy in software development that your analogy to construction becomes pretty weak—we don't need someone moving around ladders because when we realize that's a need we just write a script for it.
- forgetfreeman 3y ago
  I see y'all over there pretending lifers in your average IT department don't routinely make a career bunker out of legacy support among other odious pursuits despite the author explicitly pointing it out. In any case, if the department manager isn't tasking folks at their level of competence to extract maximum utility that's a failure on their part.
quickthrower2 3y ago
Hold on! The construction analogy doesn’t apply because in a lot of code bases, probably most there are very few menial tasks. Some code bases need IQ 120 + to do anything non trivial in and maybe even higher. So there are menial tasks, but menial like “yeah just redraft this architectural drawing for me mate, to take account of the new 2021 fire regs, I got actual brainy stuff to get on with”. Pairing senior and junior devs works. But not because the junior is an idiot, but because they have stuff to learn and raw talent and can figure stiff out. They probably already know how to code well from their passion or maybe bootcamps or interning. Not from university usually unless there is lot of coursework. I am not saying construction workers are idiots. But I am saying the OP article is implying the worst employees are left by this dead sea effect. Are you saying you can absorb untalented people on work sites. In dev teams they slow things down it would be better to pay some of them garden leave.
- 082349872349872 3y ago
  To be specific on the garden leave: "[run to the truck] for some nails" is easy to formulate yet takes effort to do. The majority of the effort for most coding tasks is the formulation, and by the time you've explained to the lame duck how to do what needs to be done, and checked that they actually did it, it would've been easier to have done it yourself. (were one to have suitable lame duck tasks, how would wetware lame ducks compete in an LLM world?)
  - economicalidea 3y ago
    This is where working at an actual construction site would be a good experience for you — or any developer really. Run to the truck and get nails also requires explanation/experience to get right if you have never done it before — what nails?which truck?how many?etc. It is completely the same thing. The first time around you might have to explain the menial tasks in detail - btw a good exercise anyway, since you need to be able to explain aka understand the task anyway, after all you need to review later. And the first time around there will be some mistakes or misunderstandings. But it gets better over time. With everyone.
ildjarn 3y ago
Given that software has reuse and abstractions, we should all be embarrassed that there are any menial tasks at all.
- lostlogin 3y ago
  A short stint on a Helpdesk will remove any illusion that menial tasks will ever be solved by machines. The users are actually amazing and seeing what happens is awe inspiring - in a bad way.
  - ildjarn 3y ago
    I’m talking about in the technology function building systems.
caseymarquis 3y ago
I grew up working construction on the side with my father, became an appprentice lineman, moved to aftermarket electrical installations in CNC machines, then ended up writing software products for over a decade. I've worked on a wide variety of software: Embedded projects requiring 2000 line assembly ISRs for legacy RS232 protocols, reverse engineering binary network protocols, implementing network server protocols from specifications, writing my own actor and dependency injection frameworks in managed languages, web application backend work, frontend work with JavaScript/TypeScript and frameworks, and so on. I also do a lot of product management, support, customer management, and internal management. Much of my customer support involves teaching external developers from large corporations how to use HTTP and SDKs. I'm usually one of the smarter people in the room when doing software development and spend a lot of time helping others. In construction, I'm the enthusiastic idiot as the skillset is different. Most tech workers underestimate how high skilled tradework and many other positions outside their experience are, especially management work. Having said all that, I feel uniquely qualified to offer a rebuttal. The article is describing a clear pattern that I see at large companies that are not focused on software development or lack solid engineering leadership. Ironically, the problem gets worse the more a company tries to outsource IT as they face all the same challenges with less control. It is an organizational health issue however, not some universal truth. If tech workers lack anything, it's experience with organizational growth, change, and group dynamics, not construction experience. Organizations are like people, they grow, change, figure out who they are, have identity crises and need different things in different phases. Ask the highest level/most competent manager you have access to for book recommendations if you're interested in this. Anyway, back on topic, software "gruntwork" typically implies a department lacks the agency to automate away said gruntwork or lacks the skills to do so. As an example, I work with many organizations using the JVM, but none of them use Scala, Kotlin, Clojure, or any other "nice" JVM language. They use Java. In some cases Java 8. If you're writing Java, there is absolutely stupid gruntwork. I've written example applications for some of these organizations and I had to create code generation tools to stay sane in this environment. In software, you eliminate stupid gruntwork with tools, not people. We do need average enthusiasts in software development, but it's not the same as construction. In construction the less talented person fetches things and does setup work. In software development, the less talented workers spend most of their time using libraries, plugins, frameworks, compilers, interpreters, databases, and languages while the more talented workers write them. My experience isn't universal, and I'd be interested in hearing some dissenting opinions on this.
rjsw 3y ago
I have spent all week exchanging emails with the "lame duck" in my ISP's accounts department. The task involved should be menial, just copy the bank account name from my email into a form, they are incapable of getting this right.
p_l 3y ago
Brooks described the Surgical Team methodology, where one senior tackled the most complex tasks including design, the next senior people were helping with complex tasks and essentially "apprenticing" - with expectation that they will move on to become most senior person on a new team - plus a group of junior programmers took care of the simple "toil", while a group of supports (technical writers for documentation, tool makers, etc) together provided necessary cross-cutting skills. This was modeled in the essay after "surgical team", with the most senior programmer being the "head surgeon" leading the operation, his direct assistants who could have major tasks delegated, and the juniors who could take on simple but still important tasks. (anaesthesiologist would probably be example of the cross-cutting support task)
BerislavLopac 3y ago
> A single talented carpenter with an energetic but otherwise totally unskilled > helper can accomplish more in a shift than two talented carpenters together. > If you don't have someone to run to the truck for nails, hold shit, move > ladders, etc. productivity suffers because your talent is wasting time on > menial tasks. But you are mistaken -- each of us (the software engineers) already has numerous helpers who fit this description perfectly. The only difference is that we don't call them "apprentices" -- we call them compilers, interpreters, build tools and the like. Probably the only term that is commonly used on both types of helpers is "git". Joking aside -- if you find yourself and your team spending too much time on menial tasks, you need to focus more on automating them. Of course, how much can be automated depends on how much hardware is involved in your work; as long as we're in software world, pretty much anything can be automated.
- moritzwarhier 3y ago
  Maybe the "untalented" colleague is the solution to the marginal cost problem of automation in IT! E.g. they won't do anything productive until CI and dev setup are "idiot-proof" - which is a feature! Noone wants to need arcane, private knowledge about how to fix that one problem with that one container in dev.
- TeMPOraL 3y ago
  Alright, so how can I automate away daily standups, timecards, semi-regular random corporate/legal paperwork, and everything about dealing with devops team?
  - BerislavLopac 3y ago
    You can't -- but that's not menial work.
    - TeMPOraL 3y ago
      To me, it is, and/or it generates an infinite stream of one/off unique menial work.
quickthrowman 3y ago
> A single talented carpenter with an energetic but otherwise totally unskilled helper can accomplish more in a shift than two talented carpenters together. I manage electricians, and this is highly dependent on the task. In most cases I’d rather send two JWs vs a JW and apprentice. I’d send two JW to pipe a new feeder, but I’d send an apprentice and JW if they’re just pulling wire and the pipe is installed already. An apprentice can easily feed wire while the JW pulls, but a JW is going to be much better at piping than an apprentice.
moritzwarhier 3y ago
This sounds intriguing, if it is true, there should be a name for this kind of observation / org law
Terr_ 3y ago
> as valuable as I'd like to preemptively emphasize the distinction between "important to have" versus "marginal price to acquire", before folks start talking past one-another with different interpretations of "valuable."

cannonpr 3y ago

Yet I’ve worked in two types of places, the ones that had a lot of menial labourers and thus lots of shuffling of stairs and carrying of nail buckets, and in places that had very few to no menial labourers and just automated away the menial tasks or designed the systems to never need menial labour in the first place. If you want to keep the metaphor some plasterers use ladders, others use stilts. In any case plenty of ways to skin a cat and people adapt to the workforce available to them.

deleted 3y ago
[deleted]

iwontberude 3y ago

Fuckin’ A man… fuckin’ A. I actually have no idea what working construction is like, but I imagine it’s hell. I hear about jackhammering causing permanent damage to people’s nerves and all sorts of random accidents.

forgetfreeman 3y ago
Having worked extensively in construction and IT (including a couple decades spent writing code) I have to say construction is a much more enjoyable and rewarding career. Pay and benefits are horrible though.
DiggyJohnson 3y ago
You get used to it much faster than you probably are imagining. I construction job on a decent project with a decent supe can result in a very satisfying workday.

lolinder 3y ago

This hasn't been my experience—the truly talented developers that I've worked with do more of the foundation tasks than the "salt" developers do. They're the ones who upgrade libraries when it's time, fix Jenkins when something goes wrong, and respond to a page and solve it, on top of the rest of their work. Meanwhile they're also automating the repetitive tasks in order to free up their own time and make it possible for them to move on to other things. Automation is so easy in software development that your analogy to construction becomes pretty weak—we don't need someone moving around ladders because when we realize that's a need we just write a script for it.

forgetfreeman 3y ago
I see y'all over there pretending lifers in your average IT department don't routinely make a career bunker out of legacy support among other odious pursuits despite the author explicitly pointing it out. In any case, if the department manager isn't tasking folks at their level of competence to extract maximum utility that's a failure on their part.

quickthrower2 3y ago

Hold on! The construction analogy doesn’t apply because in a lot of code bases, probably most there are very few menial tasks. Some code bases need IQ 120 + to do anything non trivial in and maybe even higher. So there are menial tasks, but menial like “yeah just redraft this architectural drawing for me mate, to take account of the new 2021 fire regs, I got actual brainy stuff to get on with”. Pairing senior and junior devs works. But not because the junior is an idiot, but because they have stuff to learn and raw talent and can figure stiff out. They probably already know how to code well from their passion or maybe bootcamps or interning. Not from university usually unless there is lot of coursework. I am not saying construction workers are idiots. But I am saying the OP article is implying the worst employees are left by this dead sea effect. Are you saying you can absorb untalented people on work sites. In dev teams they slow things down it would be better to pay some of them garden leave.

082349872349872 3y ago
To be specific on the garden leave: "[run to the truck] for some nails" is easy to formulate yet takes effort to do. The majority of the effort for most coding tasks is the formulation, and by the time you've explained to the lame duck how to do what needs to be done, and checked that they actually did it, it would've been easier to have done it yourself. (were one to have suitable lame duck tasks, how would wetware lame ducks compete in an LLM world?)
- economicalidea 3y ago
  This is where working at an actual construction site would be a good experience for you — or any developer really. Run to the truck and get nails also requires explanation/experience to get right if you have never done it before — what nails?which truck?how many?etc. It is completely the same thing. The first time around you might have to explain the menial tasks in detail - btw a good exercise anyway, since you need to be able to explain aka understand the task anyway, after all you need to review later. And the first time around there will be some mistakes or misunderstandings. But it gets better over time. With everyone.

ildjarn 3y ago

Given that software has reuse and abstractions, we should all be embarrassed that there are any menial tasks at all.

lostlogin 3y ago
A short stint on a Helpdesk will remove any illusion that menial tasks will ever be solved by machines. The users are actually amazing and seeing what happens is awe inspiring - in a bad way.
- ildjarn 3y ago
  I’m talking about in the technology function building systems.

caseymarquis 3y ago

I grew up working construction on the side with my father, became an appprentice lineman, moved to aftermarket electrical installations in CNC machines, then ended up writing software products for over a decade. I've worked on a wide variety of software: Embedded projects requiring 2000 line assembly ISRs for legacy RS232 protocols, reverse engineering binary network protocols, implementing network server protocols from specifications, writing my own actor and dependency injection frameworks in managed languages, web application backend work, frontend work with JavaScript/TypeScript and frameworks, and so on. I also do a lot of product management, support, customer management, and internal management. Much of my customer support involves teaching external developers from large corporations how to use HTTP and SDKs. I'm usually one of the smarter people in the room when doing software development and spend a lot of time helping others. In construction, I'm the enthusiastic idiot as the skillset is different. Most tech workers underestimate how high skilled tradework and many other positions outside their experience are, especially management work. Having said all that, I feel uniquely qualified to offer a rebuttal. The article is describing a clear pattern that I see at large companies that are not focused on software development or lack solid engineering leadership. Ironically, the problem gets worse the more a company tries to outsource IT as they face all the same challenges with less control. It is an organizational health issue however, not some universal truth. If tech workers lack anything, it's experience with organizational growth, change, and group dynamics, not construction experience. Organizations are like people, they grow, change, figure out who they are, have identity crises and need different things in different phases. Ask the highest level/most competent manager you have access to for book recommendations if you're interested in this. Anyway, back on topic, software "gruntwork" typically implies a department lacks the agency to automate away said gruntwork or lacks the skills to do so. As an example, I work with many organizations using the JVM, but none of them use Scala, Kotlin, Clojure, or any other "nice" JVM language. They use Java. In some cases Java 8. If you're writing Java, there is absolutely stupid gruntwork. I've written example applications for some of these organizations and I had to create code generation tools to stay sane in this environment. In software, you eliminate stupid gruntwork with tools, not people. We do need average enthusiasts in software development, but it's not the same as construction. In construction the less talented person fetches things and does setup work. In software development, the less talented workers spend most of their time using libraries, plugins, frameworks, compilers, interpreters, databases, and languages while the more talented workers write them. My experience isn't universal, and I'd be interested in hearing some dissenting opinions on this.

rjsw 3y ago

I have spent all week exchanging emails with the "lame duck" in my ISP's accounts department. The task involved should be menial, just copy the bank account name from my email into a form, they are incapable of getting this right.

p_l 3y ago

Brooks described the Surgical Team methodology, where one senior tackled the most complex tasks including design, the next senior people were helping with complex tasks and essentially "apprenticing" - with expectation that they will move on to become most senior person on a new team - plus a group of junior programmers took care of the simple "toil", while a group of supports (technical writers for documentation, tool makers, etc) together provided necessary cross-cutting skills. This was modeled in the essay after "surgical team", with the most senior programmer being the "head surgeon" leading the operation, his direct assistants who could have major tasks delegated, and the juniors who could take on simple but still important tasks. (anaesthesiologist would probably be example of the cross-cutting support task)

BerislavLopac 3y ago

> A single talented carpenter with an energetic but otherwise totally unskilled > helper can accomplish more in a shift than two talented carpenters together. > If you don't have someone to run to the truck for nails, hold shit, move > ladders, etc. productivity suffers because your talent is wasting time on > menial tasks. But you are mistaken -- each of us (the software engineers) already has numerous helpers who fit this description perfectly. The only difference is that we don't call them "apprentices" -- we call them compilers, interpreters, build tools and the like. Probably the only term that is commonly used on both types of helpers is "git". Joking aside -- if you find yourself and your team spending too much time on menial tasks, you need to focus more on automating them. Of course, how much can be automated depends on how much hardware is involved in your work; as long as we're in software world, pretty much anything can be automated.

moritzwarhier 3y ago
Maybe the "untalented" colleague is the solution to the marginal cost problem of automation in IT! E.g. they won't do anything productive until CI and dev setup are "idiot-proof" - which is a feature! Noone wants to need arcane, private knowledge about how to fix that one problem with that one container in dev.
TeMPOraL 3y ago
Alright, so how can I automate away daily standups, timecards, semi-regular random corporate/legal paperwork, and everything about dealing with devops team?
- BerislavLopac 3y ago
  You can't -- but that's not menial work.
  - TeMPOraL 3y ago
    To me, it is, and/or it generates an infinite stream of one/off unique menial work.

quickthrowman 3y ago

> A single talented carpenter with an energetic but otherwise totally unskilled helper can accomplish more in a shift than two talented carpenters together. I manage electricians, and this is highly dependent on the task. In most cases I’d rather send two JWs vs a JW and apprentice. I’d send two JW to pipe a new feeder, but I’d send an apprentice and JW if they’re just pulling wire and the pipe is installed already. An apprentice can easily feed wire while the JW pulls, but a JW is going to be much better at piping than an apprentice.

moritzwarhier 3y ago

This sounds intriguing, if it is true, there should be a name for this kind of observation / org law

Terr_ 3y ago

> as valuable as I'd like to preemptively emphasize the distinction between "important to have" versus "marginal price to acquire", before folks start talking past one-another with different interpretations of "valuable."