5 ms·

Another attractive option: “doing it” but for +xx percent to compensation.

wpietri 4y ago
Attractive to whom? Probably not the person you're replying to. I imagine at this point in their career they have already heard of this whole "money" thing. People who are really good at things generally thrive on challenge, because without that you don't persist long enough to get good. For many, me included, no reasonable amount of money will get them through doing years of something where they aren't growing.
- ChrisMarshallNY 4y ago
  Not to me. I've been doing "It" (shipping software -which is quite different from "writing" software) for my entire adult life. Basically, if you want to actually ship a superb-Quality native iOS/iPadOS/WatchOS/MacOS app, in an astonishingly short period of time, I'm a good person to talk to. What I have learned, is that very few people seem to want to actually ship software. Instead, companies become obsessed with "coding culture," and "process" (which can mean many different things). As it comes time to start preparing for it to go out the door, all kinds of roadblocks start piling up. It's crazy. I was "frozen out" of the industry, because of my age, which really pissed me off, but that has turned out to be a great thing. It's been a real joy, writing my own stuff. Out of necessity, I have to keep the scope humble, but that's fine.
  - hhmc 4y ago
    Defining "It" to be shipping software feels so broad as to be useless. In perticular, you're not working in the same semantic framework as GP, who was talking about "It+1", "It+2" and so on
    - ChrisMarshallNY 4y ago
      Actually, no. It has been my experience that actually delivering, working, high-Quality, supported, documented software (regardless of what the software does), within a reasonable period of time, is beyond the capabilities of many corporations. I suspect that some folks make money by convincing others to invest, then hightailing it, before the chickens come home to roost, as opposed to actually selling a finished and supported product to end-users. In that case, looking like a "shipper," is much more important than actually being one.
      - hhmc 4y ago
        I'm thrilled for you, that you're so good at delivering software. But this feels really besides the actual points being made here.
        ChrisMarshallNY 4y ago
        "It," "It+1," "It+2," etc. can definitely be delivering software. But that's just one "It" on the continuum. It could also be grant-writing, selling, managing, singing, shredding guitar, racing minibikes, whatever. In any given case, there's always some threshold of what an "effective It" is. It may not be a clear-cut line. For example, research is very "fuzzy," and a researcher that can do "It," may be excellent at failure, because their job is to poke holes in theories. In fact, if the company is all about getting A-round funding, then folding up the card tables, and moving on, someone that "looks like a shipper" could be an effective "It."
      - jdlshore 4y ago
        Complete agreement—soup-to-nuts delivery of software for a particular ecosystem (Apple in this case) is definitely an "it" I can imagine companies hiring for.
  - maerF0x0 4y ago
    > Instead, companies become obsessed with "coding culture," and "process" (which can mean many different things). Many companies must build out rigorous standards, and checks and balances in order to deal with regression to the mean. If what you're saying is true you're multiple standard deviations above the normal engineer, and scaling you is non-trivial. Bob martin has said the population of coders doubles every 5 yrs meaning at any given time 1/2 of the engineers have less than 5 years experience. When you need something that would take 1000 of you, which might not even exist on the planet, they instead have to build a system that takes 10k of those 5yr and less engineers -- and have the highest quality outliers leveraged though standards, automation, building engineering culture etc.
    - ChrisMarshallNY 4y ago
      > If what you're saying is true I get that a lot. It's absurdly easy to verify (I point to all my work), but folks would rather sling mud, than take a peek. Doesn't matter. I'm not looking for work anymore. In my time, I have worked with many people that make me look like a piker. I suspect they get chased out, too.
      - maerF0x0 4y ago
        Sorry, to be clear I wasn't trying to address/rebut/debate your skill, but rather just start from a presumption. Presuming what you're saying is true. It really doesn't matter to me if it's true about you or not, we can still discuss the issue of designing for talent several standard deviations above the mean vs one that falls within, say, [0-1] std deviation above the mean.
    - LordDragonfang 4y ago
      I've been reading the (perennially-recommended) Mythical Man Month with a friend, and this is something that gets touched on again and again. It's funny that for all the hilariously out-of-date components of those essay (development measured in compiler instructions written!), the inefficiency between a good architect and the number mean-regressed engineers beneath them is still a problem we struggle with half a century later.
  - MikeDelta 4y ago
    So many devs that have an opinion on decorators, frameworks, cloud services, but so few that actually build stuff that works. Totally agree.
  - wpietri 4y ago
    For sure. It's still astonishing to me that if you measure by everybody's behavior, actually shipping something good in a timely fashion is often pretty far down the priority list. And I feel you on process. I got involved in process because I wanted to quickly solve user problems, and then keep on solving user problems. But so much of the process-industrial complex is not focused on that. E.g., the SAFe® process is the effective opposite of what early Agile pioneers were aiming at. Its major function is to give managers and executives a sense of control almost without regard to how achievable that is or what it costs in terms of productivity and lost opportunity.
- ryandrake 4y ago
  Yea, I used to accept "Do 'It' for +N% salary" but homie don't play that game anymore. The problem with accepting additional comp without advancement is: 1. Salary will plateau eventually. I know early in your career it doesn't seem like it will, but trust me: It will. I don't care what company you are in, or how good you are, "Fourth Senior Software Engineer From The Left" is never going to be making $1M/yr. (Not that that should necessarily be your goal, but it illustrates that you will plateau at some point.) 2. When you keep job hopping for more money but no change in level, you risk gaining "1 year of experience 20 times" instead of 20 years of experience. You're sacrificing long term career growth for short term salary bumps. I did this for years and ended up shooting myself in the foot long-term. My college friends, who instead played the Title / Ladder Climbing game, are all much better off than I now. They're all job-secure VPs, SVPs, and CxO's in their companies vs. me who still doesn't even have any direct reports, and is one of many interchangeable worker bees. No more doing that for me. I'll only accept, at a minimum, a level jump at this point.
  - neon_electro 4y ago
    It sounds like you're an individual contributor and want off that track and on to the management track. Or to you, is "management" simply the next level beyond individual contributorship? I won't work for an employer that doesn't plan for career advancement in BOTH tracks - management is great, but for every one of you who sees career advancement as managing others, there's someone like me who wants to stay the hell away from that while still finding room to advance my career as an individual contributor. Any thoughts?
    - ryandrake 4y ago
      Very few companies have a legitimate “parallel but equal” tech track for IC’s that remains IC all the way up. At some point on the totem pole you end up managing. All roads upward point to it. I currently work for a company that has a robust stack of levels for software engineers, but nobody at the “director equivalent” tech level is an actual IC. I love the concept of having VP-level IC “wizard” roles who don’t have to manage, but have never seen it in practice.

Attractive to whom? Probably not the person you're replying to. I imagine at this point in their career they have already heard of this whole "money" thing. People who are really good at things generally thrive on challenge, because without that you don't persist long enough to get good. For many, me included, no reasonable amount of money will get them through doing years of something where they aren't growing.

ChrisMarshallNY 4y ago
Not to me. I've been doing "It" (shipping software -which is quite different from "writing" software) for my entire adult life. Basically, if you want to actually ship a superb-Quality native iOS/iPadOS/WatchOS/MacOS app, in an astonishingly short period of time, I'm a good person to talk to. What I have learned, is that very few people seem to want to actually ship software. Instead, companies become obsessed with "coding culture," and "process" (which can mean many different things). As it comes time to start preparing for it to go out the door, all kinds of roadblocks start piling up. It's crazy. I was "frozen out" of the industry, because of my age, which really pissed me off, but that has turned out to be a great thing. It's been a real joy, writing my own stuff. Out of necessity, I have to keep the scope humble, but that's fine.
- hhmc 4y ago
  Defining "It" to be shipping software feels so broad as to be useless. In perticular, you're not working in the same semantic framework as GP, who was talking about "It+1", "It+2" and so on
  - ChrisMarshallNY 4y ago
    Actually, no. It has been my experience that actually delivering, working, high-Quality, supported, documented software (regardless of what the software does), within a reasonable period of time, is beyond the capabilities of many corporations. I suspect that some folks make money by convincing others to invest, then hightailing it, before the chickens come home to roost, as opposed to actually selling a finished and supported product to end-users. In that case, looking like a "shipper," is much more important than actually being one.
    - hhmc 4y ago
      I'm thrilled for you, that you're so good at delivering software. But this feels really besides the actual points being made here.
      - ChrisMarshallNY 4y ago
        "It," "It+1," "It+2," etc. can definitely be delivering software. But that's just one "It" on the continuum. It could also be grant-writing, selling, managing, singing, shredding guitar, racing minibikes, whatever. In any given case, there's always some threshold of what an "effective It" is. It may not be a clear-cut line. For example, research is very "fuzzy," and a researcher that can do "It," may be excellent at failure, because their job is to poke holes in theories. In fact, if the company is all about getting A-round funding, then folding up the card tables, and moving on, someone that "looks like a shipper" could be an effective "It."
    - jdlshore 4y ago
      Complete agreement—soup-to-nuts delivery of software for a particular ecosystem (Apple in this case) is definitely an "it" I can imagine companies hiring for.
- maerF0x0 4y ago
  > Instead, companies become obsessed with "coding culture," and "process" (which can mean many different things). Many companies must build out rigorous standards, and checks and balances in order to deal with regression to the mean. If what you're saying is true you're multiple standard deviations above the normal engineer, and scaling you is non-trivial. Bob martin has said the population of coders doubles every 5 yrs meaning at any given time 1/2 of the engineers have less than 5 years experience. When you need something that would take 1000 of you, which might not even exist on the planet, they instead have to build a system that takes 10k of those 5yr and less engineers -- and have the highest quality outliers leveraged though standards, automation, building engineering culture etc.
  - ChrisMarshallNY 4y ago
    > If what you're saying is true I get that a lot. It's absurdly easy to verify (I point to all my work), but folks would rather sling mud, than take a peek. Doesn't matter. I'm not looking for work anymore. In my time, I have worked with many people that make me look like a piker. I suspect they get chased out, too.
    - maerF0x0 4y ago
      Sorry, to be clear I wasn't trying to address/rebut/debate your skill, but rather just start from a presumption. Presuming what you're saying is true. It really doesn't matter to me if it's true about you or not, we can still discuss the issue of designing for talent several standard deviations above the mean vs one that falls within, say, [0-1] std deviation above the mean.
  - LordDragonfang 4y ago
    I've been reading the (perennially-recommended) Mythical Man Month with a friend, and this is something that gets touched on again and again. It's funny that for all the hilariously out-of-date components of those essay (development measured in compiler instructions written!), the inefficiency between a good architect and the number mean-regressed engineers beneath them is still a problem we struggle with half a century later.
- MikeDelta 4y ago
  So many devs that have an opinion on decorators, frameworks, cloud services, but so few that actually build stuff that works. Totally agree.
- wpietri 4y ago
  For sure. It's still astonishing to me that if you measure by everybody's behavior, actually shipping something good in a timely fashion is often pretty far down the priority list. And I feel you on process. I got involved in process because I wanted to quickly solve user problems, and then keep on solving user problems. But so much of the process-industrial complex is not focused on that. E.g., the SAFe® process is the effective opposite of what early Agile pioneers were aiming at. Its major function is to give managers and executives a sense of control almost without regard to how achievable that is or what it costs in terms of productivity and lost opportunity.
ryandrake 4y ago
Yea, I used to accept "Do 'It' for +N% salary" but homie don't play that game anymore. The problem with accepting additional comp without advancement is: 1. Salary will plateau eventually. I know early in your career it doesn't seem like it will, but trust me: It will. I don't care what company you are in, or how good you are, "Fourth Senior Software Engineer From The Left" is never going to be making $1M/yr. (Not that that should necessarily be your goal, but it illustrates that you will plateau at some point.) 2. When you keep job hopping for more money but no change in level, you risk gaining "1 year of experience 20 times" instead of 20 years of experience. You're sacrificing long term career growth for short term salary bumps. I did this for years and ended up shooting myself in the foot long-term. My college friends, who instead played the Title / Ladder Climbing game, are all much better off than I now. They're all job-secure VPs, SVPs, and CxO's in their companies vs. me who still doesn't even have any direct reports, and is one of many interchangeable worker bees. No more doing that for me. I'll only accept, at a minimum, a level jump at this point.
- neon_electro 4y ago
  It sounds like you're an individual contributor and want off that track and on to the management track. Or to you, is "management" simply the next level beyond individual contributorship? I won't work for an employer that doesn't plan for career advancement in BOTH tracks - management is great, but for every one of you who sees career advancement as managing others, there's someone like me who wants to stay the hell away from that while still finding room to advance my career as an individual contributor. Any thoughts?
  - ryandrake 4y ago
    Very few companies have a legitimate “parallel but equal” tech track for IC’s that remains IC all the way up. At some point on the totem pole you end up managing. All roads upward point to it. I currently work for a company that has a robust stack of levels for software engineers, but nobody at the “director equivalent” tech level is an actual IC. I love the concept of having VP-level IC “wizard” roles who don’t have to manage, but have never seen it in practice.