The person who doesn’t “have time” to evaluate new software/features will the same one complaining about being “left out of the loop” immediately following implementation.
The greatest percentage of wasted hours will be those spent implementing “quick-n-dirty” solutions.
(H/t to former co-worker for the base idea) The sequence for creating a custom web application is as follows:
- Make it work.
- Make it usable.
- Make it fast.
- Make it secure.
- Make it pretty.
- Make the logo bigger! (Obligatory, albeit NSFW)
(One for the System Admins).: Computer viruses, like V.D., will never, ever be the fault of those infected. Less so when they’ve managed to infect others before they're forced to shout for help.
Death-march deadline work will be done under salary. When your body inevitably hands you the bill, the sick time will be charged to your PTO. (Because programmers just aren’t that into working out or eating right anyway, don’cha know...)
The documentation for the down-level version of third party software you have to support will have been taken off the website before you need to debug that component or wrap your brain around what-all the API does.
Any work that furthers your marketability or improves your working environment will be done on your own time and/or nickel. Accordingly, expect to be frowned-upon for wasting it on non-objectives.
No matter how much you tweak an IDE’s code completion/formatting settings, its “intelli-sense” will always train you to deal with its quirks more than you will ever train it to deal with yours.
When you’ve just come off a milestone release, your reward will be spending more--politically mandatory--time "celebrating" with the co-workers you've seen more of than your family and friends.
When the software that the office lives and dies by goes down, it will be down for long enough to impact your billable hours, but never for long enough to throw in the towel and take the rest of the day off. Unless, of course, it’s “your” software...
Your best chances of having your brain-child feature make it into the final product is to let your boss suspect that you adapted someone else’s idea.
Googling your billion-dollar idea is an exercise in discovering that: 1.) It’s already been implemented by someone else, 2.) as open source, and 3.) poorly enough to poison any market for it.
In the event of a downturn, scarce resources will be allocated to marketing, rather than quality or new features. In the event of further downward fiscal movement, still-scarcer marketing resources will be allocated to re-branding, thus wiping out any product visibility achieved by previous marketing.
(Bonus: Your firm, during its death-spiral, will have assumed more names than 007, prompting interviewers to ask why you couldn’t hold down a job with the same company for more than eighteen months straight.)
When a critical patch has to be scrambled into production, the change-sets will always be merged from the wrong branch, breaking even more features.
Planning for after-hours or weekend “quiet time” to concentrate on a thorny problem guarantees that a great gaggle of co-workers will also choose to come in at that time. With their kids in tow. Who will promptly clean out the local candy-dish. And wash it down with Mountain Dew from the soda machine. Meaning whatever Mountain Dew isn't spilled chair-jousting. You, by the bye, aren't trusted to work remotely because, you know, you’d only be distracted at home.
One programmer’s precision-targeted workaround is another programmer’s undocumented ugly hack. Guess which programmer you will be for most of your career.
Among database synchronization tools, intuitiveness and usability exist in inverse proportion to the carnage the tool can wreak.
Meetings will be added to the schedule until productivity improves!
