6 ms·

I've had similar self-doubt in the past, I considered myself fast but sloppy. I changed my opinion after a workshop on different team roles at my previous job.

I've had similar self-doubt in the past, I considered myself fast but sloppy. I changed my opinion after a workshop on different team roles at my previous job. A lot of it was boring workshop fluff, but I loved the core message: that many personality traits aren't purely positive or negative. Perfectionists are nitpickers. Fast developers are sloppy. Experienced ones overthink stuff. Bleeding-edge evangelists ruin long-term stability etc. There are two sides to every coin. We tend to value traits we have (or desire) and judge people based on that, but it really depends on the team and the task. Need a quick-and-dirty prototype ASAP? Give it to the framework hipster. Planning architecture for a complex long-term project? Ask the boring slow guy with 20 years experience. Build teams with enough variety and try to solve problems through process. Don't scold the fast guy for being sloppy, give him tasks that require speed and solve bugs with better QA and tests. TL;DR: A damage dealer will beat a healer one on one, but that doesn't mean he's better. You need them both (plus a tank) to run a dungeon successfully.

pizzacowboy 10y ago
This is a great perspective. Although, sometimes, a poorly spec'ed tank is worth pretty much his weight in garbage. :)
pducks32 10y ago
I consider myself meticulous but slow. My coworker and I often talk about he differences and I always have wish I cared less about certain things and prioritized time more while he likes hat I focus heavily on maintainability and clarity.
- rocqua 10y ago
  If traits have downsides and upsides, we get used to the upside and yearn for solving the downsides. In this yearning, we almost wish to give up our strengths so as to alleviate our weaknesses.
devoply 10y ago
Often the people judging us as good or bad are idiots that know nothing of what we do.
Fiahil 10y ago
As a healer, I love running donjons with good DPS. I often come and go, sponge their stress, and unfreeze them when they're stuck. In exchange, they sometimes review some of my pull requests and give options/advices when I need them. Just like sharks and pilot fishes.
hyperpallium 10y ago
Tradeoffs (like: two of fast/good/cheap) are legitimate, depending on the task. Though we each have preferences, talents and skills for particular tradeoffs, a lone individual developer will need to adapt. e.g. the quick and dirty prototype or "tracer bullet" to understand the problem/technology and/or the client/user needs; vs the second version that actually solves the problem or meets the needs; vs. factoring out reusable library modules.
Axiverse 10y ago
I agree with your assessment. As you get experienced, I think it's beneficial to be able to learn to be both fast/sloppy and slow/meticulous given the circumstances. Having worked in both enterprise scenarios and startup environments, I've learned that it's really a result of larger environmental pressures. If you're working in long-range software, it's by far more beneficial to be a bit slower and more meticulous in your approach. What you're really looking for is incremental improvements that have large impact because the scale or importance of the project is already established to be very big. While you feel like you're not getting much done, the impact multiplier in these situations is very large. However, when you're in a startup environment, you don't have any value in the product yet, so you have to move fast. A few bugs here and there are not really a problem since you will probably redesign and revamp different features. Testing is a lower priority and you feel like you're moving a lot faster as a developer. I think healthy teams have a healthy spread on these trade-offs, centered about around the maturity of the team/product/company. Tension between the two sides keeps things moving forward and allows adjustments to keep the machine moving forward as best it can.
- WWLink 10y ago
  You know what sucks ass though? The 10x developer that isn't actually a 10x developer, but continually gets to start projects! So they get to do that part where you can make 80% of the program in 20% of the time. They slap it together, and move on to the next big thing. Leaving everyone else to clean up their rushed mess that barely works.
  - candiodari 10y ago
    That's probably the appropriate way to tackle new projects, you know. Most ideas suck. Therefore the first (few) versions of such software is perfectly reasonable if it's rushed. I hate that I work at a big company and we get into new project discovery mode and then take 3-5 weeks to code up extremely over complicated prototype programs. But they have tests (usually more than code), they have "good design", they have code that's reviewed and sent back at least thrice, they're stable, they've got monitoring, ... And they take huge amounts of time. The one quality all of that has is that everybody agrees it's a good idea. When trying to quantify what that means ... I completely fail. The design always fails to account for something. I have had it happen once that the initial design actually lasted to "v1.0", in 3 years. So I'm becoming unsure what makes a design good, except everyone agreeing that it's good and a certain "clean" look there is no difference between a good and bad, clean and messy, thought through and ad-hoc. Good designs don't survive a few feature iterations any better than bad designs, but they impose lots of extra costs on feature iterations. And that's assuming people don't make the mistake that turns the best of good designs into horrible designs : sticking to it. Attempting to fit new features into a design that didn't account for them can make the most beautiful design an utter disaster. Same thing about reviews. Reviews seem to make people make huge changes in one go, because that feels much better if people regularly argue about much of it, compared to having to redo a change that by the time it's reviewed 5 other things depend on, where you get to throw out the 5 other things. And of course fairly commenting on huge changes is not done because pretty soon you'll feel guilty about the amount of work you're causing. Which is exactly why people have a better experience making huge changes, of course. Tests ... never prevent bugs. Now I'm not saying tests don't have value, but the current testing culture is utterly and completely broken. I've simply decided to hack the system : a cli to your methods that allow you to quickly do ad-hoc tests and record them into generated code. Why ? First, it allows you to test against real-world data, which means your idea of what your code does actually meets real world data instead of artificial cases that may miss the point in the same way your code does. Second it allows you to quickly regenerate the tests if there is some big change needed. And thirdly it completely hacks the system. Getting coverage is trivial. And your LOC stats will be through the roof. Double bonus if you do this for less-than-expressive languages like C and Go, it's less necessary for things like Java and C++. But "best practices" seem to make everyone happy in big companies, make everything take very long, and because of that very often cause the failure they're trying to prevent. It's like in chess : people like "safe" moves once you've beaten them once or twice. And in 10 moves or so they get themselves into a situation where they have to give up that safety, and your "haphazard" moves turns out control 80% of the board and fighting from that situation is not going to go well. But it's the desire for safety, the fear of loss, that's exactly what's causing their loss. They don't see things this way, though. If only they'd moved this piece to cover that as well, then it would have been fine. It doesn't even seem to matter if you show them that no, it wouldn't have been fine. That the issue was their attempt at securing what they did resulted in a complete takeover by the other party. And every attempt I make at changing this fails, often with people having emotional breakdowns and complaints. And then their projects fail, again and again. Multiple times people have been very angry at me for providing a solution to some problem they were doing a 2 year project, restarted from scratch 3 times, for by writing a 300 line script that utterly kills interest in their project because it works and solves the problem. Apparently that "violates trust". I don't understand why businesses want this. It keeps the peace, yes, practices like this, at the cost of efficiency, at the cost of developer sanity (developers wash out after about 5 years despite the current employment conditions, and often become non-developers. Hell, several people I know became accountants and prefer it over software development. Seriously). And despite this, people seem to further down the rabbit hole every time I seem to look at it. WTF ?
fnordsensei 10y ago
This reminds me of Strengthsfinder[1], that came out of Gallup as the result of a lengthy study. Basically it said that loads of time and effort is wasted by managers trying to fix the flaws of individuals. The alternative, they argue, is focusing on building teams where the members bring complementary strengths to the table, and then working on how to make the most of an individual's strength in relation to the context of the group. Let's optimise the throughput of the team instead of maximizing the resource use of individuals. Just because you maximize the the amount of code written by each individual doesn't mean that you've optimized the throughput of the team: sometimes the opposite is true. They're orthogonal concerns, but they're treated as if the former magically creates there latter. [1]: http://strengths.gallup.com/110440/About-StrengthsFinder-20.aspx http://strengths.gallup.com/110440/About-StrengthsFinder-20....
edem 10y ago
> TL;DR: A damage dealer will beat a healer one on one, but that doesn't mean he's better. You need them both (plus a tank) to run a dungeon successfully. I haven't played a single game where this was true. Simply because both the healer and the damage dealer can do damage but only a healer can heal.
- palunon 10y ago
  It's true in EVE. The an army of the most powerful damages dealers in the game would be overwhelmed by an army with a decent composition...
  - user5994461 10y ago
    The initial message said in one-on-one.
- Buge 10y ago
  I guess it would depend on whether the healer can heal himself or only teammates.
  - edem 10y ago
    I am yet to see a game where the healer cannot heal himself.
    - ManlyBread 10y ago
      Team Fortress 2 before the class updates
- webmaven 10y ago
  If the healer and damage-dealer are at an equivalent level, the healer may be damaged too quickly for them to heal themselves, or they may be able to do nothing but heal themselves. Put another way, two healers vs. one damage dealer are more likely to be evenly matched than the other way around.
user5994461 10y ago
> Need a quick-and-dirty prototype ASAP? Give it to the framework hipster. So that he can make the prototype with the newest hipster tech that noone else knows in the company and will probably be abandoned next year...
- rexpop 10y ago
  Yeah, just in time to validate the business case.
user5994461 10y ago
> Don't scold the fast guy for being sloppy, give him tasks that require speed and solve bugs with better QA and tests. What if we're in finance industry working on critical systems and a bug mean millions dollars lost? Should we hire "sloppy" at all? I think not.
- rexpop 10y ago
  Yup. You are right. The model holds. ...unless you've an R&D department dedicated to experimenting — non-critically — with myriad, "creative" algorithms or solutions. Then, hey, don't give 'em write permissions, but let 'em read and let 'em rip!
- webmaven 10y ago
  > What if we're in finance industry working on critical systems and a bug mean millions dollars lost? Should we hire "sloppy" at all? For maintaining business critical systems? Obviously not. But not everything in the finance industry requires that sort of stability and uptime. There are needs around prototyping new products and services for customers, for example. Not to mention ferreting out Excel spreadsheets being used in unconventional ways and creating intranet web-apps to better fill those unmet needs.
mathgenius 10y ago
In my experience it is the young inexperienced dev (framework hipster) that is uptight and takes forever to get something to work. The older dude is the one that doesn't care and will hack something together in record time (because he knows it is gonna get chucked out tomorrow anyway.)
grogenaut 10y ago
Mei pretty much takes down everyone 1v1 and she's just a well rounded gal.

pizzacowboy 10y ago

This is a great perspective. Although, sometimes, a poorly spec'ed tank is worth pretty much his weight in garbage. :)

pducks32 10y ago

I consider myself meticulous but slow. My coworker and I often talk about he differences and I always have wish I cared less about certain things and prioritized time more while he likes hat I focus heavily on maintainability and clarity.

rocqua 10y ago
If traits have downsides and upsides, we get used to the upside and yearn for solving the downsides. In this yearning, we almost wish to give up our strengths so as to alleviate our weaknesses.

devoply 10y ago

Often the people judging us as good or bad are idiots that know nothing of what we do.

Fiahil 10y ago

As a healer, I love running donjons with good DPS. I often come and go, sponge their stress, and unfreeze them when they're stuck. In exchange, they sometimes review some of my pull requests and give options/advices when I need them. Just like sharks and pilot fishes.

hyperpallium 10y ago

Tradeoffs (like: two of fast/good/cheap) are legitimate, depending on the task. Though we each have preferences, talents and skills for particular tradeoffs, a lone individual developer will need to adapt. e.g. the quick and dirty prototype or "tracer bullet" to understand the problem/technology and/or the client/user needs; vs the second version that actually solves the problem or meets the needs; vs. factoring out reusable library modules.

Axiverse 10y ago

I agree with your assessment. As you get experienced, I think it's beneficial to be able to learn to be both fast/sloppy and slow/meticulous given the circumstances. Having worked in both enterprise scenarios and startup environments, I've learned that it's really a result of larger environmental pressures. If you're working in long-range software, it's by far more beneficial to be a bit slower and more meticulous in your approach. What you're really looking for is incremental improvements that have large impact because the scale or importance of the project is already established to be very big. While you feel like you're not getting much done, the impact multiplier in these situations is very large. However, when you're in a startup environment, you don't have any value in the product yet, so you have to move fast. A few bugs here and there are not really a problem since you will probably redesign and revamp different features. Testing is a lower priority and you feel like you're moving a lot faster as a developer. I think healthy teams have a healthy spread on these trade-offs, centered about around the maturity of the team/product/company. Tension between the two sides keeps things moving forward and allows adjustments to keep the machine moving forward as best it can.

WWLink 10y ago
You know what sucks ass though? The 10x developer that isn't actually a 10x developer, but continually gets to start projects! So they get to do that part where you can make 80% of the program in 20% of the time. They slap it together, and move on to the next big thing. Leaving everyone else to clean up their rushed mess that barely works.
- candiodari 10y ago
  That's probably the appropriate way to tackle new projects, you know. Most ideas suck. Therefore the first (few) versions of such software is perfectly reasonable if it's rushed. I hate that I work at a big company and we get into new project discovery mode and then take 3-5 weeks to code up extremely over complicated prototype programs. But they have tests (usually more than code), they have "good design", they have code that's reviewed and sent back at least thrice, they're stable, they've got monitoring, ... And they take huge amounts of time. The one quality all of that has is that everybody agrees it's a good idea. When trying to quantify what that means ... I completely fail. The design always fails to account for something. I have had it happen once that the initial design actually lasted to "v1.0", in 3 years. So I'm becoming unsure what makes a design good, except everyone agreeing that it's good and a certain "clean" look there is no difference between a good and bad, clean and messy, thought through and ad-hoc. Good designs don't survive a few feature iterations any better than bad designs, but they impose lots of extra costs on feature iterations. And that's assuming people don't make the mistake that turns the best of good designs into horrible designs : sticking to it. Attempting to fit new features into a design that didn't account for them can make the most beautiful design an utter disaster. Same thing about reviews. Reviews seem to make people make huge changes in one go, because that feels much better if people regularly argue about much of it, compared to having to redo a change that by the time it's reviewed 5 other things depend on, where you get to throw out the 5 other things. And of course fairly commenting on huge changes is not done because pretty soon you'll feel guilty about the amount of work you're causing. Which is exactly why people have a better experience making huge changes, of course. Tests ... never prevent bugs. Now I'm not saying tests don't have value, but the current testing culture is utterly and completely broken. I've simply decided to hack the system : a cli to your methods that allow you to quickly do ad-hoc tests and record them into generated code. Why ? First, it allows you to test against real-world data, which means your idea of what your code does actually meets real world data instead of artificial cases that may miss the point in the same way your code does. Second it allows you to quickly regenerate the tests if there is some big change needed. And thirdly it completely hacks the system. Getting coverage is trivial. And your LOC stats will be through the roof. Double bonus if you do this for less-than-expressive languages like C and Go, it's less necessary for things like Java and C++. But "best practices" seem to make everyone happy in big companies, make everything take very long, and because of that very often cause the failure they're trying to prevent. It's like in chess : people like "safe" moves once you've beaten them once or twice. And in 10 moves or so they get themselves into a situation where they have to give up that safety, and your "haphazard" moves turns out control 80% of the board and fighting from that situation is not going to go well. But it's the desire for safety, the fear of loss, that's exactly what's causing their loss. They don't see things this way, though. If only they'd moved this piece to cover that as well, then it would have been fine. It doesn't even seem to matter if you show them that no, it wouldn't have been fine. That the issue was their attempt at securing what they did resulted in a complete takeover by the other party. And every attempt I make at changing this fails, often with people having emotional breakdowns and complaints. And then their projects fail, again and again. Multiple times people have been very angry at me for providing a solution to some problem they were doing a 2 year project, restarted from scratch 3 times, for by writing a 300 line script that utterly kills interest in their project because it works and solves the problem. Apparently that "violates trust". I don't understand why businesses want this. It keeps the peace, yes, practices like this, at the cost of efficiency, at the cost of developer sanity (developers wash out after about 5 years despite the current employment conditions, and often become non-developers. Hell, several people I know became accountants and prefer it over software development. Seriously). And despite this, people seem to further down the rabbit hole every time I seem to look at it. WTF ?

fnordsensei 10y ago

This reminds me of Strengthsfinder[1], that came out of Gallup as the result of a lengthy study. Basically it said that loads of time and effort is wasted by managers trying to fix the flaws of individuals. The alternative, they argue, is focusing on building teams where the members bring complementary strengths to the table, and then working on how to make the most of an individual's strength in relation to the context of the group. Let's optimise the throughput of the team instead of maximizing the resource use of individuals. Just because you maximize the the amount of code written by each individual doesn't mean that you've optimized the throughput of the team: sometimes the opposite is true. They're orthogonal concerns, but they're treated as if the former magically creates there latter. [1]: http://strengths.gallup.com/110440/About-StrengthsFinder-20.aspx http://strengths.gallup.com/110440/About-StrengthsFinder-20....

edem 10y ago

> TL;DR: A damage dealer will beat a healer one on one, but that doesn't mean he's better. You need them both (plus a tank) to run a dungeon successfully. I haven't played a single game where this was true. Simply because both the healer and the damage dealer can do damage but only a healer can heal.

palunon 10y ago
It's true in EVE. The an army of the most powerful damages dealers in the game would be overwhelmed by an army with a decent composition...
- user5994461 10y ago
  The initial message said in one-on-one.
Buge 10y ago
I guess it would depend on whether the healer can heal himself or only teammates.
- edem 10y ago
  I am yet to see a game where the healer cannot heal himself.
  - ManlyBread 10y ago
    Team Fortress 2 before the class updates
webmaven 10y ago
If the healer and damage-dealer are at an equivalent level, the healer may be damaged too quickly for them to heal themselves, or they may be able to do nothing but heal themselves. Put another way, two healers vs. one damage dealer are more likely to be evenly matched than the other way around.

user5994461 10y ago

> Need a quick-and-dirty prototype ASAP? Give it to the framework hipster. So that he can make the prototype with the newest hipster tech that noone else knows in the company and will probably be abandoned next year...

rexpop 10y ago
Yeah, just in time to validate the business case.

user5994461 10y ago

> Don't scold the fast guy for being sloppy, give him tasks that require speed and solve bugs with better QA and tests. What if we're in finance industry working on critical systems and a bug mean millions dollars lost? Should we hire "sloppy" at all? I think not.

rexpop 10y ago
Yup. You are right. The model holds. ...unless you've an R&D department dedicated to experimenting — non-critically — with myriad, "creative" algorithms or solutions. Then, hey, don't give 'em write permissions, but let 'em read and let 'em rip!
webmaven 10y ago
> What if we're in finance industry working on critical systems and a bug mean millions dollars lost? Should we hire "sloppy" at all? For maintaining business critical systems? Obviously not. But not everything in the finance industry requires that sort of stability and uptime. There are needs around prototyping new products and services for customers, for example. Not to mention ferreting out Excel spreadsheets being used in unconventional ways and creating intranet web-apps to better fill those unmet needs.

mathgenius 10y ago

In my experience it is the young inexperienced dev (framework hipster) that is uptight and takes forever to get something to work. The older dude is the one that doesn't care and will hack something together in record time (because he knows it is gonna get chucked out tomorrow anyway.)

grogenaut 10y ago

Mei pretty much takes down everyone 1v1 and she's just a well rounded gal.