One warning with this kind of behavior is that it doesn't actually insulate you from the insanity of the environment. Some of your cool stuff is going to be buried because people don't understand it and won't buy in, or because it obsoletes something they did, etc... People will complain about you "not being a team player" when you do things they don't expect. Some managers simply can't handle employees like this and will try their hardest to muzzle you lest you say something embarassing. I've seen all of the above, even at small environments where you wouldn't expect it.

This is why I have to wonder how old the parent is. When you're young and have lots to learn, sure, take on a lot and learn.

But as I've become older I've decided I'm not interested in putting in the extra time just to make my boss wealthier. Time is my greatest asset and I need to manage it with predictability. Time I spend making somebody else wealthier when I could be spending that time making my own business profitable is time wasted. I'm the one spending my time learning and building the application - that is to say, I'm taking the risk - so I should get the reward.

Performance reviews and bonuses are far too politically fragile and opaque for me, and the fact is unless you're a shareholder, you're guaranteed to never receive more than a small fraction of the true value of your work when you're working for someone else.

That's why I quit permanent work and have moved into contracting: I earn good money that I'm saving towards my own startup, I get paid for every hour I work, and as a matter of personal discipline if I'm not doing paid work I spend the free hours working on my own projects that - in the long run - should pay off far better than the contracting or permanent work ever will.

That being said, this strategy only makes sense if you believe you can generate substantially more money working for yourself than somebody else could pay you. If you don't believe in yourself you're stuffed.

Have another look at edw519's second point (emphasis added):

> 2. You'll probably have to make time for extra work. Shouldn't be a problem if you're a good programmer in an enterprise.

The point being that you can do these things on company time if you complete your day-to-day tasks efficiently.

Your points are more valid if you substitute 'energy' for 'time' in your reply. If you spend eight hours completely zoned in while working for the man, you might not have much energy left for your personal projects when you get home. You can mitigate this somewhat by working on your personal projects before work.

Or you can take the Einsteinian approach and not sweat your day job while you revolutionize physics in your spare time.

That second paragraph should be engraved.

I've never found that to be true. People love stuff being done a lot more than they hate looking bad. Managers at big companies know it costs almost as much as a programmer's salary to find a new programmer, so if the only problem that you're causing is doing extra useful work, they are not going to make it a priority to fire you and find someone else who will do what they're told. In fact, managers are often so overextended that a self-managing employee that's visible to the rest of the organization is an asset.

(This worked for me when I was at BofA. I worked on a tiny team that nobody cared about, but people pretty high up knew who I was. This was generally good for my manager and her bosses. The impression I got was when I was on a conference call, I was the only person who ever wrote code to solve problems, and people seemed almost grateful for that. I didn't really enjoy this, and there was a lot of red tape and bullshit, but I do know people who do fine with this kind of job. YMMV.)

And if you don't have the people to complete or maintain these projects? Or how about when you build out a prototype and then corporate IT policies end up having you generate hundreds of pages of documentation and a massive Java application, when your self-hosted 2k LOC Python project met all business requirements and specs?

I'd rather be in a position that encouraged rapid, pragmatic development.

Out of curiosity, why the downvotes? When I worked at a corporation, I tried to do what Ed recommended here, and these are the problems that I encountered.

> Out of curiosity, why the downvotes?

Don't worry about downvotes until time has passed. Things usually balance out.

I see that now, thanks :) I don't mind being downvoted, I'd just like to hear out any rebuttals to my comment.

Agreed, I got paid to hack a VMS mainframe, buffer overflows, etc at 22, trust me it wasn't in the official job description but I found the company $3 million in lost rev.

Honestly, unless you enjoy reading about the company you work for in Techcrunch I don't get the whole startup hype for employees. Founders are somewhat likely to get a decent cheque but employees are not. For employees the EV doesn't seem to make a whole lot of sense.

How much of that did you see?

At my last employer, I was on a very small team that wrote code that made GBP 2M/year pure profit (minus the salaries of 3-4 people for a couple of weeks, in the first year). That 2M covered the bonuses of two execs, and I got a raise of slightly below inflation (and left shortly after - and they had no idea why).

Nothing for that project.

However I was a quick study and learned that truly there was no I in team. I created a win-win situation, and soon our sales team was dramatically outperforming other regions. Turns out the sales staff knew who to call who already had the service and merely needed to be added to the billing system. There was no way that that much revenue could be sold by one person, it really did require a team.

The worst thing I found was a report that listed expiring credit cards and allowed entry of arbitrary dates in the future for which to run the report. I had to wait until the C-levels visited and hand them a stack of paper with the numbers on them to get anyone to pay attention to it.

aside: Seriously Oracle for OCaml? That's awesome, I'm a big F# fan.

One data point, I've never found a large corporate job where I didn't feel straightjacketed and annoyed with my bosses/politics/organizational inertia. A small company fits me much better, it's mainly a personality thing.

"It is easier to ask forgiveness than permission".

"The nail which stands out gets hammered down."

"When life hands you lemons, make lemonade."

"Don't make lemonade! Get mad! I don't want your damn lemons! What am I supposed to do with these? Demand to see life's manager! Make life rue the day it thought it could give Cave Johnson lemons!"

"Never rub another man's rhubarb."

Wherever you go, there you are.

The words I live by.

One thing that I've found is that sometimes you just have to do things regardless of whether you have permission. But keep in mind that it's your ass if you fuck up.

Case in point, my boss has been out on leave for a few months already, in the meantime I've had a free hand to do whatever the fuck I want with some things. In that time I've completely overhauled several systems. With my boss around it would have been a teeth-pullingly laborious process that probably would have dragged on for weeks, been interrupted by other tasks in the meantime, or compromised in so many aspects to "reduce risk" that it might have ultimately been useless. As it was I did everything and migrated critical running systems over to the new stuff in only a few days of work spread out over about 2 weeks.

That generally applies to everything in the workplace as well. The best way to change your job is to slowly but surely start changing what you do while official recognition catches up.

You sir, are "Getting things Done!".

You are the real-deal.

This is kind of like wanting sex and getting some dirty magazines.

Taking the problem in hand so to speak.. Pragmatic!

I think the trick to surviving either big-company jobs (with the tendency toward bureaucracy and risk aversion) or startup (with the high risk and uncertainty) is realizing that it's just a job, not what you have to be doing for the next 15 years. If it's boring for a couple months, who cares? If the company goes out of existence (or fires you) there will be others. I think it's becoming increasingly important to learn this, although it's easier to give this advice than follow it.