7 ms·

All jobs have some amount of grind. Being able to acknowledge its going to suck and push through it quickly can be super beneficial to your career. It's also

All jobs have some amount of grind. Being able to acknowledge its going to suck and push through it quickly can be super beneficial to your career. It's also one of the reasons why I encourage those in high school or college to try a non technical job first. Learn to appreciate doing monotonous tasks well.

_red 8y ago
As a manager of a dev group, I've migrated away from trying to hire "10x developers" and now optimize for "intelligent and persistent". The "10x" developers are seductive, and can supercharge a project into getting version 1.0 off the ground in months instead of years. However, each one we've hired has left us worse off than before once they got bored and left us in the weeds trying to piece together what they had done. Most of them suffer from "shiny ball" syndrome and are constantly dismayed by the complexities of the real world. The real world is a grind, filled with edge-cases, filled with needing to make 1-off exceptions, etc. These types of developers tend to hate that, and prefer the abstract beauty of their elegant and simple solutions....and when the real world crashes into their elegant creations, they get 'burned out' and jump ship. I'm not blaming them, its just an observation. These 10x developers can be a godsend to a brand new startup, but past a 1.0 product, they can subtly turn into a liability fairly quickly.
- astrodust 8y ago
  Unless you can coach and pivot someone from that "must make everything perfect" mentality to one where they can take a more pragmatic approach to things.
  - kradroy 8y ago
    This is really hard. Really hard. It can take years to get an engineer to that sweet spot. When I build teams I usually select "builders" and "improvers." Improvers can't create new systems because they spend all day theorizing edge cases and what-ifs. Builders can't improve systems because they spend all day theorizing new systems to replace the legacy one they see as imperfect. You also have to get the right ratio of those two. Too many builders gets you a lot of brittle systems and a huge JIRA backlog; too many improvers creates stagnation.
    - ballpark 8y ago
      I've never heard it stated that way, but I can strongly identify with this. After 18 yrs in the industry, I am finding more and more that I enjoy improving much more than building.
    - astrodust 8y ago
      This is part of a larger spectrum of developer preferences: openers, sustainers and closers. Openers want to create new things, they love a blank canvas. Where some people are scared of this, they thrive in a place where you can lay down rules, define parameters, and create structures that are a good fit for the problem domain. Sustainers like to work within a project that's evolving, but largely defined, where they can get a lot of things done and move the ball forward. They may create more work along the way, go on excursions, but the overall direction is roughly towards the goal. They have to make many compromises along the way. Closers like finishing things, closing out bugs, wrapping up features, taking care of a myriad of loose ends and "TODO" type tasks. They're interested in completing work, not creating more work. This is where you have to make harsh judgement calls, implement ugly hacks, anything to wrap things up. It's rare you'll find someone who excels at or even likes to do all three. We often have our bias.
      - kradroy 8y ago
        I disagree that "closer" is a distinct class. It's a necessary aspect in any class. In most companies if you don't "close", you get fired or put on a PIP (and you don't get coffee). There is another class that at some companies where closing isn't necessarily expected: "tinkerer". They just mess around with various projects to learn and make suggestions, but they don't have to close to keep their job.
        astrodust 8y ago
        I'm trying to distinguish between responsibilities and obligations, which you're forced to adhere to, and affinity. Anyone can close if they're forced to, but some people actually like it. Clear objectives, solutions need to be focused, etc.
- friendly_chap 8y ago
  That's not a 10x developer if they don't know how to write maintanable software, you just thought they are. The dev you describe sounds like a junior who can crank out code at high velocity.
  - rcavezza 8y ago
    This is so interesting. I have met many people that others considered "geniuses" because they solved hard problems and got things done fast. And then 3 years later, people still complain about having to deal with "[Name of Developer] Code". I guess if you move fast and write code that others can't read, it's easy to get labeled a genius.
    - saiya-jin 8y ago
      Yeah, I kind of moved of definition of good code from cool-smart-novel approach to something as simple as possible, that almost anybody can pick up, maintain and improve. This has various aspects - cleanness of the code, comments of algorithms/edge cases, overall structure, modularity etc. Syntactic sugar can't impress me anymore, unless it comes with significant performance gains or compress the code significantly without sacrificing readability to average Joe coder (this is important part). Actually I prefer 1 page of simple clean code to 1/2-liners that do it all, until they don't. I guess I am getting old.
    - Swizec 8y ago
      > And then 3 years later, people still complain about having to deal with "[Name of Developer] Code" You're saying their code was so good it survived 3 years of real world use and project evolution. That's extremely rare.
      - slededit 8y ago
        Counter intuitive, like the "put the armor where the bullet holes aren't" story about WWII bombers.
  - AWildC182 8y ago
- nine_k 8y ago
  It takes repetition: code is a liability. The less code you produce to solve your problem, the better. OTOH there is a cycle I see everywhere, all the time: * A first generation of anything is bare-bones, with multiple deficiencies and corners cut, with important parts held together by duct tape. * A second generation of the same thing tries to fix everything, adds reams of missing features, and ends up being an over-complicated, bloated monster [second system]. * A third generation of the same thing builds on the knowledge gained so far, refines the ideas, throws away all the unneeded parts, and organizes the few necessary parts elegantly and reliably. (I use indefinite articles before "first", "second", and "third", because each may take much more than one iteration.) Your hyper-productive developers likely produce the first two varieties. This may still be very useful, if they allow the business to grow. They as well may introduce too many technical problems and operation costs, and thus be detrimental to the business, too. [second system]: http://wiki.c2.com/?SecondSystemEffect http://wiki.c2.com/?SecondSystemEffect (Edited: typos.)
- SilasX 8y ago
  I think there's "10x" and then there's real 10x. Fake 10x: Turns out lots of stuff quickly but it crumples under edge cases and has non-obvious tight couplings that keep biting you. No one else can make changes to their code. None of their stuff can really be used when they leave the company, but they can fix it really fast. Real 10x: Is able to explain what they did and why bugs happened. Easy to follow along in their code, you get the impression the job was easy. You constantly find yourself turning to their old solution, when it really matters, rather than the new way everyone's trying to migrate to. Suggests ways their existing system can handle new business use-cases with only a trivial modification. You keep trying to improve upon their work but keep concluding that there was a good reason for all their decisions. Depending on the context, someone might be referring to one or the other.
  - taneq 8y ago
    Exactly. There are cowboys and then there are master crafters. Both will rapidly produce awesome results, but the cowboy's results are messy, fragile and temperamental, while the master crafter's results are robust and easy to understand.
  - tomaskafka 8y ago
    This. I understand 10x as a kind of person who creates MapReduce and writes very convenient abstraction around it that anyone can use and become 2x.
mlevental 8y ago
learning to appreciate monotonous tasks is too zen/enlightened (like someone in another thread weeks ago saying they enjoyed washing to dishes) and therefore sets the bar too high. but learning to persist and endure (by way of coping mechanisms e.g. music, short breaks) is very possible.
- bootsz 8y ago
  There's also different kinds of boring/tedious though. I'd argue it's much easier to learn to enjoy washing your dishes at home than it is to enjoy slogging through trying to grok horrible legacy code. Maybe that's just me though.
  - chrstphrhrt 8y ago
    I agree. Especially if there are other teammates who defend the bad codebase because of their association to it. Nobody should claim washing dishes is inherently wasteful or pointless. Legacy code on the other hand, comes with a lot of social pressure to just layer on more debt.
    - devonkim 8y ago
      Maybe I’m just weird but I’ve never really defended my code because I never found defensiveness to be helpful for moving projects forward. In fact, most of the code I’ve put out in my career has been rushed under pressure to deliver something fast so most of the time I’m distancing myself from the work usually saying “that wasn’t written by me, it was my evil twin that comes out at 2 am.” Trying to fix the problems of the past that keeps your codebase from improving at a better pace isn’t something shameful to me as much as a matter of pride - that you have learned from your mistakes and are not above reproach. The best stuff for me is what I do after iterating many times without fear of breaking anything though and that’s exactly what you would hope from a codebase matured through TDD.
- joshdev 8y ago
  That's fair. When I say appreciate, I mean the results of the grind. Washing Dishes or any type of cleaning isn't fun, but finding coping mechanisms (zoning out, music, etc...) you can enjoy the results.
JustSomeNobody 8y ago
I agree. A lot of the devs I know who had non tech jobs have a better appreciation for business decisions and management than do those that just went into a dev job.
sonnyblarney 8y ago
"All jobs have some amount of grind" Almost all real jobs are mostly grind. Even startups ... a good one, is 99% stupid, annoying details, some of which would be fun if you were not so busy. Airtable. What a cool app! In the news today. "But I have to get fing xyz done fing now, so abc can ship out to Hong Kong before 5 hurry up!" So there's not time to search, explore, try it out, it's just a very rapid short query to figure out the essential basics and move on. Early stage is all a grind and there's nary a moment in between. Apologies for the language.

_red 8y ago

As a manager of a dev group, I've migrated away from trying to hire "10x developers" and now optimize for "intelligent and persistent". The "10x" developers are seductive, and can supercharge a project into getting version 1.0 off the ground in months instead of years. However, each one we've hired has left us worse off than before once they got bored and left us in the weeds trying to piece together what they had done. Most of them suffer from "shiny ball" syndrome and are constantly dismayed by the complexities of the real world. The real world is a grind, filled with edge-cases, filled with needing to make 1-off exceptions, etc. These types of developers tend to hate that, and prefer the abstract beauty of their elegant and simple solutions....and when the real world crashes into their elegant creations, they get 'burned out' and jump ship. I'm not blaming them, its just an observation. These 10x developers can be a godsend to a brand new startup, but past a 1.0 product, they can subtly turn into a liability fairly quickly.

astrodust 8y ago
Unless you can coach and pivot someone from that "must make everything perfect" mentality to one where they can take a more pragmatic approach to things.
- kradroy 8y ago
  This is really hard. Really hard. It can take years to get an engineer to that sweet spot. When I build teams I usually select "builders" and "improvers." Improvers can't create new systems because they spend all day theorizing edge cases and what-ifs. Builders can't improve systems because they spend all day theorizing new systems to replace the legacy one they see as imperfect. You also have to get the right ratio of those two. Too many builders gets you a lot of brittle systems and a huge JIRA backlog; too many improvers creates stagnation.
  - ballpark 8y ago
    I've never heard it stated that way, but I can strongly identify with this. After 18 yrs in the industry, I am finding more and more that I enjoy improving much more than building.
  - astrodust 8y ago
    This is part of a larger spectrum of developer preferences: openers, sustainers and closers. Openers want to create new things, they love a blank canvas. Where some people are scared of this, they thrive in a place where you can lay down rules, define parameters, and create structures that are a good fit for the problem domain. Sustainers like to work within a project that's evolving, but largely defined, where they can get a lot of things done and move the ball forward. They may create more work along the way, go on excursions, but the overall direction is roughly towards the goal. They have to make many compromises along the way. Closers like finishing things, closing out bugs, wrapping up features, taking care of a myriad of loose ends and "TODO" type tasks. They're interested in completing work, not creating more work. This is where you have to make harsh judgement calls, implement ugly hacks, anything to wrap things up. It's rare you'll find someone who excels at or even likes to do all three. We often have our bias.
    - kradroy 8y ago
      I disagree that "closer" is a distinct class. It's a necessary aspect in any class. In most companies if you don't "close", you get fired or put on a PIP (and you don't get coffee). There is another class that at some companies where closing isn't necessarily expected: "tinkerer". They just mess around with various projects to learn and make suggestions, but they don't have to close to keep their job.
      - astrodust 8y ago
        I'm trying to distinguish between responsibilities and obligations, which you're forced to adhere to, and affinity. Anyone can close if they're forced to, but some people actually like it. Clear objectives, solutions need to be focused, etc.
friendly_chap 8y ago
That's not a 10x developer if they don't know how to write maintanable software, you just thought they are. The dev you describe sounds like a junior who can crank out code at high velocity.
- rcavezza 8y ago
  This is so interesting. I have met many people that others considered "geniuses" because they solved hard problems and got things done fast. And then 3 years later, people still complain about having to deal with "[Name of Developer] Code". I guess if you move fast and write code that others can't read, it's easy to get labeled a genius.
  - saiya-jin 8y ago
    Yeah, I kind of moved of definition of good code from cool-smart-novel approach to something as simple as possible, that almost anybody can pick up, maintain and improve. This has various aspects - cleanness of the code, comments of algorithms/edge cases, overall structure, modularity etc. Syntactic sugar can't impress me anymore, unless it comes with significant performance gains or compress the code significantly without sacrificing readability to average Joe coder (this is important part). Actually I prefer 1 page of simple clean code to 1/2-liners that do it all, until they don't. I guess I am getting old.
  - Swizec 8y ago
    > And then 3 years later, people still complain about having to deal with "[Name of Developer] Code" You're saying their code was so good it survived 3 years of real world use and project evolution. That's extremely rare.
    - slededit 8y ago
      Counter intuitive, like the "put the armor where the bullet holes aren't" story about WWII bombers.
- AWildC182 8y ago
nine_k 8y ago
It takes repetition: code is a liability. The less code you produce to solve your problem, the better. OTOH there is a cycle I see everywhere, all the time: * A first generation of anything is bare-bones, with multiple deficiencies and corners cut, with important parts held together by duct tape. * A second generation of the same thing tries to fix everything, adds reams of missing features, and ends up being an over-complicated, bloated monster [second system]. * A third generation of the same thing builds on the knowledge gained so far, refines the ideas, throws away all the unneeded parts, and organizes the few necessary parts elegantly and reliably. (I use indefinite articles before "first", "second", and "third", because each may take much more than one iteration.) Your hyper-productive developers likely produce the first two varieties. This may still be very useful, if they allow the business to grow. They as well may introduce too many technical problems and operation costs, and thus be detrimental to the business, too. [second system]: http://wiki.c2.com/?SecondSystemEffect http://wiki.c2.com/?SecondSystemEffect (Edited: typos.)
SilasX 8y ago
I think there's "10x" and then there's real 10x. Fake 10x: Turns out lots of stuff quickly but it crumples under edge cases and has non-obvious tight couplings that keep biting you. No one else can make changes to their code. None of their stuff can really be used when they leave the company, but they can fix it really fast. Real 10x: Is able to explain what they did and why bugs happened. Easy to follow along in their code, you get the impression the job was easy. You constantly find yourself turning to their old solution, when it really matters, rather than the new way everyone's trying to migrate to. Suggests ways their existing system can handle new business use-cases with only a trivial modification. You keep trying to improve upon their work but keep concluding that there was a good reason for all their decisions. Depending on the context, someone might be referring to one or the other.
- taneq 8y ago
  Exactly. There are cowboys and then there are master crafters. Both will rapidly produce awesome results, but the cowboy's results are messy, fragile and temperamental, while the master crafter's results are robust and easy to understand.
- tomaskafka 8y ago
  This. I understand 10x as a kind of person who creates MapReduce and writes very convenient abstraction around it that anyone can use and become 2x.

mlevental 8y ago

learning to appreciate monotonous tasks is too zen/enlightened (like someone in another thread weeks ago saying they enjoyed washing to dishes) and therefore sets the bar too high. but learning to persist and endure (by way of coping mechanisms e.g. music, short breaks) is very possible.

bootsz 8y ago
There's also different kinds of boring/tedious though. I'd argue it's much easier to learn to enjoy washing your dishes at home than it is to enjoy slogging through trying to grok horrible legacy code. Maybe that's just me though.
- chrstphrhrt 8y ago
  I agree. Especially if there are other teammates who defend the bad codebase because of their association to it. Nobody should claim washing dishes is inherently wasteful or pointless. Legacy code on the other hand, comes with a lot of social pressure to just layer on more debt.
  - devonkim 8y ago
    Maybe I’m just weird but I’ve never really defended my code because I never found defensiveness to be helpful for moving projects forward. In fact, most of the code I’ve put out in my career has been rushed under pressure to deliver something fast so most of the time I’m distancing myself from the work usually saying “that wasn’t written by me, it was my evil twin that comes out at 2 am.” Trying to fix the problems of the past that keeps your codebase from improving at a better pace isn’t something shameful to me as much as a matter of pride - that you have learned from your mistakes and are not above reproach. The best stuff for me is what I do after iterating many times without fear of breaking anything though and that’s exactly what you would hope from a codebase matured through TDD.
joshdev 8y ago
That's fair. When I say appreciate, I mean the results of the grind. Washing Dishes or any type of cleaning isn't fun, but finding coping mechanisms (zoning out, music, etc...) you can enjoy the results.

JustSomeNobody 8y ago

I agree. A lot of the devs I know who had non tech jobs have a better appreciation for business decisions and management than do those that just went into a dev job.

sonnyblarney 8y ago

"All jobs have some amount of grind" Almost all real jobs are mostly grind. Even startups ... a good one, is 99% stupid, annoying details, some of which would be fun if you were not so busy. Airtable. What a cool app! In the news today. "But I have to get fing xyz done fing now, so abc can ship out to Hong Kong before 5 hurry up!" So there's not time to search, explore, try it out, it's just a very rapid short query to figure out the essential basics and move on. Early stage is all a grind and there's nary a moment in between. Apologies for the language.