Overcome Optimistic Time

Because I recently delivered a lecture at Utah Valley University titled “Overcoming Optimism” I’m tickled by Seth Godin’s quick post on optimistic time.

Giving optimistic estimates can seriously handicap a web developer.  The people getting your estimates use them as a yardstick for judging your competence. Often they don’t have any better yardstick for judging your ability than how well you make your own deadlines.

It’s hard for you to be good enough to make up for consistently missing your own estimated delivery dates.

Rule of thumb: Treat every estimated date as a commitment. Give yourself plenty of time to be wrong.

How can you become good at this? Pay attention to your track record. Actually take notes on the estimates you give and how they turn out. Ask yourself some questions and adjust your estimating behavior:

  • How many of your estimates are you hitting?
    • Less than 80%: you probably need to give bigger estimates.
    • 100%: you should consider whether you are being aggressive enough.
  • How frantic are you toward the end of a schedule?
    • Never in any rush: probably not aggressive enough.
    • Hair on fire every time: give yourself more time.
    • “What deadline?” Ouch! You need to care about deadlines.

Don’t Talk About Being Professional

In the context of crowing about coming to work even though you are sick: Professionals don’t talk about being professional they just are professional. Mark Horstman, Manager Tools podcast “Yes, Go To Work Sick.” 19:23

Cheap Usability Testing on a Mac

Try out SilverBack 2.0 for recording user testing sessions. Get the screen recorded with clicks plus a view of the user as they muddle their way through your murderous web site.  They are working on a 3.0. They started mentioning it about a year ago but the release is a long time coming. But the old 2.0 is FREE and ready to download (see the bottom of the page).

Don’t Forget This Workaround:

Now, there’s a reason it’s free.  Most new Mac laptops won’t work with it out of the box. Some problem with the iSight camera. But, if you also install the demo of iGlasses then that tweaks your system in a way that makes the camera work with SilverBack 2.0.

High quality user testing tools for no money.  What’s your next excuse? Time? Bah!

Buffet’s ABCs of Corporate Decay

[The] ABCs of business decay… are arrogance, bureaucracy and complacency…. When these corporate cancers metastasize, even the strongest of companies can falter. Warren Buffet in letter to stakeholders as reported in http://www.bloomberg.com/news/articles/2015-02-28/buffett-says-next-ceo-must-fight-decay-complacency-at-berkshire

Having an Employee Performance Metrics Policy

About two years ago, pondering some of my new managerly duties, I wondered, “How do you rank employees?” Every year I have to rank employees and make tough decisions: Should we extend that internship? Should we promote that developer? How will we distribute raises? I can’t manage based on my gut. It’s not enough to feel… Continue reading Having an Employee Performance Metrics Policy

Agile: The Good and Bad Parts

Agile: the Good Parts (according to Bertrand Meyer): developing in short iterations of two to six weeks … has profoundly transformed the software industry for the better. absolutely no one, regardless of rank, is allowed to add anything during [an] iteration. And now, some bad bits of Agile: the general rejection of what’s derisively called… Continue reading Agile: The Good and Bad Parts

SimpleProgrammer’s: 11 Rules All Programmers Should Live By

Yesterday’s Simple Programmer post has a lot of good ideas in it.  If you’re in a rush I give you the rules themselves below. Read his post for the details.

  1. Technology is how you get to the solution, it is not THE solution
  2. Clever is the enemy of clear
  3. Only write code if you absolutely have to
  4. Comments are mostly evil
  5. Always know what your code is supposed to do before you start writing it
  6. Test your sh—code before you ship it
  7. Learn something new every day
  8. Writing code is fun
  9. You can’t know it all
  10. Best practices are context dependent
  11. Always strive to simplify

He correctly predicted getting a lot of comment grief on number 4. I personally agree with him. Developers tend to over-use/mis-use comments.

#7 is a lot like yesterday’s post One-a-Day Keeps Mediocrity at Bay.

Why Am I Happy About Giving Up

The snow-shoe hike to Donut Falls was supposed to be the capstone to last night’s overnight camp. So, why do I feel good about giving up on the hike this morning? Just yesterday I posted about sticking to your plan. Why am I satisfied now with an outcome that doesn’t resemble the plan?

Next page