4 ms·

I'm rather against the "working horse," methodology to software development. Maybe it's because I'm lazy but I'd rather work with tools and processes that let m

I'm rather against the "working horse," methodology to software development. Maybe it's because I'm lazy but I'd rather work with tools and processes that let me achieve more with less effort. The "get it done," attitude is admirable but ultimately, I believe, leads to the very same duplication of effort that the author admonishes. For example, you're building a web application that has a signup process and the sales team uses an external CRM service to collect sales pipeline information. The programmer who shows up and does their four hours pulls out the usual libraries and writes the code to make it happen. The view fires up a few requests in an asynchronous task that updates some models and everyone is happy. However the sales team decides to change CRM services -- there's a shiny new kid on the block with features that would improve their sales process. The work-horse programmer gets the story and hunkers down. Four hours later there are a new set of tasks, a signup function, and hopefully a few tests. The missed opportunity is that CRM software isn't terribly interesting and it should matter little when the web application signs up a new user whether you're talking to CRM A or B. I often find little scenarios like this that just add up over time. They're often missed because the focus is on getting something done for the next four hours/for the next sprint planning session/whatever. There's no real planning done beyond the next little bump in the road. And so our solution is to use the same old tools and practices but simply hire more people to be work-horses. I'd much rather engineer more robust RPC frameworks that can negotiate the protocols on their own so that a valid business decision to use a competing service doesn't cost me a couple of days of boring, tedious work. I'd rather just change a configuration line or two and sip an americano while reading the latest Vanity Fair in my garden. So.. while a great article in many respects I would add that in order to become a great developer, in my opinion, you must refine your instincts towards laziness. You must become a connoisseur in methods by which you can avoid doing work. Being busy is not a virtue.

giulianob 13y ago
Yep I'm learning that the more "lazy" I get the better quality software I release. You have to know which battles to fight and where cutting corners will save you a ton of time/bugs but won't hurt the end user too much. That's what makes a good programmer IMO.
- hibikir 13y ago
  This barely known programmer called Larry Wall said, many years ago, that the three virtues of the programmer are laziness, impatience and hubris. Be lazy because you don't want to do the same job twice. Be impatient, and don't build tools that make you tell them things they should already know. Fill your soul with hubris, and you will have to work on your code very hard so that nobody can find a fault in it. A pretty smart guy, that Larry Wall.
andyidsinga 13y ago
refining instincts to tend towards laziness - i.e. reading vanity fair in the garden - seems to be the antithesis of experimentation and practice and supportive or a 'I've seen it all before mentality'. both of these are very bad for sw developers.
- agentultra 13y ago
  Perhaps it is best to spend time away from the keyboard once in a while and open your mind a bit. Ideas don't spring forth from a vacuum. However practice is important, I believe, and should be a part of any lazy programmer's regime.
staticshock 13y ago
An idiom that dovetails nicely with laziness is YAGNI (You Ain't Gonna Need It.) A "working horse" may over-implement or over-engineer a system before any of its features actually prove to be useful. Those "fully implemented" features may later bite them in the ass when they need to pivot, or the requirements change.
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.
mcguire 13y ago
"I'd much rather engineer more robust RPC frameworks..." Be careful that you don't spend so much time engineering frameworks that you never actually ship a product.

giulianob 13y ago

Yep I'm learning that the more "lazy" I get the better quality software I release. You have to know which battles to fight and where cutting corners will save you a ton of time/bugs but won't hurt the end user too much. That's what makes a good programmer IMO.

hibikir 13y ago
This barely known programmer called Larry Wall said, many years ago, that the three virtues of the programmer are laziness, impatience and hubris. Be lazy because you don't want to do the same job twice. Be impatient, and don't build tools that make you tell them things they should already know. Fill your soul with hubris, and you will have to work on your code very hard so that nobody can find a fault in it. A pretty smart guy, that Larry Wall.

andyidsinga 13y ago

refining instincts to tend towards laziness - i.e. reading vanity fair in the garden - seems to be the antithesis of experimentation and practice and supportive or a 'I've seen it all before mentality'. both of these are very bad for sw developers.

agentultra 13y ago
Perhaps it is best to spend time away from the keyboard once in a while and open your mind a bit. Ideas don't spring forth from a vacuum. However practice is important, I believe, and should be a part of any lazy programmer's regime.

staticshock 13y ago

An idiom that dovetails nicely with laziness is YAGNI (You Ain't Gonna Need It.) A "working horse" may over-implement or over-engineer a system before any of its features actually prove to be useful. Those "fully implemented" features may later bite them in the ass when they need to pivot, or the requirements change.

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.

mcguire 13y ago

"I'd much rather engineer more robust RPC frameworks..." Be careful that you don't spend so much time engineering frameworks that you never actually ship a product.