4 ms·

The spectrum of (product engineer) <---> ($NEEDS_A_NAME) has been one I've encountered a lot and which I find is underappreciated in hiring and team-building.

by daguar 7y ago

The spectrum of (product engineer) <---> ($NEEDS_A_NAME) has been one I've encountered a lot and which I find is underappreciated in hiring and team-building. The way I think about it is that you're giving weights to one of two different goals: 1. Building the right thing 2. Building the thing right I've found that in early-stage work, you really really need to have engineers who are more interested in (1) than (2). I'd probably say a product engineer who's a good fit for early stage work probably has an 70%/30% mix of what motivates them between these two goals. The strongest product engineers also have a keen sense of the power of MANUALLY handling some cases as a way to learn. At small scale, the cost of manually handling something can be way lower than building for that case. So another attribute I've seen is that strong product engineers are either okay with or even actively enjoy supporting users in those edge cases, talking with them as a way to learn. I'd be curious to know how companies most effectively hire for and/or cultivate these kinds of behaviors in eng teams.

ebiester 7y ago
I'd say the word you're looking for is Software Crafts[man,woman] but I don't necessarily believe the two are exclusive, but rather horizontal and vertical axes. There is a difference between someone actively making compromises between time to market and features, and someone who doesn't understand how to write software in a maintainable fashion but can get something quickly out to market. There are even people who are good at neither.
- crimsonalucard 7y ago
  If you write "Crafts[man,woman]" and place the "man" before the "woman" you are implying the "man" is better than the "woman." To make things more gender neutral and less sexist you need to write "Craftspeople." For example I never use sexist or offensive words like "Mankind" anymore, I write "Peoplekind." Also my chrome highlights "Peoplekind" as a spelling error which shows you how far we are from living in a society that isn't sexist.
  - natalyarostova 7y ago
    I can’t tell if this is satire or not :|
    - crimsonalucard 7y ago
      Hard to say. Is the feminist movement growing to the point where it's tenants are becoming borderline satirical? or are you sexist and old fashioned for even thinking this is satire?
    - jaredsohn 7y ago
      It isn't the poster's real opinion or at least doesn't match practice; the poster wrote 'layman' within the past week on Hacker News.
      - crimsonalucard 7y ago
        I'm sorry. That was an accident. It is my real opinion, the post is not satire at all. I actually think it's kind of telling of how backwards modern culture is to even think something so inconsiderate is even considered to be satire. My posts got flagged which is another marker for how far we have to go for society to change. I would of thought that the people who use HN were more progressive then that.
        natalyarostova 7y ago
        Fuck, I still can’t tell.
        crimsonalucard 7y ago
        Come on. If a comedian said on stage that there was a bomb in the building it would be pretty obvious whether or not the person was joking. Clearly, my statements are self evident.
        7y ago
- rileymat2 7y ago
  This is an understated point, there is a difference between intended technical debt and incompetence. At a very micro level, yesterday I was looking at a simple JS object with 6 entries, and 3 different naming conventions. Doing even simple changes without code-completion in the code base is mentally taxing.
- Vinnl 7y ago
  Very much agreed. In fact, I'd say that "building the right thing" often enables "building the thing right": by not spending time building things that are unimportant, you can spend time making the things that are work better. Needing to get to market faster doesn't mean skimping on, say, a proper CI setup; it means not trying to do everything, and focusing on delivering and iterating on only those features that are relevant to the market.
lwb 7y ago
One possible value for $NEEDS_A_NAME is Infrastructure Engineer ... not to say that infra isn't always productized, because it sometimes is, but the instincts required just aren't the same when your customer is the team that works down the hall. Maybe Systems Engineer if you consider the type of engineer that optimizes for speed and other factors. Idk, names are hard.
- nitrogen 7y ago
  SRE sort of fits that box, though I have to point out w.r.t. the OP's post that there is being scrappy (not building for edge cases that don't have confirmed ROI) and being reckless (ignoring any engineering concern whatsoever). I've seen projects sink for having PMs too far on the reckless side. Frontend engineers who appear to be developing the day's hot feature end up building a massive platform on platform on (...ad nauseam) on Reactive React just to show a few forms, while the backend engineers get pushback every time they ask a question. The product sinks because it takes three weeks just to move a field from one form to a different form, you have to refactor the whole redux store, ... These are the teams that go so far in the "manual" direction that they refuse to build support tools of any kind whatsoever, and then when the inevitable fires come nobody knows what's going on. So product<->reliability might be often mutually exclusive just because that is what people are used to, but really engineers should be able to do both and know when to adjust, and so should the managers.
avip 7y ago
The "hire for" part is pretty straightforward - when you interview, you'll have candidates with zero idea what your company is building. They won't care either. Come Q time they'll ask about tech stack, code review, 4k screen, could they use their esoteric linux distro (yes). OTOH you'll have candidates who already know your competitors, and know the tech stack because they registered for invite-only beta the day before the interview.
- therealdrag0 7y ago
  Eh. I lean towards the former; in an interview I ask tech/process related questions and don't care about product (unless the interviewer mentions something that piques my interest). But when I start the job I give above-average energy to product-engineering. I'm looking for a tech fit, and I can apply my product-engineering energy anywhere.
chiefalchemist 7y ago
In my experience, #1 is relatively the (very) hard part. #2 is relatively easy as it's finite in scope and push come to shove you pay a bounty (to a one-off consultant) to architect the direction of a solution. Put another way, you can get #1 wrong and even if #2 hits that target, you're still wrong. But get #1 right and over a couple iterations you can get the means to support the desired ends.

by daguar 7y ago

ebiester 7y ago

I'd say the word you're looking for is Software Crafts[man,woman] but I don't necessarily believe the two are exclusive, but rather horizontal and vertical axes. There is a difference between someone actively making compromises between time to market and features, and someone who doesn't understand how to write software in a maintainable fashion but can get something quickly out to market. There are even people who are good at neither.

crimsonalucard 7y ago
If you write "Crafts[man,woman]" and place the "man" before the "woman" you are implying the "man" is better than the "woman." To make things more gender neutral and less sexist you need to write "Craftspeople." For example I never use sexist or offensive words like "Mankind" anymore, I write "Peoplekind." Also my chrome highlights "Peoplekind" as a spelling error which shows you how far we are from living in a society that isn't sexist.
- natalyarostova 7y ago
  I can’t tell if this is satire or not :|
  - crimsonalucard 7y ago
    Hard to say. Is the feminist movement growing to the point where it's tenants are becoming borderline satirical? or are you sexist and old fashioned for even thinking this is satire?
  - jaredsohn 7y ago
    It isn't the poster's real opinion or at least doesn't match practice; the poster wrote 'layman' within the past week on Hacker News.
    - crimsonalucard 7y ago
      I'm sorry. That was an accident. It is my real opinion, the post is not satire at all. I actually think it's kind of telling of how backwards modern culture is to even think something so inconsiderate is even considered to be satire. My posts got flagged which is another marker for how far we have to go for society to change. I would of thought that the people who use HN were more progressive then that.
      - natalyarostova 7y ago
        Fuck, I still can’t tell.
        crimsonalucard 7y ago
        Come on. If a comedian said on stage that there was a bomb in the building it would be pretty obvious whether or not the person was joking. Clearly, my statements are self evident.
        7y ago
rileymat2 7y ago
This is an understated point, there is a difference between intended technical debt and incompetence. At a very micro level, yesterday I was looking at a simple JS object with 6 entries, and 3 different naming conventions. Doing even simple changes without code-completion in the code base is mentally taxing.
Vinnl 7y ago
Very much agreed. In fact, I'd say that "building the right thing" often enables "building the thing right": by not spending time building things that are unimportant, you can spend time making the things that are work better. Needing to get to market faster doesn't mean skimping on, say, a proper CI setup; it means not trying to do everything, and focusing on delivering and iterating on only those features that are relevant to the market.

lwb 7y ago

One possible value for $NEEDS_A_NAME is Infrastructure Engineer ... not to say that infra isn't always productized, because it sometimes is, but the instincts required just aren't the same when your customer is the team that works down the hall. Maybe Systems Engineer if you consider the type of engineer that optimizes for speed and other factors. Idk, names are hard.

nitrogen 7y ago
SRE sort of fits that box, though I have to point out w.r.t. the OP's post that there is being scrappy (not building for edge cases that don't have confirmed ROI) and being reckless (ignoring any engineering concern whatsoever). I've seen projects sink for having PMs too far on the reckless side. Frontend engineers who appear to be developing the day's hot feature end up building a massive platform on platform on (...ad nauseam) on Reactive React just to show a few forms, while the backend engineers get pushback every time they ask a question. The product sinks because it takes three weeks just to move a field from one form to a different form, you have to refactor the whole redux store, ... These are the teams that go so far in the "manual" direction that they refuse to build support tools of any kind whatsoever, and then when the inevitable fires come nobody knows what's going on. So product<->reliability might be often mutually exclusive just because that is what people are used to, but really engineers should be able to do both and know when to adjust, and so should the managers.

avip 7y ago

The "hire for" part is pretty straightforward - when you interview, you'll have candidates with zero idea what your company is building. They won't care either. Come Q time they'll ask about tech stack, code review, 4k screen, could they use their esoteric linux distro (yes). OTOH you'll have candidates who already know your competitors, and know the tech stack because they registered for invite-only beta the day before the interview.

therealdrag0 7y ago
Eh. I lean towards the former; in an interview I ask tech/process related questions and don't care about product (unless the interviewer mentions something that piques my interest). But when I start the job I give above-average energy to product-engineering. I'm looking for a tech fit, and I can apply my product-engineering energy anywhere.

chiefalchemist 7y ago

In my experience, #1 is relatively the (very) hard part. #2 is relatively easy as it's finite in scope and push come to shove you pay a bounty (to a one-off consultant) to architect the direction of a solution. Put another way, you can get #1 wrong and even if #2 hits that target, you're still wrong. But get #1 right and over a couple iterations you can get the means to support the desired ends.