Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Ovid (2709)

  (email not shown publicly)
AOL IM: ovidperl (Add Buddy, Send Message)

Stuff with the Perl Foundation. A couple of patches in the Perl core. A few CPAN modules. That about sums it up.

Journal of Ovid (2709)

Thursday March 09, 2006
02:14 PM

Business rule #1 for programmers

[ #28938 ]

I know some programmers are going to bristle at this. For some, it's because there are reasonable exceptions. For others, it's simply because they'll disagree (I get the latter quite a bit). So for your amusement, here's "Business rule #1 for programmers":

If you're not making or saving your employer money, you probably shouldn't be employed.

For many of us who are quite fond of paying the bills, this is a no-brainer. It's as useful as saying "don't try to remove ear wax with a razorblade."

While one can definitely argue that there are exceptions to this rule, for the vast majority of us, these exceptions do not apply. Yes, you want your code to be elegant and beautiful but if you're about to lose a $100K contract because you won't deliver on time, it's OK to cut corners. When customers are calling and screaming left and right about how they "can't connect", that is not the time to imperiously announce that you'll refactor the entire system to keep this from happening again.

Unfortunately, this is a failing I see in many programmers. They want "purity". Me? I want paychecks. I've been homeless. It ain't fun.

That's not to say that I scoff at purity, either. Anyone who's read my posts about grepping through a code base to remove misapplied "if/else", "ref", or "UNIVERSAL::" code knows that. The problem is being willing to do the wrong design thing now in order to do the right business thing now. It's getting back and fixing the design issues later which is the hard part.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • Programming rule #1 for businessmen: Getting-It-Done is great, but you can't wait forever to do it right. ;)
    Ordinary morality is for ordinary people. -- Aleister Crowley
  • My first reaction to this is roughly "how would I know?" I'm not a business dude. I have no idea if the code I'm writing today will make money for my company. I consider it out of my hands. When I want to know if I should do something quick and dirty or slow and right I ask my manager. I try to lay out the options as clearly and honestly as I can and then I wait for the decision.

    In answer to your straw man who "imperiously announces that he'll refactor the entire system to keep this from happening ag

    • I think you and I are mostly on the same page. I never said that programmers should make this call. I see a lot of programmers railing against managemers who say "we need this done now" when, in fact, it really does need to be done now. When programmers get a better knowledge of the business side, they can better understand the business decisions (and that goes for the business folks knowing the tech side) and make more reasonable recommendations.

      It reminds me of when I used to manage coffee carts whil

      • Sure, I've been there, getting the wrong answers from the boss. Some business people just aren't good at making informed decisions even when you've patiently explained all the tradeoffs and benefits. I think we, as programmers, need to be sure we're holding up our end of the bargain - delivering all the data the business-people need to make good decisions. When they make bad ones anyway then it may be time to find a new job. Until then it's our job to follow orders, and to make the best use of the tim
        • True, but I see too many new programmers agonize and complain over "perfect" code, failing to realize that perfect is the enemy of the good. Of course, "perfect" is also highly subjective and changes over time. Companies are rarely hiring us for pure research. They're hiring us to get things done and either make or save money. I really do feel that one of the worst mistakes programmers make is forgetting that they're working for a business and not turning in homework.

  • Of course, the paycheck (or in my case, having clients pay my invoices) is incredibly important.

    However, the world is not black and white, and there's much gray in between. The gradient isn't linear either, and in fact, many shades of gray turn out to have a very different hue.

    While the customer (boss or client) is the one you're serving directly, you're also serving other people. People who do not pay you, or will ever know that you worked on that particular part of code. They are all the people that are i
    • It's our moral obligation to deliver quality even if our customers specifically state that they do not need it. If they refuse to pay for it, then it is our responsibility to say "no".

      Really? Define "quality" in such an unambiguous way that everyone will agree on it.

      When I'm asked about this in interviews, the thing I make clear is that if I'm told to make a button pink and have it purr like a kitten when clicked, I'll do it (even though I might ask 'em why). However, if I'm told to do something illeg

  • In principle I agree completely.

    I rarely code for clients to the same standard I code for CPAN.

    Or at least, I CODE for them as well if they are paying for me to be their "expert", but I often let some of the more finely detailed testing slip, and often let the API documentation slip.

    On CPAN, documentation is MUCH more important than for clients. Lots of comments for maintainers are still useful, but spending as much time on writing the POD as you spend writing the code (as you might for CPAN) just isn't wor
  • If you're not making or saving your employer money, you probably shouldn't be employed.

    I agree entirely your statement should be obvious. I also agree that in many organisations it's not the programmer's role to know the best way for them to generate value; that's what managers are for.

    However if one wants that pay-cheque to be bigger, it's worth finding out what's really important to your business. It's rare for developers to work in a vacuum, and knowing where the real priorities lay is often eas