Comments (0)

By Krishna, May 31, 2009

via Mark Hurst, here is an article on morning persons versus evening people from Health News:

People who keep late hours and feel more alert in the evening may have a natural advantage over those who rise at the crack of dawn and struggle to stay alert and productive in the later hours of the day. [...] While early birds experience a drop in daytime alertness by mid to late afternoon, night owls seem to handle sleep pressure better and can remain productive for a much longer period of time. [...]

However, late-night people may not fare so well outside of the lab. According to Peigneux, “Morning types may be at an advantage, because their schedule is fitting better with the usual work schedule of the society.” He also added, “It may represent a problem for evening types obliged to wake up early while having difficulties going to bed in the evening, eventually leading to a sleep debt.” In addition, early risers experience a faster dissipation of sleep pressure when they do sleep and they feel restored more quickly than late night people.

My personal experiences agree with this. I am an evening person and find my most productive hours are after 4 pm. I do get a lot of work done before then, but those are mostly one-off tasks. I find that tasks that require a lot of concentration are better tackled in the afternoons and evenings. This is true for such tasks as design, programming and writing which require more thinking.

However, I have seen that this is the reverse for many people. They do their best creative work waking up early in the morning, say 4 am, and completing it before other people wake up. From what I have read, many CEOs of large corporations follow this model because that is the time with the least interruptions.

I think it ultimately depends on the kind of work you do and how it fits in with your life and work. Generally speaking, morning people have a schedule that works better with most office practices and family lifestyles. I have noticed that the older you get, the more you have to change from an evening person to a morning person.

Comments (9)

By Krishna, May 11, 2009

Johanna Rothman considers a management problem where a team has an extraordinarily productive employee in a team of average employees and suggests that the person may be more harmful than helpful:

Another manager has the problem of one person bringing down the expertise of the entire group by being an indispensable employee. Indispensable employees prevent other people from learning because they take care of things for other people. Other smart people don’t want to work with the indispensable employee because they don’t get the challenge of solving the problem themselves.  Indispensable employees are quite dangerous to the long-term health and success of your group.

If you are faced with one really productive employee and some not-so-hot folks, reexamine your situation. Do you have a bottleneck or an indispensable employee? If so, fix the situation. They are not helping you.

It is easy to figure out what to do with a bottleneck employee, but how do you handle an employee who is sincerely working very hard? One of the comments on the post talked about “Free Electron” employees who are arrogant about their capability and disrupt the team. But that is not the general case. Sometimes, you just have a great employee who wants to and does contribute heavily.

From the viewpoint of the productive employee, they are not doing anything wrong. They will be very surprised and negatively shocked to know that they are somehow a “problem”. How do you tell an employee to contribute less? Can you fire or transfer someone for doing more work? This sound very much like the work policies put up by old-school unions to slow down work.

Now, the question is: Who is the productive employee preventing from learning? The answer shows a failure of management and a failure of imagination. There is a management failure because the manager is not hands-on enough to understand which person in his team is incapable of doing work by themselves and requires constant spoon-feeding. Those are the bottleneck employees that should be eliminated in the first place.

The failure of imagination comes from the question of other smart people. I find it difficult to believe that a team has so few challenges that one talented employee can take care of everything. If you think about it, there are so many possibilities and opportunities for research, problem-solving and learning. A manager who can only think of mundane tasks to delegate to his employees is not thinking deeply about the future of his team or product.

Having a very productive employee is a good problem to have. Yes, such an employee has the potential to negatively affect the other people in the team, but the answer is not to dampen their enthusiasm and energy, but to channel such enthusiasm into the proper tasks. Think harder and come up with greater challenges that will engage and excite them. That is also one way of retaining them.

Comments (0)

By Krishna, May 6, 2009

Justin Etheredge had a good post about using code generation only as the tool of last resort. He cites three problems:

1. Maintenance – Generated code can be a maintenance nightmare. If your solution to a problem is to just generate reams of code, then you have created that much more code that you now need to maintain. […] Sadly, many of the problems that people use code generation for can be solved with a bit of reflection, a few abstract or virtual methods, and a sprinkling of interfaces. […]
2. Flexibility – Generated code is often spit out by a custom piece of software or a template. This means that you either accept what is generated for you, or you have to customize the template. What happens when you need some piece of logic generated into a particular class? Well, you either edit your template to enable this case to be covered, or you create a new template for your class to enable this “one-off” solution. […]
3. DRY – […] code generation can be the ultimate DRY violator if you aren’t using it for the right kind of code. Whenever I see someone use code generation for something that could be easily pushed into a base class or abstracted away into another chunk of functionality, I just want to scream! Code generation, when used, should be used for code which does not repeat. […]

That last statement is the killer: “Code generation should be used for code which does not repeat.” Almost by definition, code generation is meant to generate repetitive code with a few variations here and there. Obviously, you cannot use a code generator to create code that never repeats, because what would be the point in that? You would write the actual code instead of writing the code generator.

So if the purpose of a code generator is to create repetitive code and avoid typing, the question is: What kind of repetitive code are we talking about? Is it repetition you can avoid by better design or using a tool such as ORM? Or is it something you cannot avoid because of the nature of the language or framework you are using?

Several years ago, many people would have been faced with the latter situation. For example, EJB required a lot of boilerplate code. It was better to generate it instead of wasting time chasing compiler errors because of spelling mistakes. Sometimes, you needed a data layer that required writing similar database access code. There were no good solutions around it.

Nowadays the situation is different. We have more sophisticated ways of reducing the code that we need to write. The basic idea is to write as little code as you possibly can, because each line you write contains potential bugs. Therefore, code generators do more harm than good because they increase your code footprint.

Another problem with code generators is that their developers try to keep them alive even though the code generated uses older techniques. With the level of innovation we have in the industry, it is risky to be invested in any code generator that forces you along a particular design path. Because code generators are written by the top dog in the programming house, they tend to be very defensive about them, which is detrimental to the organization.

I also hear code generators used as a means to enforce a specific coding standard. Good intention, but wrong implementation. The right way is to get developers to understand the coding conventions and learn to follow them, instead of keeping them ignorant or not allowing them to learn on their own. This kind of behavior also reduces other quality initiatives such as code reviews.

I would say it is not necessary to completely rule out code generators. Never say never. Design well. See what you can leverage from existing solutions. At some point, once you exhaust other options, you may need some automatic code generation. But they should never be a starting point for a solution.