by on

One of the hardest things I face as a developer is to get the number of billable hours right in the timesheet. Traditional office work always meant to be hours present in the office to be equivalent to the number of hours worked as there was a structure and flow to the work. It is unfortunate that the knowledge workers fall into the bucket of hours of work at the workplace as a measure of billable work.

Knowledge workers have to do a good deal of home work to stay up to date. Any task at hand they pick, will involve some amount of deep thinking and application of knowledge. Thinking can happen anytime and not necessarily at workplace. Hypnagogia has provided me some solutions for some pressing problem, it is also famous for discovering Benzene ring structure. If a scientist can benefit (eventually monetary) from that kind of discovery, then why not we bill the time we spend in thinking about the problem in hand while waiting at the traffic signal lights or having a shower.

In the book Pragmatic thinking and learning, the author mentions about L-mode and R-mode of the brain; there is an example of that here. What we usually end up billing as a knowledge worker is what is done by L-mode, but the many of the inputs comes from the R-mode of the brain. The bias of billing for the L-mode makes people spend a good deal of time with tools rather than thinking about the solution and constantly striving to update themselves. It leads into a vicious cycle of working too long without success if the task at hand requires deep knowledge and application, which leads to more hours billed without any work done.

We should look at work as a whole outcome than measuring it in terms of man hours or lines of code. In that way it provides the individuals the freedom to plan their day and deliver effectively at their job.

Image: FreeDigitalPhotos.net

by on

Nat Geo’s air crash investigation series gives a good deal of idea behind what went wrong behind an air crash or failure. I was watching one of the episodes which was about the rudder malfunction of Northwest Airlines Flight 85 and how the pilots kept such a large plane in control and landed it safely. All the pilots in that plane continued to fly the plane by adjusting the engine thrust and ailerons to fly to the nearest airport and land safely.

As per the captain’s account it was a very tough thing to fly such a large plane manually. The captain is also a flight instructor so he had a sound understanding of the dynamics of the plane. When interviewed he said “Learning to fly manually is an art, sadly that is a dying art“. Increasingly planes are being designed and manufactured to fly themselves most of the times. This makes the lives of the pilots so easy that most part of the journey is assisted by the machines. But when the machines fail or not designed to handle failures, can humans take over?

What happens to other professions where there is an ever increasing assistance provided by the computers and machines? The result must be the same; when something goes terribly wrong; then there will be a disconnect between the man and the machine. From that point onwards it will be just trial and error handling if there is no deeper understanding of the system.

I read this article on leaky abstractions longtime ago. The author states that if something non trivial is abstracted then the abstraction will be leaky and put us in a spot. This article also prompted me to dive deeper into something if I am learning new. It is really tempting to hang on to the hello world examples & the new hello world of GUI “To do lists” and get away with a feeling that I have got a fair exposure. If I just learn that but not spend enough time to understand the internals, then I would be in a bad spot someday when I least expect.

Image: bk images / FreeDigitalPhotos.net

by on

Patents were introduced to encourage inventors to come out in public and get the due credit for the invention. It also granted exclusive rights to the inventor for a certain period to enjoy the fruits of the invention. Though patents are a great way to protect inventor’s effort the laws and enforcements are generally tricky. Some countries have chosen to ignore the Pharma company patents to protect the health of the public as patents were monopolizing life saving drugs.

Paul Graham mentions in his book Hackers and Painters about the copyrights & patents in software and how the laws enforcing them are beginning to threaten intellectual freedom in the field of computers. Laws can be so tight that it can prevent an individual from dismantling something and looking at how it was built. Many people I have met are of the opinion that patents do not have a place in software.

Assume that we work hard and create something,  secure it with a patent and prevent a large corporation from copying it. They can still ignore the patent go ahead with money power to face the lawsuit. So patents for inventors might not guarantee immunity. Then how can we be sure that someone cannot copy our work?

Paul Graham’s answer is to run up the stairs. His analogy was interesting, assume in the computing world the giants are usually large, burly people and startups or individuals are slim and agile; if they are trying to chase us out of existence then it is fairly easy when running downstairs or on the corridors but it is extremely difficult for them to chase when we run upstairs.

The examples are in the profession of sports, arts and music. What a top musician does is so easy to imitate, but she/he can keep coming in with more performances that others find it hard to emulate the success. Innovation is the key skill, the skill cannot be copied. What we need is to find what is tough for others to do and do exactly that. To run up the stairs we need to be strong and healthy, similarly to be ahead at work we need to be strong at what we do.

If we run upstairs chances are high that the competition is always left behind. Here is Paul Graham’s essay which covers the topic of running up the stairs.

Image: Ambro / FreeDigitalPhotos.net