5 ms·

I'm probably misunderstanding you, but your example seems like the whole reason Rockstar programmers can be harmful to a team. I agree completely about laziness

by e28eta 13y ago

I'm probably misunderstanding you, but your example seems like the whole reason Rockstar programmers can be harmful to a team. I agree completely about laziness and looking to the future, however. * It sounds like the upfront cost is higher than the simple solution. * I don't think changing the CRM is going to be a common occurrence, so don't optimize for it. YAGNI * I doubt you'll get it right up front. The new CRM is going to require a couple tweaks to the code in addition to a config line change * Maintainer needs to learn the custom layer you've built on top, whose documentation, googleability, and stack overflow support will be much less than the standard libraries. To me, that's what I took away from the article's work horses. They focus their efforts on moving the product forward and maintaining clean code. Sometimes, that means forgoing the fancy engineering challenges. I like this xkcd for trying to keep myself honest: http://xkcd.com/1205/ http://xkcd.com/1205/

agentultra 13y ago
You're absolutely right. It makes far more sense to make the tactical decision to simply change the necessary code to work with the new CRM. I, and I suspect most of us, make the very same decision every day. When your goal is to build a product and ship then tactics, as in chess, will win you the game > 90% of the time. I apologize if my trivial example failed to illustrate my point for you. My point is that part of being a good developer is learning how to avoid doing the same task more than once. Tactical thinking inevitably leads to doing the same things more than once. The best programmers I've had the opportunity to work with rarely had to re-write anything they had to written. They had internalized the paradigms, patterns, and practices to avoid writing code that is brittle to changing requirements. This is what I mean when I say part of being a good developer is learning to cultivate laziness. Focus on the things that matter but learn to internalize ways to avoid making work for yourself.

by e28eta 13y ago

agentultra 13y ago

You're absolutely right. It makes far more sense to make the tactical decision to simply change the necessary code to work with the new CRM. I, and I suspect most of us, make the very same decision every day. When your goal is to build a product and ship then tactics, as in chess, will win you the game > 90% of the time. I apologize if my trivial example failed to illustrate my point for you. My point is that part of being a good developer is learning how to avoid doing the same task more than once. Tactical thinking inevitably leads to doing the same things more than once. The best programmers I've had the opportunity to work with rarely had to re-write anything they had to written. They had internalized the paradigms, patterns, and practices to avoid writing code that is brittle to changing requirements. This is what I mean when I say part of being a good developer is learning to cultivate laziness. Focus on the things that matter but learn to internalize ways to avoid making work for yourself.