Beefy Boxes and Bandwidth Generously Provided by pair Networks
Clear questions and runnable code
get the best and fastest answer

OT: Why Hackers dont do well in Corporate World

by mkirank (Chaplain)
on Jun 10, 2005 at 07:25 UTC ( #465455=perlmeditation: print w/replies, xml ) Need Help??

Your client had a old *CGI* code and that was having a little performance problem and your company had suggested a Great Idea and for the Past year the client had procured a High Performing application server and the application entirely re-written in J2EE (with 8 people working) , the Hacker Innocently modified Apache setting to run the Old *CGI* to run under mod_perl and It performs 2 times better than the new Application in J2EE and has Lesser bugs

Your company had developed a *Great Application* in house for the Past 1 year and when the manager gave a great presentation explaining all the features of the application and at the end of the presentation when the Manager asks are there any questions , The hacker Innocently asks there is a XYZ application on sourceforge that does all this + some additional features and why dont we use that

Your company is a CMM level company and the hacker does not know the KPA's but talks *wierd stuff* like Agile methodologies , Test driven development, XP ...

The hacker suggest doing it in Perl but *everybody* knows that *Enterprise Applications* are done in Java and .NET

The hacker finds that the system is not secure and to prove his point sends a mail to the Top management saying their system is not secure and as an example sends the password of a top president (which is *very funny*) and the Hacker is charged for breaking in to the system and stealing passwords

Hackers don't believe that management is "above"

Do you have anything to add to this list ?
  • Comment on OT: Why Hackers dont do well in Corporate World

Replies are listed 'Best First'.
Re: OT: Why Hackers dont do well in Corporate World
by Anonymous Monk on Jun 10, 2005 at 09:54 UTC

    Sorry for posting anonymously, but you'll understand when you read on.

    I am working as a consultant in such an environment.

    My course of action when I started my first project with the company was to give advice on The Right Tools to use for the job at hand, and they did not listen to me. As a result, I got paid to do something I didn't like, without the level of confidence that I would have had if I were allowed to use my tools, and without that kind of personal satisfaction that comes from knowing that a good app is (at least partially) obtained from your suggestion.

    But I learned my lesson, and when the next project started, instead of simply proposing The Right Tool I wrote a nice presentation with fancy colors, got a fancy name out of the top of my head, and sold the company a Perl wrap that I wrote around the right tool. This way, I had the confidence of the tool, the satisfaction of being part of the decision making chain, and a bunch of money more than my usual fee. (You can't just sell Open Source for peanuts, because the management does not take you seriously; but if you charge them an outrageous amount for something that they could find in SourceForge, they usually go for it). I had even the guts of releasing my wrapper under the Artistic License.

    Perhaps this approach does not apply to every company, but the next time you are in a position of proposing a solution, keep this story in mind.

    Anonymous Saint

      This is somewhat like the advices given by Carnegie in "How to win friends and influence people". People don't like to be told what to do abrubtly - you have to "work on them", tell them stories, make them wanna do it themselves. The highest level of mastery comes when you manage to convince people it was actually their idea, this way they're glad to do what you initially wanted.
        ITYM "work them over". It's more than they deserve.
      I agree entirely with anonymous monk and spurperl. People like stories. They cannot take barebone contents. It's not easy to handle. Packaged contents are good. Packaging seems different for different people depend upon experience. Even on it's nicely packaged for you. Just try yourself. How many barebone ideas you have handled? Packaging works, not just because people like that, but because it might be the part of inherent laws of nature. What might be true for most people, may have atleast some values.
Re: OT: Why Hackers dont do well in Corporate World
by hv (Parson) on Jun 10, 2005 at 08:47 UTC

    The hacker is always the last to leave, late at night, which impresses the MD. Until the evening the MD walks past and finds that the hacker is working on fixing a crashing bug in the inhouse editor instead of on his given task.

    MD: "If you're not going to work on the job you've been given, I don't want you on the premises."

    Hacker therefore resolves to fix tools bugs during the day, when the MD is less likely to be wandering about.


      The hacker is always the last to leave, late at night, which impresses the MD

      Counterpoint: Hacker uses disciplined development languages and RAD, dynamic languages (e.g., Perl) to get their work done during regular 9-5 hours (often ahead of schedule), and never needs to work late or demand more budget/schedule/employees.

      Slacker throws sh*t at the wall until something sticks, relies on the buzzword languages de jure (Java, .NET, etc.), ends up putting major extra hours in to cover their own screwups, goes over schedule and over budget.

      Slacker gets awards, promotions, and raises, while hacker gets layed off, since PHB sees "Slacker goes the extra mile to get difficult projects done", while "hacker doesn't seem committed to the team".

        Reminds me of a time when "the team" was asked to stay up late to help with a server upgrade. The upgrade was a wide-awake nightmare! The "admin" decided to upgrade all the software on the production server to the current version; this included major version changes on the OS, database, Apache, Perl, you name it. Perl alone went from 5.00503 to 5.8.3! Of course nothing worked, and everything on the site had to be retested and debugged that evening, er, morning. We're still finding broken site elements to this day.

        I worked my usual 9-5, went home and had dinner, then worked from 7-10:30 and went to bed exhausted. I come in early the next day to find (surprise!) that I'm the only developer there. All those "team players" took the morning off! Customer service, marketing, and suits are asking me "WTF happened?"--not a single message had been forwarded to them to let them know what was working, what was borken, anything at all. I try to reproduce from sporadic late night email exchanges what is working and what is not.

        That afternoon, PHB gives me a hard time for not burning the midnight oil; looks like I'm "not a team player". Meh, I stopped caring long ago. Oddly enough, the rest of "the team" thought I did the right thing once I explained it to them. And as long as the ladies in customer service still like me, I'm OK. :-)

      "...working on fixing a crashing bug in the inhouse editor instead of..."

      Of course, companies that insist on creating their own in-house editors, mail clients, programming languages, etc. are a whole class of problems unto themselves!

        This was in the days when the PC was just coming on the market - the hardware was also designed and built inhouse.

        Another programmer that started around the same time as our hacker brought his own PC in to work, and insisted on doing all his development on that. But by avoiding using the system he was writing for as much as he possibly could, he ended up learning nothing about the system. It isn't clear whether that was the only reason his code was crap.


Re: OT: Why Hackers dont do well in Corporate World
by spurperl (Priest) on Jun 10, 2005 at 07:32 UTC
    A hacker is warning the team leader for a long time that the half-a-million-KLOC project is becoming a "big ball of mud" - there is no design, no documentation, barely any tests. The hacker says it will eventually trip the team and lose time, since debugging is very hard and there are a lot of defects. The team leades says there's no time for design, no time for refactoring and no time for testing - the application should work *yesterday*.

    The hacker whips up some test scripts in Perl and works for a week to refactor some code that will save months of debugging later, but is being accused of wasting his time.

Re: OT: Why Hackers dont do well in Corporate World
by tlm (Prior) on Jun 10, 2005 at 12:10 UTC


    I don't doubt that what you depict is true, at least to some extent, but you are basically preaching to the choir here.

    There is a growing literature (e.g. Eric Raymond, Paul Graham) in praise of the "hacker ethos," casting the hacker as a paladin of excellence surrounded by an ocean of mediocrity. Of course, hackers and hacker-wannabes lap up the stuff, but I think such writings (which I find vaguely reminiscent of Ayn Rand's fables) say little that is actually constructive or practical. All they do is give the "beleaguered IT guy/gal" some hidden reserve of self-justification to draw from during his/her disagreements with management.

    I like reading Joel Spolsky because he is a bit of a contrarian in this respect (and a few other ones). Even though he's a programmer himself (or maybe I should write "former programmer, now manager"), he doesn't fall for this blanket adoration of "The Hacker." It's not that he's entirely blind to some of the issues you bring up, but he seems just as likely to see foibles in programmers as to see them in managers:

    So now, you have your own office (instead of sharing a cubicle with The Summer Intern Who Never Left), and you have to fill out those biannual performance reviews (instead of ruining your eyesight staring happily into a CRT all day), that is, when you're not wasting time dealing with the bizarre demands of prima donna programmers, back-slapping sales guys, those creative "UI designers" (who were hired as graphic designers, for Pete's sake) who want shiny OK/Cancel buttons that reflect, I mean, what's the RGB value for "reflective?" And dealing with inane questions from the senior VP who learned everything he knows about software from an article in Delta Airlines In-flight Magazine. "Why don't we use Java instead of Oracle? I heard it's more unified."
    That last line kills me, but lines like "ruining your eyesight staring happily into a CRT all day" and "prima donna programmers" are a clear sign that this guy is not out to stroke anyone's ego. I don't always agree with Spolsky (in particular, I think he gives Microsoft too much of the benefit of the doubt), but I find his skeptical voice to be a refreshingly down-to-earth alternative to the romanticism of the thriving hacker fan press.


    Update: Oops, I neglected to cite the source for the Spolsky quote. It's from p. xiii of his book Joel on software.

    the lowliest monk

      ESR is a gasbag who's biggest contribution was walking away from the Mozilla project when it was starting to tank. But I can't say the same for Paul Graham. That's because he actually co-founded a business around Hackerism, killed his competition, and now has enough money laying around that he'll probably never have to work again. He knows it works in the "real world" of buisness, because he's already done it.

      "There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.

Re: OT: Why Hackers dont do well in Corporate World
by coreolyn (Parson) on Jun 10, 2005 at 11:48 UTC

    Once upon a time a hacker without any education; other than what he learned from banging at a Tandy Color Computer II to print his novel in progress via the serial port to a brother daisy wheel typeriter, went into the military. Once there it was discovered that he could adapt his hobby to the hundreds of idle CPM machines. When the military aquired 8088's by the truckload they didnt' know what to do with them. So the hacker showed them - and it was good

    A decade later the hacker left the military and found he wasn't qualified to get paid for his hobby for he had no education so the hacker built PC's first for a small shop where he automated a test process that he took to a larger shop - where he perfected his automation until he was getting 25 PC's a day out the door - and it was good.

    Then the bottom fell out of the domestic PC market, so the hacker wrote database programs for the thousands of new end users in the world. The County he lived in heard of his talents and asked him to take care of the WAN for the counties library system - and it was good.

    Word spread amongst the vendors he dealt with of his knowlege and a large corporation faced the job vacancies of y2k and finally the hacker had arrived. He happened by luck to have been placed with a team of hackers. They were in charge of the development integration, and the servers for both dev and QA. They were the ones that made the square block ( new applications ) fit into the round holes ( Corp infrustructure ). They exceeded every expectation. While they had more servers than production, their server uptime was higher. Their value in assisting the dev teams in customizations was highly valued by all. So they endevored to have the procedures and automation created by the team made 'standard' in production - For this the team was disbanded.

    So the hacker took a new position - Java developer/analyst ( Perl became shunned by the corp ) works 30-35 hours a week at the same salary, turns a blind eye to better ways of doing things and is finally realizing he has enough time to write those books he started on so many years ago.

    ( Sorry had to spew - nice topic )
Re: OT: Why Hackers dont do well in Corporate World
by mw (Sexton) on Jun 10, 2005 at 14:20 UTC
    Ye ghods... Talk about opening up a can of worms. It's the eternal struggle between the nerds and the pointy-haired ones. I think life as we know it would be a lot better if everybody knew where their strengths and weaknesses were, and endeavoured to keep their activities in their area of competence.

    Hacker gets contracted in to configure storage for big company. Finds the equipment he's supposed to work on neatly wrapped on the pallet it came on. No electricity, no network. When he asks for specifications on how to configure storage, is presented with a piece of paper describing such beauties as a Raid-1 array on a single disk, and a RAID-0 array for a database. Hacker works late at night correcting mistakes and doing a pretty decent job. Is then told that this is not according to specs, and told to follow the specs, in the mean time, is blamed for the project running late. Explains that in a RAID-0 configuration, failure of any of the seven disks will be the end of the entire database. Is told that we have a good backup. Thinks "Bollocks, if that's what you want, that's what you get". Configures as nearly to the specs as physically possible. Then, a disk breaks. It turns out that there is not, in fact, a backup of any kind. Guess where the excrement lands...

    One bit of text I've always treasured in this regard is "Abigail's Oath", reprinted herewith:

    I am hired because I know what I am doing, not because I will do whatever I am told is a good idea. This might cost me bonuses, raises, promotions, and may even label me as "undesirable" by places I don't want to work at anyway, but I don't care. I will not compromise my own principles and judgement without putting up a fight. Of course, I won't always win, and I will sometimes be forced to do things I don't agree with, but if I am my objections will be known, and if I am shown to be right and problems later develop, I will shout "I told you so!" repeatedly, laugh hysterically, and do a small dance or jig as appropriate to my heritage.

    --Abigail's Oath for Sysadmins

    I never did find out who Abigail was, but he/she definitely demonstrates the levels of cynicism that is the hallmark of the system administrator. Thinking of this: I may be posting this in the wrong monastery.

      Note that Abigail got kicked out of the USA for not getting a piece of paperwork filled out on time.

      There's some sort of moral there, but I'll let others find it.

        Are you (we) sure which Abigail is being quoted? There was another Abigail of told-em-so fame.
        (That might've been the reference (above) to the scary devil monastery)
      Scary Devil Monastery is thataway =========>.
Re: OT: Why Hackers dont do well in Corporate World
by Mutant (Priest) on Jun 10, 2005 at 11:32 UTC
    Although I understand the frustration (first hand) working with management, I think it's important to understand that there are two sides to every story.

    The stero-typical view of hackers from within management is someone who is too smart for their own good, believes they're above the law, has poor communication skills, and has absolutley no understanding of the realties and constraints of running a business. To management, your brilliant, time-saving tools and techniques are actually the opposite. They waste time, are unproductive, and simply delay the release of something that the client needs *yesterday*. To managment, this is the bottom line (literally). The client won't pay for something that's delivered after they need it.

    This view may be completely unrealistic (although this is an extreme version of it), but I think it's important to realise where management is coming from. In my experience, only a small percentage of managers are complete morons, and if your company's worth working for, they won't be around too long. The rest of them just don't see the picture from the same point of view as us.

    To me, though, the task of breaking down the barriers rests on the shoulders of both parties. It's important as a hacker to respect and understand the ways your company works. If there are problems that need to be addressed, there are proper channels to go through. If those channels don't get a response, then go to the next level in an appropriate way. By making these small concessions (and others), it's easy to get on in the corporate world.

    Management (usually) has the best interests of the company at heart. But unless you can explain your side to them in a way they can relate to, they have no reason to listen.
Re: OT: Why Hackers dont do well in Corporate World
by Gekitsuu (Scribe) on Jun 10, 2005 at 10:44 UTC
    When a hacker is doing everything right, there is smooth sailing. This causes management to think they don't have enough work to justify a full-time hacker costing the hacker his job.

    (This one is my personal fav)

    A Hacker comes up with an idea, boss tells clients idea was all his, hacker walks leaving boss with idea and no chance of implementing it by himself. Clients leave, company folds. Yay me.
Re: OT: Why Hackers dont do well in Corporate World
by rinceWind (Monsignor) on Jun 10, 2005 at 11:14 UTC

    This sounds amazingly familiar. My present client has an interesting twist to the saga.

    They have a project to rewrite all their so called "legacy" applications in a new platform of Java + J2EE + Oracle. The project was kicked off over 2 years ago, and has just been severely downsized after going €multi-million over budget without delivering anything. This has resulted in redundancies to some of their permanent staff.

    My role here is "Applications Support", looking after one of these "legacy" C++ apps. So far, I've been reporting to production management, and involved in "stabilisation" - monitoring scripts that digest log files, written in, guess what, perl :).

    The PHBs are looking to integrate apps support with development, and I look on this with a certain amount of trepidation.


    Oh Lord, won’t you burn me a Knoppix CD ?
    My friends all rate Windows, I must disagree.
    Your powers of persuasion will set them all free,
    So oh Lord, won’t you burn me a Knoppix CD ?
    (Missquoting Janis Joplin)

Re: OT: Why Hackers dont do well in Corporate World
by etcshadow (Priest) on Jun 11, 2005 at 03:05 UTC
    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 * 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 * 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
      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
Re: OT: Why Hackers dont do well in Corporate World
by salva (Canon) on Jun 10, 2005 at 09:07 UTC
    because he has better things to do than converting his elegant, perfect, pod generated documentation to that silly .doc templates that everybody "likes", designed by some "artist" at marketing that was inspired by elements found at the Amazonia (and maybe high quantities of ilegal substances).
Re: OT: Why Hackers dont do well in Corporate World
by Ninthwave (Chaplain) on Jun 10, 2005 at 11:41 UTC

    Hacker working on a project to get firewall on every machine in company sees another project to get inventory data on every machine in the company. Suggests merging the two projects to avoid overlapping. Is told that company has tool to avoid a visit to each machine. When said tool fails to fix inventory data hacker is asked to help. Hacker has already writen code to scan network and keep track of assets on the network, takes the db from this and goes and scans all machines updating data on the go. Hacker says project should take 10 to 15 weeks is given 5 weeks and is screamed at when data is still not complete.

    You will always work for idiots, give up all hope and just talk on perlmonks all day. When they fire you for slacking it is better than being fired for not meating unreasonable time scales that you told were unreasonable from the beginning.

    "No matter where you go, there you are." BB
Re: OT: Why Hackers dont do well in Corporate World
by tmiklas (Hermit) on Jun 10, 2005 at 12:47 UTC
    The hacker sits 6hrs at his office desk doing nothing (visible) and eventually working (doing anything visible) for the last 2 hrs... He gets fired due to being "unproductive".

    MD perspective:
    at least 3/4 of the time he does nothing except browsing the web, we have to find "more operative" employee.

    hacker perspective:
    nobody cares about fresh ideas we could implement... and nobody pays me for the job and the savings the company has thanks to that little one-liner i wrote last week... maybe they should count the time they saved that way as my "visible" working time :-o

    Greetz, Tom.

      I dunno ... I don't bother telling my manager what I'm doing. He asks, "is it done yet?" and my usual answer is "yes." That suffices. The fact that I spent 2 hours writing a tool that did my job for me instead of 3 hours doing my job isn't something he concerns himself with.

      Sometimes, I admit, it's reversed, but only for tasks I know I'm going to do a second time. So I'll spend 4 hours writing a tool to do a job that it would take me 1 or 2 hours to do by hand. But it's a tool I'll use 5-10 times over the next year, so by the next deliverable, I've saved the company maybe a full day's worth of my time which I can spend on other things.

      I have an entire development environment (originally written for 4OS2, now ported to ksh/bash, since my job description has changed from OS/2 to Unix/Linux) which I've spent literally weeks of time on, but which has saved me literally months of wasted time, not to mention my teammates who also use my environment saving countless person-months over the last 5 years.

      My manager simultaneously warns me not to spend too much time on it and lauds me for it in front of his manager - it has made my yearly review a few times already.

      Of course, this is the same manager who told me explicitly not to create a team website, and then, when I did it anyway, put it in my yearly review as another positive (I actually save time that way, too, since it serves as a repository of FAQs to which I can point people so I don't need to retype answers all the time). Or, when handling our testplan, explicitly told me not to put it on the web, and explicitly not to use an RDBMS to store the testplan. If you're following the theme here, you can guess what happened: it made my yearly review 2 years in a row as more positives. I spent literally weeks designing, coding, and writing for these sites. And our team literally saved months of effort and management got instant, up-to-the-second status reports any time they wanted. Which saved me hours of work right there - those status reports could be requested in the middle of a meeting, and were painful to produce. ;-)

      Moral of the story: like anything else, you gotta know how to sell to your audience. Sell yourself and what you did for the company. Short term always matters more than the long term, unless you have an especially gifted management, which is very unlikely in a publicly traded company.

Re: OT: Why Hackers dont do well in Corporate World
by zentara (Archbishop) on Jun 10, 2005 at 10:58 UTC
    The same reason that artists, visionaries and people who "think for themselves" don't do well in the military.

    I'm not really a human, but I play one on earth. flash japh
      That's not entirely true, they make excellent snipers and do will as part of killer insertion teams...


      "Never try to teach a pig to wastes your time and it annoys the pig."
        I'll never trust another artist. ;-)

        I'm not really a human, but I play one on earth. flash japh
Re: OT: Why Hackers dont do well in Corporate World
by TedPride (Priest) on Jun 10, 2005 at 18:53 UTC
    Hackers should never take 9 to 5 jobs, imho. If they're geniuses and do their work for the day in half an hour, their reward is more work and/or complaints that they're slacking off. The other people in the company, however, being total idiots, will managed to spin the same amount of work out into 10 or 12 hours, thus getting raises, promotions, and/or overtime.

    A hacker who works on a consulting basis and is paid by the job, however, can put in his half an hour, get paid several hundred dollars, then go off and play Quake.

    I myself do all my work by phone / email. I can pretty much work my own hours (within limits), and I get paid from $25 to $50+ per hour overall depending on whether I'm doing design work or programming. A 9-5 job would probably kill me, since I'm handicapped and can only manage five or six hours of work per day without my health taking a death spiral, so consulting is definitely the best option here.

Re: OT: Why Hackers dont do well in Corporate World
by wolfger (Deacon) on Jun 12, 2005 at 10:58 UTC

    I think the major disconnect is that hackers only care about what works (functionality), while management typically only cares about what makes them look good (appearances). Those two things are often at odds with each other when money enters the picture.

Re: OT: Why Hackers dont do well in Corporate World
by Qiang (Friar) on Jun 11, 2005 at 00:09 UTC
    after the hacker spend all morning writting an automation script.

    'Yeah, just show another characteristic of yours' the boss

    'oh, what's that? efficiency?' hacker smiles

    'no, laziness' the boss

    'Arghhhhh' the hacker

    i read that on a cartoon series. but forgot which one. somehow fit in the perl programmer 3 virtues. ;0

    Update thanks, sheme. :)

      Dilbert Daily Comic 2005-05-29:

      Dilbert: Can I show you something that I'm proud of?
      Dilbert: I just automated a task that used to take me three hours.
      Boss: Well, well, well isn't that just like you?
      Dilbert: Resourceful?
      Boss: Lazy.

      see the cartoon - the followup is ... painful.

by educated_foo (Vicar) on Jun 11, 2005 at 19:14 UTC
    It's also worth thinking about the other question: why do programmers who do poorly in the corporate world sometimes label themselves "hackers"?
      Because that's what the Corporation Suits expect us to call ourselves. If I dress and act the way they expect a Hacker to dress and act, They will leave me alone and won't try to promote me. I have the people-skills to do the job, I just plain don't want to be a manager. I have, in fact, once issued the threat "If you promote me, I will quit." Don't try to call down on the Old man, he been playing the game longer than you have, and he may not be bluffing..... (Yup, they did, and I did; the same day.)

      I Go Back to Sleep, Now.



        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
        "Science is about questioning the status quo. Questioning authority".
        The "good enough" maybe good enough for the now, and perfection maybe unobtainable, but that should not preclude us from striving for perfection, when time, circumstance or desire allow.
Re: OT: Why Hackers dont do well in Corporate World
by mda2 (Hermit) on Jun 11, 2005 at 16:53 UTC
    English (google translated)

    In 2003 I participated of a great project, a new version of a system to configure the services (HTTP, ftp, etc).

    This project had had 3 groups:
    <read more>

  • Web (java)
  • Config (Perl)
  • Hardware/services (Linux, Solaris and Windows)

    In the beginning lider of the project idealized to contract external development for complete development.

    However I already had developed a small version to configure some services my heads I had decided to assume part of this task.
    We work in 4 people (3 heads and I - meetings had been many). I developed application of configuration, in six months, following all the defined concepts, in crazy hours (10:00AM the 01:00AM, some times working more than 24 followed hours), costing less than 1/4 of the one of the foreseen value.

    However to it I finish the web site, developed for 15 people, it did not take care of the necessities and he was with many bugs, and everything is gives to be abandoned. My work was not valued, although to take care of to all the requirements, it was made by only one developer person and cost very little...

    Despite this, the solutions in Perl had started to be well accepted, and I already developed others 3 similar projects, and although to be of low cost, they had always taken care of the requirements and they are of easy maintenance, and quickly developed.

    Brazilian Portuguese

    Marco Antonio

Re: OT: Why Hackers dont do well in Corporate World
by Anonymous Monk on Jun 14, 2005 at 02:40 UTC
    This sounds exactly like something I would have written a year ago. Then, well, I found a wonderful little startup filled with Python hackers. They could have been Perl hackers, it doesn't matter. Bottom line, there is no hierarchy. Ideas rule. There is no pride. There is some push from outside forces in the "Java" way, but those forces are being resisted. Life is good. It's amazing the way you can work late and not care, and in general how much less confrontational and positive you can be. I wish more industry were like this, and I hope I can hold this job forever -- since I think very little of it IS like this. For the record, I still believe respect is earned and I do not respect people for their position, title, or paycheck. I am generally respectful of everyone on a human level of course, but defering isn't something I'm programmed to do, fortunately everyone seems to let ideas win out. There are exceptions, people that don't quite think that way, but they seem to be the minority. All I can say is, keep looking around, not all companies are evil.
Re: OT: Why Hackers dont do well in Corporate World
by brian_d_foy (Abbot) on Jul 07, 2005 at 23:01 UTC

    I see a lot of people who don't do well because they think everyone else is an idiot, often simply because they aren't hackers or don't spend all of their time knowing every thing that ends up on Slashdot, Freshmeat, or whatever other fora hackers read every 15 minutes of the day. Even the original post has the sub-text that everyone else is an idiot, and it's a bad place to start.

    I don't really beleive that "hackers" as a group don't do well in a corporate environment. I know quite a few very smart one who do. I think that the same people you point to who would not do well in the corporate world would also have a lot of problems in other areas in life where they have to deal with people, and they just happen to be hackers. It's not that hackers and the corporate work environment don't mix, I think, so much as the notion that the people you think of simply don't like playing nice with other people.

    These people have the mixed-up idea that they have to solve all the world's problems, or that everything has to exist in black-and-white terms, and they can't function outside of that. Operating under these absolutes makes them tread all over the thing that really solves problems: people. Of course, this problem extends beyond the work environment for these people.

    I often blame these things on the misguided notion that a good hacker should have more respect, more say, or more anything simple because he is a hacker. Maybe they've just read a bunch of Ayn Rand, Dilbert is verbatim from Scott Adams real life experiences, or they have always been treated with deference in school because they were so smart. When it comes to the corporate environment, being smart doesn't get you much because there is a lot of dull, banal, repetitive work to do. These people doesn't realize that there is an entire cast of other people ensuring they have a desk to sit at, a chair to sit in, power for their desk lamps and computers, that he gets paid on time and the appropriate amount of money goes to various social withholdings, and so on. The hacker is just part of the machine, and not necessarily even the most important part no matter how highly they esteem themselves. Plenty of companies run by smart techies haven't gone anywhere. Hackers aren't the magic ingredient.

    Whatever situation you are in, you have to deal with the people around you no matter how or why they got to the positions they did. Not only that, you have to deal with them in a way that you can be effective and continue to be effective. I've seen a lot of people who simply can't do that.

    I think it would be more productive to look at the people who are hackers and have been successful in the corporate world so you can figure out what they did to make it all work. Continuing to beleive that hackers and work don't mix simply perpetuates the stereotype and admits defeat. It's not useful to anyone, and harmful to a lot.

    brian d foy <>
      I don't mean to be an ass -- well, maybe I do -- but I couldn't even read the first sentence of the original post here. It was barely legible. Maybe if the author spent more time working on his language skills instead of bitching about how management is stupid, management would pay attention to him more.

      Just a thought.

      Oh, and brian is right on about how management has to make sure the machine runs smoothly. That is its job. You are not that important, and you can be replaced. Especially if you can barely put a few words together to form a sentence. Not for nothing.

      brian_d_foy Thanks for your comments , I did not intend to cause harm to anyone , anyways I got the message . Thanks again for pointing it out.
Re: OT: Why Hackers dont do well in Corporate World
by artist (Parson) on Jun 19, 2005 at 14:18 UTC
    Corporations exists as a framework. Each entitiy is like a componenent of that framework. In order to be successful in corporate world, you have to think with 'that' framework.

    Business between any two people (entities), strictly depend on some logic.

    Hackers create their own framework of thinking and doing the things. Hackers try to implement thier own framework in corporations. Corporate world see this as a threat, becuase they don't have sufficient resource to understand the new framework. It also means altering the existing framework to certain extent.

    The success could become reality if hackers spend some type in understanding the existing framework and to work within that framework. Since original content matters, hackers can put their own work into an existing framework.

    Companies built entirely from hackers, will also bring some type of order after intial phase.

    Believe it or not, hackers exists because of the corporate world. In order to be successful hackers have to pay respect to corporate practices at some point.


Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://465455]
Approved by spurperl
Front-paged by bart
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others browsing the Monastery: (2)
As of 2021-04-19 01:12 GMT
Find Nodes?
    Voting Booth?

    No recent polls found