Super-Productivity

Posted on November 1, 2011 by Hayim Makabee

In a previous post I discussed the reasons some programmers are much more productive than others. But the fact is that every programmer experiences periods of time when he is much more productive than average, and I think there are several reasons for that.

Focus

It is clear that to be productive you must be focused. This means that, even if you have several things to do, and even if all of them appear to be important, you must be able to concentrate on a single task. This requires the ability to define your priorities and your posteriorities. Better yet, decide that there are things you do not really need to do.

Peter Drucker dedicates an entire chapter of his classical book, “The Effective Executive”, to this issue. In the chapter entitled “First Things First”, he says: “Most of us find it hard enough to do well even one thing at a time, let alone two”.  Thus, multi-tasking is something that should clearly be avoided.  

I believe that Agile Software Development improves focus because it reduces the granularity of programming tasks. Developers participating in a Scrum project normally have relatively small features to implement at each Sprint, and extensions are done iteratively. Agile methods also help the team to prioritize the tasks and focus first on the most important features, using artifacts such as backlogs.  

Problem Solving Mindset

Programming is an exercise in Problem Solving and as such it is natural that programmers dedicate a considerable amount of time to think about the problem, analyzing its several aspects. In general a problem will have diverse possible solutions, and in this case the programmer needs to compare these solutions and understand their advantages and disadvantages.

During this time spent thinking the programmer will not write any line of code, so it may appear he is not producing anything. But when he has completed his analysis and found a good solution, he can suddenly implement all the functionality very fast and with few errors, becoming Super-Productive. I believe that this ability to dedicate enough time to analysis before jumping to a solution is a key for real productivity, but unfortunately it seems that not all programmers have this habit.

This is similar to a chess game. Watching a chess game may be very boring, because most of the time nothing is happening on the board: The players are thinking. But after they have decided what to do and chosen a strategy, they can move very fast. Good chess players can plan many steps in advance, and thus avoid making mistakes.

Inspiration

Many programmers claim that software development is a form of art. I believe that this is partially true, because, like painters or musicians, programmers need inspiration to produce really great software.

Everyone has at least once faced a problem that at first appeared impossible to be solved. No matter how hard you examined it, you could not imagine a way to overcome its difficulties. And then, suddenly, you saw the solution. You were inspired by something or someone that allowed your brain to follow a different reasoning path.

There are also these days when you just wake up inspired. Everything will appear easier, you will just sit in front of the keyboard and let the code flow directly from your brain to your fingertips, typing new instructions as fast as possible. In these days you are Super-Productive, even if you will never be able to explain why. Unfortunately, there is no general recipe of how to become inspired.

Pressure

It is not easy to admit it, but the truth is that most people work better under pressure. It is very easy to postpone some action or decision if you know that you still have lots of time to implement it. Most programmers work much harder when they get closer to the deadline. They often regret being complacent in the beginning of the project, when it appeared to them that the allocated time was more than sufficient. But it rarely is.

I believe that Agile methods improve this situation by defining short development cycles. For a team working with Scrum, each Sprint has a well-defined set of tasks that must be completed in a few weeks. The end of each Sprint is a deadline, and it is always close enough to make the developers feel they need to work intensively, since the beginning. They programmers in a Scrum team cannot postpone their work, because their progress is being measured on a daily basis and exhibited clearly in a burn down chart.

In Summary

There are several factors that may help you become Super-Productive:

  • Focus: Defining your priorities and concentrating on a single task.
  • Problem Solving Mindset: Thoroughly analyzing the problem and comparing possible solutions before implementing.
  • Inspiration: That state of mind in which all your thoughts flow with amazing clarity.
  • Pressure: Having a well-defined deadline, ideally in less than a month.

Notice that three of these factors may result of using the right methodology: You can systematically become more focused, adopt a Problem Solving Mindset and follow a Software Development Life Cycle (SDLC) with short iterations. But you also need to learn what inspires you. For me, personally, inspiration only happens when I face a challenging task.

Of course each programmer may have his own personal reasons that help him dramatically increase his productivity. For some people it may be compensation for improved performance in the form of bonuses or prizes. For others it may be the feeling of full ownership of a project, like “this is my baby”. Please feel free to use the comments below to share your experience. Thanks!

Posted in Agile, Efficacy | Tagged , | 4 Comments

An Inspiring Jobs

Posted on October 11, 2011 by Hayim Makabee

With the recent death of Steve Jobs, I decided to learn more about his life and his many contributions to the world of personal computers. During my searches, I found a very inspiring speech he gave in a graduation ceremony at Stanford University.

In this speech to thousands of students that had just finished College, Steve Jobs said:

“Your work is going to fill a large part of your life, and the only way to be truly satisfied is to do what you believe is great work. And the only way to do great work is to love what you do. If you haven’t found it yet, keep looking. Don’t settle.”

I think this is a very important message for software developers, for two reasons:

The first reason is that programmers normally work long and exhaustive hours. The software development process can be very demanding and stressing. The only possibility of tolerating this heavy work load is to really enjoy what you do. I discuss the problem of the programmers’ hard work on a previous blog post: “How Decision Fatigue Affects the Efficacy of Programmers”

Besides that, I believe that programmers are fully productive only when they work with enthusiasm. Several studies have shown that there is a big difference in the quantity and quality of code produced by different developers, and in my opinion the main cause for this difference is that some programmers work with greater passion. I talk about that in a previous post: “Nothing is More Effective than Enthusiasm”

In another part of his speech, Jobs said:

“I have looked in the mirror every morning and asked myself: “If today were the last day of my life, would I want to do what I am about to do today?” And whenever the answer has been “No” for too many days in a row, I know I need to change something.”

I think that this need to change is essential for software developers. Of course any human being needs to feel that he is evolving and making some kind of progress. But I believe that programmers in particular need to invest a lot in self-improvement, probably more than most other professions. I discuss this issue in my blog post: “The Effective Workplace”

Finally, Jobs makes these important conclusive remarks:

“Your time is limited, so don’t waste it living someone else’s life. Don’t be trapped by dogma — which is living with the results of other people’s thinking. Don’t let the noise of others’ opinions drown out your own inner voice. And most important, have the courage to follow your heart and intuition. They somehow already know what you truly want to become. Everything else is secondary.”

The death of Steve Jobs was certainly a great loss for the world. By studying his biography we learn that he was an example of vision, perseverance, creativity and innovation. I feel sad about his death, and greatly inspired by his work.

Posted in Efficacy | Tagged | Leave a comment

Research at Yahoo! Labs

Posted on October 9, 2011 by Hayim Makabee

My friends frequently ask me about the kind of research I do at Yahoo! Labs. Usually I cannot give them many details, because our work is confidential. But after a project is completed we frequently publish a paper describing it. This is a great opportunity for others, inside and outside the company, to learn more about our efforts.

The first project I participated at Yahoo! Labs Haifa was called FAME – a Framework for Agile Media Experiences. We recently published a paper about it:

Title: “Hierarchical Composable Optimization of Web Pages”

Abstract: “The process of creating modern Web media experiences is challenged by the need to adapt the content and presentation choices to dynamic real-time fluctuations of user interest across multiple audiences. We introduce FAME – a Framework for Agile Media Experiences – which addresses this scalability problem. FAME allows media creators to define abstract page models that are subsequently transformed into real experiences through algorithmic experimentation. FAME’s page models are hierarchically composed of simple building blocks, mirroring the structure of most Web pages. They are resolved into concrete page instances by pluggable algorithms which optimize the pages for specific business goals. Our framework allows retrieving dynamic content from multiple sources, defining the experimentation’s degrees of freedom, and
constraining the algorithmic choices. It offers an effective separation of concerns in the media creation process, enabling multiple stakeholders with profoundly different skills to apply their crafts and perform their duties independently, composing and reusing each other’s work in modular ways.”

You can freely download the full PDF version of the paper.

Here is a presentation about this project:

Hierarchical Composable Optimization of Web Pages

There are many other very interesting projects going on at Yahoo! Labs worldwide. To learn more about them, you can check these two sites:

Yahoo! Labs

Yahoo! Research

You can also search the publications repository, looking for papers about a specific subject. A few papers are more theoretic in nature, but most of them are very practical.

For example, a recent publication that became very popular makes an analysis of user behavior at Twitter, and surprisingly concludes that “roughly 50% of tweets consumed are generated by just 20K elite users”. Of course this conclusion has some important implications for companies that want to advertise on Twitter.

So good luck learning more about our research activities at Yahoo! Labs. I’m sure you will find some inspiring ideas. Enjoy!

Posted in Research, Yahoo! | Tagged , | Leave a comment

The Effective Workplace

Posted on September 27, 2011 by Hayim Makabee

In a recent article at the Harvard Business Review, entitled “The Twelve Attributes of a Truly Great Place to Work”, Tony Schwartz provides a list of characteristics of an effective workplace that makes the employees more “engaged”, and thus more productive. These are the attributes, in summary:

  1. Commit to paying every employee a living wage.
  2. Give all employees a stake in the company’s success.
  3. Design working environments that are safe, comfortable and appealing to work in.
  4. Provide healthy, high quality food, at the lowest possible prices.
  5. Create places for employees to rest and renew during the course of the working day.
  6. Offer a well equipped gym and other facilities that encourage employees to move physically and stay fit.
  7. Define clear and specific expectations for what success looks like in any given job.
  8. Institute two-way performance reviews.
  9. Hold leaders and managers accountable for treating all employees with respect and care.
  10. Create policies that encourage employees to set aside time to focus without interruption on their most important priorities.
  11. Provide employees with ongoing opportunities and incentives to learn, develop and grow.
  12. Stand for something beyond simply increasing profits.

I personally agree with the importance of all items in this list, and I think that a wise manager should try to provide them in order to increase the productivity of his employees.

Now the question is: If you are an employee, how do you convince your manager to improve your workplace?

If you observe the list above, it is obvious that most items have some cost, and some of them have a significant cost. For some items it may be easy to compute the Return On Investment (ROI), but for others it may be very difficult. Therefore, as an employee, to convince your manager to really invest in improving the workplace may be a hard task.

Hence, I suggest a different approach: Convince your manager to allow you to invest more time on self-improvement. Convince him to invest on you!

For software developers, self-improvement may include:

  • Participating in professional courses.
  • Going to group meetings and conferences.
  • Being a listener in advanced courses in the CS Faculty.
  • Self-study from technical books and articles.
  • Learning a new programming language or technology.
  • Using and contributing to Open-Source projects and libraries.
  • Visiting frequently Q&A sites such as StackOverflow.
  • Reading professional blogs.
  • Writing your own professional blog.
  • Giving talks about your field of expertise.
  • Developing prototypes for new products or features.
  • Dedicating a fixed amount of time to your own innovation initiatives.

Of course you must also convince your manager that your investment in self-improvement will not reduce your productivity. Perhaps you will even need to work some additional hours to perform these self-improvement activities, but the benefit will come in the form of clear personal growth and development. Good luck!

Posted in Efficacy | Tagged | 1 Comment

Programming Without an Internet Connection

Posted on August 29, 2011 by Hayim Makabee

Are you able to program without an internet connection?

In my case the answer is definitely “No.” In most of my programming tasks I need to get some help from the internet, generally in the form of documentation and examples. I’m currently programming in Java, and frequently using new libraries, frameworks and APIs. Even in the Java standard libraries there are so many classes that it is very hard to know how to use them correctly. This situation reminds me a quote:

“Knowledge is of two kinds. We know a subject ourselves, or we know where we can find information on it.” – Samuel Johnson

A few months ago I was working on a Web-based demo, which included the use of HTML, CSS and JavaScript. I’m not an expert on these technologies, but still I wanted to be sure I was implementing things correctly. So, for each problem I had, I asked myself: “Is it possible that none had this problem before?” Then I looked for solutions and with enough patience and a bit of luck I was always able to find an example similar enough to what I needed to do. I never came back of a search with empty hands.

When I program in Java I’m always concerned about not reinventing the wheel. If I need some specific function not yet provided by the classes I know, first of all I search if there is some well-known public library that can be useful. Then I download it and write some short program to test it. Sometimes I find several such libraries that appear to be potentially adequate for my needs. In this case I will spend enough time comparing them, and perhaps even testing all of them.

Therefore, the internet is much more than a source of information in the form of documentation and examples. It is the ultimate reusable code repository, from which millions of developers worldwide are frequently downloading the latest libraries. This level of global reuse certainly saves us a huge amount of development effort, making our work as programmers much more productive and even more pleasurable.

If possible, I would like to hear about your personal experience. Please leave a comment answering these questions:

  1. How frequently do you access the internet when you code?
  2. For what purposes do you access the internet when you code?
  3. Do you feel you are less productive when there is no internet connection?

Thanks!

Posted in Efficacy, Software Reuse | Tagged , | 7 Comments

How Decision Fatigue Affects the Efficacy of Programmers

Posted on August 23, 2011 by Hayim Makabee

In the past, programming was an activity based on assembling low-level instructions using a small numbers of structures: there were loops, conditional statements and function calls. Systems were built through the application of relatively few patterns at different scales. Even the design was very simple: Dataflow Diagrams (DFDs) consisted of only processes, data flows and data stores; Entity-Relationship Diagrams (ERDs) had only entities and relationships.

Today, programmers work on a much higher level of abstraction, applying the mechanisms of Object-Oriented Programming, adopting Design Patterns, reusing sophisticated class libraries and extending powerful frameworks. Besides writing new code, developers are also expected to perform parallel tasks such as Refactoring and writing Unit Tests. The design phase requires a great diversity of complex diagrams, like the ones defined in UML.

The consequence is that today developers are making very important decisions at each step of their work. They must choose between composition and inheritance. They must decide if a class in a library is appropriate for their needs. They must analyze the trade-offs involved in the adoption of different Design Patterns. They must plan how to Refactor their code and how to assure good coverage through Unit Tests. Many of these decisions are not really programming issues in the traditional sense; they are in fact design decisions.

Then, if programming today can be defined as a series of high-level decisions, the question is: How can we assure that the developers are making these decisions effectively?

Decision Fatigue

A recent article at the New York Times addresses the issue of Decision Fatigue. The article mentions several researches that prove that people who are required to make many decisions become mentally exhausted, until they reach the point in which they are no longer able to make effective decisions. In its words:

“No matter how rational and high-minded you try to be, you can’t make decision after decision without paying a biological price. It’s different from ordinary physical fatigue — you’re not consciously aware of being tired — but you’re low on mental energy. The more choices you make throughout the day, the harder each one becomes for your brain, and eventually it looks for shortcuts, usually in either of two very different ways. One shortcut is to become reckless: to act impulsively instead of expending the energy to first think through the consequences. The other shortcut is the ultimate energy saver: do nothing. Instead of agonizing over decisions, avoid any choice.”

One concrete example is Copy-and-Paste programming. It is very common for a programmer to need a piece of code that is very similar to something he has already written in the past. The best way to reuse this code would be to Refactor it so that it can be shared, but this involves many decisions about how to do it correctly without breaking existing code. Thus, if the programmer is tired, he will probably just copy-and-paste it, because it is the most impulsive action and requires minimal mental effort.

The problem of Decision Fatigue is particularly important when the person needs to make trade-offs. As we know, most design decisions require evaluating different options and analyzing their advantages and disadvantages. In the words of the article:

“Part of the resistance against making decisions comes from our fear of giving up options. Once you’re mentally depleted, you become reluctant to make trade-offs, which involve a particularly advanced and taxing form of decision making. To compromise is a complex human ability and therefore one of the first to decline when willpower is depleted. If you’re shopping, you’re liable to look at only one dimension, like price: just give me the cheapest. Or you indulge yourself by looking at quality: I want the very best.”

I believe that every developer has experienced this single-dimension reasoning, making decisions that appeared to be good at the moment, but then proved to have some very serious negative consequences. For example when a programmer implements a new data structure and forgets about the need to keep it synchronized in a multi-threaded environment. Sometimes these bad decisions are just discovered when the system starts exhibiting some very strange bugs and unexpected behavior.

So, to assure that developers are making decisions effectively, we must either avoid Decision Fatigue or provide ways to recover from it. The article recommends consuming sugar, for example in the form of soft drinks. I would recommend making a short break whenever you feel tired, and spend a few minutes in some activity that does not require much mental effort. And have a Coke.

The most important conclusion is that, if a developer is making important decisions, he should not be required to work long hours. It is absolutely impossible for a human being to continue making effective decisions after many hours of work, no matter how smart or experienced he is.

Posted in Efficacy, Psychology of Programming | Tagged , | 5 Comments

The Wisdom of Agile Development

Posted on July 24, 2011 by Hayim Makabee

What is wisdom? This is a definition from the Ethics Resource Center:

“The ability to make good judgments based on what you have learned from your experience.”

According to this definition, a wise man is someone with vast knowledge and experience, a person who can teach others.

However, the Jewish sages had a different view of wisdom, as expressed in the ancient book “Ethics of the Fathers” written almost 2000 years ago:

“Who is wise? One who learns from every man.”

Thus, to become wise, a person needs to have contact with many others, to be exposed to their opinions, and to learn from their knowledge and experience.

I believe that Agile software development, among its many advantages, creates many such opportunities for sharing knowledge and learning from others. Let’s consider a few examples of situations in which this may occur:

Code Reviews

Agile methodologies give emphasis to the importance of Code Reviews. This is a great chance for each developer to receive some feedback on the quality of the code he is writing. My experience is that Code Reviews have the potential to significantly and quickly improve the programming skills of the members of the team. They create opportunities to discuss design alternatives and analyze the implications of the adopted algorithms and data structures. Of course there is no contradiction between Code Reviews and traditional development methodologies, but in practice Agile teams dedicate more time to this activity.

Pair Programming

Pair Programming is one of the most fundamental concepts of Extreme Programming (XP). The idea is that programmers should not work alone, but in pairs. Then, at the exact moment one programmer is typing the code the other programmer is reviewing it. It is like an immediate code review, with the advantage that the developer always has someone to discuss his decisions at the moment he is writing his code. Of course this is considerably more expensive than traditional development, but experience has proved that Pair Programming has a great positive impact on the quality of code.

Stand-Up Meetings

During the daily Stand-Up meeting in Scrum, people can share what they are doing. The meeting itself is not the appropriate place to discuss technical issues, but it strengthens the connections among the team members, removing communication barriers and creating new opportunities for the exchange of knowledge and experience. After Stand-Up meetings each developer understands what the others are doing, so that he knows from whom he should ask for help on a particular issue.

Retrospective Meetings

At the end of each Sprint, the team organizes a meeting to evaluate its own performance. This is a great opportunity to discuss what was done right as well as what were the mistakes, thus learning from the shared experience. This kind of feedback mechanism is essential in a self-management approach such as Scrum. Its main goal is to constantly improve the process, but another consequence is that it forms more effective team members.

In summary, Agile methods introduce many new opportunities to learn from others by giving emphasis to team work. According to the ancient Jewish sages, this is the key to real wisdom.

Posted in Agile, Jewish Sources | Tagged , | 1 Comment

Who is an Expert? – On Rules and Exceptions

Posted on July 18, 2011 by Hayim Makabee

It is relatively easy to find very young people who are brilliant programmers, who seem to know every detail about a particular language, platform or technology. Some of them will be able to implement a nice Android app in a few days, others can write cool Facebook games in a week.

These bright young programmers are frequently very quick learners as well. Give them a new programming language and they will grasp its syntax in a couple of hours. Present them a new API and they will very soon understand all the differences among similar methods and the roles of each parameter.

Now the question is: Do their knowledge and ability to learn transform them into expert software developers?

Whenever I meet these young programmers, I remember this quote:

“The young man knows the rules, but the old man knows the exceptions.” – Oliver Wendell Holmes

So my answer to the previous question is “No”. Knowing the rules of a programming language or platform can make you very effective when working in a particular environment. But to really be an expert you must know the exceptions. You must know when to violate the rules.

1st Example: Composition versus Inheritance

I once worked with a good Java programmer that followed the rule “favor composition over inheritance”. The problem is he was fanatic about it: In all situations he used only composition. In his programs you could not find a single class extending another class. If he wanted to reuse a class, he would just encapsulate it in a new class and forward most method calls. A rule with no exceptions allowed…

2nd Example: Const-Correctness

I once participated in the development of a very large C++ system. I noticed that almost none was using const methods, and as a consequence they could not pass const parameters, even if an object was not supposed to be changed by a function.  I was surprised; it seemed that most people were not aware of the importance of const-correctness.

But then I discovered another reason for this mystery: Most programmers didn’t know about the possibility of declaring a data member as mutable. Then, many classes that used synchronization mechanisms had not const methods, even when the state of the object was not being changed. Even the accessor methods could not be declared as const, because they were changing some lock.

The rule says that const methods should not change the values of data members. But the real intention is that they should not change the object state. Hence the exception to the rule is that Semaphores and Mutexes can be changed by any method, because they are not part of the object state. They should be declared as mutable.

Conclusion: It is relatively easy to learn the rules, but only experience can teach you the exceptions. If you know the rules and the exceptions, then you are an expert.

I will be happy to hear in your comments more examples of rules and exceptions. Please share your experience. Thanks!

Posted in Efficacy, OOD, OOP | Tagged , , | 4 Comments

Design Patterns and the Tower of Babel

Posted on July 11, 2011 by Hayim Makabee

This is the story of the Tower of Babel from Wikipedia:

According to the biblical account, a united humanity of the generations following the Great Flood, speaking a single language and migrating from the east, came to the land of Shinar, where they resolved to build a city with a tower “with its top in the heavens… lest we be scattered abroad upon the face of the Earth.” God came down to see what they did and said: “They are one people and have one language, and nothing will be withholden from them which they purpose to do.” So God said, “Come, let us go down and confound their speech.” And so God scattered them upon the face of the Earth, and confused their languages, and they left off building the city, which was called Babel “because God there confounded the language of all the Earth.” (Genesis 11:5-8).

There is a very clear message in the story of the Tower of Babel: When people speak a common language, they may succeed in very challenging projects. If, however, everyone speaks a different language, the project will surely fail.

The catalogue of Design Patterns in the Gang-of-Four book was a very important contribution to the software development industry worldwide. Many programmers improved their object-oriented design skills, learning from the examples collected in this work. But, in my opinion, the book’s main gift to us was the creation of a common language on a higher level of abstraction.

Before this book, software engineers tried to express their ideas using the basic concepts of Object-Oriented Programming (OOP): inheritance, composition, encapsulation, dynamic binding and abstract methods. There were very few names to capture a portion of the design, i.e. the relationships among several classes in a system. One of the few examples was Model-View-Controller (MVC).

Then, when the Design Patterns book became popular, as an immediate consequence a common vocabulary was created. Suddenly people were able to talk about Singletons, Visitors, Factories and Strategies. Today, when you mention any of these names, you expect other developers to understand exactly what you are talking about, without any further explanation.

We know that it is a characteristic of each profession to have its specific vocabulary, which allows work to be done more effectively. In this sense, I believe that the Design Patterns book was a big step for the maturity of software engineering as a profession.

Posted in Design Patterns, OOD | Tagged , | 2 Comments

The Facebook Killer: Lack of Reciprocity

Posted on July 3, 2011 by Hayim Makabee

Some people claim that Facebook will be replaced by some other social network such as Google+. I think that the real Facebook killer will be the Lack of Reciprocity:

If you are constantly posting about your personal life, you will eventually discover that your hundreds of “friends” know everything about you, but most of them don’t want to tell you about their lives.

This is my classification of Facebook users, according to the way they use it and the kind of information they publish: 

    • Naïve Users: Are very active users, publishing lots of personal information and family pictures. They will let you know everything about their lives: In which restaurants they eat, what clubs they frequent, where they are planning their vacations. They have many albums with lots of pictures, some of them very personal. They also frequently comment and like the posts of others.
    • The Jokers: They like to post statuses that they think are very funny and/or smart, such as: “How are turkeys called in Turkey?” They will never publish anything personal. If they upload a photo, it will probably be something bizarre they saw in the street. They don’t comment or like the statuses of others, but it is very important for them to have as many people as possible liking their own posts.
    • The Linkers: They provide lots of links to things they think are interesting and should be shared, like videos on YouTube, TED talks and news articles in digital journals. They also like to be the first to share some breaking news like “Michael Jackson is dead!” The Linkers never post any kind of personal information.
    • The Gamers: They spend most of their time playing games at Facebook, and their many posts are all notifications of the kind “Nancy has found a lost cow in his farm!” The Gamers don’t post personal information, but they will frequently invite you to play with them.
    • The Fans: They use Facebook very actively to follow everything their friends are publishing. They frequently comment and like other people’s posts, but never write about themselves. They make a true effort to be nice and friendly, but do not share about their own lives.
    • The Wishers: They only use Facebook to wish a “Happy Birthday” to their friends. They connect every day, check who has a birthday, and then post a congratulation message on his/her wall. If there are many such friends, they use “copy-and-paste”. The Wishers rarely write anything on their own wall.
    • The Scanners: They use Facebook to always keep up-to-date about what is happening to his many contacts. They are very interested in other people’s lives, so they read every status and see every picture. If there is not enough activity in the News Feed, the Scanners will start checking who the friends of their friends are. As the name suggests, they never write anything, so they cause you the impression they are not using Facebook. But they are, and a lot!

It is obvious from this classification that the only people publishing any personal information are Naïve Users. Moreover, people using Facebook to read their friends’ posts are interested mostly in the personal information provided by the Naïve Users. The Jokers’ jokes, Linkers’ links and Gamers’ notifications are different types of garbage that only pollute the News Feed. There is nothing really “social” about them, so they do not contribute much in a social network.

I believe that eventually the Naïve Users will understand that they are sharing too much personal information with too many people. They will discover that details of their lives became public domain, while the people consuming this information, their “friends”, do not really reciprocate. Then I doubt they will continue sharing that much.

At the moment that Facebook will lack the personal information provided by the Naïve Users, its social aspect will be lost, and this will greatly affect the motivation of all other types of users.

Technology can provide us new tools to communicate, but it cannot change the inherent defects in human nature.

Posted in Social Networks | Tagged | 2 Comments