9 ms·

What you're saying is important for everyone to internalize. I'll spin it like this: Your job satisfaction/pay are a function of your impact. Your impact is a

What you're saying is important for everyone to internalize. I'll spin it like this: Your job satisfaction/pay are a function of your impact. Your impact is a function of your leverage. If you're a "pure coder" who doesn't have any of the other skills you mentioned, your output is incredibly limited. At best, you produce a day's worth of code in a day, but you also require someone to manage you closely to make sure you code the right stuff. The more of these other skills you have, the more you can (a) work independently (b) make others more productive and (c) make sure your team/business is doing the right things and (d) drive overall efficiency. The more of these things you do, you become orders of magnitude more impactful than a pure coder.

KineticLensman 6y ago
Agree. One of the most important skills is the one he describes like this: >> The more specialized your work, the greater the risk that you will communicate in ways that are incomprehensible to the uninitiated. In my experience (35 years), this isn't just about knowing the right way to describe things, it's also understanding what things to concentrate on when communicating, and what to ignore. If you are a tech person communicating with a decision maker, they are typically looking to understand options and their implications and risks, not the details of how the options work. They can then decide, based on their (presumably) better knowledge of the wider context, which options to select. If the decision makers are genuinely intelligent and motivated, but their eyes glaze over when you describe something, chances are you have chosen the wrong things to communicate to them.
- xyzelement 6y ago
  Yup. I agree with you (and your pragmatic approach to helping the raptors!)
  - KineticLensman 6y ago
    Thank you! (Actually the raptor conservancy [0] is interesting from this perspective as well. I'm a newbie / junior in that context, but I can see standard employee patterns that I recognise from the tech industry, e.g. in terms of people who know to report and / or delegate well, or to make effective decisions vs. be indecisive. Perhaps I'll have to see if I can document my observations on what I've learned in my career). [o] https://news.ycombinator.com/item?id=25650535 https://news.ycombinator.com/item?id=25650535
- Dirlewanger 6y ago
  Very well said. It's stuff like this that makes me think all CS majors need some sort of business communications requirement, something to at least give a foundation on how to speak to decision makers.
  - yowlingcat 6y ago
    Good business communication is something you only learn by /doing/ it. Expecting a course to facilitate that is flawed. I'd be all for increasing the roles of internships in CS education in order to accomplish that -- and I have noticed that's begun to happen as well. CS majors these days have internships lined for summer and winter if not more (especially due to COVID). I am sure they'll learn a lot more than I did during that era of my life just by sheer osmosis.
    - Kevguy 6y ago
      If it is a good course on business communication they _should_ be doing it - in class. And getting feedback and suggestions on improving with every attempt. Internships are a wonderful thing but many people don't realize how they are coming across so don't look to improve. There is some learning by osmosis, but mostly people keep doing what they have always done because it works (as far as they can tell).
      - yowlingcat 6y ago
        > they _should_ be doing it - in class They won't be doing it, they will be doing a simulation of it. How are they going to learn business communication without doing it in the context of a real business with a real P/L line and real consequences for good and bad execution?
one2know 6y ago
Found the manager. This is just more developer hate drivel. Yes, if you think managers are more valuable, then obviously you are going to say engineering work is "incredibly limited" and manager activities are "orders of magnitude more impactful" Listen, no amount of ass kissing and brown nosing is going to solve actual tech problems.
- macintux 6y ago
  This tone is unwelcome on HN, which is probably why your previous comments have often been downvoted and flagged.
  - one2know 6y ago
    Bashing and shit talking software engineering profession is welcome on HN?
    - macintux 6y ago
      Let me paraphrase the original comment to make my next question easier to answer: Effective software engineering in a business context requires awareness of business needs. Which part of that is “bashing and shit talking”?
      - mcguire 6y ago
        How about, Effective software engineering in a business context requires awareness of business needs as well as the technical skills to address those needs.
        xyzelement 6y ago
        Nobody would argue with this.
- deleted 6y ago
  [deleted]
- deleted 6y ago
draw_down 6y ago
It’s ok to just produce a days worth of code in a day. This is not a failure mode or something to be avoided. It’s ok to just work a job. Not everyone is focused on “impact” and all that junk, and nor does everyone need to be.
closeparen 6y ago
This is the party line. It misses that “a day’s worth of code” is highly unequal across individuals. The people whose “day’s worth of code” are most valuable, quickly get pulled off of spending their days that way. It appears that they key skill is coordinating a lot of developers, because the ones left developing are the ones you need a lot of (and who need close supervision) to get anything done. Managers will never rock this boat, because their career KPI is the number of people they manage.
- astrange 6y ago
  That means you have bad middle/upper management. Large tech companies have heard of the Peter Principle and don't promote this way; they have separate technical tracks. Which is not to say they're doing everything right.
  - wolco2 6y ago
    Having a tech track is the right direction. Having no track even better. Some people like what they are doing and the field is constantly changing. You want your best surgeons doing operations not managing other doctors.
    - astrange 6y ago
      I think that would encourage not getting raises. You need some kind of title so people can feel responsible for career growth and so you can calibrate against other companies' pay at least; it doesn't need to control what kind of work you're allowed to do.
      - ghaff 6y ago
        Even if they don't transition to managing people, someone in an individual contributor role presumably needs to be growing in some way if they want to get raises. While someone doing something valuable even without growing will probably continue to get small raises anyway, it's not the ideal path. And, as you say, to the degree that position titles mean something cross-company, it gives a point of comparison.
that_guy_iain 6y ago
> If you're a "pure coder" who doesn't have any of the other skills you mentioned, your output is incredibly limited. At best, you produce a day's worth of code in a day, but you also require someone to manage you closely to make sure you code the right stuff. This seems to miss the point of teams. Everyone should have a role if you hire someone as a software engineer and they spend all their time doing devops because they like it more you've made a bad hire. If all your engineers are having product meetings with various departments then you've again made bad hires. Everyone should have their role and fullfill that role to work as a successful team. People thinking they're above fullfilling the role they were hired for is one of the fast ways to have a poor performant team. To put this into sports you don't want your defender to be constantly hanging around the other team's goal mouth.
- chii 6y ago
  And yet, there's incentive for somebody (say, in soccer) to try and score a goal even tho it's not their role - because scoring a goal is rewarded to the individual. Individual coders/contributors' compensation don't scale until they are shown to "score a goal". And yet, to do so, they may have to stop contributing in their usual, assigned role, but go "above and beyond" - such as redesigning the system, or to make their mark on the product and be recognized as such. This, i find, is probably what the fundamental problem/friction with teams are.
- AgentOrange1234 6y ago
  I can appreciate how this kind of specialization helps a team to scale. At the same time, what I like least about my current job is how structured my role is. ‘Draw within the lines’ is constraining and can push creative folks away.
mcguire 6y ago
"Your job satisfaction/pay are a function of your impact. Your impact is a function of your leverage." I'm skeptical. I mean, sure, for most people, the ability to convince a large number of other people to do things, to do your things, without worrying how they do it, is going to have more impact than any other contribution they could make. On the other hand, Van Jacobson's algorithm is like four lines of code (I used to know where it is in *TCP/IP Illustrated, Vol II.) and is responsible for the Internet as we know it. That's an awful lot of impact.
- deleted 6y ago
  [deleted]
- xyzelement 6y ago
  I don't think we disagree. I hadn't heard of Van Jacobson but a quick glance at his wikipedia doesn't make it look like he was just a "pure coder" in the cartoonish sense of someone who doesn't know what's important and can't collaborate with others.
asiachick 6y ago
I'm not sure how "(a) work independently" fits. In fact it seems the opposite. The whole point is about working with and influencing others. That's not "working independently"
- tremon 6y ago
  "Working independently" is not the same as "working in isolation". Not sure that this is also what the GP meant, but "work independently" usually means that you understand what the business needs and can initiate new tasks on your own, without waiting for someone to tell you what to do.
fairity 6y ago
> The more of these things you do, you become orders of magnitude more impactful than a pure coder. Your job satisfaction/pay are also a function of how unique your skillset is. With this in mind, increasing your impact (through soft skills) is just one of two ways to increase pay - the other way is to do something that not many others can do. For many people, doing something unique is far more satisfying than dealing with people problems.
- grogenaut 6y ago
  I will point out that a lot of engineers are bad communicators, and those that are not often change roles. So communication is a unique skillset. As is understanding the business.
- matthias509 6y ago
  > For many people, doing something unique is far more satisfying than dealing with people problems. These are not mutually exclusive. If you want to accomplish big unique things, you can't do it yourself. You are going to have to convince others that your big new idea is worth doing so that they will help you achieve it.
dangisgay 6y ago
Having these other skills are equally useless making what you say useless

KineticLensman 6y ago

Agree. One of the most important skills is the one he describes like this: >> The more specialized your work, the greater the risk that you will communicate in ways that are incomprehensible to the uninitiated. In my experience (35 years), this isn't just about knowing the right way to describe things, it's also understanding what things to concentrate on when communicating, and what to ignore. If you are a tech person communicating with a decision maker, they are typically looking to understand options and their implications and risks, not the details of how the options work. They can then decide, based on their (presumably) better knowledge of the wider context, which options to select. If the decision makers are genuinely intelligent and motivated, but their eyes glaze over when you describe something, chances are you have chosen the wrong things to communicate to them.

xyzelement 6y ago
Yup. I agree with you (and your pragmatic approach to helping the raptors!)
- KineticLensman 6y ago
  Thank you! (Actually the raptor conservancy [0] is interesting from this perspective as well. I'm a newbie / junior in that context, but I can see standard employee patterns that I recognise from the tech industry, e.g. in terms of people who know to report and / or delegate well, or to make effective decisions vs. be indecisive. Perhaps I'll have to see if I can document my observations on what I've learned in my career). [o] https://news.ycombinator.com/item?id=25650535 https://news.ycombinator.com/item?id=25650535
Dirlewanger 6y ago
Very well said. It's stuff like this that makes me think all CS majors need some sort of business communications requirement, something to at least give a foundation on how to speak to decision makers.
- yowlingcat 6y ago
  Good business communication is something you only learn by /doing/ it. Expecting a course to facilitate that is flawed. I'd be all for increasing the roles of internships in CS education in order to accomplish that -- and I have noticed that's begun to happen as well. CS majors these days have internships lined for summer and winter if not more (especially due to COVID). I am sure they'll learn a lot more than I did during that era of my life just by sheer osmosis.
  - Kevguy 6y ago
    If it is a good course on business communication they _should_ be doing it - in class. And getting feedback and suggestions on improving with every attempt. Internships are a wonderful thing but many people don't realize how they are coming across so don't look to improve. There is some learning by osmosis, but mostly people keep doing what they have always done because it works (as far as they can tell).
    - yowlingcat 6y ago
      > they _should_ be doing it - in class They won't be doing it, they will be doing a simulation of it. How are they going to learn business communication without doing it in the context of a real business with a real P/L line and real consequences for good and bad execution?

one2know 6y ago

Found the manager. This is just more developer hate drivel. Yes, if you think managers are more valuable, then obviously you are going to say engineering work is "incredibly limited" and manager activities are "orders of magnitude more impactful" Listen, no amount of ass kissing and brown nosing is going to solve actual tech problems.

macintux 6y ago
This tone is unwelcome on HN, which is probably why your previous comments have often been downvoted and flagged.
- one2know 6y ago
  Bashing and shit talking software engineering profession is welcome on HN?
  - macintux 6y ago
    Let me paraphrase the original comment to make my next question easier to answer: Effective software engineering in a business context requires awareness of business needs. Which part of that is “bashing and shit talking”?
    - mcguire 6y ago
      How about, Effective software engineering in a business context requires awareness of business needs as well as the technical skills to address those needs.
      - xyzelement 6y ago
        Nobody would argue with this.
deleted 6y ago
[deleted]
deleted 6y ago

draw_down 6y ago

It’s ok to just produce a days worth of code in a day. This is not a failure mode or something to be avoided. It’s ok to just work a job. Not everyone is focused on “impact” and all that junk, and nor does everyone need to be.

closeparen 6y ago

This is the party line. It misses that “a day’s worth of code” is highly unequal across individuals. The people whose “day’s worth of code” are most valuable, quickly get pulled off of spending their days that way. It appears that they key skill is coordinating a lot of developers, because the ones left developing are the ones you need a lot of (and who need close supervision) to get anything done. Managers will never rock this boat, because their career KPI is the number of people they manage.

astrange 6y ago
That means you have bad middle/upper management. Large tech companies have heard of the Peter Principle and don't promote this way; they have separate technical tracks. Which is not to say they're doing everything right.
- wolco2 6y ago
  Having a tech track is the right direction. Having no track even better. Some people like what they are doing and the field is constantly changing. You want your best surgeons doing operations not managing other doctors.
  - astrange 6y ago
    I think that would encourage not getting raises. You need some kind of title so people can feel responsible for career growth and so you can calibrate against other companies' pay at least; it doesn't need to control what kind of work you're allowed to do.
    - ghaff 6y ago
      Even if they don't transition to managing people, someone in an individual contributor role presumably needs to be growing in some way if they want to get raises. While someone doing something valuable even without growing will probably continue to get small raises anyway, it's not the ideal path. And, as you say, to the degree that position titles mean something cross-company, it gives a point of comparison.

that_guy_iain 6y ago

> If you're a "pure coder" who doesn't have any of the other skills you mentioned, your output is incredibly limited. At best, you produce a day's worth of code in a day, but you also require someone to manage you closely to make sure you code the right stuff. This seems to miss the point of teams. Everyone should have a role if you hire someone as a software engineer and they spend all their time doing devops because they like it more you've made a bad hire. If all your engineers are having product meetings with various departments then you've again made bad hires. Everyone should have their role and fullfill that role to work as a successful team. People thinking they're above fullfilling the role they were hired for is one of the fast ways to have a poor performant team. To put this into sports you don't want your defender to be constantly hanging around the other team's goal mouth.

chii 6y ago
And yet, there's incentive for somebody (say, in soccer) to try and score a goal even tho it's not their role - because scoring a goal is rewarded to the individual. Individual coders/contributors' compensation don't scale until they are shown to "score a goal". And yet, to do so, they may have to stop contributing in their usual, assigned role, but go "above and beyond" - such as redesigning the system, or to make their mark on the product and be recognized as such. This, i find, is probably what the fundamental problem/friction with teams are.
AgentOrange1234 6y ago
I can appreciate how this kind of specialization helps a team to scale. At the same time, what I like least about my current job is how structured my role is. ‘Draw within the lines’ is constraining and can push creative folks away.

mcguire 6y ago

"Your job satisfaction/pay are a function of your impact. Your impact is a function of your leverage." I'm skeptical. I mean, sure, for most people, the ability to convince a large number of other people to do things, to do your things, without worrying how they do it, is going to have more impact than any other contribution they could make. On the other hand, Van Jacobson's algorithm is like four lines of code (I used to know where it is in *TCP/IP Illustrated, Vol II.) and is responsible for the Internet as we know it. That's an awful lot of impact.

deleted 6y ago
[deleted]
xyzelement 6y ago
I don't think we disagree. I hadn't heard of Van Jacobson but a quick glance at his wikipedia doesn't make it look like he was just a "pure coder" in the cartoonish sense of someone who doesn't know what's important and can't collaborate with others.

asiachick 6y ago

I'm not sure how "(a) work independently" fits. In fact it seems the opposite. The whole point is about working with and influencing others. That's not "working independently"

tremon 6y ago
"Working independently" is not the same as "working in isolation". Not sure that this is also what the GP meant, but "work independently" usually means that you understand what the business needs and can initiate new tasks on your own, without waiting for someone to tell you what to do.

fairity 6y ago

> The more of these things you do, you become orders of magnitude more impactful than a pure coder. Your job satisfaction/pay are also a function of how unique your skillset is. With this in mind, increasing your impact (through soft skills) is just one of two ways to increase pay - the other way is to do something that not many others can do. For many people, doing something unique is far more satisfying than dealing with people problems.

grogenaut 6y ago
I will point out that a lot of engineers are bad communicators, and those that are not often change roles. So communication is a unique skillset. As is understanding the business.
matthias509 6y ago
> For many people, doing something unique is far more satisfying than dealing with people problems. These are not mutually exclusive. If you want to accomplish big unique things, you can't do it yourself. You are going to have to convince others that your big new idea is worth doing so that they will help you achieve it.

dangisgay 6y ago

Having these other skills are equally useless making what you say useless