| Yet you can do a few simple thought experiments. What would those fast-dev do in a vacuum? Or with only clone of themselves coworkers. What happens when one of those fast-dev quit? -- If everything is/would be fine, then yes, they are truly rockstars (in all the good meanings of that word and none of the bad). Or maybe merely decent among mediocre ones. Otherwise, there is a free-rider aspect in their approach. -- Also it can work only depending on the criticality level of the industry. Ship broken crap quickly (but fix it quickly too)? Good if you are creating yet another social website maybe. Less good for e.g. medical devices. -- One more point: the business value approach is not necessarily the only one to apply esp. if there are tech infrastructure components in what you ship. You can easily be stuck in local optimums too far from global ones, and fossilize some aspects of your product. See for example the classical http://blog.zorinaq.com/i-contribute-to-the-windows-kernel-w... that includes some example of death by thousands cut. What I mean is that moving fast is partly in the eye of the evaluator. Maybe you implement what PM wants quickly, and that's cool, but maybe also doing only what PM wants is not the best thing for the project. -- If you are easily able to plan things, have a good data model, and can develop quickly, probably you don't have a real code quality problem to begin with. At least not in the parts you contribute to. I don't actually distinguish the data model from "code" that much: it's all design. -- Final last thought: imagine you are actually a good fast-dev like you describe, and your colleagues are less good, but imagine a case where the whole organization would actually benefit from you slowing down a bit and working on developing better way to work more efficiently with others or making them improve, overall yielding even more business value at the end. This can happen too. |
Well considering my assertion is the dev is just fast and producing the same quality as others. Carry on working.
> What happens when one of those fast-dev quit?
The company would need to replace them or have the team produce less work due to less works?
> Final last thought: imagine you are actually a good fast-dev like you describe, and your colleagues are less good, but imagine a case where the whole organization would actually benefit from you slowing down a bit and working on developing better way to work more efficiently with others or making them improve, overall yielding even more business value at the end. This can happen too.
This seems like "What if, it is better that you don't do the job you were hired for but do a higher job without getting promoted and recognised for your skills?". Well one, is if a company wants their fast dev to teach others they should make them a coach or something along those lines. Secondly, just because they're fast doesn't mean they can teach, sometimes the reason they're fast is they have less interactions with people and therefore able to continually code without having to stop to talk to Jenny from Admin about how important a bug is (not actually a devs job, there should be product/project management for this).Maybe fast dev is fast because they've been there for longer and understand the system, then it's just a case of other devs need to ramp up. Lastly, maybe the fast dev doesn't want to do this other role and just likes programming.