Commuting, and colleagues, bug you. You want to retire early, but sustain a high burn rate afterwards.
Here are some ways to secure your job, both good and evil:
- Learn the deepest darkest corners of your language and find its most obscure features.
- Apply DriveByAnalysis & BigDesignUpFront, then use them as an excuse to write the core of a program (before you ever start adding any single individual feature). In other words, you are guessing at the entire structure of that program on paper, and then committing the most important part of that guess to code. Long before you ever have a single "UserStory" to satisfy.
- Invest the core totally in those most obscure features. Heck - it's the core, so it has to be advanced and powerful, right?
- Complicate the hell out of that core by snarling those unreadable undiagnosable language features up into a ton of YouAreGonnaNeedIt guesswork that adds no value whatsoever. Make entire layers full of extensible templates, virtual functions, and obese macros - then never extend these or encounter a reason to. (ObfuscatedCode.)
- Enforce extreme sensitivity not just to your compiler, but to its current version. Cripple the PrecompiledHeader? facility; make source-level debugging a nightmare. Use your imagination. If you write C++, invent your own String class, then overload 'new' inside that and put the reference counting stuff there. [Hahah! I love it!!! -- RobertDiFalco]
- Now don't document anything. If anyone asks, document the requirements, or simply produce a useless snow-job. Observe that, from the outside, on paper, this looks just like a healthy Spiral development model. If you don't look too closely.
- Don't put in any UnitTests out there either, because folks might use them to Refactor & simplify your EasterEgg out of existence.
- Spawn a whole bunch of new modules, each of which "extends" the core. Which really means they "couple with" the core. Start adding the features to these modules, to lock in their dependency on the core.
- Analyze your company's profit model to see how high they can go.
The result: Every few weeks, for many years, your old company will pay you $450, $550 or $650 an hour - as high as you know they can go - to fix every bug and add every feature that crosses this core of the program that you burned your mark into.
Meanwhile, hosts of junior programmers will work on actually adding features to this useless core, seriously impeded by its slow compile times, fragility, obscurity and coupling.
Based on a true story.
An instance of an AmorphousBlobOfHumanInsensitivity
Some software houses do this to the public on a large scale as a standard marketing policy...
...alternatively, you can write your code and documentation in Welsh
So I gotta learn another language. Darn. -- PCP
We document in German (ok, Welsh is more obscure). -- JuergenHermann
I can attest to the truth of Based on a true story.
. I'm working on the project he's referring to, maintaining that incomprehensible core. The guy who originally wrote it quit after a couple of years and the company paid him big bucks to work at home enhancing it. He was the "best" C++ programmer I ever knew, and the worst. -- jpm
This is a job for HowToIntegrateExpertInExtremeProgrammingTeam.
This is totally untrue, see:
doesn't require any intentional mischief on the beneficiary's part. Rather than making things unnecessarily complicated, just get yourself assigned to a project that nobody else will touch (either because it is impossible, or because of some horrible required technology. Then even if you quit, they'll beg you to do more work on it. (Unfortunately, based on my own true story.)
That reminds me of the time when I saved my old high school from the tragedy that was their MS Access/Foxpro/whatnot database for timetables scheduling and grading. I rewrote the core of the Access system to be able to do everything correctly in about 2 weeks (that's when they needed the timetables for the next year... they called me in out of panic). Of course, that wasn't enough time to do a proper design, and it was never intended to be. I later made them an offer to build a sustainable system with a proper database back-end and a Delphi front-end, but they refused. Two years later, after they completely trashed the Access system trying to move data to the next school year, I've become a rumored terrorist there. Even many years later, some still seem to think I "planted" something to make the system go bust after certain time. -- SvenNeumann
I'm sure MS knows of this technique.
In MS's case, they plant
the dark corners in their systems, to make VendorLockin?
Not sure whether I want this in CategoryEmployment
, but it's definitely a member of CategoryAntiPattern