6 ms·

> For software that includes fixing a lot of hard bugs and really delivering on features like complete documentation, monitoring, and good upgrades. That's exa

> For software that includes fixing a lot of hard bugs and really delivering on features like complete documentation, monitoring, and good upgrades. That's exactly the kinds of things I wish that I could do. In my experience it's mostly managers that want you to push features without any documentation and filled with bugs.

wnevets 10y ago
Even if it isn't the managers themselves that personally want to skip those things, their boss wants the next feature.
- xorblurb 10y ago
  Then they are useless. Send us the boss directly, will save a layer of communication. Problem is the boss wants a unique interlocutor, and one who says yes. Then if he is friendly enough, engineers will prefer to do a shitty job (rush "features" and even more bugs) rather than inconvenience their manager who already committed on behalf of the whole team.
  - wnevets 10y ago
    sounds like you want a flat structure.
    - m4x 10y ago
      Or they just want to cut out unnecessary layers. You don't really want an extra level between the group demanding the features and the group implementing them. Feedback about technical feasibility, time to implement et cetera really needs to go directly to the group demanding the feature, and their responses need to come directly back to the group implementing it. A competent middle man can help those two groups interact, but generally adding an extra middle layer reduces everybody's ability to function well.
- majormajor 10y ago
  A major part of the art of the handwavey term "good" management at the technical-line-level-and-middle-management stage is exactly in that area of "selling the rest of the business on why this will take longer than it sounds" and "protecting the team's time to work on what the team needs to work on to continue to be able to deliver stuff fast." Good management means the team can keep working fast. Bad management means that three-to-five years later, someone has to come in and really put their foot down and say "if you want simple features to stop taking six months we have to take the time now." But to be able to sell that message outside the tech team at that point, you sorta have to be an external "fixer" - IME, it's hard to sell your own ability to clean up the mess if you're seen as part of who created it, sadly. Figuring out the difference between a place with good management and bad management if you're interviewing there can be tricky - but if they don't have tests, etc, and also can't tell you their plan to add them / why they're adding them now, that's probably a bad sign. Or ask them what they've shipped recently and how long it took - maybe easier to look for the symptoms than for specific process failings, since those could be wildly varied. EDIT: I love working in flat structures where the total relevant number of people to what I'm working on is under 15. Either a small startup or a truly independent sub-unit. But there are few worse environments than a flat structure where 30+ people feel like they should have a say in a given feature.
talmand 10y ago
I second this. Well, the pushing features part but hopefully documented and without (many) bugs. But features for the sales team is considered important. I usually like researching and fixing bugs, especially when they are mine. But compare business value between bugs versus new features and guess which one wins the most.
AsyncAwait 10y ago
I am a junior developer, but my experience so far has been exactly this; arbitrary deadlines, poorly defined or no technical specification and worst of all, no room for testing or documentation, yet still somehow expecting it to happen in the end.
- nradov 10y ago
  It isn't a manager's job to provide you with well defined technical specifications. Figuring those out takes an ongoing iterative process involving input from multiple stakeholders. One thing that can really help in organizations that lack discipline is to define a detailed, rigorous definition of done and institute strict work-in-progress limits for each agile team. That way the team will be less likely to underestimate in the first place and everyone understands that time must be allowed for testing and documentation.
  - rantanplan 10y ago
    Technical specs no, but well defined product requirements definitely yes. I'm fine with engineers fleshing out the technical specs(who else is gonna do it anyway?), but requirements come by engaging with the stakeholders, as you said, most notably your client(s). And this is not a job for your engineers.
    - angryasian 10y ago
      >product requirements definitely yes No matter where I've worked, most product is basically no one knows what they want until its built and sitting in front of them.
      - nradov 10y ago
        Yes that is exactly why lean agile development was invented. It should be standard practice in most development organizations by now, but yet people still want to believe that it's possible to reliably anticipate what customers want far in advance. Sometimes you can guess right but that's a risky proposition and seldom repeatable.
asimuvPR 10y ago
They also might expect documentation and thorough testing when things break. This forces an inverse relationship where the engineer has to manage the manager by documenting interactions and then having the manager acknowledge them. Otherwise the manager will push and blame the engineer when things go sour. Its a sad dynamic that is rather common. You sort of get used and good at it with time. It is not exclusive to software, though. Its everywhere because most people can't manage.
nrinaudo 10y ago
I agree with part of your sentence only. Managers, especially professional ones (as opposed to ones that were promoted from the kind of position they end up managing) do tend to push for client-facing features with little thought to the accumulating technical debt. It's been my experience, however, that when left to their own devices, developers tend to either learn new things or refactor code that's getting too hard to maintain. And both are important, critical even, but certainly no help in getting up to date documentation, fixing "painful" bugs, or writing good tests. In fact, they can even be counter-productive in that respect: heavily refactored code will invalidate at least part of its documentation and tests.
bobbytherobot 10y ago
I've had this and I have good managers. I worked outside of the Bay Area before coming here. I can tell you that the Bay Area tech has the worse managers. They drink the Kool-Aid way to hard out here.

wnevets 10y ago

Even if it isn't the managers themselves that personally want to skip those things, their boss wants the next feature.

xorblurb 10y ago
Then they are useless. Send us the boss directly, will save a layer of communication. Problem is the boss wants a unique interlocutor, and one who says yes. Then if he is friendly enough, engineers will prefer to do a shitty job (rush "features" and even more bugs) rather than inconvenience their manager who already committed on behalf of the whole team.
- wnevets 10y ago
  sounds like you want a flat structure.
  - m4x 10y ago
    Or they just want to cut out unnecessary layers. You don't really want an extra level between the group demanding the features and the group implementing them. Feedback about technical feasibility, time to implement et cetera really needs to go directly to the group demanding the feature, and their responses need to come directly back to the group implementing it. A competent middle man can help those two groups interact, but generally adding an extra middle layer reduces everybody's ability to function well.
majormajor 10y ago
A major part of the art of the handwavey term "good" management at the technical-line-level-and-middle-management stage is exactly in that area of "selling the rest of the business on why this will take longer than it sounds" and "protecting the team's time to work on what the team needs to work on to continue to be able to deliver stuff fast." Good management means the team can keep working fast. Bad management means that three-to-five years later, someone has to come in and really put their foot down and say "if you want simple features to stop taking six months we have to take the time now." But to be able to sell that message outside the tech team at that point, you sorta have to be an external "fixer" - IME, it's hard to sell your own ability to clean up the mess if you're seen as part of who created it, sadly. Figuring out the difference between a place with good management and bad management if you're interviewing there can be tricky - but if they don't have tests, etc, and also can't tell you their plan to add them / why they're adding them now, that's probably a bad sign. Or ask them what they've shipped recently and how long it took - maybe easier to look for the symptoms than for specific process failings, since those could be wildly varied. EDIT: I love working in flat structures where the total relevant number of people to what I'm working on is under 15. Either a small startup or a truly independent sub-unit. But there are few worse environments than a flat structure where 30+ people feel like they should have a say in a given feature.

talmand 10y ago

I second this. Well, the pushing features part but hopefully documented and without (many) bugs. But features for the sales team is considered important. I usually like researching and fixing bugs, especially when they are mine. But compare business value between bugs versus new features and guess which one wins the most.

AsyncAwait 10y ago

I am a junior developer, but my experience so far has been exactly this; arbitrary deadlines, poorly defined or no technical specification and worst of all, no room for testing or documentation, yet still somehow expecting it to happen in the end.

nradov 10y ago
It isn't a manager's job to provide you with well defined technical specifications. Figuring those out takes an ongoing iterative process involving input from multiple stakeholders. One thing that can really help in organizations that lack discipline is to define a detailed, rigorous definition of done and institute strict work-in-progress limits for each agile team. That way the team will be less likely to underestimate in the first place and everyone understands that time must be allowed for testing and documentation.
- rantanplan 10y ago
  Technical specs no, but well defined product requirements definitely yes. I'm fine with engineers fleshing out the technical specs(who else is gonna do it anyway?), but requirements come by engaging with the stakeholders, as you said, most notably your client(s). And this is not a job for your engineers.
  - angryasian 10y ago
    >product requirements definitely yes No matter where I've worked, most product is basically no one knows what they want until its built and sitting in front of them.
    - nradov 10y ago
      Yes that is exactly why lean agile development was invented. It should be standard practice in most development organizations by now, but yet people still want to believe that it's possible to reliably anticipate what customers want far in advance. Sometimes you can guess right but that's a risky proposition and seldom repeatable.

asimuvPR 10y ago

They also might expect documentation and thorough testing when things break. This forces an inverse relationship where the engineer has to manage the manager by documenting interactions and then having the manager acknowledge them. Otherwise the manager will push and blame the engineer when things go sour. Its a sad dynamic that is rather common. You sort of get used and good at it with time. It is not exclusive to software, though. Its everywhere because most people can't manage.

nrinaudo 10y ago

I agree with part of your sentence only. Managers, especially professional ones (as opposed to ones that were promoted from the kind of position they end up managing) do tend to push for client-facing features with little thought to the accumulating technical debt. It's been my experience, however, that when left to their own devices, developers tend to either learn new things or refactor code that's getting too hard to maintain. And both are important, critical even, but certainly no help in getting up to date documentation, fixing "painful" bugs, or writing good tests. In fact, they can even be counter-productive in that respect: heavily refactored code will invalidate at least part of its documentation and tests.

bobbytherobot 10y ago

I've had this and I have good managers. I worked outside of the Bay Area before coming here. I can tell you that the Bay Area tech has the worse managers. They drink the Kool-Aid way to hard out here.