6 ms·

So you want to do all the fun work, and pass off the grindy boring shit to someone else, most of which probably results from your "core" coding? I think I would

So you want to do all the fun work, and pass off the grindy boring shit to someone else, most of which probably results from your "core" coding? I think I would hate working with you and you're bringing this on yourself. You might have an inflated idea of how good you are at this shit. If you are really good, you won't have much grindy boring work to do. If you're not taking a major part in the final tasks of a project, how can you be so certain you are good at preparing it for the future?

jhome 13y ago
Sometimes people really do enjoy the "boring" work. We're all different.
- ecnahc515 13y ago
  Definitely. For example, some people call writing tests the boring work, even though they're very important. I have a co-worker who would rather write tests for code on a project he doesn't work on, then write the feature the test is for. He just loves it.
jwoah12 13y ago
> You might have an inflated idea of how good you are at this shit. If you are really good, you won't have much grindy boring work to do. Anyone who has worked on any sort of sufficiently large and complex application knows that this isn't true. Programmers come and go, people have different styles, requirements change, deadlines are imposed, etc. There will always be grunt work, no matter how good a programmer is.
- fragsworth 13y ago
  But he's talking about startups, not large, high-budget projects. If he was good at very large project management he would not be complaining about his problems finding work.
bmelton 13y ago
> If you're not taking a major part in the final tasks of a project, how can you be so certain you are good at preparing it for the future? I'm not the parent, but I'll answer, from my own experience. The "final tasks" of a project aren't important, in the grand scheme of things, at least, not the way that I work. If I have an idea, let's say "Github" for example, what's the core of the application? Whatever your answer, I'd bet you dollars to doughnuts that it isn't "the login page", or "the frequently asked questions", or "what color the navigation bar is". The 'core' of the application is the interface between git and github. That's also, generally speaking, the 'hard part'... and the developer that can take you from a blank screen to a demo, by his or herself, and can deliver that product to market, is the ideal developer. If you can hire a guy that can take you 95% of the way there, and then outsource the fiddly bits like login and navigation to oDesk or whomever, then you've got a real talent. That is the type of developer the parent seems to be describing, at least to me. As to his self-understanding, I dramatically prefer working with developers that know where their limitations are, and know where they're not good. I find myself getting bored with the result of a QA report, and it doesn't excite me. Solving a problem excites me. Tweaking an animation to prevent flickery scrolling on IE7 does not excite me. It took me a lot of years to get from being the 95% guy to the 100% guy, but even my 100%ness is qualified -- it has to be within a given set of parameters. For somebody to acknowledge their weaknesses, in my opinion, demonstrates a higher degree of self-awareness than the average person who doesn't.
- eru 13y ago
  The problem is: the first 95% take 95% of the time, the last 5% take another 95% of the time.
  - bmelton 13y ago
    As far as adages go, that's wholly incomplete, and generally mitigable with good product planning. Either way, if it's taking just as long to write the generic CRUD of your application as it took to write the application itself, either your application is quite trivial, or you're doing something very wrong. In practice, for most people, the "last 5%" doesn't get added in until after deployment, if at all. Regardless, if you're proving a market, and the highest priority is in determining whether or not there's money to be made on a product at all, the 95% guy is an ace in the hole. The GP even admits that yes, the 100% guys are better, but they are indeed far rarer to come across, and usually involves other trade-offs.
deftnerd 13y ago
I respect your opinion, but as some other commentators have pointed out, there is nothing wrong with people knowing their own weaknesses. In fact, my core strength isn't development. I'm good at it, but I'm not great. The 100% guys are great. My core strength is systems administration and building resilient infrastructure. That's my 100% skill. The development stuff is just what I'm doing for my side projects. I dev to 95% minimum-viable-product state and then launch and look at the reaction and shake out the bugs. If the service has no traction, I move on. If it has a customer base, then I slog through the tedious 5% (that takes just as much time) to try to perfect the product... but if I don't need to do it, I won't, because I find it too mind-numbing.

jhome 13y ago

Sometimes people really do enjoy the "boring" work. We're all different.

ecnahc515 13y ago
Definitely. For example, some people call writing tests the boring work, even though they're very important. I have a co-worker who would rather write tests for code on a project he doesn't work on, then write the feature the test is for. He just loves it.

jwoah12 13y ago

> You might have an inflated idea of how good you are at this shit. If you are really good, you won't have much grindy boring work to do. Anyone who has worked on any sort of sufficiently large and complex application knows that this isn't true. Programmers come and go, people have different styles, requirements change, deadlines are imposed, etc. There will always be grunt work, no matter how good a programmer is.

fragsworth 13y ago
But he's talking about startups, not large, high-budget projects. If he was good at very large project management he would not be complaining about his problems finding work.

bmelton 13y ago

> If you're not taking a major part in the final tasks of a project, how can you be so certain you are good at preparing it for the future? I'm not the parent, but I'll answer, from my own experience. The "final tasks" of a project aren't important, in the grand scheme of things, at least, not the way that I work. If I have an idea, let's say "Github" for example, what's the core of the application? Whatever your answer, I'd bet you dollars to doughnuts that it isn't "the login page", or "the frequently asked questions", or "what color the navigation bar is". The 'core' of the application is the interface between git and github. That's also, generally speaking, the 'hard part'... and the developer that can take you from a blank screen to a demo, by his or herself, and can deliver that product to market, is the ideal developer. If you can hire a guy that can take you 95% of the way there, and then outsource the fiddly bits like login and navigation to oDesk or whomever, then you've got a real talent. That is the type of developer the parent seems to be describing, at least to me. As to his self-understanding, I dramatically prefer working with developers that know where their limitations are, and know where they're not good. I find myself getting bored with the result of a QA report, and it doesn't excite me. Solving a problem excites me. Tweaking an animation to prevent flickery scrolling on IE7 does not excite me. It took me a lot of years to get from being the 95% guy to the 100% guy, but even my 100%ness is qualified -- it has to be within a given set of parameters. For somebody to acknowledge their weaknesses, in my opinion, demonstrates a higher degree of self-awareness than the average person who doesn't.

eru 13y ago
The problem is: the first 95% take 95% of the time, the last 5% take another 95% of the time.
- bmelton 13y ago
  As far as adages go, that's wholly incomplete, and generally mitigable with good product planning. Either way, if it's taking just as long to write the generic CRUD of your application as it took to write the application itself, either your application is quite trivial, or you're doing something very wrong. In practice, for most people, the "last 5%" doesn't get added in until after deployment, if at all. Regardless, if you're proving a market, and the highest priority is in determining whether or not there's money to be made on a product at all, the 95% guy is an ace in the hole. The GP even admits that yes, the 100% guys are better, but they are indeed far rarer to come across, and usually involves other trade-offs.

deftnerd 13y ago

I respect your opinion, but as some other commentators have pointed out, there is nothing wrong with people knowing their own weaknesses. In fact, my core strength isn't development. I'm good at it, but I'm not great. The 100% guys are great. My core strength is systems administration and building resilient infrastructure. That's my 100% skill. The development stuff is just what I'm doing for my side projects. I dev to 95% minimum-viable-product state and then launch and look at the reaction and shake out the bugs. If the service has no traction, I move on. If it has a customer base, then I slog through the tedious 5% (that takes just as much time) to try to perfect the product... but if I don't need to do it, I won't, because I find it too mind-numbing.