4 ms·

> "Accept that "the grind" is part of the job" Of all the pieces that struck home for me, this. Especially doing what I'd call my 'dream job', it's 'the grind'

by polemic 14y ago

> "Accept that "the grind" is part of the job" Of all the pieces that struck home for me, this. Especially doing what I'd call my 'dream job', it's 'the grind' that I most struggle with, even if it's ultimately what ends up being the most valuable output. I'd add a line to the effect of: the grind is easier to handle when you keep focused on the outcome of what you're trying to achieve (cool new feature, happier customers, company success). It's easy, as a programmer, to lose sight of the big picture when you're at the never-ending 80% phase of a big development effort.

pjungwir 14y ago
As a friend's dad says, "That's why they call it work."
- alex_doom 14y ago
  Also, "There's a reason they don't call work, fun."
  - TeMPOraL 14y ago
    On the other hand, problems are to be solved, not suffered through.
- mjcohen 14y ago
  Another old saying: "If growing up were fun, I would have done it a long time ago."
derefr 14y ago
Schleps exist, but only some of them are necessary (the ones composing the "problem domain.") Others (usually "infrastructure" problems) are just Gordian knots you can slash apart with the right mindset--usually because someone else has already helpfully solved the same problem during a schlep of their own, and released the result as a library, product, or service you can just slot in (e.g. Stripe.)
tehwalrus 14y ago
> "the never-ending 80% phase of a big development effort." currently suffering through this. I have spent 8 months, on and off, trying to solve a particular problem; this includes implementing 3 or 4 different methods, none of which have worked so far (I am currently tweaking method number 2.) I have been a few days away from something that might work since about January now, and the anticipation/tension/wanting the damn thing to just work is starting to get to me... The big picture - that if this code works it will allow me to generate a thesis-worth of conclusions in a few months - is all that keeps me sane! :) However, at this stage productivity comes in fits and starts - I sometimes need 2-3 days just doing something else before I can bear to look at the code again (being a grad student, I don't really have what you'd call weekends.) See my top-level post about rescue time for what I'm doing about this.
- javajosh 14y ago
  Original research is a little different than ordinary productivity. The OP's article is fantastic, but when it comes to original research, although everything he talks about is essential (having specific goals; staying absolutely focused during work-periods), there is the problem of solving problems that haven't been solved before. Such problems require inspiration. Inspiration, by definition, comes from nowhere. Although, if we're being honest, the research process is really just the process of transforming a big, vague, great idea into a very specific, actionable, pretty good idea. This is, of course, the hard part. It's hard for a few reasons: first, it's always more personally satisfying to hand-wave and get emotional agreement than to motivate calculations and get analytical agreement. But professional satisfaction (cash flow) requires you to attain the later (in our field, this is, essentially, the working code requirement). So you've got to make a choice to prove your idea. Second, demonstrating that an idea is good has an element of risk: the idea may turn out to be bad. You need to be open to this possibility, and take the attitude of the explorer rather than the proud parent. This is probably why researchers start off with an advisor, and even later submit their work to peer review: a third party who is not so attached to your idea can be an invaluable aid in navigating that difficult path between inspiration and demonstration. (And it so happens that this path often leads to learning new things, which is probably why original research is so intertwined with learning and teaching.)

by polemic 14y ago

pjungwir 14y ago

As a friend's dad says, "That's why they call it work."

alex_doom 14y ago
Also, "There's a reason they don't call work, fun."
- TeMPOraL 14y ago
  On the other hand, problems are to be solved, not suffered through.
mjcohen 14y ago
Another old saying: "If growing up were fun, I would have done it a long time ago."

derefr 14y ago

Schleps exist, but only some of them are necessary (the ones composing the "problem domain.") Others (usually "infrastructure" problems) are just Gordian knots you can slash apart with the right mindset--usually because someone else has already helpfully solved the same problem during a schlep of their own, and released the result as a library, product, or service you can just slot in (e.g. Stripe.)

tehwalrus 14y ago

> "the never-ending 80% phase of a big development effort." currently suffering through this. I have spent 8 months, on and off, trying to solve a particular problem; this includes implementing 3 or 4 different methods, none of which have worked so far (I am currently tweaking method number 2.) I have been a few days away from something that might work since about January now, and the anticipation/tension/wanting the damn thing to just work is starting to get to me... The big picture - that if this code works it will allow me to generate a thesis-worth of conclusions in a few months - is all that keeps me sane! :) However, at this stage productivity comes in fits and starts - I sometimes need 2-3 days just doing something else before I can bear to look at the code again (being a grad student, I don't really have what you'd call weekends.) See my top-level post about rescue time for what I'm doing about this.

javajosh 14y ago
Original research is a little different than ordinary productivity. The OP's article is fantastic, but when it comes to original research, although everything he talks about is essential (having specific goals; staying absolutely focused during work-periods), there is the problem of solving problems that haven't been solved before. Such problems require inspiration. Inspiration, by definition, comes from nowhere. Although, if we're being honest, the research process is really just the process of transforming a big, vague, great idea into a very specific, actionable, pretty good idea. This is, of course, the hard part. It's hard for a few reasons: first, it's always more personally satisfying to hand-wave and get emotional agreement than to motivate calculations and get analytical agreement. But professional satisfaction (cash flow) requires you to attain the later (in our field, this is, essentially, the working code requirement). So you've got to make a choice to prove your idea. Second, demonstrating that an idea is good has an element of risk: the idea may turn out to be bad. You need to be open to this possibility, and take the attitude of the explorer rather than the proud parent. This is probably why researchers start off with an advisor, and even later submit their work to peer review: a third party who is not so attached to your idea can be an invaluable aid in navigating that difficult path between inspiration and demonstration. (And it so happens that this path often leads to learning new things, which is probably why original research is so intertwined with learning and teaching.)