4 ms·

> You must deliver software like you're delivering a book from amazon, no matter what. This particular story provides an important refinement to this point. Su

by pdpi 7y ago

> You must deliver software like you're delivering a book from amazon, no matter what. This particular story provides an important refinement to this point. Success isn't always possible. Delivering "no matter what" is part of what engenders trust, but an even more important component is being ahead of the ball. If your manager comes to you saying "you're not matching expectations", whatever explanation you might have will be read as an excuse. If you proactively tell your manager "hey, this framework seems hellish, we might face some problems", you're leading the discussion in how to recover from a bad situation — You redefine "success" early enough in the game that you can actually deliver it. Knowing how to have this conversation (and the self-reflection necessary to understand you need to have it) is one of the most important parts of a "true" 10x engineer.

quadcore 7y ago
"hey, this framework seems hellish, we might face some problems" The problem if you think about it is that you will tell him just that every time you see him. In other words, how do you show that you know how to make a good framework other than by beating deadlines? Beat deadlines, again and again, and then you will be granted the right the make a framework yourself. One that. among other things, actually beat deadlines.
- pdpi 7y ago
  I think you missed my point. "Beating the deadline" means that you deliver something that meets or exceeds expectations within the deadline. You achieve this by pulling two levers: By adjusting expectations and by getting things done. Crucially, each lever only goes so far — you (usually) can't adjust expectations to the point where you're expected to do zero work, and you can't deliver on impossibly demanding expectations solely by working extra hard. While you're absolutely right that the "keep shipping" lever is very important, the article provides an example of where you need to pull the other lever early.
  - granos 7y ago
    I'm currently living this. About a year ago I inherited a large codebase that has been allowed to accumulate tech debt for the past 5 years. This was all done in the name of adding new features and keeping the business competitive. But it's time to pay down the debt. I've had MANY frank conversations with both product and engineering leadership about the current state of the world. The VP of engineering is onboard and understands the pain of what we're going through. Product is a bit harder to convince, but just as important -- probably more important. They understand that my team is having to spend 20%+ of our time just bringing the code into this decade, because I set that expectation early and reinforce it often. I argued AGAINST a from-scratch rewrite because I knew it would never be ok to stop shipping. But I have been able to convince them that slowing down now will let us move faster later.

by pdpi 7y ago

quadcore 7y ago

"hey, this framework seems hellish, we might face some problems" The problem if you think about it is that you will tell him just that every time you see him. In other words, how do you show that you know how to make a good framework other than by beating deadlines? Beat deadlines, again and again, and then you will be granted the right the make a framework yourself. One that. among other things, actually beat deadlines.

pdpi 7y ago
I think you missed my point. "Beating the deadline" means that you deliver something that meets or exceeds expectations within the deadline. You achieve this by pulling two levers: By adjusting expectations and by getting things done. Crucially, each lever only goes so far — you (usually) can't adjust expectations to the point where you're expected to do zero work, and you can't deliver on impossibly demanding expectations solely by working extra hard. While you're absolutely right that the "keep shipping" lever is very important, the article provides an example of where you need to pull the other lever early.
- granos 7y ago
  I'm currently living this. About a year ago I inherited a large codebase that has been allowed to accumulate tech debt for the past 5 years. This was all done in the name of adding new features and keeping the business competitive. But it's time to pay down the debt. I've had MANY frank conversations with both product and engineering leadership about the current state of the world. The VP of engineering is onboard and understands the pain of what we're going through. Product is a bit harder to convince, but just as important -- probably more important. They understand that my team is having to spend 20%+ of our time just bringing the code into this decade, because I set that expectation early and reinforce it often. I argued AGAINST a from-scratch rewrite because I knew it would never be ok to stop shipping. But I have been able to convince them that slowing down now will let us move faster later.