You gain knowledge from information coming from many different sources including books, articles, blogs, conferences and all the discussions you have with other professionals. Being able to interpret, evaluate, assimilate, synthesize and apply the data you collect is called critical thinking and is an essential skill for anyone (including the developer).

“A persistent effort to examine any belief or supposed form of knowledge in the light of the evidence that supports it and the further conclusions to which it tends” Edward M. Glaser

The word critical derives from the Greek word kriticos, which means discerning judgment. The roots of critical thinking come from analytic philosophy (Greek Socratic tradition) and pragmatist constructivism (Buddhist teachings).

In this article, I’ll try to isolate the 3 most common steps to practice critical thinking which is similar to scientific skepticism.

1. Identify potential cognitive bias

Cognitive bias, such as the confirmation bias, is a pattern of deviation in judgment that occurs in particular situations. Everybody is more or less affected by it. The more you know about those biases, the less likely they are to affect your judgment negatively. Here are some well-known cognitive biases:

• Confirmation bias: the tendency to search for or interpret information in a way that confirms one’s preconceptions.
• Mental filter: inability to view positive or negative features of an experience, for example, noticing only a tiny imperfection in a piece of otherwise useful clothing.
• Gambler’s fallacy: the tendency to think that future probabilities are altered by past events, when in reality they are unchanged.  This results from an erroneous conceptualization of the Law of large numbers. For example, “I’ve flipped heads with this coin five times consecutively, so the chance of tails coming out on the sixth flip is much greater than heads.”
• Overgeneralization: Extrapolating limited experiences and evidence to broad generalizations.

Sometimes journalists, politicians and even experts are affected by the overgeneralization bias and write like this: “The scientists confirmed global warming”. Try to replace words like “the scientists” or “the experts” respectively by “some scientists” and “some experts” which usually reflects the reality. It will give a very different meaning to the text. Be aware that identifying another’s bias is easier than identifying your own and don’t forget some people will use tricks to consciously manipulate opinion.

2. Separate facts from opinions

Anyone can post anything online and this is a great opening for narcissist leaders and other fake experts with extrovert personality.  The internet is full of information coming from these sources and a lot is based on opinions rather than facts. A critical thinker is able to separate the two.

You will prefer references to recent scientifical studies. Serious papers will reference multiple sources. But as you will see in next point, mentioning references is not a guarantee that the information and its interpretation are correct.

Always verify the credentials of the experts.  Has the business expert only created one or two businesses or has (s)he created several ones facing difficulties? Is it easy to find information about them or does any data about their past seem hidden or difficult to reach?

3. Analyze the data

To be reliable, the source must be based on empirical data that is produced by observation or experiment. The theory based on the experiment must be refutable.

“A theory which is not refutable by any conceivable event is non-scientific”. Karl Popper

In human sciences, any experiment which aims to define a theory or methodology should be reproducible in at least 95% of the attempts. A good example of non scientific theory is the Freud’s Oedipus complex in psychology. There is no way to refute the theory because Freud states that if the behavior doesn’t appear, it’s because it is repressed.  There is no way to validate or invalidate the theory. Even if there is a possibility than the theory is true, there is no way to verify it and so it should treated with care.

Here are the research methods commonly used in human sciences:

• Observation: usually the first step of research to attempt to identify potential causes of a behavior.
• Surveys & tests: if you can’t observe thoughts, we can ask people to describe them. The problem with surveys is that you can’t be sure that the answers are correct.  Social desirability bias, demand characteristics, memory errors are some of the problems you will encounter in addition to the sampling bias. After that, when you interpret the results using correlational approach, it’s impossible to prove that changes in variable A causes changes in variable B. At best, this method can be used effectively to describe or predict a behavior (what), but not to explain it (why).
• Case study: this is the most popular research method in software as it is easy to do. Observe a few persons and try to determine a pattern. You can’t really prove a causal effect,  just like with surveys. But like observation, this is a good first step for the experimental approach.
• Experimental: the experimental approach is the only type of methodology that, if well conducted, is able to make causal statements.  They are very difficult to carry out, especially in the field of software development. A well conducted experiment will include the following:
  • At least one control group in addition to test group(s).
  • A preference for double-blind trials.
  • A study sample based on sufficient and random sampling to avoid sampling bias.
  • Have dependent and independent variables.

Have you ever read a book written by successful entrepreneur or software developer that converted his own and unique experience into a methodology? Your critical thinking would force you to evaluate the methodology by calculating how many successes have been made out of the millions readers. How many of these would have been successes anyway even without applying the methodology? As a reader with critical thinking you will be able to take what is useful in the book and leave the rest for what it is: a case study at best, observation in most cases. This applies, of course, to any source of information.

But even the results of well conducted studies can be wrongly interpreted, consciously or not, by the person that mentions it. Sometimes it is even conscious: a great example is how some people are caught lying with statistics. Politicians against the decriminalization of marijuana claimed that studies showed 87% of heroin addicts started by using cannabis. Cannabis would  therefore lead inevitably to hard drugs. What they forgot to mention are the millions of people smoking cannabis that never use heroin. The information is true, but manipulated.  In fact, we could present a study that demonstrates that 100% of heroin addicts used coca-cola! Should we prohibit coca-cola?

The 3 steps

Developing a critical mind is not easy, and we must be prepared to accept that a certain number of our current beliefs are wrong. To summarize, here are the three steps to follow to ensure you won’t be intoxicated by the information you gather:

1. Step 1: identify potential cognitive bias.
2. Step 2: separate facts from opinions.
3. Step 3: analyze the data.

To learn more

How much of your current knowledge and beliefs are opinions rather than facts?

Check the cognitive bias list on Wikipedia to learn more about them. You can read more about the different methods summarized above on this page.

Book recommendations:

The estimate of the value of production of software based on the number of lines of code (LOC or KLOC or SLOC) is as popular as it is controversial. The main criticism is that there are too many factors influencing the final measurement value. Robert E. Park (1992, page 140), software metrics specialist & staunch defender of the method, responded to critics with the following:

“When we hear criticism of SLOC as a software measure, we are reminded of a perhaps apocryphal story about a ditch digger who, when asked one day how he was doing, replied, “Dug seventeen feet of ditch today.” He didn’t bother to say how wide or how deep, how rocky or impenetrable the soil, how obstructed it was with roots, or even how limited he was by the tools he was using. Yet his answer conveyed information to his questioner. It conveyed even more information, we suspect, to his boss, for it gave him a firm measure to use as a basis for estimating time and cost and time to completion.”

Originally, this technique could probably be used in the conditions mentioned by the Park. Later models such as COCOMO (Boehm 1981) also allowed developers take into account a number of parameters whose variability was probably reasonable at the time. But since then, the number of factors affecting the number of lines of code has become so important that it is very unwise to take this action seriously both in the evaluation of the software and the productivity of the design team.  I will try to illustrate the problem using eight arguments.

1. Different languages and different frameworks

Today hundreds of different languages exist (Wikipedia 2013).  For each of these languages there are several frameworks.  For the same functionality, there may be a very different number of lines of code produced depending on which technology is chosen.  In addition, modern architectures use different technologies, which further complicates calculations. Correction factors exist but they hardly seem defensible given the wide variety of types of applications that are being developed today.

2. Experience and competence of the developers

We must also take into account the experience of the developers involved as this may affect the calculation in many ways. A very competent developer often writes fewer lines of code than other less experienced developers because they will use design methods created for the sole purpose of reducing the number of lines and increasing readability and maintainability. In addition, they are more competent with the functionalities offered by tools (technology stack). Indeed, through ignorance of these, many programmers rewrite existing code, greatly increasing the number of lines of code.  In this regard, many experts in the area do not hesitate to speak of “lines of code spent” as opposed to “lines of code produced” (Dijkstra 1983).

3. The practice of refactoring

The fact that the same piece of code can change over time with the refactoring (reworking of code) can skew the results. This practice reworks the source code without adding functionality (Wikipedia 2013) and it is becoming more common because it can increase code quality and reduce technical debt. This can cause unexpected situations: if many developers practice this technique while the lines of code are being measured, the result could give the appearance of a reduction in output (fewer lines of code than in the previous measurement), while it is clear that the opposite occurs.

4. The practice of reuse and / or code generation

The reuse of existing code is very common and highly recommended in DRY (Do not Repeat Yourself). So many parts of the code can be retrieved from a previous project or copied from an open source project, library or another blog post. In addition, modern development tools can automatically generate code for the developer who works with various high level design tools.

5.  Tasks outside development

Activity in the development of software is not limited to writing code on a keyboard. In fact, many other tasks are needed to produce quality code. Here, a high variability can emerge according to the different methods used, the composition of the team or the documentation requirements.

6. The reliability of the measurement tool

A wide variety of measurement tools are available on the market. Given the lack of consensus on the method of counting the amount of lines of code in a source file, the outcome may be materially different depending on the tool used.  In addition, certain technical problems can arise when it comes to identifying what should actually be counted or not. For example, some software has difficulty differentiating comments from instructions when they are mixed (Danial 2013). The efficiency and quality of those source line counter is also very variable.

7. The (potential) manipulations

When a measure may have an impact on one or more person, we need to consider the possibility that some of them try to manipulate it to their advantage. Thus, if the productivity of a developer is measured based on the number of lines of code (or functions), they could very easily manipulate the source code to inflate the results. This problem is very common in companies that use KPIs to conduct assessments of their employees. One can also easily imagine a company trying to maximise the numbers if they know they will be evaluated based on this metric.

8. Time

Almost all the above elements are time sensitive. For example, the competence of a developer does change with practice (this includes the famous learning curve). More features of languages ​​and frameworks are also evolving to increase the productivity of the developers. The longer a project takes, the longer the measurement will be sensitive to this bias

Conclusion

In conclusion we can say that estimating the production effort or value of a program using this software metric is very risky. However, this technique is widely used. Some estimate experts such as Steve McConnell (2006) are very aware of the ineffectiveness of the method but still use it in the absence of anything better. Other methods based on “function point” (business functionality) have attempted to resolve some of the issues addressed above, but the values ​​remain highly correlated with the number of lines of code (Albrecht 1983).  For me, the information obtained by these metrics, and anything based on them, should never be considered as reliable and should be used with great caution in your decision making process.

Note: Some of the information in this text come from the fruit of the research I have done for LIEU (Liaison Entreprises-Universités) a network of valorisation units of Universities and colleges of the Wallonia-Brussels federation.

References

Albrecht, A. (1983). Software Function, Source Lines of Code, and Development Effort Estimation. http://ieeexplore.ieee.org/xpl/articleDetails.jsp?tp=&arnumber=1703110&searchWithin%3Dp_Authors%3A.QT.Albrecht%2C+%2FA%2F.J..QT.%26searchWithin%3Dp_Author_Ids%3A37850740200

Boehm, B. W. (1981). Software Engineering Economics.  Englewood Cliffs, NJ. http://userfs.cec.wustl.edu/~cse528/Boehm-SE-Economics.pdf

Danial, A. (2013). CLOC Limitations. Retrieved the 2 august 2013 from http://cloc.sourceforge.net/#Limitations

Dijkstra, E. W. (1983). The fruit of misunderstanding. Retrieved the 2 august 2013 from http://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/EWD854.html

List of programming languages. (2013, July 30). In Wikipedia, The Free Encyclopedia. Retrieved 12:48, August 2, 2013, from http://en.wikipedia.org/w/index.php?title=List_of_programming_languages&oldid=566431816

McConnell, S. (2006). Software Estimation : Demystifying the Black Art.Microsoft Press. http://www.amazon.com/Software-Estimation-Demystifying-Practices-Microsoft/dp/0735605351/

Park, R. E. (1992). Software Size Measurement : A Framework for Counting Source Statements. http://www.sei.cmu.edu/reports/92tr020.pdf

Réusinage de code. (2013, juillet 5). Wikipédia, l’encyclopédie libre. Retrieved the 12:04, august 2, 2013 from  http://fr.wikipedia.org/w/index.php?title=R%C3%A9usinage_de_code&oldid=94719037

This personal kanban could just save your life.

This is an extremely simple method of personal organization based on concepts just as simple.

Along with many other advantages it will help you to:

• Combat Procrastination
• Reduce general anxiety levels
• Increase visibility

Used in work (or family) teams a Kanban can also help to improve collaboration.

To make your personal kanban

You can get everything you need for around $ 50:

• Corkboard (1.5 ‘X 2’) – $ 29.99
• Push Pins – $ 1.49
• Bamboo 2-Tone Business Card Holder – $ 2.99
• Notes (3” x 3“) – $ 12.50
• 1 Sheet of white paper

I chose products from Staples (prices may not be the same), but you can use whichever products you prefer, provided that:

• The total area of the corkboard does not exceed 1.5′ x 2′. This is important – we will see why later.
• The business card holder must be able to contain up to 30 notes or more.

Assembly is simple.

1. Take a sheet of white paper and cut two strips along the length of about 0.3 inches. Place them vertically, equally spaced, on the corkboard.
2. Although optional, you can add a heading to each of the three sections you have just created (you can use what is left of the white paper for this). The sections are: TO DO; IN PROGRESS and DONE.
3. Finally, paste the business card holder at the bottom of the third section.

Once assembled, your personal kanban should look like this:

Implementation

The central element of your personal kanban is the backlog. The backlog is the list of everything there is to do. It is constantly evolving and to be effective, you must trust it.

Collection

Take the notes and begin to list all the tasks that are going through your head. Use one note per task. Do not worry if you forget something, one of the best things about this tool is that you can add things later to get them in the process. For more information on the collection process, refer to the description of GTD.  Fans of GTD will see how you need to have a kanban for each “location context”.

The way you describe your work is essential. The principle of “next action” should be used whenever possible.

For example if you need to call your telephone company to cancel your subscription, don’t write “cancel subscription”, but “Call Phone Company to cancel the subscription.”

The difference between these two descriptions is obvious. The first version describes your goal, while the second invites you to action. This technique is particularly effective against procrastination. Your mind is less likely to find avoidance strategies.

Prioritization

Once you have all your tasks on notes, you must prioritize them. Organize your tasks in order of importance. The strategy is simple: one task is always more important than another. When you set priorities, think long term. An important task that will become tomorrow’s urgent task should be completed before it becomes urgent. Having urgent tasks always creates more anxiety.

Planning

You must “plan” a maximum of five tasks on your corkboard. In other words, you can’t have more than 5 notes in total on the board. To add a new note, you must remove one that is in the “Done” section, provided of course that it is “Done”.

Ideally, you choose the five most important tasks of your backlog. But it may happen that you decide to group tasks for practical reasons such as economies of scale. If you need to do some odd jobs in the garden, it might be more advantageous to plan to do them together.

Execution

When you decide to start a task, you take the note and put it in “In Progress”. This indicates that you really will do the job. If for any reason you decide to put off the job without having begun it, replace the note in the first column.

Here is a very important rule: Never have more than 2 notes in “IN PROGRESS“.
This stops you from starting to do several things at once without completing any of them; one of the root symptoms of procrastination. This simple rule prevents you from having to waste more time choosing between tasks and means that you can advance.

You can browse your backlog regularly (every 2 to 3 days for example), and update and then re-prioritize if necessary.  You add task notes to the “To Do” section as you take them from “Done.”

You can add to the backlog but you should only ever take a task out of the backlog if its completion would no longer provide you with the intended value.

This process is perpetual. That is to say that there is no end.  We will always still have things to do, that is “situation normal”. If you can accept this fact, it will really help you to reduce any feelings of stress.

How does it work?

The problem that all methods of improving productivity face is the need to fight procrastination. Procrastination fuels anxiety.

When you procrastinate, your mind seeks avoidance strategies and your energy goes into implementing them rather than the tasks. Having only a few tasks that are permanently visible allows your mind to unlock faster. This phenomenon is greatly amplified by the power of the “next action” that calls for action and not for more reflexion which just feeds your toxic thoughts.

Procrastination often happens because you are discouraged by the feeling of having too much to do. For this reason, the size of the board only allows you to displays a limited number of tasks.

How do you eat an Elephant? One bite at a time!

Having a list, or backlog, (and being able to review and update it) gives you peace of mind.  When there are too many unknowns your thoughts often go in all directions in search of potential threats rather than focussing on what needs to be done.

The kanban is more effective than the standard task list, because a long task list, although it helps you to see all the tasks clearly, sometimes generates as much anxiety as it removes.

Seeing a big task list can really discourage you so you must make your task list accessible but not visible. You can do this really simply with the personal kanban. Place the notes in the business card holder. Your list will instantly seem smaller than it is. The first note in the stack is the most important and therefore it is most likely where you need to start.

The personal Kanban reassures you.  Your tasks are visible but, thanks to the contrast between the notes tucked away in the business card box and those displayed on the board, the size of the backlog is not advertised. Your attention is directed naturally to what matters most at that moment i.e. the 5 tasks on your board.

Also, having a real, physical board which involves you in real action promotes a direct link between your brain and managing your tasks. Taking a task and moving it across your board creates a concrete sense of accomplishment: much stronger than when you click on a checkbox in software.

Another thing that typically causes anxiety is the fear of forgetting something.  The availability of the backlog, easily accessible and convenient, removes this fear. Having the backlog (and regularly updating it) means you can relax.

Finally, the prioritization of the most important tasks allows those which are the least important to fall back to the bottom of the list. You lose less time dealing with trivial things and you are in control of how much time you give to those tasks.

Many students and future entrepreneurs ask me how it is possible to leave their job and security without the risk of ruining their life.  In fact, this fear is irrational as is the illusion of security in your job.  That will be subject of a future article, but in the meantime here’s the one thing I generally recommend for start up without risk.

You must have enough money put aside to support you financially for an entire year.

If you do not, you will be at the mercy of each little setback, making your journey much more difficult.  And to launch your start up without working on it full time will also affect your chances of success.

Here are the 6 steps you need to go through to quit your job safely:

1. Reduce your monthly expenses to a minimum
2. Save any extra money
3. Increase your income
4. Get ready for the adventure
5. Negotiate your departure
6. Commit yourself fully

The first three points can be found in dozens of books on managing personal finances, with the common denominator : spend less than you earn and put the money aside.  The aim of these three points is to get yourself into a good financial situation.   The final three points are really important for a good start.  Missing one step can act against you.

Here’s an explanation of the 6 steps:

Reduce your monthly expenses to the minimum

Have a modest lifestyle then you can dramatically increase your level of freedom and your ability to seize opportunities. People with a very high standard of living are often prisoners of this lifestyle and slip into a vicious cycle called The Rat Race. They are on the treadmill never able to stop, because stopping would mean big problems. Having a modest lifestyle is a luxury accessible to all.

Get rid of all the unnecessary stuff in your life.  This could include selling your expensive car, reducing your frenetic shopping and the number of meals out in restaurants every month.  Instead of an expensive gym subscription try running or cycling outdoors.  Consider swapping your shiny, new, latest generation iPhone for a second hand android and don’t forget to cancel all the subscriptions that you don’t really use.  Next summer instead of going abroad to a 5-star all inclusive hotel try camping or bed and breakfast.

Worried about loss of your well being? Scientifical studies (Malka/Chatman 2003, Baucels/Sarels 2010, Boyce/Brown/Moore 2010 & Krugman 1999) prove that once your basic needs are met, any extra money won’t really affect your happiness. In fact, too much stuff in your life may introduce boredom and anxiety. More is less.

Still worried? Don’t forget it’s just temporary until you can afford it (again). In fact you should never buy anything you can’t pay for with cash. If you can’t pay in cash (with the exception of your house), it means you can’t really afford it. You’ll be able to buy all the luxury you want with the extra money you’ll get from your successful company.

I personally sold my brand new luxury car (Mercedes ML) for a simple and cheap second hand utility car (Ford Transit Connect for less than 8K). Less happy? On the contrary! Liberty of choice is priceless.

Save any extra money

The difference between your income and expenses, is your ability to save.  The bigger the gap is, the faster you will reach the goal of the equivalent of one year of expenses. If your start up requires an initial investment, you must include this in your calculation.

We saw earlier that your income, after a certain point, won’t affect your happiness much. Lack of savings can really affect it (Gavin 2005).

What you do by taking all your extra money is pay yourself first, a lot. Here are the definition from Investopedia:

A phrase commonly used in personal finance and retirement planning literature that means to automatically route your specified savings contribution from each paycheck at the time it is received.

Because the savings contributions are automatically routed from each paycheck to your investment account, this process is said to be “paying yourself first”; in other words, paying yourself before you begin paying your monthly living expenses and making discretionary purchases.

Increase your income

To speed up the process, I strongly recommend you increase your income.  You can do this simply by asking for a raise (it works, really, just try), finding a second job on weekends or evenings, or by getting rid of all those gadgets that you do not need anymore by selling them on eBay (whatever you may think of it). Ideally, you can do all three at once!

One really original way that I have had occasion to test with success is proposed by Timothy Ferriss in his book The Four Hour Workweek.

Please note that this mustn’t be to the detriment of a well balanced life. If you really can’t afford to work extra hours, don’t do it.

Get ready for the adventure

Just because you work full time elsewhere does not mean that you cannot clear a little time to prepare your start up. This need not be more than 4 hours per week. If you have to choose between working more (previous step) or this one, pick this one!

I highly recommend that you use this time to talk to the potential customers of your projects. This will allow you to adjust your business plan in order to develop a product that truly meets market expectations.  This is called Customer Development.

Many start ups fail because the entrepreneurs have never talked to customers and therefore “derived” requirements based on their own experience. What they did not know is that their experience is unique, and often does not reflect reality.

Starting well prepared will help you to face the challenges in a more serene manner. Of course you cannot predict everything, but read enough about the subject and you can protect yourself from most common mistakes.

Additionally, start to subscribe to every major blog of your industry and follow the specialized press. Watch similar companies and try to attend to few trade shows to observe the market.

Finally, to help you prepare, I recommend that you read Four Steps To Epiphany, you can get a pdf version here.

Negotiate your departure

Once you have gathered a year or more of expenses, it’s time to get started.

This is the simplest step, and yet it is one that can seem to be the most insurmountable! It’s not really the fact of announcing your departure to your boss that causes the most concern, but actually making the leap.

Many choose to apply for a sabbatical year (this is a legal right in some countries), others consider this step as a liberation in itself.

If you have fully realized the previous steps, you will be much more confident. You will have enough money to both achieve your business and live normally.

The most elegant way to announce your departure is to request a meeting with your boss and explain that you are going to try the great adventure.  During the interview, take advantage of their experience to ask for advice!   Send your official letter of resignation only after the interview.

Make sure that your departure is not too detrimental to the company and that your departure is not too painful for your employer.

If you are lucky enough to have a good boss, they will let you go without putting any obstacles in your way. Otherwise, they might try emotional blackmail.  If your departure harms your employer, it is likely because you have been poorly managed. It’s rarely your fault. This will be your first test: to deal with this while remaining professional.

Commit yourself fully

You have started!  Now you need to focus on your business full time.  This is no time to indulge in other things. If you chase two rabbits, you won’t catch either.  Don’t start two businesses at the same time. Focus on one and only one. You’ll be able to work on different things at the same time once you get more entrepreneurial experience.

You will probably read in many other information sources that the best entrepreneurs work 100h per week. I really think this is as ridiculous as it is dangerous.  It’s true that working many extra hours will provide you with extra productivity short time, but will likely harm you long term.  You must work hard, but not destroy your health, which is more important than all the money in the world.  In fact, I believe that working too hard can prevent you from being successful as much as not working enough!  Dead or burnt out, you are useless to your business. Your start up needs a healthy entrepreneur with a well balanced life.  I highly suggest you that you don’t work more than 9 hours a day, with regular breaks, including lunch time away from your computer.  Invest the rest of the time in what should be the most important: your family and yourself.

Whatever happens you have this advantage: you will not have the pressure of needing an immediate result. You know you have enough money to support yourself and in case of problems, you know you have the capacity for a much better job than you had before.

What if I fail?

The success of your business is not the subject of this post. That being said, you do need to consider failure.  Statistically, it is even quite likely that you will fail, but if you prepare properly you greatly improve the chance that you will succeed in developing a profitable business in which you blossom.

In the event that it just does not work, know that you come away from this adventure much stronger than before, which will greatly increase your chances of finding a better job.

The reason is simple: Employers love people who take things in hand, those that turn problems into opportunities.  They are quite rare and generally, people who can do this are probably already employed and so not likely to be applying for jobs, or have already set up their own business – this means these skills are in demand.

Indeed, fear of failure is so great that very few people manage to succeed as far as point 5 point, even the brightest. You will be in a unique position that allows you to find an exceptional job.

If you can afford it, save a little over a year in advance to give you a few more months to find a job in optimal conditions, ie without pressure.  For you, the key to finding a better job is that you have become more competent, with no debt and most importantly, with no regrets for not having tried.

All software development team project managers hope for a dream team of successful developers working to assist the company to achieve its objectives. Unfortunately, this type of team is very rare in all professions, including in the area of ​​software development. I am thinking particularly of enterprise applications or software companies where teams of developers are working simultaneously on the same code base of the same product.

The reason probably lies in the way we generally go about increasing developer productivity. It is probably too focused on improving the hard skills of the individuals (e.g. sending them on technical training and evaluating them individually on these points) and not their soft skills which without doubt positively and significantly impact on the effectiveness of the whole team. We should also consider “groupal” improvements: organizing the team so that it can naturally grow and reach a much desired level of maturity.  Raising awareness of the groupal phenomena is an example that I will specifically address in a future article.

I propose here a brief introduction to the concept of team dynamics that I will discuss more thoroughly and specifically in future posts. To begin with, I offer a definition from “high performance teams” research in group dynamics and organizational psychology. This approach is put forward by Katzenbach & Smith (1993) in their book “The Wisdom of Teams” and seems to me to be a particularly interesting way to begin addressing this issue. Both authors propose, as a first step, to clarify the difference between a single group of individuals and a team:

“A team is a small number of people with complementary skills who are committed to a common purpose, performance goals and approach for they hold themselves mutually accountable.”

We will see how this breaks down operationally. According to Katzenbach & Smith, the characteristics that differentiate between a normal team and a successful team are:

1. A limited number of members

As the number increases, it is less easy to maintain high efficiency. As suggested by the authors in their work, it is clear that problems of communication grow along with the size of the team.

2. They are composed of people with complementary skills

We immediately think of the different technical skills, but it goes further than that. The authors propose three categories of skills:

• Technical & functional expertise
• Problem-solving and decision-making skills
• Interpersonal skills

In software development, we tend to wrongly focus on the first category (hard skills) while neglecting others. One of the best ways to increase the efficiency of an entire team is to invest in developing their soft skills. This should also allow them to see things from a “groupal” perspective as opposed to the “individual” view which is overwhelmingly the case. In addition it should be noted that the multi-complementary members of a team involves active support – and that even within the same skills category. Thus, the developer of the backend will fully rely on the expertise of the DBA when needed and vice versa. All promotion of individualism, for example by individual evaluations (explicit or implicit), would make a good team ineffective.

3. Committed to a common purpose and performance goals

This is a common objective defined in agreement with the team. The goals should never be imposed by any individual (eg the team leader). The performance of the team to achieve the goals must be measurable. The measurement method is paramount and should in no case enter into conflict with the above principles, for example by measuring the team members individually and not collectively.

4. Committed to a common approach

This approach should also be clearly defined. It seems to be that the first requirement is the establishment of coding guidelines that must be enforced by a continuous integration server and / or frequent code reviews. The latter, to be effective, must not be made by the same people but by the team in rotation. This allows different members of the team to share learning and leads to a mutually enriched team. The criteria should be re-discussed and re-evaluated in a retrospective sprint (if you work in an iterative model as Scrum). The team should also have overall responsibility for development tools it uses. If they have a strategic interest in the company, its main users should be involved in one way or another in the discussions. Which brings us to the last point.

5. Mutual accountability

This element seems to me particularly important to ensure good cohesion in the team. If you want to get to an optimum efficiency level, you must delegate some control over the project to the team (eg the choice of tools as mentioned above). The worst situation would be to make the team fully responsible for the result but taking away any means of control over their performance. This would create very severe stress that would be counterproductive for the entire organization.

As you may have noticed, there is plenty of room for discussion. And this is just based on the findings from a single study. There are hundreds of other studies that will allow me to return to these questions of team dynamics (aka group dynamics) very frequently in the future.  I think that this is a fundamental element in the field of software development. The specifics of this sector will allow us to approach things differently. I am thinking especially of the psychological profile of the developer in general (myth or reality), but also the technical means available to create an optimal working environment to meet the criteria for achieving optimum performance. For example the use of the continuous integration server but also the various meetings organized within the framework of a method of iterative development.

If you are interested in the subject, do not hesitate to share your experiences in a comment or by contacting me directly.

I’ve been doing technical support for the last 13 years and still do it today, I love it.  I love it so much that I’ve now got friends all over the world.  I used to have a map of the world in my office with pins that located them.  I’ve even been invited to the wedding of one of them on the other side of the planet, which I attended with great pleasure.  This is invaluable experience and just for that, I’ll continue for the next 13 years in the exact same way.

But in addition to the social aspects that are obviously linked to my personal interest in multiculturalism, technical support is a real opportunity to grow for both developers & business owners.  Support connects you to your users and it’s one of the best channel of gratification you may have.  The comments and suggestions you receive positively from it help you improve your products, skills or strategy.  If you are doing great at support, there is a great chance you are or will be great as an entrepreneur or lead developer.

There are many motivational theories and they are not universal as we are all different. We are all driven by both extrinsic and intrinsic motivation at different levels.  A good example of extrinsic motivation is salary or threats (the donkey, the carrot and the stick). You do support because you are asked to do it or only for money (or because potential loss of money), or both.  Intrinsic motivation on the other hand is the motivation you get from just doing the task.  You are aware of your own performance and you are not specifically seeking for extrinsic motivation.  In fact, that kind of motivation often comes naturally afterwards.

“Many, many thanks Pierre for helping me out […]. It’s rare to get such service and I really appreciate it. […]. I owe you a beer or three next time I am in Brussels!” A customer from UK

Because technical support agents are often at the very bottom of the hierarchical pyramid, it is likely to be perceived as a low profile job.  Many technical support guys try to do the bare minimum and hope they will be promoted soon to get out of that awful situation.  I believe it’s the exact opposite.  The essential skills needed to be a great technical support agent are the same you need to be a brilliant developer or successful entrepreneur.  Great developers & great entrepreneurs have strong interpersonal skills.

Strong interpersonal skills include being genuinely interested in your users and being able to put yourself in their shoes.  Empathy through social awareness is one of the core element of emotional intelligence.  If you don’t understand your users, you will face strong problems.  Some users have difficulties expressing their needs or feelings.  Your great ability to decode what your customers need or want will not only make them happy, but also help you improve your products and overall company strategy.

“I must say Pierre that we are very impressed so far not only with the product but with your overall attitude and all the assistance you have given us. I can’t thank you enough but hope to thank you soon as a customer.” A customer from US

Because support is an integral part of your product, support is also one of your main sales & customer relationship channels.  A study conducted by RightNow® Technologies has found that 46% of Australians declared they would leave their current internet provider because of poor customer service.  The same survey states 21% already left a previous provider for the same reason.  How many customers can you keep or get with a great support?  In software development, support is often the first human to human contact your customers get and how it will goes will be weighted in their overall perception of your product.  In fact, your product is not the bits that get downloaded and installed on your customers machines, your real product is the whole experience your customers will get with your company.

Since your product is your company, including its support, any assistance you give to your users should be free and optimized.  To make it painless for both our users and ourselves, we try to use the following procedure once we receive a request:

• If it’s a reproducible bug, we add it into the backlog and give its ID to the customer/user. We also take the ID of the customer/user to notify him of resolutions and releases personally. This is easy if you collect his email directly.
• If it’s a problem using the software, we take this as an opportunity to improve the documentation.  Any answer is written like a knowledge base article that we add in our database afterwards.  It takes triple the time to write, but we don’t have to repeat ourselves later (most users prefer browsing in KB).
• If it’s a feature request we connect the user with the product owner directly.  This is very valuable.  Of course we use systems like uservoice.com, but talking with the user directly is a lot better.
• If it’s a complaint we try to manage that outside the process.  People that complain like to be considered as important (even if the complaint is trivial).

Support is your free & perpetual market research.  Support is one of your main sales channels. Support is your opportunity to learn how to improve your social awareness.

The sprint review meeting is crucial for you, the developer, because this is the time you will be able to both give a lot of visibility to what you are doing and also get the feedback necessary to better align your work on the real needs of customer and or users. Yet too often, this meeting does not achieve these objectives because it has been badly prepared.

Show what you have done

I would like to draw your attention to two of the main problems that may be encountered.

Firstly, showing the result of work that has no user interface, and then secondly making sure you show something that works.

For the first point, the difficulty intensifies when you are dealing with people who have never been programmers. They often do not realize that a developer can sometimes work for weeks for minimal changes to the user interface. In other words, they can hear what you have to tell them, but they cannot see it. The solution developers choose far too often is just not talk about it.  If you can’t demonstrate it – don’t show it.

This attitude is typical of personalities we technicians have.  It is undesirable because you cannot then get the views of your user on the progress.  Their understanding and view is much more important than yours.  You are first and foremost in their service, and not the reverse. Developers who comprehend this have a very significant advantage over others.

The best way to show something that will not be obvious in the user interface is to use a presentation slide that describes the change. Because every time you develop software it is supposed to add value, you must find a way to highlight it. Some examples:

• For performance improvements, clearly indicate the gain in a metric understood by the user.
• If you have completed some intensive code refactoring, you should be able to demonstrate the usefulness of the work by using metrics highlighting the reduction of complexity, testability, or other value that will in the long term give significant savings in maintaining the code.
• For the functions for which it is impossible to show something, such as support for a new source of information in a communication tool, do not settle for spending a few moments going through an a list of work done. Describe the challenges you encountered – this should give them the context that they lack.

In any case you should avoid sounding as if you are just justifying the time you have spent on the work.  The idea here is to evidence that you have progressed and that you are in control of the situation.

One last thing about the demonstration: Make sure you do the following things:

• draft a scenario that you will repeat to your users.  You must not just randomly chat about the project
• This scenario should cover most of the needs expressed by the client. This makes sure you are not interrupted by constant questions during the demonstration. In addition, this will allow you to ensure good feedback (we will cover this again below).
• Run the demonstration several times on the machine that will be used during sprint review. This should eliminate most problems.
• Rehearse it once or twice under the same conditions as the meeting. That is to say physically in the room with the same equipment.

Collect feedback

Great developers excel in this task. They know that developers who give the most satisfaction to their users or customers are those who understand and realize the things that bring their customers the most value. This type of profile is very rare and it is again very difficult for a technician to fully grasp this concept.

Everyone knows that the users are usually more comfortable when describing their problems than with finding solutions. There must be a real interaction between the technician who will eventually devise the solution and the person who has the problem. For this interaction to be productive, the programmer should be able to ask the right questions and discuss areas for improvement – and this is especially true during sprint reviews.

Many developers fear this time because they are likely to be criticized. This particularly affects perfectionists. Here are some tips to manage any negative reviews:

• Be aware that criticism of your work is primarily criticism of the latter – the work, and it would be inappropriate to assume that the customer is actually criticizing you.
• Remember that criticism relates mainly to the person who has made it and how they have interpreted the situation.

Having considered the two points above, we must consider every criticism as an opportunity for improvement.

Of course, all this also applies to positive feedback and I will write an article soon that will cover this in detail.

To summarize:

• You can show your progress and all your activities
• Feedback is an opportunity for you to excel in your profession

All social groups seek the company of people who help them reach their goals. For example a network-gaming oriented group will generally be composed of people with profiles compatible with the purpose of the group: gamers. On the other hand, people with generally incompatible profiles are rejected. This becomes a problem when someone still wants to join with an inconsistent group. The only solution for that individual is to adapt and align their goals with those of the group, or find another group compatible with their current profile.

In the case of a social group, this process is more or less unconscious. In a company, it’s the same thing, but with the aggravating circumstance that you generally cannot choose. If you are not aligned with corporate goals, you will eventually pay the price. On the other hand, if you understand that the closer you get to the corporate goals, and show that you will help achieve them, you will become indispensable.

This type of person was recently named the Linchpin in the latest book by Seth Godin (which has the same name). Here is his description:

There used to be two teams in every workplace: management and labor. Now there’s a third team, the linchpins. These people figure out what to do when there’s no rule book. They delight and challenge their customers and peers. They love their work, pour their best selves into it, and turn each day into a kind of art.

Linchpins are the essential building blocks of great organizations. They may not be famous but they’re indispensable. And in today’s world, they get the best jobs and the most freedom.

This book is really worth every penny, and if you like this article, I strongly suggest you to buy it as it is full of similar content.

In this article I will tell you about a simple and effective way to become indispensable: make sure you do not create new problems, and on the other hand, that you solve a lot. Become a problem solver.

The trick in organizations is to identify what is “creating a problem” and what is “solving a problem“. For example it is not necessarily creating or resolving bugs. It’s evident that if you create many bugs, you’re creating problems, even though when you solve them, you are solving problems. I will focus on another kind of behavior that can be considered, generally unconsciously, the same as the act of creating problems. Some problems that you are not directly responsible for will still be associated with you just because you report them. Or worse, you don’t report them. Here are examples of behavior that will be seen by your management as problems that you create (or bring) while this is not necessarily the case:

• You complain to your hierarchy about your work environment.
• You indicate that your application has serious performance issues.
• You report that the components suite that you purchased is not suitable for your needs.

All these examples are your problems until you talk to your manager. They become the problem of the manager from the moment you bring them to him. Even if you are not directly responsible for these worries, you’ll be automatically associated with them. The average manager has no time to deal with new problems and he will try to avoid anything related to them.

The first tip is to manage them yourself as much as possible and thus to take responsibility. You have everything to gain with this attitude. Because in this case, you do not create the problem, you are really solving them! Very few people have the ability to take responsibility for such decisions. But we can develop that talent by doing. When you face a problem, ask yourself the question “can I myself, or with the help of my colleagues solve this problem?”

Unfortunately in many cases this is not so easy. You will simply not be able to adopt that attitude for organizational reasons, such as hierarchical approval processes. If you can’t be the decision maker, you must pass it to the management. Faced by what seems to be a great constraint, there is a very simple technique that is used by the indispensables and almost always overlooked by others: report the problem and your recommended solutions.

Too many people limit themselves to reporting the problem and then are inevitably associated with it. When reporting the possible solutions you are associated with them and then credited for what you’ve become: a person who solves problems. Someone absolutely essential to keep in the organization in contrast to those who create the problems and who it would be better to get rid of.  The more you act this way, the bigger your circle of influence grows. Your opinion will have more and more value. While you are improving your company, you’ll also improve your own working conditions.

Just like the basic concept, the technique is extremely simple to remember. When you encounter a problem that affects you or your company, do the following:

1. Identify possible solutions to the problem.
2. If you think you can solve the problem directly, without the advice or approval of a tier, do it without hesitation.
3. You cannot (yet) make the final decision? Then report the problem with the solutions obtained in step 1.

Examples repeating the above examples:

• You complain to your hierarchy about your work environment: if the problem can be solved with a purchase, specify the references of the desired material as well as all associated costs. Don’t forget to explain how you are affected and how it impacts the company.
• You indicate that your application has serious performance issues: don’t excuse yourself, they don’t care. Recommend potential architecture changes instead or at least an external expert that could come up with more advice.
• You report that the components suite that you purchased is not suitable for your needs: propose a few alternatives that you have tested and always give your personal opinion (what you would pick if you were the boss).

Additional tips to write an effective problem/solution report:

• Be convincing by using an appropriate response structure (see this article).
• Write your email so your boss just has to write the word yes or no in his reply.
• If you have many problems to report together with your solutions, send them in one mail only, even if it’s more logical to have separate threads in case of discussions. The average boss will generally try to avoid discussions.
• Focus on the problem and the solution and only that. Avoid talking about people when possible.

Becoming indispensable to someone is a lot about solving his problems and having the same goals. Companies are seeking problem solvers. Become one of them.

The design of a resume of a software engineer or developer, just like its content, is very important because a well-designed resume will improve your chances of getting selected from among hundreds of others. This post will give you a few tips on how to design an effective resume.  For general guidance on how to create a good resume, there are plenty online resources that will do it better than me. Here I’ll give you extra tips that may help when you are specifically seeking a job as a software developer.

I believe the objective of a resume is not about getting the job. Not directly. The primary objective of the resume is to get selected from among all the others and get the interview. Getting the interview is a slightly different objective than getting the job.  Getting the job offer is the objective of every interview.  Then comes the final objective of getting that contract, after the negotiations.  That’s a different way to see things and you should design your resume to get you past all the filters between your CV submission and signing your contract.

Getting interviews, getting offers and getting the contract are three steps that will be discussed on this blog in the coming weeks. Today, let’s focus on getting those interviews.

Understanding the process for hiring a programmer

To understand why it is important to have a well-designed CV, you must understand what it is like to hire new developers for a company. When a company identifies a need or position, it is described and then published. They publish it on their website, on specialized job boards, and in many cases, and this is one of the specifics of IT world, they hire a recruitment company specialized in IT.

These professional recruiters are usually wrongly called “head hunters”. Head hunters are generally involved in hiring very high profiles such as CxO. The kind of recruiter we are dealing with are processing a lot more data, talking to many more people and therefore can’t use the same soft methods.

At their level, there are 2 major filters involved. One is simple computer software, usually poorly written. The other involves very busy humans: the recruiters themselves. How those recruiters work is important to know because you must create a resume that will prevent you from being ignored by their system.

First, the recruiters need to process hundreds of requests in the very vast & rich domain which is IT. Recruiters generally don’t have any IT background. If they did, given the actual demand they would be working in an IT company for a better salary. They are usually people with more sales oriented profiles that are willing to learn the high level concepts of their customer’s businesses. This problem, coupled with the fact they have hundreds of thousands of resumes in their database make it almost impossible to avoid the use of a search engine to do a pre-selection based on keywords. That’s our first filter.

Hopefully, they don’t blindly export the results and mass mail their customers. They carefully check every occurrence beforehand.  Here the level of professionalism varies between recruitment companies. However they all have something in common: they are very busy. A study based on eye tracking technology determined that a resume is read in less than six seconds and they look for six main things: name, current company & title, previous company & title, previous position start and end dates, current position start & end dates, and finally education. The rest of the data was almost completely ignored. Once your CV is picked, the final step usually involves a quick chat with you to assess your availability & confirm their understanding of your skills.

Once your resume passes that second filter, there is at least an additional one. That’s the person responsible for the recruitment for the company that wants to hire someone. If you are lucky, it’s the team leader of your future team, but it’s not uncommon to have one or more intermediates in between depending on the size of the company. Each of them is a human filter you need to pass. In addition to everything that interests the professional recruiters, your future employer will look for additional details that will be discussed later.

When no professional recruiter is involved, you go directly to the company. It’s what I call the royal way. The royal way is not necessarily a good thing. It usually involves an HR department you don’t want to deal with and/or potentially more documents to be processed by the hiring company.

The overall system you need to pass through, simplified for the purpose of this article, looks like this:

Many of you should now understand why when you send your resume to 50 companies, you receive so few responses (positive or negative).

Let’s go through each filter and see what we can do about it.

The professional recruiter

At this level, we saw that we have 2 filters: the search engine and the actual busy recruiter.

SEO

The software is the easiest filter to pass for a developer. Despite that, I see many CVs that seem to have been designed to be stopped by them. As I said earlier, they are based on keywords and without google science. Therefore you must ensure that every single piece of technology you know well is specified on your resume. I’m still receiving offers for ColdFusion gigs despite the fact that word appears a single time on my resume and in a mission from year 2000! Yeah that makes me think, and you should be thinking too, about removing every unwanted keyword that would get CV selected for projects that you are not interested in!

Don’t hesitate to specify a technology multiple times if used at different companies. As a developer we naturally aggregate that in an area called skills. While it would be a good idea to have such section in your resume, it doesn’t help you to get enough visibility. Repeating keywords for every professional experience will put emphasis on your experience in a particular technology and make it more visible to the recruiter. If you have 5 years experience and worked only 1 year as a java developer, it’s like you have only one year of experience in that particular technology. Don’t abuse those keywords. Be sure to specify tools you have actually used. I usually recommend that you put the words in bold for the technology you have mastered particularly well. On the other hand, remove any irrelevant keywords. I know you learn COBOL at school, but it’s already 5 characters too much on your resume.

One page

The number of pages in your resume doesn’t matter much. What matters however is the first page. When you do a search on your favorite search engine, you rarely look at the second page. Ensure that the essential information is there on the first page. Here is a list of things important to the recruiter that need to be there. There are other things that are important to the hiring company that will be added in the next section of this article. Here we focus on what the recruiter will look for:

• Keep contact information short.
• Choose a good title for your resume. Common mistake is to put your education there. I usually recommend putting “Software Developer” which is the perfect description of a software developer 🙂
• Start with a short description of your expertise. It should not be more than 2 sentences. Don’t be too precise there. You’ll get into details later.
• List your professional experience first, from the newest to the latest. Be sure that the 2 latest are present on the first page. Each experience should have a start & end date, a position title, the company name, a brief description of the project (3 to 5 sentences, easy to read) and of course the list of technologies you used.
• Don’t abuse titles. They are deduced by the description of your mission. They will be discussed in the interview as well.
• Put all languages you speak on the last page. If it’s important for the recruiter, he will look there.
• Avoid including your picture. The average human will unconsciously judge you based on how you look and you want to leave that for the interview.  A recruiter will put even more emphasis on it because he will try to anticipate the judgment of his customer.

Gaps & job hopping

All this advice is far from being enough. You have already polished your CV to seduce professional recruiters, now you need to ensure that you don’t have anything in it that will be a blocker. The recruiter is playing his reputation, so he will systematically eliminate any resume that seems too dangerous.  Two things indicate you are a potential danger (even if it’s not true): gaps and job hopping.

Start & end dates of your experience are very important. Gaps can have many explanations. As a coach for developers seeking for jobs, I see those gaps very often. When I ask what the candidate did in between I get all kinds of answers and surprisingly, the explanations I get  from the candidates are actual extra bonus points instead of the expected negative impact. If you took one year out to start a company (even if you failed); put it in your resume. If you took one year to visit Asia with your family; put it in your resume. If you went back to college; put it in your resume. A single sentence explaining the gap is more than enough.

Gaps are not the only disqualifying thing related to dates. Job hopping can be a serious problem too. Having too much job experience in a short period of time can be seen as instability, and therefore a potential problem to deal with in the future.  The hiring process, not counting the internal training every newcomer has to do, is a very costly process for the company. Therefore, it’s easy to understand why every employer is looking for (very) long term collaboration. The only way to soften how this can be perceived is ensuring that you put lot of visibility on contributions you made for each company your worked for. Make it evident that hiring you will provide value, even if you don’t stay there for years. Please note that while job hopping is generally seen as a bad thing for employees, the same is not necessarily true for freelancers.

The hiring company

From multiple hundreds of matching resumes, the employer can still receive dozen of CVs on a daily basis. Believe it or not, many of them match their profile requirement. It doesn’t mean every profile fits the position, it means that there is more work for the hiring company to filter them out (again, since the professional recruiter has already  pre-filtered them). He doesn’t want to spend the whole day reading that pile of paperwork, especially when the person recruiting is a different person than the person who is actually in need of that additional resource. Another common situation…

More importantly, nobody has the time to interview dozen of developers.  So a massive filtering will occur just for the interview. Your primary objective is to pass that very strict filter and be in the first selection, just like you want to be in the first page of a google search. You want to give your prospective colleague the chance to meet you. In addition to all the tips specified above here are some that are usually overlooked.

You solve problems, you don’t create them

First if you have a technological blog, participate in developer communities, wrote a programmer’s book, or all of the above, that’s something you want to specify on the first page of your resume. This will give you extra bonus points and many recruiters, especially if they have an IT background, will give lot of value to that.

Secondly, the company wants to know how you will help them solve their problem. The best way to show you are the guy they need is to write a short description of the problem you solved for each experience listed. Don’t limit yourself to describe what you did, but write why and how.

I developed a new backend system for their e-commerce website using ASP.NET and SQL Server.

How boring! Instead put yourself in the shoes of the recruiter and write something like:

Developed their new backend system allowing agents to process an increased number of orders and provided them with tools to improve communication with their customers. Facing aggressive deadlines & heavy pressure we heavily relied on extreme programming and scrum. We exploited the possibilities of ASP.NET & SQL Server to the limit.

Of course, everything you write must be true. You will have already read on the many other resources about building a great CV that telling the truth is the golden rule.

The texts above have been invented for this article, but having worked on these with dozens of developers, it’s generally possible to get amazing descriptions just by thinking a bit. By extension, be sure to avoid giving unnecessary facts. By removing useless information, you free up some space to put what is relevant to your future employer.

Miscellaneous & hobbies

Knowing what is relevant is difficult and one area that is often overlooked is miscellaneous or hobbies. Too often, it is completely removed for the purpose of a clearer CV. I believe it is a mistake because it is a great opportunity to tell them a bit more about you and influence the decision to get you into an interview. It helps the recruiter to understand how the candidate manages his life but more importantly, it gives information on his soft skills. I will take two real life examples.

The first wrote “sports, computing & movies”. When you talk a bit more with him about that, you discover that he runs intensively and often competes in marathons. Marathons? Yeah, that guy knows what effort is doesn’t he? I also recommended that he mentioned what kind of movies. I bet it is sci-fi ones, and I bet it would interest many other recruiting developers 🙂

The second one had “scouting” in the hobbies he listed. After few questions I actually discovered he was a chief scout, managing dozens of kids every weekend and in summer camps. That’s someone I need in my team!
Which aspects of your personality do you need to say more about and which are important points for recruiters?  Ask yourself the question “what am I doing when I’m not programming?” and put everything you think would interest the recruiter. Don’t minimize your skills. Instead, put emphasis on them, while staying as humble as possible.

Conclusion

Your resume should demonstrate you are a problem solver and should avoid any indication that you are going to create problems. It’s a document that is supposed to sell yourself so there is no shame on putting emphasis on every good thing in you.

Summary of the tips:

• The first page is the most important one. Polish it.
• Use appropriate keywords, and highlighted when appropriate.
• Fill the gaps with relevant information.
• Anything that differentiates you from the lambda developer should be on the first page.
• Write attractive experience descriptions focused on your problem solving abilities.
• Don’t underestimate what you do outside programming. Use it to tell more about your capabilities and soft skills.

As you build your career, you must make choices. One of the most difficult choices to make is in deciding which  technologies to invest in.  It is not unusual to see consultants who have invested years of their lives in a technology that will eventually be abandoned by the market or its designer. It is virtually impossible to predict the future at this level and the best strategy is to learn how to learn, and be a programmer, regardless of the technology or language. Above all it is always better to invest in things you enjoy doing.  On the other hand there are simple ways to get an idea of what is in demand right now and act accordingly. Simply check for the skills that companies are currently seeking. The law of supply and demand – get it?

One effective method to get answers is to go on large sites offering jobs such as jobserve.com. At the time of writing this post, joberve.com offers no less than 14.626 jobs in IT, just for the United Kingdom!  If you add other countries like the United States, France or Germany, the figure explodes.  The ideal is to use a site that is popular in your region or country.

Browsing the latest offers of employment will give you a pretty good idea of what is being sought. The more criteria you add, the more accurate will be your answer. So if you can only work in the London area, there is no need to search in San Francisco. It is pretty obvious, the nature of IT projects developed in these two cities can be very different.

This research can be tedious. Fortunately, another site that offers jobs provides a faster way to determine the technology application, but at some cost. This is Careers 2.0 by StackOverflow and has an amazing technology tag feature.

I was able to obtain figures in under 5 minutes using the following technique: I created a sheet in my favorite spreadsheet. I typed each tag that I found, one after the other – for the latest 25 bids only (1 page) initially. I then aggregated the occurrences and found myself with a list of technologies and the number of times each was mentioned overall. The following result is for the latest 25 or 50 job offers near London (occurrences are in % for comparison).

I compared 25 to 50 because it is well known that the more data you have, the more accurate the result you have. With the 25 latest job offers, I got a total of 120 tags, reduced to 56 after aggregation. When I took the latest 50 job offers, I got 235 tags reduced to 89 after aggregation. You can immediately see without having to do much calculation that the latest 25 job offers is more than sufficient.  Adding more offers did not change the result significantly,  keeping a satisfactory validity for our purpose: having some indication of what is in demand.

Now that we have our results for Careers 2.0, can we generalize them (external validity)?

Of course not!  And this is the main issue.  There is an obvious website bias involved.  Careers 2.0 provides us with a convenient way to test technologies thanks to their amazing tagging system, but companies posting on it are not representative.  It has only 83 job offers for the London area at the time of the test (12th of July 2012). Jobserve.com on the other hand has 8,657 jobs available for the same criteria.

Careers 2.0 is growing fast, so we can expect that in a few years it will be the reference for programmer’s job vacancies and will provide more accurate data.   For now, use them as an indication and nothing more. Until then, be sure to develop your ability to learn and give priority to technologies you love working with rather than just the ones that are currently in demand. Success almost guaranteed!