Category Archives: Productivity

It’s about the Individual, not The Team!

I am so tired of late hearing about how it takes great teams to succeed. Whether it’s software development, starting a business, or football, the dogma is the same: “It takes a great team to win!”. That’s baloney!

The one thing that’s often overlooked by the people preaching this non-sense is Pareto’s Law (80-20 Rule). Which states that 80% of the results, comes from 20% of the effort. The numbers are often skued even higher 90-10, 95-5, but the general rule is that in no matter what system you have, the vast majority of the results come from a VITAL FEW.

Maybe the people preaching this are there to make others feel good, or they are selling something, because after-all, 80% of the people that contribute the least to things want to feel important.

Programmer Productivity

What makes a programmer productive?

There are lots of ideas about this and I have a few of my own. I have read some interesting articles and books on Pareto’s Law (The 80/20 Rule) and am finding that most productivity comes from just a few things.

3 Most Effective

  1. The Language – The language you choose to do most of your coding is directly proportional to the efficiency of your programming (lines and quality).
  2. The Libraries/Frameworks/Resources Available – Depending on what you are programming, re-inventing the wheel is wasted effort.
  3. The Programming Environment – Text Editors, PC/Mac/Linux, Number of Monitors, Other Tools, Fast Internet Connection.

3 Least Effective

  1. Development Methodology – This only matters when projects are not well thought out and people don’t know what they want programmed. But for the programmer that knows what he wants to code, it does not matter.
  2. Unit Testing – I have friends that will roll their eyes at this statement, but I’ve written so many lines of code with no to little defects and I’ve not written one unit test or test case. In fact writing unit testing and doing testing on obvious stuff was the most wasted weeks I’ve ever spent.
  3. Anything that makes code more maintainable – Often you will hear about rules that are good for creating maintainable code, some pattern, avoiding some anti-pattern, lines of code in a method, or size of a class file, etc. These all sound good, but the fact is only a small percentage of code is ever re-used, so stop trying to make 100% of it reusable.

My Do Not List (!To-Do)

I’ve been working lately on creating a DO NOT LIST, my first few items are below:

  • Do not multi-task, I find that when I do this I end up doing all items half-a$$ed.
  • Do not check email and Google reader all the time. I’ve found this tough to do, I think it’s because I’m so conditioned to doing these things so I “feel” productive, but they actually don’t make me productive, they just fill time.
  • Do not speed through life/the day. Once again to “feel” productive I want to rush home, rush to work, drive to place X the most efficient way possible. All of this optimizing has made me completely loose sight of enjoying the day.
  • Do not spend time on the 80% of things that contribute the least to my life.

So if you’re thinking and wondering about being productive and more efficient, consider creating a “DO NOT LIST” as way to keep yourself in check.

Arch Villains – FUD Man & Frameworkinstein

I was reading this article over at 37signals and I realized that my enemy is inefficiency and it takes form in two arch villains:
  • FUD Man – This is the person on the team or the architect that creates enough Fear Uncertainty and Doubt to ensure a solution/application is over-engineered and over-budgeted. This usually takes the form of a J2EE solution requiring offshore to get it done on time and on budget.
  • Frameworkinstein – This person is usually FUD Man disguised as a hero coming in to propose a framework to take away time but in actuality it adds time and complexity to an already over-engineered solution.

How do you defeat these two in corporate IT? Ruby? Dynamic Languages? No. Those are usually the wrong weapons and you can’t fight FUD with something people know little about. To win this war you need to take lessons from Sun Tsu. Here’s some tactics:

  1. Attack The Foundations of FUD by finding the most important emotional driver for the decision maker. If it’s cost make it cheaper, if it’s quality, introduce a quality process, if it’s power, caste doubt on his/her ability to control the project.
  2. Ask questions like: How would we do this if we had half the time and budget to management without FUD Man around to respond.
  3. Find a better framework than proposed only to show that one is not really needed.
  4. Show examples of how someone smarter than you or your villain would do something different and how they succeeded.
  5. Create a prototype/example in a few hours that does a good majority of the work, and ask management: If this only took me a few hours, how can we spend all this time and effort on something that’s essentially the same thing?

Good Luck in your fight, may the force be with you!!!

Perfecting Lazy

Over the past three weeks I have been perfecting one thing, being lazy. Not lazy in the sense where I do nothing, but lazy in a way that we drive cars instead of walk, that we use washing machines instead of washing boards, that we use computers instead of pen and paper.

Some of the things I have done is batching of the following task:

  • Email twice a day, mainly to just check for emails from friends and family.
  • Google Reader in the evening for pleasure reading.
  • Stopped reading news sites, just checkout Google News for sports updates.

I have also stopped multi-tasking and have decided to do just one thing at a time. I always thought I would get more things done by multi-tasking, and well I did, but it was usually four busy things to one important thing. I’ve stopped doing the busy and unimportant, and concentrated on just one thing to do per day that is the most impactful and brings me the most enjoyment.

For more readings checkout The Lazy Manifesto over at zenhabits.net.

One Project – A Robot Building DVD

I think that this year I am going to try and limit myself to one project at a time, rather than starting three or four and doing them all partially and then getting frustrated at the results.

The whole multi-tasking concept is dead for now. My thinking today is that if something is worth doing, it’s worth doing well with focus. I use to think that doing more was being more productive, but as I look back, I did more things, but was not more productive, I was just busier, and more stressed.

Currently I am going to do some market research in a Robot Building DVD. The initial concept is to have a how-to DVD and manual that would allow for someone to with a short supply list acquired from the local hobby shop or online robotics shop, to build a robot that does something cool. It’s just an introduction, but I find in all of my robot meetings, there’s a lot of people interested in robotics, but very few have robots to bring in and most just have a desire to learn about robotics.

Giving Up Stuff

I am re-reading my book, The Power of Less, and have noticed for the past 5 days I have given up, hourly email checks, television, news, RSS, and all the other things that I waste my time doing when I’m back home. I am so relaxed.

It makes you think about all of the things you end up spending your time doing and then you wonder why do I say I never have the time? It’s just about focus, priority, and doing what matters vs. keeping myself busy for the sake of being busy.

I am writing now, but this is relaxing, I’m on my PC, but because of network access I don’t surf or checkout Facebook, I just go through the photos on my camera and post a blog or two, before going to take a nap, or a walk on the beach or reading some of the books I brought with.

Now giving up beer, I think that will have to wait until I return back to the states…