http://www.perlmonks.org?node_id=465742


in reply to OT: Why Hackers dont do well in Corporate World

The Hacker is hired into a team of about 50 other programmers (half local, half offshore). The Application the Hacker is working on supports about 20,000 users and handles a billion dollars per year. It contains about a million lines of code... some of it dating back as much as 6 years, but still under heavy, active development.

So the Hacker takes a quick look at the code of the Application, and gets upset. There's a small number of global variables in it, which are bad. It was also written for perl 5.005 (before warnings was a module), and doesn't pass -w. That simply cannot stand, as the Hacker knows better.

There are modules in the application which implement the same sorts of functionality as various modules on CPAN. Of course, it is true that these modules do slightly different things, or are integrated into the other modules in the Application. Also, most of them were written into the Application before they appeared on CPAN (remember that the Application is more than 6 years old in parts). That doesn't matter, though, there should be no date module other than DateTime. The Application may have a unit-testing suite, but it is not written for Test::More, so it doesn't count.

The hacker has is charge. He will set these wrongs right. First, He's gonna put my in front of those global variables, rather than use vars. He's also going to remove all the warnings he can find. The code passes perl -wc, so it must be right, right? So He submits His changes. Seconds later, the other 50 developers start shouting obscenities, as one of the global variables He myed was the database handle in the startup module. So, not a single page in the application works anymore. It also turns out that many of the warnings were removed in ways which subtly changed functionality, which comes out later on in regression testing.

Any one of these things would have been easily caught if the Hacker had bothered to follow any of the evil "rules" which were laid out before him, or if he had tested his code before submitting it. But hey, "rules" are for suckers. They only slow down a real hacker.

But these things eventually get cleaned up, and it's time for the Hacker to bless the Application with real modules. You know, the kind that you download from CPAN (the only place where perl code is allowed to be written... except for that which is written by the Hacker). So the Hacker starts writing His unit tests in *.t files for Test::More, rather than in *_Test.pm files for the Application's unit-testing system. QA is not able to make use of his tests without altering their unit-testing processes and writing a bunch of new harnesses around Test::More. Eventually, they just decide to write *_Test.pm files around all of His *.t files. The confusion, lost energy and bickering is certainly worth the trouble. Now His (same) test code ends in .t. HOORAY! It's also a little bit longer, because it repeats some of the Application-specific things that are built into the Application's test system. Oh, well.

The Hacker wants to start using DateTime, in place of the Application's existant date manipulation module. The Hacker cannot understand why there is any resistance to this idea, whatsoever. Clearly, it's worth His time to do this. Heck, He'll even do it in His spare time, so nobody can even argue that the energy invested in this project is taking away from work that someone else is counting on. Forget that this would require retraining the other 50 members of the team, sucking up a couple of person-days worth of already over-taxed QA resources (remember that they're still busy dealing with huge gobs of regression errors from His perl -w work), and require the sysadmins to install a new bundle of CPAN modules on about 100 servers... about half of which are locked-down production machines.

So, at this point, the Hacker has decided that the architects, the QA manager, and the sysadmins are all a bunch useless twits. All the stories are true. Hackers just aren't given a fair shake in the Corporate World. Sucks, too, 'cause he was a smart guy, and he could really code well. He just couldn't lower Himself to test His code or take on any appreciation for the other people who worked at the Company.

Oh, well. Hope He enjoys working for Bill. That's bound to be less corporate. And I'm sure that the software, there, will meet His high standards of code purity.

------------ :Wq Not an editor command: Wq

Replies are listed 'Best First'.
Re^2: OT: Why Hackers dont do well in Corporate World
by Anonymous Monk on Jun 12, 2005 at 14:09 UTC
    Doesn't sound like much of a hacker to me.
      Well, I may not have made it clear, but he was, in fact, a very smart guy and a very good coder (with a few caveats). He just mistakenly thought that any kind of rule someone threw at him, like rules about testing code, our team processes, and code conventions (I didn't go into it, but he decided that he wanted to change all our code from CamelCase to using_underscores) was stupid, and clearly the product of an inferior mind. He had never worked on a project involving more than a handful of people before, and just couldn't seem to believe that there was aything more to being a programmer than just the programming.

      I brought up the story in this thread because it seems to be a common misunderstanding that this thread is promoting: "If you're a good programmer, but people give you crap about aspects of your work other than programming, then they're jerks/idiots." In general, this thread (with some exceptions) consists of little vignettes demonstrating this concept from the point of view of the poor, put-upon hacker, who is unhappy with how his obviously-superior work is received by his bosses or by those other (i.e. not the antisocial, but self-proclaimedly super-humanly talented hacker) programmers at his job.

      Point being: this is a fairly one-sided round of complaints, and I wanted to give the other side. It's an easy thing to think that if ones work is ill-received, that it must be because the people judging the work are beneath ones consideration. It's a much harder thing to think that maybe there is some merit to the criticisms and try to improve yourself. It's also a much more useful, productive, and mature thing to do.

      ------------ :Wq Not an editor command: Wq