3 ms·

It's basically a trope on this site for everyone to imply that everyone who doesn't have their fingers in code 8+ hours a day has a so-called "bullshit job," as

It's basically a trope on this site for everyone to imply that everyone who doesn't have their fingers in code 8+ hours a day has a so-called "bullshit job," as if developers don't work for businesses which have to earn money, so forgive my skepticism. And yes . . . I do code.

rramadass 3y ago
You have missed the point. It has nothing to do with coding but everything to do with adding tangible value towards achieving an Objective Goal (Business/Technology/whatever). Hence the Problem Domain and technologies used in the Solution Domain are what matter and everything else is ancillary. The Processes/Methodologies used are only useful in as much as they help us understand the problem domain better and map it to a specific solution. Thus the application of the former is informed by knowledge of the latter and cannot exist by itself. Hence the reason we have so many types/variations of Processes/Methodologies; there are some common principles but will always need to be adapted/customized to the problem and tools at hand. This is what is the problem with modern-day Management/Leadership and eloquently pointed out by David Graeber(Bullshit Jobs - https://en.wikipedia.org/wiki/Bullshit_Jobs https://en.wikipedia.org/wiki/Bullshit_Jobs) and Jeffrey Pfeffer(Leadership BS - https://jeffreypfeffer.com/books/leadership-bs-fixing-workplaces-and-careers-one-truth-at-a-time/ https://jeffreypfeffer.com/books/leadership-bs-fixing-workpl...). I highly recommend reading this speech by David Packard (one of the founders of Silicon Valley via HP) to new Managers given in 1960 and note how relevant it is for all companies today - https://gizmodo.com/the-hp-way-how-bill-hewlett-and-i-built-our-company-5634378 https://gizmodo.com/the-hp-way-how-bill-hewlett-and-i-built-... Relevant Excerpt: Over the years we have developed the policy that it is important for the supervisor to thoroughly know and understand the work of his group. A debate on this has been carried on by management people for years. Some say you can be a good manager without having the slightest idea of what you are trying to manage, that the techniques of management are all important. There are many organizations which work that way. I don't argue that the job can't be done that way but I do argue strongly that the best job can be done when the manager or supervisor has a real and genuine understanding of his group's work. I don't see how a person can even understand what proper standards are and what performance is required unless he does understand in some detail the very specific nature of the work he is trying to supervise. We have held closely to this philosophy and we intend to continue to do so. We expect you who are supervising to learn techniques of supervision and keep up to date. I want to emphasize you can supervise best when you know a great deal about the work you are supervising and when you know the techniques of supervision as well.
- theshrike79 3y ago
  There is a difference between "understanding the work" and "knowing how to do the work". I've had multiple Producers who "understand the work" of creating mobile games as a whole and understand how the team needs to work and interact to produce a result on time. None of them could code a mobile game to save their life. What your example is talking is a situation where a fresh off the press MBA is shoved in to a very specific field and they start just doing pure numbers and Excel management out of a management book without knowing how that specific industry operates. Managing a team of deep-sea welders is VERY different from managing a software team, which is again different from managing a team of people building a physical machine.
  - rramadass 3y ago
    >There is a difference between "understanding the work" and "knowing how to do the work". True. However, the relationship between them need not be a "Total Function" but definitely needs to be a "Partial Function" to a certain degree. You cannot be completely divorced from the "How" and hope to have a good "understanding" of the system. >Managing a team of deep-sea welders is VERY different from managing a software team, which is again different from managing a team of people building a physical machine. This is precisely the point; domain/technical knowledge is needed to effectively Manage a project. This is independent of knowledge of techniques of Management. The problem today is that entire industries have been created out of thin air which posit that the latter is sufficient if one follows a certain process/methodology which is patently absurd.
- CRConrad 3y ago
  > You have missed the point. No, I think at least in large part, you missed the point. > It has nothing to do with coding but everything to do with adding tangible value towards achieving an Objective Goal (Business/Technology/whatever). As I understood _Bullshit Jobs,_ "adding tangible value" to some business that doesn't actually add anything of actual (non-monetary) value to the world is bullshit. There are whole industries that make billions of dollars, but everyone who works in them is still doing a bullshit job. (I often think I do.)

rramadass 3y ago

You have missed the point. It has nothing to do with coding but everything to do with adding tangible value towards achieving an Objective Goal (Business/Technology/whatever). Hence the Problem Domain and technologies used in the Solution Domain are what matter and everything else is ancillary. The Processes/Methodologies used are only useful in as much as they help us understand the problem domain better and map it to a specific solution. Thus the application of the former is informed by knowledge of the latter and cannot exist by itself. Hence the reason we have so many types/variations of Processes/Methodologies; there are some common principles but will always need to be adapted/customized to the problem and tools at hand. This is what is the problem with modern-day Management/Leadership and eloquently pointed out by David Graeber(Bullshit Jobs - https://en.wikipedia.org/wiki/Bullshit_Jobs https://en.wikipedia.org/wiki/Bullshit_Jobs) and Jeffrey Pfeffer(Leadership BS - https://jeffreypfeffer.com/books/leadership-bs-fixing-workplaces-and-careers-one-truth-at-a-time/ https://jeffreypfeffer.com/books/leadership-bs-fixing-workpl...). I highly recommend reading this speech by David Packard (one of the founders of Silicon Valley via HP) to new Managers given in 1960 and note how relevant it is for all companies today - https://gizmodo.com/the-hp-way-how-bill-hewlett-and-i-built-our-company-5634378 https://gizmodo.com/the-hp-way-how-bill-hewlett-and-i-built-... Relevant Excerpt: Over the years we have developed the policy that it is important for the supervisor to thoroughly know and understand the work of his group. A debate on this has been carried on by management people for years. Some say you can be a good manager without having the slightest idea of what you are trying to manage, that the techniques of management are all important. There are many organizations which work that way. I don't argue that the job can't be done that way but I do argue strongly that the best job can be done when the manager or supervisor has a real and genuine understanding of his group's work. I don't see how a person can even understand what proper standards are and what performance is required unless he does understand in some detail the very specific nature of the work he is trying to supervise. We have held closely to this philosophy and we intend to continue to do so. We expect you who are supervising to learn techniques of supervision and keep up to date. I want to emphasize you can supervise best when you know a great deal about the work you are supervising and when you know the techniques of supervision as well.

theshrike79 3y ago
There is a difference between "understanding the work" and "knowing how to do the work". I've had multiple Producers who "understand the work" of creating mobile games as a whole and understand how the team needs to work and interact to produce a result on time. None of them could code a mobile game to save their life. What your example is talking is a situation where a fresh off the press MBA is shoved in to a very specific field and they start just doing pure numbers and Excel management out of a management book without knowing how that specific industry operates. Managing a team of deep-sea welders is VERY different from managing a software team, which is again different from managing a team of people building a physical machine.
- rramadass 3y ago
  >There is a difference between "understanding the work" and "knowing how to do the work". True. However, the relationship between them need not be a "Total Function" but definitely needs to be a "Partial Function" to a certain degree. You cannot be completely divorced from the "How" and hope to have a good "understanding" of the system. >Managing a team of deep-sea welders is VERY different from managing a software team, which is again different from managing a team of people building a physical machine. This is precisely the point; domain/technical knowledge is needed to effectively Manage a project. This is independent of knowledge of techniques of Management. The problem today is that entire industries have been created out of thin air which posit that the latter is sufficient if one follows a certain process/methodology which is patently absurd.
CRConrad 3y ago
> You have missed the point. No, I think at least in large part, you missed the point. > It has nothing to do with coding but everything to do with adding tangible value towards achieving an Objective Goal (Business/Technology/whatever). As I understood _Bullshit Jobs,_ "adding tangible value" to some business that doesn't actually add anything of actual (non-monetary) value to the world is bullshit. There are whole industries that make billions of dollars, but everyone who works in them is still doing a bullshit job. (I often think I do.)