This year I turned 40, and I looked at a lot of different things in my life.  One of them that I focused the most on was what was meaningful work to me.  I spend 8-12 hours a day working for someone who isn’t me, and in those 8-12 hours I need to do things that make me happy, otherwise I should probably go off and become an organic hybrid chioat (half chicken, half goat…egg bearing of course) farmer.

So I sat down and figured out what matters the most to me at work.

Don’t Do It Unless You Can Make It Awesome
I love Captain Pike’s line in the JJ Abrams Star Trek Movie. “You know, your father was Captain of a starship for 12 minutes, he saved the lives of 800 crew including your mother’s and yours. I dare you to do better.”

My goal is to make everything I touch better, no matter how small that improvement is. That should be your goal too. Everything you do should be better than it was before you touched it.

If you can’t do that, stop touching things.

What You Do Is More Important Than How You Do It!
The minute you have written that last line of code you will figure out a better way to do it. I can’t count the number of times that I’ve finished a project, looked back at a bunch of the CSS classes I declared, and said “Well whoever did that was obviously stupid.”, that whoever was me…and at this point…who cares? Get it done, refactor through iterations, and move on.

Just Get It Done!
Seriously, get it done. Don’t spend endless hours wondering what you could do, writing intricate specs, and trying to figure out exactly what user base will use exactly what feature.

Experience tells me that we’re wrong 90% of the time anyway.

Users don’t use your product the way you think they will. They’ll hack it into new configurations, and figure out new ways to ruin it. Just get it out there, refactor it through iterations, and move on.

Just Ship It Already!
It’s good enough. You have no idea what users are going to do to it anyway. Why are you optimizing the network code if you don’t even know that 5 people are going to use it? Get it out, and if 1000 people start using it, throw up a “Oops, you guys are kicking our asses” post and get busy refactoring it…then refactor it further through iterations, and move on.

Make sure you know who you’re coding for
This is where “As a (type of user) I need to (do something) so I can (gain a benefit).” comes into play, if you’re unsure of exactly what you’re doing, make sure you look hard a the user type, what they want to do, and what benefit they get out of it. If you’re missing any one of those you’re probably doing something that doesn’t need to be done.

A system is NOT a type of user
Don’t ever say “as a system I need to do something”, systems aren’t actors, and if you’ve identified a system level task, congratulations…you just discovered a task. Figure out who the person is who gains the benefit, and you’ve got a task.

Know when to throw out the rules
As a (type of user) I need to (do something) so I can (gain a benefit). It’s a great way to remember all of the actors and benefits, but frankly if “The publishing tool needs to PUBLISH A GORRAM BLOG POST WITHOUT BREAKING” gets the point across…WHO CARES (besides the Scrum Police ™).