Time management – Don’t just work in order of importance

I think every time management book, article, & blog post I’ve ever read tells you to put all your work in order of importance and then work in order of importance. This is great, since the easiest / fastest stuff is always deceptively drawing you in, but never seems to end … and most of it really isn’t important to your goals.

However, I don’t know about you, but my most important tasks seem to be 100+ hr sub projects, and simple 5 minute job never become the most important task, even though you can knock em down in minutes!

So here’s how I attack my work now:

1. I work on my most important task first.
2. Then I work on the fastest & easiest tasks.
3. Then I work on my oldest tasks.

I also pay attention to the time, and never spend more than a day on the easy stuff, so I don’t spend my whole life on it.

Two Rules for a Happy Consulting Client while Charging an Hourly Rate

Some of my projects are a fixed rate and some are hourly. If the scope of the project is small enough to accurately estimate, risks are minimal, and nailing down requirements is practical, I may propose a fixed price. Working on fixed price projects are a piece of cake, I go home, work on it, provide periodic updates via email, phone, or in person. When I finish it I install it and give them a CD with all the binaries, documentation, and source code.

However, I’ve found working on an hourly rate to be a little different than doing all the above while just counting my hours. There is a lot of distrust with hourly professionals which is only compounded with a mysterious process like software development. After all how do they know you aren’t home watching soap operas, working on your own projects, the project of another client, or even sitting on the beach? How can they tell they aren’t being over charged? The problem with trust, is even if you are honest, a false perception can still destroy the relationship.

I know this too well. Once in the late 1990s I was working from home, charging hourly, and I got a call from one of the newer partners of my biggest client (only client at that point). While talking I rebooted to clean out my system* and when the system came back up it played the 20th Century Fox theme, a configuration change I thought was very cool, and he said ‘Are you watching TV?’ I said ‘No. Why?’ … Seriously, I didn’t even making the connection. Two days later I was called in for an unscheduled meeting where my invoices were questioned, I heard a lot of “we’re not accusing your of inflating your hours…”, and the next day, feeling insulted and unappreciated, I resigned. I didn’t make the obvious connection until much later. It doesn’t matter that I was under charging both in terms of my rate and what I charged for, and would never inflate my hours! It doesn’t matter, because the perception was corrupted. It was a tragic misunderstanding since I loved working there and provided a competent, yet naively discounted service.

That’s when I came up with rule # 1
1. Work at the client site when charging hourly.

While following this rule gave my clients assurance that I was actually working, it still left them in the dark as to my effectiveness and what exactly I was doing. I soon realized that working on site isn’t enough. I need to communicate my challenges and accomplishments more effectively as well.

So I came up with rule # 2
2. Provide detailed invoices.

Until this point, my invoices had the typical, single ‘All services rendered’ line item. I changed it to include every single thing I did. I’m not kidding. Here is a sample from an invoice I wrote a couple years ago, after establishing this rule:

---

App F – Investigate & Fix bad XXXXX data

App A – Altered data tables to use the datetime data type for the create_dt & update_dt fields. This is needed to have a granular time for list updates. Communication /w Coder X and answering his questions. Conversation with Coder X about Stored Procedures. Discussions with Coder X about the stored procedures. Generating Business objects.

Feature X – Add Save & Save to Profile to the IFeatureX specification. Alter the Feature X specification document to include autosuggest searching ability in the IFeatureX interface. Reviewed Coder Xs progress.

Planning – Discussions with Manger Y about the purchase of App R, project status, and got permission to take the API documentation for App R off-site for review.

Website – Added new user.

---

Notice how it’s written for the target audience (a non-programmer, IT manager in this instance)? Notice all the detail? Notice I explained why I was changing the data types? Notice the descriptive verbiage (investigated, fixed, altered, reviewed, etc…)? Notice how even something as basic as adding a new user to the website, a 5 minute task is included? Notice I confirmed my permission to take confidential documentation off premises?

There is some terminology which might be unfamiliar to my client, but these terms were introduced to the client before hand, so they understood every thing said on that invoice when it showed up in their inbox.

All this detail may seem like overkill, but it gives the client a level of transparency into the mystical world of software development. It provides a record of activities, allowing the client to feel in control, knowing the priority decisions they made are being acted upon as agreed. It reveals a shadow of tangible evidence on an outwardly invisible service. But most of all, it gives the client comfort and I believe raises the level of trust.

I should also point out, the invoice sample above is not based on a 50-60hr work week, but from a week where I put in 14 billable hours. A 50-60hr work week would usually be 500 words or more.

… hey! Don’t freak out, you can write a detailed invoice without spending your weekend on the first draft. Here’s a brief list of things you can do to reduce the time you spend writing monster invoices:

1. Maintain a detailed time log filled out as you do things. This takes discipline, but almost no time.
2. Make detailed source control comments and do a report at the end of the time period.
3. Make detailed bug tracker notes and list all the bugs/tasks/tickets you worked on during the time period. You can just list the bug ids, but I usually write something like ‘Investigated and resolved ticket # N – User receives 404 error when clicking customer link’.

The key to any of these is to write with your client as your intended audience, this way you just cut and paste into your invoice.

More than a decade after reluctantly getting into consulting, I’ve realized that Perceived value is directly related to the quantity and quality of communication with the client. An invoice can be a key communication device with your client and a powerful marketing tool if you make the effort.

*It was Windows 95 after all. At that point I was rebooting 10 times a day at least.

Copyright © John MacIntyre 2009, All rights reserved
WARNING – All source code is written to demonstrate the current concept. It may be unsafe and not exactly optimal.

11 Personal Programming Assumptions That Were Incorrect

Today I got side tracked and spent an unreasonable amount of time on StackOverflow.com. One of the questions I was looking at was What is your longest-held programming assumption that turned out to be incorrect?

Many of the answers immediately resonated with me, like Instantsoup’s answer That people knew what they wanted and JohnFx’s awesome answer about comparing his knowledge to the collective knowledge of all other programmers. Other answers reflected a poor initial understanding of the language or technology, many of these I was fortunate enough to not relate to.

As you can imagine, I immediately started coming up with my own answers, so I continued reading to make sure they weren’t already there. But as I read, I came up with more initial assumptions which proved to be false. I thought I’d pick out the best, and answer with that one, but realized I had a whole blog post!

So without further ado; here is my list of assumptions about programming and the industry which proved to be incorrect:

1. The customer and user are the same person.
   In consulting with custom in house software this is (almost?) never the case. The customer has their eye on the budget and many won’t give 2 cents to make something easier for the user.
2. You isolate and kill all bugs without exception
   Truth is; there will always be bugs, and what gets fixed is an ROI decision.
3. Writing beautiful software as an act of craftsmanship
   It’s taken a LONG time for me to get it through my head that it’s just another financial investment, where you want to get as much as possible while giving as little as possible. However, although I know it intellectually, I still don’t ‘get it’.
4. Working 24/7 would be rewarded
   Truth is, working all the time will burn you out, lower your productivity, and cause you to make stupid mistakes which reflect on your professional abilities.
5. Vendors can be believed
   In my experience, don’t believe the product will integrate as seamlessly as they say without getting their API documentation and building the whole integration mentally first.
6. You are not actually working from the monitor.
   With today’s GUI platforms, this is largely abstracted out, so you can actually program believing that a textbox is a physical entity. But when you are managing your own graphics, that textbox isn’t going to capture your keyboard presses and display them, unless you provide the illusion. It’s actually up to you to capture the keyboard input, and adjust the memory buffer containing your screen image with the newly typed letter in the control. This was a real mind bender for me, when I first got into this.
7. That I wasn’t a very good programmer
   Like JohnFx’s answer, I was unsure about my abilities. I don’t have a C.S. degree, and was overwhelmed by the depth and breadth of the knowledge out there. But the more people I meet, the more I realized, I might actually be pretty good. Don’t get me wrong, under malicious attack, there are many who could expose and exploit the holes in my knowledge, but in my general area (business software), I’m finding that I’m not too bad.
8. You need to / should grok a language or tool before you even start.
   Groking is a powerful way to start with a new language or tool. But in reality, especially with consulting, there isn’t always time. If you can hack something together in a completely unfamiliar language/tool/framework/paradigm/etc in 5 days, and it would take somebody who knows it cold 1 day, but it would take you a month to grok it … you hack. You may not want to, but from a business perspective … that’s the correct answer.
9. You don’t say you know something unless you’ve grok’d it.
   Well, you don’t need to have too many conversations with too many programmers to know this idea is not wide spread.
10. Other programmers saw beauty in their work.
    Personally, a well written piece of software is similar to a piece of art. It’s my form of artistic impression. It’s my baby. However, there are many people in our industry who do this 9-5, and appear to get no more enjoyment out of it, than I got out of a factory job I had in my teens.
11. The best programmer is recognized
    In retrospect this is almost laughable, at least in consulting! If programmer A writes a wiz bang sub system, takes 2 weeks, it’s flexible to extend, and the core system never requires maintenance. Programmer A would not be held nearly in as high regard as programmer B who takes 1 week, hacks together a piece of garbage which is a nightmare to extend, and is maintained with multiple bugs for it’s life time. This is unfortunate, but in my experience, only a very capable manager would know the difference.

Copyright © John MacIntyre 2009, All rights reserved
WARNING – All source code is written to demonstrate the current concept. It may be unsafe and not exactly optimal.

How to eliminate analysis paralysis

Over the first decade of my programming career, one trend became very obvious to me. I noticed that I could always increase my efficiency dramatically in the 11th hour before a deadline. It took a long time to see (like a decade), but I finally saw the truth…

I now know:

1. Without the deadline; I had Analysis Paralysis
2. Analysis Paralysis is caused by fear
3. Analysis Paralysis is specifically caused by the fear of making decisions

In the 11th hour before a deadline, I made decisions immediately, where as without the deadline, I’d ponder endlessly. Once I realized this, it was very easy to fix; Get all the information, give myself a time limit (1-5 minutes), make a decision, and start.

This was an incredible productivity boost!

Here’s how I streamlined my own personal development process to ‘get all the information’:

1. I list all my options for each design decision
2. I pick the best option(s) based on pros/cons (may be more than one)
3. I list the risks of the best option(s)
4. Then for each risk, I design & write a ‘conclusive’ proof of concept
5. If the proof of concepts prove it will NOT work, then I toss the idea, pick another one & repeat.

A few things to keep in mind:

1. A ‘Proof Of Concept’ is a minimal app to prove something. (mine are usually 1-6hrs)
2. If 2 or more options are equal, I give myself a time limit (1-5 minutes) and make a decision … any decision, and don’t look back.
3. Trust yourself to be able to deal with any problems you hit which were not take into account at design time.

Copyright © John MacIntyre 2009, All rights reserved

WARNING – All source code is written to demonstrate the current concept. It may be unsafe and not exactly optimal.

Obviously unethical consulting … but why?

A few years ago I did some research into CMS applications and it occurred to me, that an unscrupulous web design company could easily sell a website and deliver nothing more than an installed, free, open source CMS app with a simple custom skin. They could basically; install the CMS app, create, buy, or even steal a skin, then cut & paste the clients copy into it. A fairly sophisticated (aka expensive) site could be launched in one evening, and the client would never even know the difference. Heck, many clients wouldn’t even care if they knew the difference and a carefully worded contract would protect the web design company if the client did care.

It’s easy to speculate that others may be doing this right now, been doing it for years, and some may have even made fortunes doing this.

… wait … what? … fortunes? …

… and with this, my rational mind kicked in and argued that as an ‘Entrepreneur’, isn’t this exactly what I was supposed to be doing? Trying to make as much money as quickly as possible, while minimizing my costs? Isn’t that what business is all about? Isn’t this providing the customer more value faster? Maybe this is the way to go!

Think about it; StarBucks is praised for quadrupling the price of a cup of coffee by adding foam … foam! … Air with a thin milk film separating the $5.00 air from the free air. How is it StarBucks is praised for selling foam, while what I described above is clearly wrong?

To be honest, I had a very tough struggle with this … not IF I should do it, but why is it wrong? I mean you could probably do this ‘legally’, while the ethical question was very difficult to quantify and easy to argue against with simple business logic.

It really comes down to the question; what exactly is unethical about this?

After wrestling with this question for weeks, I finally realized the answer.

As a consultant, there is an implied promise to use ALL my knowledge and skill to advance the clients interests.*

The ethical issue in this specific situation arises when information about an easily implemented solution is withheld from the client. This is the problem … this is why the above scenario would make anybody with a conscience uneasy.

This situation can be made ethical by a disclosure of the advantages of using the particular open source package and what exact you will bring to the arrangement. By selling the installation, customization, and configuration of open source software, not burying the term in the contract while implying a custom solution, and you are being ethical.

You can still make a lot of money doing this and it’s ok to charge a high rate. Charge $50/hr, or $80, or $100, or $150, or $200, or $2000, or more if you want … that’s totally fine, as long as information is not hidden from the client. After all, everybody likes money right?

Now as far as I know, there is nothing illegal about the above scenario, but just because something is legal doesn’t make it moral.

Agree? Disagree? Can you add a clearer distinction? Add a comment.

* With exception to confidential information acquired outside of this client.

Copyright © John MacIntyre 2009, All rights reserved