All the Perl that's Practical to Extract and Report
use Perl Log In
Ovid (2709)
(email not shown publicly)
http://publius-ovidius.livejournal.com/
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.
Business rule #1 for programmers
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.
I pour myself a cup of strong coffee. :-)
-- Jarkko Hietaniemi
I'd like to add ... (Score:1)
Ordinary morality is for ordinary people. -- Aleister Crowley
Do you really want programmers making the call? (Score:2)
In answer to your straw man who "imperiously announces that he'll refactor the entire system to keep this from happening ag
Re:Do you really want programmers making the call? (Score:2)
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
Re:Do you really want programmers making the call? (Score:2)
Re:Do you really want programmers making the call? (Score:2)
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.
Balance (Score:2)
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
Re:Balance (Score:2)
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
Re:Balance (Score:2)
As for your second paragraph, that's more or less what I do too. (Although most of the time, it is my *job* to avoid pink buttons.)
Re:Balance (Score:1)
See The Crooked Timber Of Software Development [hacknot.info] and the awesome response Tye wrote at PerlMonks [perlmonks.org] when I posted that link.
Re:Balance (Score:1)
Unfortunately I can't because the site has an internal error.
Furthermore the internal error shows me that they present a full stack backtrace on internal errors. Which you shouldn't do in production because it allows people to debug their attacks against your site.
If they're recommending shortchanging program quality for business considerations, the current state of the site suggests that they may wish to re-prioritize...
Re:Balance (Score:1)
It’s still available from the Google cache [google.com], thankfully. I also have a local copy in my aggregator, should that too fail.
Agree wholeheartedly, but there's one tricky bit.. (Score:1)
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
Making other people money. (Score:1)
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