4 ms·

8. Protect your job: Write code that only you can maintain. Always have a "backlog" in dev that needs you to promote it. Cultivate customers who want only you.

by edw519 13y ago

8. Protect your job: Write code that only you can maintain. Always have a "backlog" in dev that needs you to promote it. Cultivate customers who want only you. 9. Bring up the same fundamental company flaws every staff meeting. This is very easy to do because there are so many and they hardly ever get fixed. "Testing is broken because..." 10. Provide vivid postmortems of problems in meetings and emails. Again, this is so easy to do (and, oddly, greatly appreciated by management). 11. Block out tons of time in Outlook for "faux meetings". You must be important to be so hard to schedule. 12. Leave complex voice mail instructions: "If this is for ORP, contact Joe. If this is for Europe, ping me at...". Makes you look way more important than you really are. 13. Always have lots of complex diagrams on your white board. Change them often. 14. Always have lots of paper plastered to your wall. Change it often. 15. Publish & email explicit status reports often. Make it look like you're the only one who really knows what's going on. "I talked to Mary and she said we have to..." 16. Write & deploy lots of "generating" software that writes other software and runs cron jobs. Make sure your initials are perpetuated on logs everywhere. 17. Always walk quickly. Never have enough time to talk. "How's it going, John? Catch up with you later. Late for a meeting in dev..." (Bonus: always carry important looking papers/folder) 18. Always be on your cell phone. (Not texting or surfing; that make you look like a slacker. Always talking loudly and urgently: "No! The other log program!") 19. Always leave food on your desk. Only busy people never have time to finish what they're eating. 20. Always have treats to share with others. They may not realize it, but they'll probably never allow themselves to notice any of your possible apparent faults. 21. Get your name/initials on as many tickets and documents as possible, even those with only one line of code of just a quick comment on some little thing. People subconcisouly measure in quantity as much as quality. ("Wow, Ed's really been busy lately!") 22. Never use the words "but" or "can't". Put others down (thus elevating yourself) without offending them. 23. Always say things like "Yes, of course," "I am at your service," or "If you ever need help, let me know," You don't actually have to do anything. Just say that you will. People will remember it as if you actually did something. 24. Never chit chat in the break room, hallway, or social get-togethers. Don't accidently destroy your carefully cultivated "too busy" persona.

woody99 13y ago
I once saw a technical manager forced his team to use a poor language he developed to rewrite the company's product to secure his position. It's a few year ugly process. But it worked for him. His position is very secure now.
philwelch 13y ago
So, stop me if I'm crazy, but I thought vivid postmortems were actually valuable?
- mechanical_fish 13y ago
  Vivid post-mortems are valuable if they serve their purpose: Motivating action that prevents future post-mortems. But post-mortems themselves are not valuable at all. Quite the opposite: Every post-mortem signifies that something has died. Resurrecting the dead has probably consumed a lot of time and resources that could have been better spent on something else. An organization should never write the same post-mortem twice, and should see the rate of post-mortems diminish over time, to the point where they are incredibly rare. But that doesn't always happen. Instead, fetishizing post-mortems can be a real problem. It is easy to accidentally build an engineering culture that glorifies firefighting. Every day an expensive team of trained technicians comes to work and dives into the usual series of daily emergencies. Each emergency winds up with a glowing after-action report that gets filed with the other reports. People compete to tell the most entertaining tales of command-line heroics in the face of hilariously broken systems. It can actually be kind of fun, like a game. Everyone feels very productive and important, because without constant vigilance the software would die dozens of times every day. And the post-mortems may be of the highest quality, because every employee has ample opportunity to practice writing them. In such an environment it's astonishingly easy to lose the plot: It is better to be the organization whose software consistently works, and which never writes post-mortems because nothing ever dies. A boring report is a quality report!
  - philwelch 13y ago
    I think it's good to build a culture where having to write a postmortem is a mark of shame. It seems incredibly perverse to do otherwise, and while I appreciate the thrill of a good crisis, any professional should endeavor to do no more and no less than sleep soundly knowing that nothing will break and page them at night. (Developers aren't in the on-call rotation? That's your first problem.)

by edw519 13y ago

woody99 13y ago

I once saw a technical manager forced his team to use a poor language he developed to rewrite the company's product to secure his position. It's a few year ugly process. But it worked for him. His position is very secure now.

philwelch 13y ago

So, stop me if I'm crazy, but I thought vivid postmortems were actually valuable?

mechanical_fish 13y ago
Vivid post-mortems are valuable if they serve their purpose: Motivating action that prevents future post-mortems. But post-mortems themselves are not valuable at all. Quite the opposite: Every post-mortem signifies that something has died. Resurrecting the dead has probably consumed a lot of time and resources that could have been better spent on something else. An organization should never write the same post-mortem twice, and should see the rate of post-mortems diminish over time, to the point where they are incredibly rare. But that doesn't always happen. Instead, fetishizing post-mortems can be a real problem. It is easy to accidentally build an engineering culture that glorifies firefighting. Every day an expensive team of trained technicians comes to work and dives into the usual series of daily emergencies. Each emergency winds up with a glowing after-action report that gets filed with the other reports. People compete to tell the most entertaining tales of command-line heroics in the face of hilariously broken systems. It can actually be kind of fun, like a game. Everyone feels very productive and important, because without constant vigilance the software would die dozens of times every day. And the post-mortems may be of the highest quality, because every employee has ample opportunity to practice writing them. In such an environment it's astonishingly easy to lose the plot: It is better to be the organization whose software consistently works, and which never writes post-mortems because nothing ever dies. A boring report is a quality report!
- philwelch 13y ago
  I think it's good to build a culture where having to write a postmortem is a mark of shame. It seems incredibly perverse to do otherwise, and while I appreciate the thrill of a good crisis, any professional should endeavor to do no more and no less than sleep soundly knowing that nothing will break and page them at night. (Developers aren't in the on-call rotation? That's your first problem.)