5 ms·

Imagine a situation where your job is CRUD development. You write PHP and CSS and JavaScript for a series of ad campaigns (say, every marvel movie for the next

by seiji 11y ago

Imagine a situation where your job is CRUD development. You write PHP and CSS and JavaScript for a series of ad campaigns (say, every marvel movie for the next 10 years). It's repetitive drone work. Then compare that to a situation where you have to send a rocket to space in the next 6 months or the company is out of business and you'll be homeless. Which situation motivates you to do better work?

sgk284 11y ago
Define "better work"? Sounds like that second situation will lead to some crappy architecture with bug-ridden code. The rocket will likely fail and explode. Meanwhile in the first scenario you've got breathing room to build some truly beautiful code that will pay dividends as the upfront cost is amortized over a decade of reuse. We see similar results in academia, where incredible research can be done because there is predictability and reliability in the environment in which it is being performed. High-stress rushed environments just lead to shitty work/life balance and, at best, mediocre solutions that will provide a stop-gap solution until there is time to do something better. Look at the incredible output from engineers at Google, Facebook, etc... Most tech companies do their best work once they've removed stress and timeline pressure from the equation. The trick is to get to that as early as possible in the company's life.
- seiji 11y ago
  It's about purpose. Either you are basically a human robot doing spec work or you can drive your own creative output for goals larger than yourself. People don't know what they are capable of until they are pushed beyond limits they thought they had. The future isn't made by cautious people, it's made by being better than anybody thought could be accomplished. "Create advertising units for campaign 3,401 of 16,032" isn't something where "beautiful" or "meaningful" comes into play. It's just drone work. get to that as early as possible in the company's life. We don't model startups on how a 30,000 employee company works. Completely different beasts.
HillRat 11y ago
Pretty sure the latter situation ends with homeless engineers and dead test pilots. Einstein developed his seminal theories working as a patent clerk; not sure you can argue without evidence that an insane, high-stress workload is conducive to anything other than burnout.
- seiji 11y ago
  You do realize this is the website for 80-hour-work-week, launch-startup-in-3-months fans, right? This isn't the place for nonsensical "work life balance" (which really means "i'm lazy and don't want to do good work, i just want to waste everybody else's time").
  - HillRat 11y ago
    No one's ever going to see this, but I feel like your reply merits a response. I believe, simply put, that hours-per-week are as useful a metric of progress as SLOC. The fact is that for any nontrivial development effort, adding work hours does not noticeably improve time to delivery and, in fact, starts to degrade progress. There are a few reasons for this. First, the most important effort in any significant project takes place before anyone starts slinging code. Design and strategy are obvious examples, but programming problems of sufficient complexity also don't benefit from throwing hours at them. For example, one of our current problems can be formalized as an adversarial non-Bernoulli bandit with an unknown budget. I don't think the architect conducting the literature review is going to produce better or faster work if he went from 50 to 80 hours a week. Second, even when everyone's got their shovels out, there isn't a linear relationship between hours and project velocity. At some point the marginal productivity per hour plateaus and, after that, quality issues and technical debt start piling up. A team with the ability to intellectually come up for air is a team that is going to deliver a better strategy, a better design, a better experience and ultimately a better product. I'd rather take an extra six months to get to market than have to pivot half a dozen times (I say, as they box up the startup next door -- sure, they shipped fast, but their strategy and their product failed, and they found that you can't get your Series A subscribed to when you have zero market energy). I do think that for some people there's an idea that work-life balance (and I refuse to use scare quotes) shows insufficient commitment or hustle. But would you want a surgeon who boasts about how fast he can cut a patient open, rather than his or her postoperative results? An engineer who can whip out a bridge design in half the time with only a 10% higher catastrophic failure rate? Are we so insecure in the intellectual value of what we do that we have to brag about how hard we work instead of the value we bring? I disagree. What we do is difficult, and it is intellectually challenging. If a project demands that the dev team work 10, 14, even 16 hour days through the project timeline (and I've been in all three of those positions), then there's something wrong with the project, the taskings, or the stakeholders. We are professionals. We are intellectuals. We are not measured by the sum of our hours, but the result of our efforts. Take pride in yourself, because when you're a manager -- if you're not one already -- you need to take pride in your team.

by seiji 11y ago

sgk284 11y ago

Define "better work"? Sounds like that second situation will lead to some crappy architecture with bug-ridden code. The rocket will likely fail and explode. Meanwhile in the first scenario you've got breathing room to build some truly beautiful code that will pay dividends as the upfront cost is amortized over a decade of reuse. We see similar results in academia, where incredible research can be done because there is predictability and reliability in the environment in which it is being performed. High-stress rushed environments just lead to shitty work/life balance and, at best, mediocre solutions that will provide a stop-gap solution until there is time to do something better. Look at the incredible output from engineers at Google, Facebook, etc... Most tech companies do their best work once they've removed stress and timeline pressure from the equation. The trick is to get to that as early as possible in the company's life.

seiji 11y ago
It's about purpose. Either you are basically a human robot doing spec work or you can drive your own creative output for goals larger than yourself. People don't know what they are capable of until they are pushed beyond limits they thought they had. The future isn't made by cautious people, it's made by being better than anybody thought could be accomplished. "Create advertising units for campaign 3,401 of 16,032" isn't something where "beautiful" or "meaningful" comes into play. It's just drone work. get to that as early as possible in the company's life. We don't model startups on how a 30,000 employee company works. Completely different beasts.

HillRat 11y ago

Pretty sure the latter situation ends with homeless engineers and dead test pilots. Einstein developed his seminal theories working as a patent clerk; not sure you can argue without evidence that an insane, high-stress workload is conducive to anything other than burnout.

seiji 11y ago
You do realize this is the website for 80-hour-work-week, launch-startup-in-3-months fans, right? This isn't the place for nonsensical "work life balance" (which really means "i'm lazy and don't want to do good work, i just want to waste everybody else's time").
- HillRat 11y ago
  No one's ever going to see this, but I feel like your reply merits a response. I believe, simply put, that hours-per-week are as useful a metric of progress as SLOC. The fact is that for any nontrivial development effort, adding work hours does not noticeably improve time to delivery and, in fact, starts to degrade progress. There are a few reasons for this. First, the most important effort in any significant project takes place before anyone starts slinging code. Design and strategy are obvious examples, but programming problems of sufficient complexity also don't benefit from throwing hours at them. For example, one of our current problems can be formalized as an adversarial non-Bernoulli bandit with an unknown budget. I don't think the architect conducting the literature review is going to produce better or faster work if he went from 50 to 80 hours a week. Second, even when everyone's got their shovels out, there isn't a linear relationship between hours and project velocity. At some point the marginal productivity per hour plateaus and, after that, quality issues and technical debt start piling up. A team with the ability to intellectually come up for air is a team that is going to deliver a better strategy, a better design, a better experience and ultimately a better product. I'd rather take an extra six months to get to market than have to pivot half a dozen times (I say, as they box up the startup next door -- sure, they shipped fast, but their strategy and their product failed, and they found that you can't get your Series A subscribed to when you have zero market energy). I do think that for some people there's an idea that work-life balance (and I refuse to use scare quotes) shows insufficient commitment or hustle. But would you want a surgeon who boasts about how fast he can cut a patient open, rather than his or her postoperative results? An engineer who can whip out a bridge design in half the time with only a 10% higher catastrophic failure rate? Are we so insecure in the intellectual value of what we do that we have to brag about how hard we work instead of the value we bring? I disagree. What we do is difficult, and it is intellectually challenging. If a project demands that the dev team work 10, 14, even 16 hour days through the project timeline (and I've been in all three of those positions), then there's something wrong with the project, the taskings, or the stakeholders. We are professionals. We are intellectuals. We are not measured by the sum of our hours, but the result of our efforts. Take pride in yourself, because when you're a manager -- if you're not one already -- you need to take pride in your team.