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

Whatever your motivation is, one thing is clear – going for a degree is a serious decision. More than that, it is a serious investment of your time and you have to know very well why you are doing it. For the duration of your studies you won't be able to take a fulltime job, potentially a part-time job is going to be a problem too. The studies are going to become your priority and you must understand how this works in order to obtain the most benefits from your venture and gain the highest return on your investment.

Academic environment is generally surrounded by many illusions, misconceptions, preconceptions and false beliefs. The most widespread false idea is that the role of academia is to train workforce for the industry. That is far from the truth. Universities give education to the students. Academic lectures and courses have only one purpose in mind – to demonstrate various fields of knowledge and let students to experience a variety of things within a short period of time. This is the ultimate goal of the education – to extend your knowledge horizons and make you aware of the complexities of the world around you and the particular field you're leaning towards, be it medicine, linguistics, arts, engineering or software industry. When the studies are complete, graduates can choose to specialize in a particular field with the two general choices – entering the industry or going into research. But until that time arrives, academia is not going to enforce any decision on you. And almost certainly you are not going to be trained into a skilled worker ready to get cracking from the first day on your first job.

Your studies of computer science will give you theoretical knowledge in many fields – data structures and algorithms, computer architectures, graphics, data analysis, information theory, cryptography, formal languages and grammars, compiler construction, architecture of operating systems and many others. That is the highest value of the education – getting a good overview of the field and forming a big picture. If you believe a priori you are going to become a practicing software developer, you will have to take additional steps outside the curriculum and find a way to get substantial practice developing software in your own time. The academic environment may not be offering you chances to write code at every step of the way, but it will not be stopping you from taking initiative and seeking out opportunities to do so. There are several options available which we are now going to discuss.

1) Whenever you get an assignment with any course, be it math, physics or anything else where there is a potential to automate your work – use it. Write some code, a simple application to process data, to run algorithms and analyze the results, to simulate natural processes and gather statistics. While it seems like not a big deal, it will be useful in learning about data types, operations on them, performance and rounding problems. From the basics you will move on to the higher grounds.

2) If you have a free choice of tools or when it is your own initiative to write a program, pick up a different tool each time. For common programming tasks there are usually several libraries and frameworks available. Try many of them, compare them, see how they approach solving problems, discover their limitations and strong sides. Learn several programming languages, procedural, object-oriented, functional. Compare their paradigms and what effect on application architecture they exercise. Forming a good overview of the technology landscape counts towards your goal of drawing a big picture.

3)Whenever somebody in your academic environment expresses the need for a little tool to help them automate some work – offer to write it for them, if you believe it is within your capabilities to accomplish. If it works, you will have forged a good relation with somebody in the staff. If it doesn't – well, failure is still valuable experience and nobody is going to blame you for that. You're just making your first steps and the success expectation is low by default. You're not in a production environment where there are deadlines for delivering the work and you're stressed all the way. Instead you have a relaxed schedule so take your time, try things, see if they work out. With your undertaking you would merely be offering a courtesy and they would not be paying you anyway, so nothing would be lost if you don't succeed, provided that you really try.

4) With some courses you will see opportunities to write a helpful tool for the teacher. An utility to process some data and display the results could be a nice demonstration tool in the instruction process. An application to compare different algorithms and see how they handle particular data would yield some practical results the teacher could integrate into his material to prove certain points. An assessment tool to check if the students grasped particular knowledge. Any other form of a lab experiment that applies to the course you're attending would always be useful and welcome too. Offer to code that tool. The teacher will most likely be very glad, and sometimes you can negotiate (or even be offered upfront) being freed from the final examination if you go an extra mile and offer your help. Be warned however that the last tip is a cultural thing and depending on where you live this may be perceived as inappropriate since it would mean you would be getting a favor over the others, even if it seems like a fair deal. You're the best judge of your culture and it's up to you to explore this opportunity.

5) If you're deeply interested in a particular field, approach the teacher and ask if he or she would be willing to coach you if you personally would dive much deeper in the subject than the course foresees. Teachers are generally frustrated most of the time that students are generally bored with what they teach. When they get a highly motivated person in the pack, it lightens their day. If they genuinely like teaching, they would be bringing you more material on their own accord and spending more time with you helping you master the advanced section during the basics class. This is however a very personal opportunity and in part a cultural thing too.

6) Take internships that will help you get a foot into the world of practice. These are generally offered in most universities on local news boards. If you don't see anything compelling, drop an ad on popular career sites or on programming forums popular in your country. Usually there is always a need for a smart student that could help around for very little money, and you will learn how things are being done in the industry. Be warned however that some companies like to exploit students and use them to do the boring work while not giving them a chance to learn. If you feel you're in that situation, leave and take on another post. The internship only works as a mutual relationship, it should not go misbalanced.

7) If you see you've made a significant advancement over the other students, make them aware of your progress. Not that you should brag about your intellectual abilities, never do that, but offer to be a helping hand to the others who struggle with the material. It will teach you to be a coach for the others, even if in its simplest form.

8) Offer to give a series of presentations on some advanced material you've mastered, or at least don't reject it when you're asked to. Learning some presentation skills and the ways to shape and deliver information to the audience would add to the collection of your valuable assets.

9) For the group work choose to team with people with different background than yours, coming from another region or possibly from another country. Intercultural experience is going to be profoundly illuminating, if you're willing to see past your differences and keep an open mind.

10) When choosing which courses to take, try to select the teachers with a practical mindset and possibly industry experience. You can expect to hear more useful and wise ideas in their lectures. And if you get yourself noticed and recognized as a motivated and enthusiastic student, they may help you land your first job as they are more likely to have connections in the industry. If you live in a location where the job market is tough, this can be a huge leverage. Don't miss it.

If you stick to the default curriculum then it will pretty much be a wasted time and a lost opportunity. But if you do follow the advice you can expect to graduate with good marketable skills and be highly competitive against your former classmates who just tagged along for the ride.

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.

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.

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!

Developing your ability to learn, before everything else, is the only viable job security strategy you could have. In fact, stopping learning is the most effective way to screw your career. Developing your ability to learn will not only help you to get more attractive jobs, but it will also increase your intellectual performance.

In this post, I’ll describe a few techniques I found useful during my career in the hope you find them interesting too.

Practice

The most obvious one you may think, but it seems that it’s also the most overlooked. I see many developers reading a technical book from cover to cover, closing it, then starting a new one. This is far from being effective.

I hear and I forget,
I see and I remember,
I do and I understand.
[Confucius]

This is really my favorite quote because it summarizes it all.  You should put everything you read into practice, when possible and when appropriate.  It's how the learning process works best.  Many of the things we read are not understood until put into practice. And it is very likely that you’ll forget what you don’t understand, or worse, apply it improperly.

Without going into details, there is a technical explanation for this.  Practicing involves many other areas of your brain and it helps integrating everything. Here is some additional advice specifically related to technical books, blog posts or conferences:

• When you finish a chapter, do the exercises. All of them, even the most simple ones. In fact you should give priority to books with exercises.
• Try to summarize every chapter to a colleague. It will force you to deconstruct and therefore understand it. Talking about something you read also involves a different part of the brain and it helps with integrating the knowledge. You don't have to speak to someone: you can just simulate a discussion. It will work just as well.
• Put it together in a test project you build from scratch.
• Don't limit yourself to the single source of knowledge. Google everything you learn and read the different positions and perspectives available. Writing your own synthesis can help a lot too. Why not in a blog post?

Get feedback. Give feedback.

As an extension of practice, seeking feedback is another great learning method.  In programming, one of the most effective ways I know is pair programming & reviewing.  Don't wait for it.  Ask for pair reviewing or programming actively.  If you are a solo developer, consider online reviewing platforms.

Also be sure to read as much code as you can. Open source projects are a great fit for that. It's how many of us learn the features of the framework or language they are using.

Oh I wasn't aware I could do that in just one line of code! [Random learner]

Another  effective way to learn is to actually teach. Teach another what you are supposed to learn. When you teach others, you are responsible for the information you give and you have special motivation. That one to many relationship is not the only available one. Participating in communities can stimulate your learning process. “Being there” makes you learn from other's knowledge & experiences.  As a bonus, you learn how to teach or transmit your own knowledge.

Overcome information filters

Our brain is constantly overloaded with environmental data and we have developed a kind of mental filter that is supposed to let pass only the information important to us. This type of filter also stops our creativity from expressing itself and blocks the acquisition of knowledge - even the knowledge that will be useful in the future.

Stanley Kubrick has developed a special technique that he describes in his biography. According to him, this technique has allowed him to acquire considerable knowledge, increase his creativity and his ability to learn. The most visible and obvious result is his films.

The technique was extremely simple: he went regularly to a library and picked up a book at random, without even looking at the title. He read to the end even if he did not like it. This technique has forced his mind to expand into new territories by preventing the mental filters from operating. The new knowledge gets integrated with the previous and creates new perspectives.

You can train yourself like that with anything, not only books. As a programmer, it is often recommended you learn a completely different language than the one you have used every day for years. Just to give you another perspective on things. In fact, too much bias towards technologies or ideas often stops you from advancing and evolving to the next level.

Fail

If you don't fail sometimes, you are not putting enough effort into what you are doing.

Failure is the most natural learning process you can find. In fact, we are physically and mentally wired to learn from failures.

I make more mistakes than anyone I know. And eventually I patent them. [Thomas Edison]

I do not suggest that you start doing anything carelessly. I suggest that you stop being afraid of failure. Fear of failure prevents you from doing the necessary experimentation to advance in life. Fear of failure is also completely irrational. Since most people try to hide their failures, we only have a tiny part of the information and we think people who never fail are the norm.

Experience is how you should describe failure.

Learn by choice

I kept the most effective way to boost your knowledge for the end. This is a very simple technique that I developed over years. In my research of novelty, I was always attracted by new technologies and new domains. I discovered that this way of behaving helped me to gain knowledge faster than choosing the path of least resistance.

Every single time I had to choose between two or more projects, I took the most difficult and challenging one. The one that contained the most unknown technologies or the one in a new domain I wasn’t familiar with. Never stay in your comfort zone.

The most difficult part is not deciding to take the hardest path. The most difficult part is to justify your lack of experience in a given technology when an employer is specifically looking for it. Hopefully, you'll be able to convince them that you are a fast learner and someone will give you the opportunity to show it.

And there is a positive side effect with this method: job satisfaction. The combination of competence & challenge leads you to satisfaction. I will end this blog post with a link to a video related to this that is really worth watching.

This post will explain three rules to follow in order to avoid most of the troubles that you can encounter during the process. The outcome will depend on how you announce it, the feedback you give and the support you provide.

As usual, to know how to behave, you must put yourself in the other person’s shoes. You may know the feeling you get when you get fired. If your career is not long enough to have that kind of experience, you may remember how you felt when a loved one announced (s)he won’t continue the relationship with you. When an employee announces his departure, the employer can feel exactly the same.

So let’s look at it that way and imagine how you would prefer to be fired.

Announce it in person

You will certainly prefer to receive the letter from the hand of your boss rather than by a registered letter in the cold morning.

After you write a short resignation letter, book a meeting room with your manager. I don't suggest you put every detail in the letter as this may be used against you or others. Since it is not required, I would avoid it completely.

Prepare in advance what you are going to say. Just like your letter, this has to be short too. The discussion that will emerge from your meeting can be lengthier of course, but the announcement itself should not be too long. Also be sure to prepare the announcement with a short introduction that will soften the effect a bit.

Give honest and personalized feedback

When you announce it, the most common question will be “why?”  You would probably appreciate some honest feedback on the reason(s) why your employer decided to end your contract. The feedback you give to your employer doesn’t have to be detailed and must be oriented to you, not him.

Example: if you decided to leave because they still work with an old programming language and you can’t do anything about it, don’t tell them it’s wrong, but simply say that you don’t feel comfortable with it. In fact, almost everything is personal; someone else might love to work with that language. Using the old programming language isn't “wrong”, just less appropriate for you.

Here's a few recommendations for the discussion:

• be specific
• put the emphasis on how you feel things, how it affected you
• avoid any judgment on persons
• don’t talk about problems that can’t be changed
• be sure to have a neutral tone and avoid sarcasm or anger

Your feedback doesn’t have to be focused only on things that can be improved. It’s a very good opportunity to say what was great. Just like the reasons for leaving, prepare a list of what you really enjoyed at the company and be sure to talk about it during the last part of the discussion. It will soften the whole discussion.

Offer your full support

Leaving a company is not only a loss in resources, but also a source of potential problems. While your employer should have taken precautions to avoid trouble in such cases, you must ensure that you can provide the minimum support required for your former company and colleagues. Even if things didn’t go very well between you, you must stay professional.  Offer your support at the very end of the discussion. Be sincere but be sure to put some limits and don’t hesitate to say no if necessary.

Quitting a job is never easy and in almost all cases, feelings are hurt. It is very unlikely that you will never face this situation again in the future. You may be in the manager’s position one day and everything in this post also applies to employees being fired.

Summary:

• Announce it person
• Give honest & personalized feedback (oriented to you)
• Offer your full support

- Domain expertise: Authors are usually experts in the domain covered by the library.  This will ensure that you will get the most appropriate implementation.  A good example is SharpMap.  The main committers are experts in geospacial software.

- Stability: These libraries have the big advantage of being used by other people as well as you, and in many cases, hundreds if not many thousands of developers worldwide.  Most of the early problems have already been encountered by others and fixed by authors.  If they don't fix them, it's a good opportunity for you to contribute and give back to the community!

- Knowledge: You will learn from others’ code and design. Many popular libraries are written by top notch developers and are usually great examples of good coding practices and design.  You will learn by just using them.

- Finance: You save tons of money.  The equivalent of hundreds if not thousands of man days of work for free or, at the very worst, the cost of one man day for commercial libraries.

- Support: Paid libraries usually come with free support from top class developers that you can contact 24h a day.  Many developers of free libraries also provide that level of support.  Exposing your team to these developers will be beneficial for them.

- New features: They will appear automatically, without effort, in your product.  If you are using the reporting engine from vendor X, and vendor X releases the new feature Y, you will be able to provide the new Y feature to your customer at no cost, with very low effort.  You can consider the authors of your libraries as other teams working for you, for free or for very little money!

So, assuming that you are not an expert in the domain, don't have thousands of users, have lots to learn from others, don't have tons of money, will probably need support and resources are stretched, don't reinvent the wheel.  Unless you plan on learning more about the wheel.

Do you think NASA would have been able to send men to the moon if they tried to build the components of their rocket themselves?

This post is not about the potential threat of offshoring for your job, so if you are particularly concerned by that, keep reading this blog, I have few articles directly related to developer job security coming.  Meanwhile, you can check existing content that covers the subject. A few years ago, Chad Fowler wrote a book called My Job Went to India: 52 Ways to Save Your Job, later renamed The Passionate Programmer: Creating a Remarkable Career in Software Development (Pragmatic Life). I highly suggest you purchase the book as it summarizes it pretty well.

The advantages of outsourcing

There are several advantages for local development teams in outsourcing a part of their software projects.

• You have access to talent worldwide: given the difficulty for western countries to find skills locally, access to talent worldwide is a real asset. There are tons of great developers out there waiting to provide you the best.
• Cost controlled to the cent: outsourced projects can be started and stopped very quickly.
• Highly scalable: because of the availability of the skills out there, it's very easy to scale up.
• Empower your local team: if you use outsourcing to empower your local team instead of trying to replace it, you'll get best results.
• You contribute to a better world: a developer you hire in India is able to support a whole family alone with only one salary. If you pay him the same rate as in your own country (which I do often when I'm financially able to), a whole village can be supported.

The only potential disadvantages are directly related to the way you manage them. Over the past 10 years I have outsourced up to 400 projects with hundreds of different providers spread over all 5 continents. Here are the 10 core principles that allowed me to reach almost 100% success rate with my recent outsourced projects. These 10 principles are divided into 3 categories: choice, supervision & strategy.

Choice

Choice is about picking the right guys. Choice is very important and you should spend time on it.

I decided to start over and created a new presentation with the following objectives:

• Based on the official Scrum Guide: the structure is very similar and I attempted to extract only the essentials.
• Not more than 10 slides (without the front and back cover).
• The least text possible to extend the possibility for the presenter to say what is important to his organization without missing the core principles of Scrum.
• Having good visuals to make it attractive.
• A final invitation to read the official Scrum Guide for those who wanted more detailed information.

The result is a ten slide presentation that you can download then use as a powerpoint by clicking on the button below. Images are also available so you can use another presentation tool. It is licensed under a Creative Commons Attribution-NoDerivs 3.0 Unported License (commercial usage & sharing allowed & encouraged). Feedback & suggestions welcome in the comments of this post.

Here are the slides: