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 sf.net 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.
--Artist

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.

Hugo

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.

Hugo

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.

<devilsadvocate>

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."

</devilsadvocate>

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.

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.

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 =========>.

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.

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
[download]

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
[download]

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.

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.

That's not entirely true, they make excellent snipers and do will as part of killer insertion teams...

--hsm

"Never try to teach a pig to sing...it 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

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.

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.

'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.

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.

OGB

Amen!

---

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.

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>

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.

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.

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.