Stories
Slash Boxes
Comments
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

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • 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.