Thought Clusters

5 Steps to Becoming a Terrible Programmer

2008-07-06T20:40:00.001-04:00

During your career, you will come across both great and poor programmers. While one may be tempted to group all poor programmers together, there are different levels of poor programmers. It is instructive to know the difference, because generally (especially if you have just joined a new company), you cannot go on a firing rampage, throwing out anybody you deem incompetent. You may to have to tolerate some levels of incompetence and know what you can work with.

Here are the 5 levels of incompetence, in increasing order:

No intelligence
No interest
No sense of responsibility
No fear
No self-respect

No Intelligence

A more intelligent developer means more productivity, more creativity and fewer mistakes. The reason why a particular developer is performing poorly may be that they are unable to comprehend or remember things as effectively as a more intelligent person. The population of programmers is, on average, more intelligent than the general population, but you will find some extraordinarily brilliant persons and some not so good.

Sometimes, the problem is that you are expecting too much from someone that is beyond their physical capabilities. So, you have to tone down the challenges a bit. Reduce the multi-tasking. Provide systems that help them remember and keep notes. Establish standards. Use software and/or procedures like code reviews to help them in their work. They may perform adequately in their reduced responsibilities.

No Interest

A person of average intelligence, but with a high degree of interest in software, can be a very useful developer. When a person develops a special interest in a subject, they spend an undue amount of time tinkering with the subject and, by constant reinforcement, can learn the necessary techniques and tools. The only problem with a lot of knowledge and less intelligence is that the person cannot be depended on to find any creative solutions.

But when the person has no interest, you have to depend on external motivation and rewards to get the person to do anything. You may need to allocate separate time and funds for the person to improve their skills, because they hardly spend any time outside the office even thinking about their work. You should never assume that the passage of time has automatically made them more experienced and more capable.

No Sense of Responsibility

An external factor for many career programmers is a sense of obligation towards customers. The customer pays the bills and hence they are entitled to good quality software that performs to the customer's expectations. Or the developer may feel obliged to pull their weight for the team. When the programmer stops caring about the customer, the team or the company, they don't worry about productivity or quality. They just think about the paycheck that they receive without any moral qualms.

At this level, you cannot reward the programmer to do more. Instead, you can only use punishments to enforce quality. Fear of losing one's job could be a factor, especially in a bad economy. However, there are many problems for you as a manager. Until used, the firing option is simply a vague threat. You must have demonstrable differences of the fired persons with respect to the rest of the team. Finally, firing someone can have unpleasant side-effects on the project and the team.

No Fear

The talent-less and irresponsible programmer may still produce something if he/she knows that the work is being monitored and is aware of the consequences of bad quality (such as demotion or unemployment). Some persons may not even care about that. For example, during a labor shortage, some employees may be job-hopping and may not be worried if they lose a job. Or for reasons like nepotism or favoritism, the employee may never have to fear about punishment.

At this stage and assuming you cannot fire them, you have nothing left except to beg the person to get something done. Appeal to anything that they may have left in their character. A more practical approach would be to assume that they don't exist, and then hire more people to fill in the gaps. That is pretty expensive, but that may be your only option.

No Self-Respect

You have nothing left. Period. If the person does not even care what others think of him or her, they will just do what they want. If they don't feel ashamed that their poor quality of work reflects upon them in front of their boss or their co-workers, it is impossible to do anything with them.

Final Thoughts

The last three factors (and perhaps even the second one) are a function of age. The older one gets, the more one feels the need for security, belonging and self-worth. It is also more difficult to change one's profession. People develop a greater pride in their work. So being a terrible programmer is not a static situation.

Technorati tags: software development, programming

Web List Functionality

2008-06-22T21:00:00.001-04:00

Initial implementations of lists in a web application are generally very simple. As the list grows in size, more functionality is required. Here is an attempt at compiling the major functional requirements of a list. You may not use many of these functions, but it is useful to know what is possible.

Searching

There should be an easy way for users to search all fields of the entire list. The simplest implementation would be a single textbox with a Search button. Users may then want to search on specific fields. A straightforward method is to present separate input fields for each searchable field. This however limits the user to searching each field for one particular value. You may have to present additional fields for specifying ranges or conditional operators (like greater than or equal to).

For more complex conditions, it may be helpful to present a query language like a simplified version of SQL. Or better still, provide a query builder, where the user can create a complex query and execute it. This is more preferable as it reduces the learning curve from beginner to intermediate. The query builder should also provide for searching dynamic values such as "today", "current time", etc. and aggregate functions such as "total sales is greater than x".

Users may wish to save their queries for a later time. It should be easy to give them a meaningful name, description and even allow for tagging. Sometimes, the user may want to save the results of the query (a snapshot in time) instead of the query itself. Saving a data set may only be possible if the list size is small. Otherwise it should allow the users to export the information out to a document in Word, PDF, Excel or other formats.

Paging

Paging is more a practical than usability concern. Users may wish to have all records displayed to them, but doing so would be time-prohibitive and involve unnecessary data processing, when the user is interested in just a few records. Paging is generally implemented by links to different pages, though nowadays, it is common to see the "infinite" page where vertically scrolling down displays more records fetched dynamically that weren't there initially. Live Image Search and Google Reader (see below) have good implementations of the latter design.

If the list is organized alphabetically or chronologically, being able to access a specific page is a more useful feature than displaying an infinite page. The reverse is true if the list organizes the results by relevance or randomly. For example, you might guess that the middle page of a contact list may contain names starting with "K" or "M", but retrieving the 100th page of Yahoo! search result page is meaningless. For the former case, provide links or "jump-to-page" functionality at the top and bottom of the list.

Users would also find it useful to control the number of results per page. A global setting is usually appropriate, though it is more helpful to provide a setting in each list screen and remember the last selected value. For the default page size, choose a value that returns a reasonable-sized amount of data without the user having to navigate or scroll too much. Somewhere between 10 and 25 seems like a good guess, but you can make a more educated decision by observing your users and finding out how much they click to a different page or scroll for each page.

Displaying the number of results across all pages can be useful. But performance concerns may prevent you from giving an accurate value. In such cases, you can do what Gmail does, give an estimate:

Sorting

The most common implementation of sorting results is doubling the header column as a sort column. You click on a header column; the data sorts by that field. You click again; it sorts in the reverse order. Display the sort direction as an icon or arrow in the column. The limitation is that you can generally only sort the data by one column. Also, the sorting is not linked to the search functionality, so each time the user issues a search, he or she has to sort the search results again.

A better implementation would be to allow the user to specify multiple sorting criteria, so that the user can say, sort the contacts by city and then by last name within each city. This can be part of the search section and so each saved search can have its own sort. You can still retain the column heading sort, but it would be overridden by the search sort condition when the search executes. But after the results are displayed, clicking on the columns would override the search sorting, thus avoiding the need for users to change the search sort condition for a temporary sorting need.

There are client-side implementations of sorting data, but they should be avoided because generally the client does not receive all the data because of paging. Sorting the single page of results provides incorrect results from the right method of first sorting the entire data and displaying the first page. Another mistake commonly seen in client-side sorting is that numeric values or dates are sorted as if they were strings.

If the user has not sorted the data, it should default to the most meaningful sort. For example, contacts should be sorted alphabetically. Bills should be sorted by the one pending for the longest time.

Layout and Information

Should you have lines for separating the columns? What should be the font size of the columns? Should you display alternating rows in different colors? There are so many different choices that you can make for presenting the list information. Let me point you to Matt Berseth for some examples (and code!). Of course, tables do not have to be your first choice, either. You could present the data in a visual manner, such as graphs or maps. In such visual displays, paging and sorting are less of a concern, but searching (or filtering) remains important.

While designing the layout, you should be concerned about noise. The user is generally interested in only a few records and perhaps only a few columns. Searching solves the first problem. Providing the ability to show and hide columns helps with the second. I think it is better to allow selection of necessary columns when providing search criteria, and then allow a separate override when the search results are displayed.

Summary headers or footers are useful. While the conventional method is to have a summary row, on the web, providing the summary information in the header can avoid scrolling. You can even create a summary that provides information other than an aggregate function of a particular column. Of course, it goes without saying that the summary information must be emphasized using a greater font size or color.

List Management

Users want to do more with their lists. People like list management because it reminds them of a spreadsheet program like Microsoft Excel, which makes it very easy to add and change data. Though a web application has other better features, users want it all. A common need is to apply an action across multiple items in the list, such as Delete or Mark as Read. We see this uniformly implemented using a checkbox column. Users can choose the required items and select an action. While this works effectively, it limits the user to working with the current page of results.

Many implementations also have a master checkbox (in the header column) that selects or unselects all the checkboxes in the list. However, Gmail differs by offering text links for selecting "All", "None", "Starred", etc. Hotmail has, perhaps, the worst implementation of the checkbox column. First, the checkbox is hidden behind an envelope icon. Second, if you miss the checkbox when clicking, it opens the message, making you lose all the previous checkbox selections you made.

With the increase in Ajax-enabled applications, users are demanding more from the list screen, such as the ability to add and edit records right in the grid. This works well when the number of fields in a particular record is relatively few. When a record has more fields, the user is forced to scroll horizontally. Some fields may require more advanced controls making the page code-heavy and unwieldy.

Security

A final piece of the puzzle is security. Some records must be hidden or disabled for some actions for different groups of users. A simple case would be each user owning the records that they have created and others unable to view them, unless the user decides to make them public or share them with select friends. This is a common situation with most social networks.

Advanced security may require an authorization module that allows the system to define user roles and access rights. Building this or re-using an existing framework may take a life of its own especially if security is very fine-grained, because the authorization module is linked to every part of the application. Keeping it simpler can mean easier development.

Security is a large and complex domain. This is one area that you will have to pay increasing attention to as your application gains more users. Managing the authorization framework, managing the needs of the end users and continuing to build your application can be quite demanding. So plan well for it.

Technorati tags: software development, web development, lists

Why Leadership?

2008-06-17T18:09:00.001-04:00

The powers-that-be of the cricketing world have finally come to their senses and decided to allow players to challenge an umpire's decision. The umpire can now use slow motion replays, microphones and other technology to make a more accurate decision. For those unfamiliar with cricket, this is the culmination of events that were set forth after a match between India and Australia marred by some egregious umpiring decisions threatened to snowball into a diplomatic crisis.

For the spectator, a decision like this is a no-brainer. You don't want your team to lose because of an incorrect decision, nor would you be thrilled when they win only because the umpire helped them. Yet, the decision makers kept finding all kinds of reasons to avoid using technology: "Officials must be respected!", "Technology is not infallible!", "Bad decisions are part of the game!", and so on

In the general context of organizational behavior, this is not very surprising. Organizations tend to do nothing until their hand is forced by a crisis. But this kind of behavior does reveal some patterns why organization behave so. Small mistakes are easily forgotten, especially when they make little difference to the final outcome (for example, most games are not affected by bad decisions by officials). People also like to move on, instead of dwelling on mistakes. People who are negatively affected have little decision making power. This is true for every consumer, and in many cases, a monopoly prevents the consumer from taking his/her business elsewhere.

It is useful to pay attention to the small mistakes to prevent them from causing harm in the future. But that option can also be taken too far, where every mistake is caught and people taken to task. Such an environment breeds fear and prevents people from taking any risks. Another problem is that you may over-react to infrequent problems and cause more harm by trying to fix something best left alone.

The situation explains why leadership is so important. Without leadership, it is very easy to ignore problems or create new ones by being panicky. Leadership provides the right organizational setup, where people can take risks while continually evaluating their processes and decisions without creating a climate of fear and mistrust. Crisis prevention, not crisis management should be the guiding principle of good leadership.

Technorati tags: business management, leadership

Actionable Web Bookmarks

2008-06-16T17:57:00.001-04:00

I have been using web bookmarks using various applications like del.icio.us, Yahoo Bookmarks and Google Bookmarks, as well as the built-in functionality within the browsers. Although all of them have good features, one important thing that is missing from them is the ability to tie actions to them. Here is what I would like to ideally do with different kind of bookmarks. Some applications have partial functionality available and I have enclosed them in parentheses.

Mark a bookmark as something I will use on a daily basis, such as login pages for various accounts. I should have an option to open all such bookmarks in different tabs in the browser (Firefox/IE does this).
Mark as something that I may need infrequently. I might have different levels of frequency of use. So I would want to classify them as such.
Mark a bookmark to visit on a particular date, or on a recurring basis. Example: a bill payer or bank site. I should get a reminder in email to visit the site.
Mark as read and archive with an option to share. This might be an article that I want to read, but I have no use after reading it. I might want to email or share the bookmark with others in my network (del.icio.us and Google Reader does this).
Mark a bookmark as the definitive answer to a problem I faced. The application should keep track of why I bookmarked the answer, so that it can help me answer the question in the future (Google Web History remembers the search and the associated search result I clicked on).
I would like to know if someone visited the bookmark I shared with them.

Most bookmarking sites are concerned with categorizing bookmarks based on content, or sharing the bookmarks with others in the social network. That is helpful, but the bigger benefit for an end user is answering the questions: What does the end user want to do with the bookmark? When do they want to perform an action based on the bookmark?

Technorati tags: bookmarking

Pair Programming and Code Reviews

2008-06-15T20:36:00.001-04:00

One simple definition of pair programming would be continuous code review. Instead of doing code reviews at definite intervals, one programmer continuously monitors the code written by his/her pair programmer. One could have yet other code reviewers in addition to the pair programmers, but in general, the principle stands.

A single programmer producing code without any code reviews may be the most efficient scenario, if it didn't conflict with the reality that programmers make mistakes. Those mistakes are uncovered during testing and the programmer is forced to spend additional time fixing those mistakes. The effort and time involved in fixing a bug is greater than that involved in correcting it before the code was sent for testing.

One reason is the time taken to perform the release processes again after the bug is fixed. Second, the process of fixing the bug involves the programmer to spend time re-understanding the code and debugging. Thus, combining programming with code reviews increases the efficiency of the programmer.

Pair programming, considering that it is constant code review, should increase the correctness of work produced by a programmer. At the same time, it keeps one programmer off producing code. So does the efficiency of producing correct code balance the inefficiency of keeping one person idle? There are studies done to find how efficient pair programming is, but the jury is still out. However, I think a few ideas may be useful in deciding what works in your situation.

First of all, there are many development activities that lend themselves well to working in pairs or small teams. Design, at a higher architectural level or lower algorithmic level, is one such activity. Working together can help team members complement each other, providing ideas and correcting errors as they occur. I have often found that working on a relational database design in a team can be very productive.

On the other hand, some programming activities can be done in isolation. For example, if you have a well-defined HTML prototype, re-creating that in a web programming language (by a reasonably competent developer) does not require much oversight. Or, if your application requires a lot of boilerplate code and you are not using code generators, you could have developers work on it independently.

Another concern is that pair programming can avoid distractions and help you make the most use of the available time. This is one reason why study groups are so popular - each individual can maximize the time spent in productive activity. Assuming that pair programming makes more time available for development, it may be more efficient than a simple comparison with the work done by a single programmer alone would imply.

Technorati tags: software development, pair programming, code reviews

Project Scope and Bug Density

2008-06-09T18:28:00.000-04:00

One important consequence of bug reports is that they not only affect your schedule, but also conflict with your priorities. Release of product features is negotiable to some extent. A critical bug seldom is. You have to postpone much of your planned work until the bug fix is released. That step requires you to perform the release management steps again, so your quality staff members are also involved and they cannot pursue other planned activities.

The other important problem with bugs is that every bug lowers the confidence of the stakeholders in both the product and the creators of the product. The bug does not have to be serious to reduce confidence. It can be a minor bug that is irritating or confusing or careless. Lack of confidence reduces the effort that users are willing to put in to learn the system.

There are many ways to improve quality in your project and reduce the bug count such as different forms of testing, code reviews, etc. But there is a certain limit to quality that you can achieve with the normal constraints of a project (available time and budget, quality of technical resources, etc.) Your limit may be higher or lower than other projects, but it exists, and you cannot improve the level of quality by performing more quality activities because the law of diminishing returns kicks in.

Assuming that you are operating at your highest quality level, the quality of your product is proportional to the size of your product. The more features and code it has, the greater number of potential bugs, assuming that bug-to-feature ratio stays constant. That is why the suggestion by 37signals to build less seems very attractive. 37signals has a more general (and sometimes controversial) philosophy than just reducing bugs, but let us focus on bugs for now.

It does not seem practical at first glance to reduce product size. After all, customers demand features. More functionality sells more products. And there is nothing more capable than a rush of customers leaving you for other products to increase product scope dramatically. But if we cannot reduce product features, what can we do?

One answer is to tightly integrate features instead of distributing them throughout the application. For example, instead of building different screens for displaying records for data entry purposes and for reporting, merge the two screens. Provide more information on a single screen instead of breaking it up into multiple tabs. Avoid wizard screens and make all your screens easily learnable for the beginner user.

So reduce the project size to project feature ratio. This requires more work because you have to create a more visually compelling and intuitive user design. And your code will have to be modified to make it more streamlined and able to implement more complex needs. But in the end, having an overall smaller code base and project size earns its reward in higher quality, greater consumer confidence and better project planning.

Technorati tags: software development, bugs, project scope

Teams and Disagreements

2008-06-08T22:58:00.001-04:00

The common image that comes to mind when we talk about "teams" is a group of people that work jointly to achieve a particular objective. We think of charismatic leaders who take the team from vision to goal. Disagreements and arguments are often thought of in the context of dysfunctional teams, those that fail despite the talents of the individuals involved in the team.

But even the most successful teams are composed of individuals, often with widely varying backgrounds, ideas and opinions. Is the successful team therefore built on compromise? Do successful teams have no arguments within? Do team members relinquish their opinions and simply trust in the leader?

Let us try to classify teams on the basis of internal disagreements and the basis for the disagreements.

	Team members tend to agree	Team members tend to disagree
Team members driven by self-interest	A	B
Team members driven by team goal	C	D

In Group A, team members, driven by self-interest, never disagree. Why would someone agree publicly to something that they privately disagree with? This would only happen if they would encounter harm by voicing their disagreement. An example would be a dictatorial leader, who treats disagreement as lack of loyalty, respect or patriotism. Or a group-think situation that anyone who presents an opposing thought is viewed as foolish, naive or ignorant. The physical and emotional risks involved in making an unpopular stand may make it wiser for an individual to keep silent.

Being different does not mean being correct. The majority opinion or the leader's choice may be the right one. But no one is infallible. And so, in the cases where it is wrong, there is no alternative choice to fall back to. Too often, people do not even accept that failure has occurred and suppress those who report the bad news. Such a team structure is a disaster waiting to happen.

In Group B, there is much disagreement, but everyone is acting out of self-interest. This most commonly occurs in a divided legislative body (such as Congress) in the absence of strong and bipartisan leaders. Every politician is answerable to his or her constituency - they are sent to Congress or Parliament to argue for their voters. At the same time, they also have an obligation towards the nation. In the absence of a strong national consensus on a subject, elected politicians favor the position that would get them elected again, not one which benefits more people. We also see the same dynamic in bureaucracies where different groups argue for the position that would be most favorable to their department.

This situation does provide benefit to some people, and even people who do not benefit understand how the game is played and behave accordingly. In the end, almost everyone loses because no one failed to provide for the common benefit. Vast amounts of time and money would be spent before anyone recognizes the harm done.

In Group C, team members work towards a common goal and rarely voice any disagreement. Even though it is not harmful to them to voice their disagreement, they still agree with the leader and the group. The only possibility is that they believe that any contradicting thoughts they have are wrong or misguided. Instead they believe in the rightfulness of the leader or the group. For example, consider the CEO of a Fortune 500 company with a 30-year successful track record in a group with new recruits fresh out of college. Every word uttered by the executive would be taken as gospel by the group, even in areas that he or she may have little experience in or knowledge of.

When the group places too much belief in the leader, they can miss even obvious mistakes in decision making. Leaders have to actively step back and let subordinates take greater responsibility to avoid this trap. The problem with leading too much is that when the leader is gone or missing, the group ceases to function or make any decisions.

In Group D, the members of the group voice their disagreements openly, but they do not think of themselves. They want the group to succeed and they have the same goals. They disagree about strategies and tactics. So what happens? If they never reach agreement, they cannot function and hence may have to split into different groups, each using different methods to achieve the same goals. For example, in parliamentary systems, there will be different parties with similar stated objectives, but radically different economic policies to achieve them.

But a team comprising people with different opinions could also stay and work together. This situation could easily devolve into a Group B situation, where the reason for staying together is to win and share the spoils. But if that does not happen, how could a team survive and stay together even though there are internal disagreements?

One way for people to stay together is the knowledge that everyone is acting not selfishly, but for the common goal. That knowledge comes from common belief systems or from sacrifices made by the team members for one another or for the team. Teams bond when they go through emotional experiences together. However, the more diverse the members of group, the greater work that must be done by the leader to forge common bonds.

Secondly, having disagreements does not meet lack of decision making. Decisions should be made for pursuing a course of action (or inaction, as the case may be). But all decision-making should follow these important rules:

Everyone agrees that each person in the team owns the decision. Hence, there will be no "I told you so" if a decision fails. If this is not done, the dissenters will wait for failure while the supporters will hide or spin any mistakes. With this rule in place, everyone works to make the decision a success and step in when a fellow team member needs help.
Everyone agrees that the decision is the best that could be made in the present circumstances and considering all options. That means that future circumstances could possibly make the decision seems wrong with the benefit of hindsight. This rule helps avoid finger-pointing and wishful thinking when things don't go as expected.
Everyone agrees that the decision will be final, ending further discussions until new circumstances come about or new facts are uncovered. This avoids private discussions that may result in lower morale and possibly sabotage.

Decision making can be made in many different ways, but any process should not rely on a method that fails to bring all opinions to light. For example, using a simple majority to make a decision may be counter-productive even though everyone had a voice ("vote"), if the decision makers have not taken the time to understand the consequences of the decision. And decision-making does not necessarily mean a democratic process. It could be a manager who has extensive discussions with his team before accepting a minority opinion that has a greater resonance with facts.

People often confuse a successful team with a team that has achieved success. A successful team transcends the divisions and differences of its constituents. The results of its efforts are dependent on many factors, and so a successful team may not always meet its goals. But its ability to tolerate different views and adapt to changing circumstances provides it with a greater potential to achieve success in the long run.

Technorati tags: business management, teams

Vocabulary

2008-06-02T18:11:00.001-04:00

I was chatting with my friend the other day and we got talking about vocabulary. In his case, he was interested in some short-term solutions to the problem because of an approaching exam. I didn't have many ideas at that time, but later, I came up with some thoughts:

Read political writing in blogs and newspaper editorials. The writing is generally done by trained journalists who are very good writers. Politics also covers a wide variety of topics (economics, law, etc.) and you will be exposed to many different words in short time. Any of the major newspapers (liberal or conservative) or magazines would do the trick as long as you consistently read them. Blogs are even more convenient. Reading a few articles daily takes just a few minutes, but pays a high dividend.
An easy book to learn big words is Norman Lewis's "Word Power Made Easy". It contains several exercises and mnemonics. I suppose there are many similar books in the same category to improve vocabulary, but this is the only one I have read. My recommendation is to get at least one book in the category and work through it.

Short-term vocabulary improvement requires making a conscious, active effort at learning. This can mean writing down new words that you are unfamiliar with and looking them up in a dictionary. You should try to use these new words in your writing or speech until you become comfortable with them. Sometimes, a poor choice of words may result in embarrassment, but such problems come with the territory when you are in learning mode.

A long-term commitment to improving vocabulary can be passive. The easiest way is to read whenever you can and your subconscious mind will automatically learn new words. Fictional works will introduce you to generic, but obscure words, while non-fiction will give you jargon, terminology specific to the area you are reading. The trick is repetition. The more often you see a word, the more your brain understands the context and is able to notice it then and recall it at a later time.

Writing is a good way to strengthen your knowledge of words. You don't have to write articles or blogs to do this. It could be as simple as trying to write better emails to people, or writing full sentences when you exchange instant messages with someone. You could use the opportunities when you are asked to prepare any written material (say technical documentation) to use the words that you come across.

Listening to famous speeches and podcasts is another way to improve recognition of words, the only problem being that it is sometimes inconvenient to interrupt your listening and record the new words that you are hearing. Joining a Toastmasters Club or a local debating association will also help you improve vocabulary skills (and of course, your speech-making capability). Public speaking forces you to be structured and accurate with your words. In addition, you also get to hear talented speakers.

Technorati tags: improvement, vocabulary

To Learn C or Not

2008-06-02T01:25:00.001-04:00

The past few weeks, I have been listening to the podcasts of Joel Spolsky and Jeff Atwood at stackoverflow.com. The discussions are perhaps not as informative as a Hanselminutes podcast, but they are definitely entertaining and cover many topics related to software development. Atwood has posted some of the discussed topics on Coding Horror. One of the subjects that caught my attention (and others as well) was the fact that Jeff did not know the C language and didn't feel that it was necessary, while Joel holds the opposite view.

This debate is different from most language fights. Most of them are about which programming language you must use. Here, no one is suggesting that you use C to replace your current programming language. The C advocates recommend that you learn C to gain a more fundamental idea of the low-level issues of programming, something that current languages isolate developers from. Since my first programming language was C, my first instinct was to agree with Joel, and then I realized several problems in my reasoning.

The first mistake was to forget the important place that C had in my learning curve. When I moved to C++, I was only learning the object-oriented features provided on top of C. The basic language structure (except for the OO constructs) remained the same. Moving to Java from C++ once again required only learning a few additional features and unlearning some of the C++ features. Thus, with every other language (C#, VB, Python, etc.), the learning process was always about trying to relate my existing knowledge to the feature set in the new language.

For a person who started with C, it is difficult to imagine how someone else could have learnt anything without the initial C knowledge. But if that person had started with Visual Basic, they would have learnt many fundamental aspects of programming (such as logical structure of programs, debugging, etc.) through those languages. And that person, when moving to other languages, would use their VB knowledge to understand and learn them.

The difference here is like mother tongues. For example, one person is a native English speaker and another is a French or German citizen who learnt English as a second language. But regardless, both can understand and speak English fluently, despite the fact that one of them "thinks" in another language.

But what about the advanced stuff? What about pointers and dynamic memory allocation? I think a fallacy here is to compare an advanced C programmer and a naive VB or Java programmer. If we look at the skills of an advanced programmer in any language, they would have the same level of understanding complex concepts, algorithms and data structures. The point being, you have to look at more than the programming language knowledge of a developer to understand his or her true worth.

I think it is instructive to look at the reasons why C was displaced in the first place by other languages. C has many peculiarities that get in the way of writing business logic. For example, different sizes of data types on different operating systems, null-terminated strings, etc. While knowing these intricacies gives you a better idea of what goes under the hood, it does not help you solve your business problems any faster. Secondly, they can even hinder learning. For example, a language that has automatic garbage collection may make it easier to learn data structures or algorithms without the C-specific pointer and memory handling.

A C programmer may have to unlearn some lessons when they move on to higher-level languages. The advanced C programmer has a tendency to write tight, clever code, sometimes at the cost of making it incomprehensible for anyone else. The lesser C programmers ignore concepts of data encapsulation and tend to create classes that are simply a bunch of related functions that keep shuffling data around.

It is also a mistake to assume that just because a programming student has learnt C, that they have somehow achieved a state of greater understanding. It is possible to write non-trivial large programs in C while staying away from complex constructs (in fact, it may make for less debugging even if it introduces inefficiency). A bad programmer can also make bad mistakes with pointers and memory allocation, and have a program that runs correctly for many different test cases and for long periods, just because it didn't hit the error conditions.

The final fallacy is a generational problem. The older generation always feels that the younger generation have had it easy so far, and because of their inexperience with failure, they are on the verge of making some colossal errors. The idea goes like this, "We suffered. We learnt the hard way. And that is why we are successful today." Hence, there must be something wrong with the success of the new generation. Maybe they are just lucky. This argument, of course, is not unique to programming.

But perhaps, it is possible that maybe you don't have to fail before you succeed. Maybe you don't need to go through all the hardships and sacrifices suffered by the people before you. The new generation can start programming in their simplistic programming language and still create works of wonder without ever knowing one hardware term. Maybe the rules have changed.

At some level, I think people understand this. But there is a real sense of nostalgia that believes that the new generation will never get to experience what they had. The feelings of achievement on solving a complex problem. The respect and love for the programming profession. The constant quest for learning. The acquisition of minor trivia. The knowledge that makes inside jokes funny. But this sense of loss ignores the fact that different people can reach the same goals by different journeys.

A real programmer is always on the lookout for improvement. Some of them, who started with a different language, may choose a path where they go back and learn C, maybe even contribute to projects that require C knowledge. Others may choose a different path where they learn about new languages or techniques. In the end, I think what matters is not what a programmer knows, but what and how quickly he or she can learn, and how well he or she can contribute to solving real problems.

Technorati tags: software development, C language

Google App Engine

2008-05-25T00:45:00.001-04:00

A few days back, I received an invitation to create an application on Google App Engine (GAE). I was impressed with the ease with which I was able to create a quick CRUD application. Even though I am not very knowledgeable in Python, it took only a few hours from downloading the framework to creating a usable application (different from the example app), and that time would have been shorter, if it hadn't been for some minor troubleshooting with configuration issues.

Google markets GAE as providing you with the ability to "build web applications on the same scalable systems that power Google applications." The High Scalability site has some good advice on how to leverage the framework to build a scalable solution. However, I think GAE may be more attractive to those building small-scale web sites that do not need a whole lot of programming.

Consider the web sites of typical small businesses. Many of them have a few pages describing the company and their products with a few email forms for sales or support. GAE can be used to create and host such web sites. Those sites have been pre-dominantly built with plain HTML with PHP or Perl for the web forms. Now, they could be created on or moved to GAE which has free hosting and an arguably better programming infrastructure.

Personal web sites hosted on web sites like Geocities can also be moved to GAE. While Geocities charges for programming in PHP and mySQL, GAE provides a free option to program with Python and the GAE Datastore. Most of these web sites (business or personal) will never come close to consuming the 500 MB and 5 million page views that would require additional cost. And so, the value proposition of GAE is very high.

For large-scale web applications, I feel that GAE may serve more as an incubator rather than a long-term hosting solution. During the initial stages of building an application, GAE provides a convenient programming environment at zero or low cost. However if the application becomes popular, the developers require greater control over the programming environment (hardware and software). Presently, GAE does not provide scheduled processes or database export, two features that would be essential for a large consumer application.

The most important barrier, though, is the lock-in to the Google infrastructure. Being tied to GAE will keep you hostage to Google's pricing, infrastructure and service. Porting to a different infrastructure might require time-consuming changes to your application. The longer you wait, the larger your risks. So, using GAE for creating an initial version of your application may make sense from a cost and prototyping-ease perspective, but if you have a much larger vision for your application, you may want to examine other platforms too.

Google now has a few services that are separate, but would seem to belong together: Blogger, Google Pages, Google Sites and App Engine. Let us call the amalgamation of these services as, say, Google SiteBuilder. It would provide the ability to create dynamic pages in Python (and other languages). You could create static pages and edit them visually. You could perhaps edit the dynamic pages along with the static ones in an administrative interface. You could change the site layout through pre-built or custom templates.

Google SiteBuilder could allow you to add different blogs and feeds to your website. You can also create a wiki or more for different people to collaborate. This last feature is an extension of the function of editing static pages: You are allowing other people to edit the static pages and upload documents, while maintaining the history. With all these features, Google SiteBuilder perhaps becomes more like an online Visual Studio for web applications.

I suspect that we will not see such a consolidated product from Google soon because of the possible administrative complexity for end users, many of whom are not programmers. For example, a user of Blogger simply wants a good-looking layout and the ability to add and edit posts, and may dislike seeing an interface showing the various files for the application. What may happen is these applications will start converging towards each other and co-opt each other's features.

Technorati tags: google app engine, scalability

Outbursts of Creativity

2008-05-05T19:25:00.001-04:00

Cornelius's post on his recent low frequency of blog posts was very interesting. Since my blogging frequency has also gone down, I look back at 2007 and wonder the same thing: What helped me blog so much then? To some extent, Cornelius is right in saying that the less structured one is, the more output one can produce. But that explanation does not really solve the problem, because the trick is: How do you produce quality in greater quantity, at least in accordance with one's own definition of quality?

I feel that the biggest requirement of any creative work is the availability of time, or more accurately, the assumption of uninterrupted time. Creativity, by definition, means doing something that has never been done before or never been done quite the same way before. Because of its uncertain nature, it is difficult to estimate how much time it would take to complete a creative endeavor. To start a creative task, a person must have some confidence that he or she would be able to complete it, and what they need most, apart from tools, is the feeling that they will have sufficient time to complete that task.

Now strictly speaking, time is always available. It is possible to find gaps of unallocated time in the midst of other tasks that one is doing, but such time segments are useless for creative work. Creative work requires a significant focus of the mind to achieve a state called "flow". Flow is achieved when the mind is fully knowledgeable about the critical pieces of the creative work and at the same time, heavily processing that information to make new decisions. Until the first stage (knowledge-acquisition) is achieved, the second stage (decision-making) is very inefficient. The first stage always requires some time, and the more complex the creative work, the more time it consumes.

When you have a short time segment, you don't have enough time to achieve the first stage, even though the actual work accomplished in the second stage could have been completed in that time. When you are interrupted in your creative work, you have to start all over from the beginning. When you feel that you are likely to be interrupted, you decide not to start something because of the same reason.

There is sometimes a "zeroeth" stage (if I may use the term) of "desk-clearing". Sometimes, a person will go out of his or her way to dispose of other totally minor tasks like replying to emails or taking out the garbage, even though the more urgent work is pending. To an outside observer, this behavior can be ridiculous and frustrating. But what the person is doing is to remove all possible distractions and create a solid chunk of time that can be spent on creative work.

High performance in creativity comes when the person has achieved flow and can count on not being interrupted. This usually means very early hours or very late hours when the chances of being interrupted are very low. Another option is, of course, a physical location where one can work in peace for long periods of time.

I don't want to confuse this with workaholism, which is about spending more hours per day. A more creative person may or may not spend less hours than a hard-working person, but they spend those hours with more focus. Creative passion can lead to voluntary workaholism (at work or as a hobby), but that is a different topic, some aspects of which I have discussed previously.

One technique around the constraints of uninterrupted time is to convert creative work into mechanical work. For example, one could design a mechanical way of writing blog entries, such as post the most interesting link you read all day and write a couple of paragraphs outlining your views. Sticking to a well-defined structure can reduce the need for greater analysis and ramp-up time. However, the quality is the production-line type of quality with less deviation from the norm. So even though you are unlikely to produce total failures, you are also less likely to produce hits.

The other technique is to maximize the use any sufficiently long time period at the risk of being less productive. This article on sleep deprivation by 37 signals is pretty accurate, but it misses the point that when it comes to creativity, you are usually operating (without sleep deprivation) nowhere close to 100% unless you are well isolated from interruptions. If you are doing mechanical work, it does not make any sense to stay late hours, but if you are doing something creative, it may pay off to continue to produce until your brain drops off the flow state.

Technorati tags: creativity

The Wrong Lessons from Mistakes

2008-04-28T23:22:00.001-04:00

Whether we like it or not, we all make mistakes. Failures, big and small, are a part of our life. Although we don't welcome them and although some failures can be harsh, they can be very educational. Learning from mistakes is part of building experience and knowing what works and what doesn't. There is a saying, "Fail early". If you make mistakes when they are less critical, you can avoid making them later on when it would be more expensive to clean up.

But for all that, sometimes we learn the wrong lessons from mistakes. The first problem with mistakes is that in many cases, it is not easy to pinpoint the exact cause of the failure? Was it a wrong idea? Or was it a good idea wrongly executed? Did the failures lie in the process used? Were some of the people involved wrong for the job? In many cases, answers are hard to come by. Most people fall back on the simplest or most non-controversial reason, hiding the true nature of the failure.

For example, a project failure may be blamed on a technical challenge that was difficult to solve, but the real reasons may have been elsewhere: misunderstood requirements, wrong architecture or design, insufficient exploration of alternatives, unskilled personnel and so on. Not understanding and fixing the root causes keeps them alive to disrupt future endeavors.

Another mistake is to assume that the conditions under which the failure happened to be constant and never-changing. Many failures occur because of wrong timing. For example, a product may be unsuccessful because its demands on infrastructure (hardware or software) may mean that it is too slow or too expensive. But in time, as technology becomes faster and cheaper, the same unsuccessful technology could become a bestseller. Consider the timing of YouTube. A few years earlier, it would probably have gone nowhere.

It is not just technology, either. People (users and other decision makers) change too. People who previously exhibited skepticism about something (and caused its downfall) may be more amenable to it today. Even people who were adamantly opposed sometimes change their views because they have learnt something new or positive about it in the meantime. The other possibility is that the most vocal opposition has left the decision-making table for other ventures. In any case, people or technology, what this means is that a mistake yesterday may not be a mistake today, even if you do the exact same thing.

The third and most important mistake is to lose heart and become disillusioned because your efforts are not paying off. Most people have great ideas. But great ideas need the right environment and care to flourish and succeed. So when those ideas fail to prosper, those people sometimes stop dreaming and having new ideas.

The key to overcoming such disappointment is to understand the greater goal behind those ideas and become less attached to the ideas themselves. If one path to the vision is blocked, you have to find a detour. This could provide the inspiration for new ideas as well as maintaining your enthusiasm. Never let mistakes destroy your spirit.

Technorati tags: mistakes, lessons, unlearning

Change and Emotion

2008-04-09T18:21:00.001-04:00

At the risk of stating the obvious, every change needs a status quo, because there is no change if there is nothing to change. And every status quo has supporters, without which it would not exist. Supporters may favor the status quo because they benefit from it, or they may approve of it because other options seem risky or costly. Faced with a proposed change, these supporters worry about their existing benefits, their new risks, their potential loss from the change and their status in the new order created by the change.

Even though such concerns are based on self-interest, they are legitimate. Ultimately, change is about the people it affects, positively or negatively. If more stakeholders are adversely affected by the change, then perhaps the proposed change is not an improvement and must be dropped. But assuming that you are honest about your facts and you sincerely believe that the proposed change is beneficial to the community or organization, your challenge is to convince the status quo supporters.

When you propose a change, you are essentially creating a conflict with the supporters and beneficiaries of the status quo. In a purely intellectual debate based on facts and reasons, you could win (at least theoretically) every argument by presenting the facts. But in real life, people seldom evaluate costs and benefits as if the situation were a simple math problem. You must consider the emotional attachments and grievances of the evaluators. So, if you want to convince people of the change, you have to take emotion out of the equation and get people to focus on facts. Here are some ways to accomplish that:

Look forward, not behind: Put forth your change as a better approach for the future, instead of criticizing the status quo. Post-mortems only makes people defensive. Many change leaders mistakenly assume that everyone would oppose a policy when its flaws are pointed out. However, criticism can make many practitioners dig their heels in harder, because change would point out to the rest of the world that their initial judgment was wrong and that they were ignorant of the flaws.

It takes courage and humility for people to willingly admit that they were wrong. Forcing them to accept their mistakes is humiliating. So why put them in a difficult spot in the first place? Instead, suggest that the older policy may have made sense in the past, but changing circumstances requires a new approach. This tactic offers people a dignified way to support the new policy while silently erasing past mistakes.
Make people feel important: Change often results in real or perceived loss of power and control. People don't know what their role in the changed environment will be. To avoid this feeling of helplessness, give due importance to all stakeholders. Ask them for feedback. Involve them in the key meetings. Communicate often and regularly. You may not be able to accept everyone's feedback, but they should feel that you had considered them in your decision making.

At the same time, de-emphasize yourself, so that the change you advocate does not come off as a power grab. This is not just important for convincing your opponents, but also to gain the trust of your allies. Give opportunities to both your supporters and detractors to participate in and contribute to the change process. Lead, but also delegate. Try to ensure a fair distribution of the benefits accruing from the change.
Listen and answer criticism: People will put forward different arguments to counter your assertions. Some of these may seem silly or irrelevant to you, but there are important to those people. Listen to their reasons, and understand why they are important to those people. Provide a fact-by-fact counter-argument to those arguments, but take care not to dismiss something high-handedly or insensitively. Sometimes, a criticism is valid and must be acknowledged.

For example, suppose you want to move a desktop application to the web. A valid criticism would be that the desktop application is a much richer client and hence more user-friendly. This argument cannot be countered by putting forth a false argument that the web application can provide the same user experience. But it can be countered by pointing out the advantages of the web application that outweighs this particular disadvantage. Acknowledge the costs of the change and your argument will be more honest.
Make it easy, but not simplistic: People are overwhelmed by complexity. So you have to present your change proposal in a way that is easy for people to understand. But people are also afraid of making a mistake. So if they think you are simplifying the question and not paying attention to details, they will think you are hiding something or don't have a clue. So, you have to balance presentation and content.

One commonly used technique is to provide executive or visual summaries of your proposal, with additional (voluminous) research or data (by you and others) made available online. You could have some short meetings that provide high-level information and other longer voluntary meetings for providing additional information with Q&A sessions for those interested in learning more. Use various communication channels (email, blog, memos, etc.) appropriately to cater to information demands from different types of stakeholders.
Get rolling: The larger the change, the more resistance you will encounter. So, sometimes it is better to start implementing a smaller part of the change, than waiting for approval for the whole package. Usually every change will have some incremental change that is non-controversial and perhaps even offers immediate benefits. Start there, show progress and obtain credibility for greater changes.

Incremental change can sometimes drive away more passionate supporters who are tired of waiting. Nevertheless, it does serve to calm down people's fears of failure. It also provides minimal disruption, a key factor for buying the support of people (like middle managers) who are responsible for positive short-term results in their department. Incentives (financial or otherwise) are more powerful in incremental change.

All these steps take negative emotions out of play and introduce positive feelings of respect, importance, confidence, belonging and success, taking you a long way towards acceptance.

Technorati tags: change management, stakeholders, involvement

Strengths vs. Weaknesses

2008-03-27T18:22:00.001-04:00

When it comes to managing one's strengths and weaknesses, there are different schools of thought. Some people are of the opinion that weaknesses are areas of improvement and it pays to work on them. The contrary point of view is that we should focus on improving and taking advantage of strengths rather than trying to reduce weaknesses.

Focusing on strengths and working at a job where you can utilize your talents and skills makes sense on different levels. You can be much more productive and have a greater chance of obtaining successful results. Success at your job can provide greater satisfaction in both tangible and intangible ways. Strengths usually have a snowball effect, i.e., the better you are at something, the more you are likely to learn and improve upon them.

Of course, you don't have to be dependent on your job to receive satisfaction. Many skills can be used at hobbies, which provide an outlet for greater creativity and fun. Many personal qualities can be channeled into productive activities within your community, helping people in the best way you know.

But let us look at the limitations with only focusing on improving strengths:

The snowball effect does not continue forever. At some point, you hit a point of diminishing returns from improving your strengths. This is usually a function of external circumstances. For example, while the best programmer may be 10 times more productive than the worst programmers, they never get paid at the same ratio. High rates of improvement may not be possible because of stagnation or lack of innovation in your industry. This is not true of the technology industry, but many other sectors are conservative and not receptive to or do not generate new ideas.
People often confuse managing their strengths and weaknesses with managing other people's strengths and weaknesses. As a manager, it is advantageous to place people in situations which make maximum use of their strengths and reduce any risks caused by their weaknesses. All things considered, you cannot force people to change their personality and hence this is your best option. But when it comes to you, you do have a choice to do something about your weaknesses, such as creating a process around you to prevent problems.
You cannot expect other people to accept your weaknesses and put you in a situation where only your strengths matter. That may be the wise thing for those people to do, but often, they don't do it and you don't have a choice. Nobody loves you for what you are. They always love you for what you will become (or what they imagine you to be). And that means change. There will be many aspects of your job that will require you to overcome certain weaknesses. A new opportunity that closely matches your strengths may also mean managing some of your failings. You cannot be perfect, nor can you improve upon everything, but you may have to work hard on some aspects of your personality.
Many people also tend to confuse strengths and weaknesses with likes and dislikes, leading to premature dismissal of anything distasteful. Some jobs or tasks may take great advantage of the person's strengths, but the person takes time to realize this. Often, the cause is bad training or a bad trainer. You can see this in the school system where some students fail at everything, even though it is conceivable that they may succeed in jobs requiring one or more of those subjects.
Knowing one's strengths and weaknesses is an imprecise science. For example, consider the Myers-Briggs Type Indicator and its different personality types. Even setting aside concerns about reliability and accuracy, people may end up making mistakes in answering an MBTI questionnaire, and think that they have strengths and weaknesses that they do not possess. This may drive them to make incorrect choices about their career and what they do at their jobs.

Nothing is ever static. As industries evolve and the nature of jobs change, strengths that may have worked for you in the past are no longer as helpful. Long-term neglect of weaknesses may create a crisis situation. To avoid that, pay some attention to your weak spots regularly. Constantly evaluate your strengths and weaknesses with respect to your present career path and make necessary adjustments to avoid big corrections in the future.

Technorati tags: personal learning, strengths, weaknesses

The Distinct Types of Workaholics

2008-03-16T01:07:00.001-04:00

Jason Calacanis, CEO of mahalo.com, recently generated some heated controversy over his statement “Fire people who are not workaholics” as part of a longer post about how to save money running a startup. While many people criticized him for not understanding what work-life balance means, a few others supported him for suggesting what startups require to succeed. Calacanis later changed his statement to “Fire people who don’t love their work” and wrote another post attempting to answer the question of whether one can have a life and work at a startup company.

I felt that neither his posts nor the various reactions (positive and negative) carefully considered the different types of workaholics and the circumstances and motivations under which a workaholic operates. In this essay, I would like to explore the difference between voluntary and involuntary workaholics and also the relationship between being a workaholic and liking one's job. Let us also take a look at the benefits vs. costs of such behavior.

A workaholic can be defined as someone who spends extraordinary time or effort at his or her work. The similarity with the word "alcoholic" provides a negative tone, meaning that the person is "addicted" to his or her work and would rather spend time at work rather than activities that most people find enjoyable. However, in some work environments, being called a "workaholic" can be positive because it means someone who is dedicated to and loves their work beyond everything else. Such a person is committed to the goals of the organization, and hence is a team player who can be relied upon.

In this context, the term "involuntary workaholic" can seem puzzling because it conflicts with the general belief that workaholics derive pleasure from what they are doing. This confusion arises from the problem that we associate the behavior of working longer with the intention of working longer. We think that just because someone works longer, they want to work longer and hence they must be workaholics. Unfortunately, this is not the case.

Involuntary workaholics are those people who are driven by external forces to work longer, even though they would rather be doing something else. Insufficient staffing, inflexible deadlines, lack of planning, improper prioritization, bad estimates, poor quality and unforeseen risks can create circumstances where employees and managers have to work harder and longer. Many workaholics are actually victims of situations created by themselves or other people or processes in their organization. They are working harder because they have no other choice.

A second type of involuntary workaholic is created by managers who wrongly associate more effort with more output, and reward or encourage workaholic behavior. Such managers are themselves busy all the time and they want to see everyone put in as much effort as they do. Such a direction puts pressure on everyone to demonstrate their "dedication". However the proxy for more effort is simply “more time spent in the office” or “more face time with the manager”, not necessarily actual work.

Quality is the first casualty in a workaholic environment as people hit biological limits on their body and brains and start making elementary mistakes. Then, the rate of work getting done starts decreasing, because people get too tired to contribute as effectively, and also need time to fix the mistakes that they made. In the end, there is only a very short-term improvement in productivity coupled with major quality problems and a long-term decline in productivity and increase in attrition due to employee resentment.

Another problem often ignored in this situation is that only some employees are better placed to be involuntary workaholics and can produce more if they work more. For example, unmarried young employees have generally fewer responsibilities than married employees or employees with children. When everyone works longer, some of them may contribute more while others may resent the situation and contribute less. So overall, there is no gain, even temporarily.

Now, let us look at voluntary workaholism. Some people object to this term because they cannot imagine someone being addicted to their work. But like any passion or mania, it is difficult for people who don't have the same feelings to understand those who have it. Voluntary workaholics spend incredible amounts of time and effort on their profession. Their interest does not seem to decline once they are outside the office. If you ask them, they love their work and enjoy the time spent at doing it.

From an organization's standpoint, there are significant advantages to having voluntary workaholics over involuntary ones. Voluntary workaholics are more knowledgeable and produce high quality of work consistently. They tend to be more flexible with changing needs because they have more time at their disposal. They are willing to take on more responsibilities, even if they sometimes overestimate their capabilities.

Many organizations seek out such people and try to reward such behavior. As mentioned previously, that carries the risk of increased involuntary workaholism by other individuals, so a little care is necessary. The first thing to understand is that there is no substitute for proper estimation and planning. That creates your baseline for measuring individual productivity as well as setting standards for quality. When you do this, you can measure the extra effort by the individual in meeting targets in schedule and quality. That may be the basis for a reward system.

It is also essential to understand how your organization motivates the voluntary workaholic. Remember that one's love for the profession and one's love for the tasks done in the profession may not have a linear correlation. For example, a programmer may be excited and animated when talking about their work in general, but they may be periods of time when they have to work on tedious, boring and repetitive tasks. Sometimes a workaholic may be working late just because that is the only uninterrupted time for the tasks they enjoy doing.

Another problem is the decision making on the project. A voluntary workaholic likes the creative aspect of work. So when their work environment is dominated by a few senior people who evaluate options and make all the decisions, they may decide to spend greater effort on some personal project (related to their profession) where they get to play the boss. So it is important for managers to understand how to channel the workaholic's enthusiasm towards the work at hand.

A twist on this entire situation is that workaholics can turn into involuntary workaholics. During uncertain economic times, the workaholic may decide to spend more effort than usual to preserve their job. Alternatively, a new situation in the workaholic's life, like a marriage or a new child, can reduce the effort they can spend. This happens more frequently than managers realize. The issue here is that workaholics fear that reducing their effort would be viewed negatively and thus they have no exit strategy.

So far, we have been talking about workaholic employees. But there are also workaholic employers. The motivations which drive them are very different from the workaholic employees. They have a direct financial incentive towards working longer hours, because usually additional effort from them results in more positive results for the organization such as increased revenue or better products. So there is a certain level of involuntary behavior here, because business reality demands them to spend more hours until they find good people to delegate to.

Some (though not all) business owners have already achieved financial security and consider their business an additional investment in something they enjoy doing. This may be contrary to their employees who need the job to survive and pay their bills, even if they love the job. The employer would be mistaken in his or her assumption that employees share the exact same feelings about the job situation. The ongoing success of the business concern can play a huge part in the motivation of employees.

A final word: Workaholics are seldom understood by other people, who always tend to project their feelings on them. Some people admire them and call them passionate, dedicated and hard-working. Others mock them for not worrying about their health or personal relationships, as well as missing out on other things in life. Very few truly try to comprehend their internal motivations and their circumstances. I hope this article changes that attitude to some extent, at least.

Technorati tags: business management, workaholism, hard work

The Meaning of No Time

2008-03-02T02:06:00.001-05:00

In both business and private life, you often hear people saying that they had "no time" to do something. In many situations, the amount of time required for the task is something that you would expect the person to have, so what do they mean when they say they had no time? It is important to get to the root of the problem because usually the something that they didn't do is something you care about. Pointing out the obvious ("you had a lot of time") does not help you. So what is going on?

Here are some reasons:

They were mentally pre-occupied with something else. Maybe a deadline at work. Maybe a family issue. Unless they get moral support and mental relief from that, they will not be able to work on your task. What can you do? Ask them what is going on and try to help if you can. Otherwise, move the task to some other person or to a future date.
They are waiting for some time to dedicate to the task. For example, if they know that a task takes 4 hours, they will not start on the task until they know that they have 4 hours to dedicate to that task. The problem is that tasks keep coming and they can never allocate a continuous stretch of time. What can you do? Break down the task into smaller pieces that must be submitted separately. Also, if you have the authority, you can create the conditions where the person will be uninterrupted for that time.
They don't like the task or they have lost interest. Chores and repetitive tasks fall into this category. One indication of this problem is that the person gets irritated (instead of being worried) when you remind him/her about the task. What can you do? Partner the person with someone else so that the task seems less tedious and boring. Also, examine the task to see if it is really that important and, if not, cancel or transfer it.
They never knew about the task or forgot about the deadline. I am serious - this happens! The indication of this problem is that the person shows signs of alarm and panic when reminded of the task. All you have to do is ask when it will be complete, and usually it will be ready by then.
They don't know how to do or complete the task. They may have accepted the task without understanding its nature or complexity. They may retain some confidence that they can pull through, so they are not yet willing to throw in the towel. You can understand this problem by asking to see the work in progress and seeing the extent and quality of work done. The next step may be to provide additional training or guidance, or transfer the work to someone else.
They have over-estimated the scope of the task. Usually employees just past the beginner stage over-analyze tasks, reading more in them than what is needed to get the job done. Both beginners and experts simplify - the former due to lack of knowledge and the latter out of experience. Try to understand the details of what the person is doing, and then simplify it for them.
They are having starting trouble. Sometimes a task overwhelms a person that they find it mentally difficult to tackle it, even though they are capable of doing it. To handle this, start the task together with them and establish yourself as a go-to person if they have any problems. This will give them additional confidence to continue with the work.
They are not receiving support from other team members. When a person works on a task, but does not see other people working as hard, they start losing interest in the work. For example, people are more likely to go to the gym if they have a partner who is also motivated to become healthy. It is never about the 30 or 60 minutes they need to spare. Look for this team dynamic and manage the resources accordingly.
The outcome of the task (such as a report) is bad news. That is one reason why audits are done by people who have no stake in the project or operations. If the information provided as the result of a task could reflect badly on a person, do not assign that task to the person. But if you must have that person, make it clear that the information will not be used against him/her. Otherwise you will be waiting for a long time.

Technorati tags: business management, time management

The Different Aspects of Intelligence

2008-02-12T18:44:00.001-05:00

When companies look to hire people, they always want to hire the most intelligent people they can find or afford. Many companies try to recruit from the top universities and colleges. Others snatch away the top performers in other companies. But what exactly do we mean by intelligence? And how can you leverage intelligent people for business success?

Intelligence is frequently stereotyped in caricatures such as the absent-minded professor, the mad scientist, the black hat hacker, and so forth. Such exaggerated images fail to convey how intelligence is a combination of many different aspects. Here are some characteristics I can think of:

Ability to grasp information from data: Two people may receive the same information, but one of them is able to comprehend it better and derive meaning from it. This is not necessarily a function of past knowledge, but an ability to recognize patterns in the data and derive conclusions. A person with this ability is best suited to work in analytical situations, being able to process huge amounts of information and make sense from them.
Ability to remember information: This is perhaps a misunderstood aspect of intelligence, and usually negatively associated with exam cramming. However, you can notice differences there too. Some people are able to cram more information than others. Some are able to remember relevant information from long ago. Memory is an essential part of the brain function. A person who is able to operate with large volumes of relevant information easily accessible while working can be highly efficient. Such a person is well suited for technical work. For example, a software developer who is very familiar with the language API's.
Ability to juggle multiple things: A good soccer player can run down the field with the ball, and also simultaneously remember exactly when and where to pass the ball, because while running, he can visualize where the other players are. Or think of how an aircraft controller works. Many people break down when confronted with multiple things at the same time. The person with the ability to multi-task revels in such situations.
Ability to concentrate on one thing: This seems the opposite of the previous point. But in some cases, the ability to juggle also requires the ability to tune out certain things. The soccer player in the previous example tunes out the thousands of cheering fans, his personal life and whatever happened 5 minutes ago as he runs. The aircraft controller shuts out all the other distractions in the room. By only focusing on the essential, the entire brainpower is devoted to the main task at hand.
Ability to apply solutions to problems: Most people associate intelligence with problem-solving, but it is not the solution per-se that displays intelligence, but it is the process. Intelligence is the ability to match and apply strategies to solving problems. All strategies have to be learnt, but some people do better than others at understanding when to use them. For example, most accountants are familiar with the various strategies to minimize taxes, but some are just better at actually doing it.
Ability to devise new solutions: When faced with a unique problem, a person with this ability can come up with new ways of solving problems. For example, Leibniz and Newton (independently) invented calculus to solve their mathematical (and physics) challenges. The key difference with the previous point is that a person without this skill will get stuck when faced with new challenges, even though they can use the strategies they know to devise a new solution.
Ability to imagine: This goes beyond logical ability to devise solutions. People with this skill think unconventionally. Their ideas do not come out of some combination of putting existing ideas together or improving them. People working in creative fields are good examples of this. Another example is the discovery of the ring structure of benzene. Without such people, innovation would always be incremental and human progress would not be where it is.

In many cases, companies measure only a few of these aspects. Some of these are difficult to measure in a typical interview. For example, asking people to solve puzzles in an interview may only be measuring their ability to remember information, if they already know the answer. But I still think it is worthwhile to think about ways to understand where a person stands with regard to these traits.

For example, you are hiring a developer. If you look at the previous abilities, here is what they mean for that role:

Ability to grasp information from data: Understand specifications and other written documents.
Ability to remember information: Remember programming standards and libraries, and also important information conveyed through conversations.
Ability to juggle multiple things: Work in multiple modules at the same time.
Ability to concentrate on one thing: Spend vast amounts of uninterrupted time building programs, thus increasing quality.
Ability to apply solutions to problems: Know when to use which best practices and design patterns.
Ability to devise new solutions: Create new programming modules that solve common problems faced by other developers.
Ability to imagine: Design better. Debug better.

And this goes for other roles in the company.

Technorati tags: software development, intelligence