Fast learning for ambitious programmers

Learning has been one of my favorite activities since my childhood. I’ve tried many methods and found those that were the most appropriate for me. We are all different and the method that works perfectly work for George could fail with Amy.

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.


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.

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.


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.


The 3 rules to quitting your job with style

Quitting your job can be very difficult.  Just the idea of announcing that you are leaving can be very stressful.  But leaving a company properly is also required to avoid any unwanted negative effect on your career. It can even boost it: every employer you leave is a potential sponsor.

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.


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


6 advantages to using third party libraries over developing your own

You should always consider using existing software components instead of developing your own; even if you think that the latter would be much better. Here are 6 reasons why working with third party projects (open source or commercial) is usually a better choice:

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?

10 tips to manage outsourced software projects

First a few words about the idea of offshoring. Many developers think offshoring is a threat to their job. I can tell you right now that if you can potentially be replaced by an offshore developer, then yes, you have a big problem. You are just a developer. Being just a developer can get you replaced fairly quickly, even by another local developer. To avoid being replaced you must become a problem solver: a problem solver whose specialty is software development.

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 is about picking the right guys. Choice is very important and you should spend time on it.

1. Avoid lowest & highest bidders

The potential problem you may encounter with lowest bidders is obvious. When asked what he thought about as he sat atop the Redstone rocket, waiting for liftoff, Alan Shepard answered “The fact every part of this ship was built by the low bidder”.  What about the highest ones? It seems that there is some correlation between bid amount and quality of the deliverable you will get. However, I found that in most cases, quality was high enough with average bidders and therefore selecting highest bidders would be a total waste of your project budget.

2. Check ratings

Offshoring platforms often give you the rating of previously completed jobs. That information should be taken seriously and used to make your choice. You wouldn’t hire anyone without checking with his 2 or 3 previous bosses right?  On a rating scale of 10, I usually discard any bid with a rating under 9 as well as bidders without any rating yet. Sometimes, I forget this rule for very small project so I can help new providers to get their first rating.

3. Prioritize motivation

Many bidders bid without reading your specifications carefully. I know this because I have posted absurd or incomplete specifications in the past (by mistake) and very few bidders actually reported it. Now I read all cover letters carefully and give more credit to those who actually write about the project itself. Some bidders will write about possible solutions to your problem and others will actually discuss how they will implement it. In practice, I have observed that the most motivated ones tend to perform better than the others.


4. Protect your intellectual property

Seems obvious right?  But still, that’s one of the most common mistakes as most of us completely forget it. Things can go bad and the company you hired for the project can claim full ownership of their work. Or worse, they decide to use what you paid for in their own businesses. Ensure that a proper NDA and intellectual property rights assignment is signed. Most offshoring platforms provide that by default, but if you plan to go alone with no support, this is something you must handle yourself and require before starting work.

5. Refuse custom frameworks

Very often the developers or company you hire decide to use a custom framework or library they have written. Verify it is acceptable to you. Sometimes the development shop will give you full rights on the code they wrote specifically for you but not for their libraries. This is problematic. You have a huge problem if you are so dependent on them that changing trivial things in the application requires you to hire the same development shop. It’s not only about legal stuff, but also the potential complexity of the code that they wrote that makes it impossible for the standard developer to understand. Keeping the potential to continue your project without them is a really important choice that you will want to keep.

6. Impose standards

Make sure that they use standards in the technology of choice. Even if they don’t use specific custom libraries (see previous point), you may face another problem: a specific way of coding that doesn’t meet industry standards and globally accepted guidelines. In the worst case, you could be forced to rewrite everything from scratch to make any maintenance possible. I tend to give priority to main stream technologies for that reason. PHP or .NET for instance, depending on the project I outsource.

7. Review early, review often

You don’t want to discover at the end of the project the code did not meet your quality standards, eg missing comments, missing or poor documentation, poor coding practices, etc. Reviewing the work frequently will allow you to give feedback early in the development phase. Reviewing frequently is also the most effective way to adjust any misunderstandings of your specifications. Each review gives you the opportunity to clarify requirements.

In addition to requesting frequent demonstrations, require access to the repository. If this is not possible, request that you are sent the full source every week for review.



8. Test providers with small projects

Before I give a bigger project to a provider, I test them with one or two smaller ones. I also try to give specific projects to specific providers that have performed well in the past on similar stuff. For example, I outsourced few web design jobs to a provider through a well known offshoring platform and now I work with him directly by email because I know he will perform really well.

9. Accept multiple bidders to reduce risk

For critical projects, I select two or three bidders then I take the best implementation. This works best with very small projects (under $5000). It takes more of your time but it is sometimes required. It was with this approach that I discovered that bidders with motivated content perform better than others.

For bigger projects, you can use a combination of the point 8 and this one: you test multiple bidders with a small chunk of your big project and see which one performs the best.

10. Assemble components

Another way to reduce risk is to outsource components that your core team can assemble locally. One advantage of this approach is that you can easily switch between providers and no one really gets access to the whole thing (reduce intellectual property risks).  But the most underrated benefit of this approach is that your architects are then obliged to develop an open architecture that will help you extend the application or replace whole parts of it painlessly in the future.

Final thoughts

Applying these principles alone is not enough. You will need to fail a few times to really learn what can be written in a simple blog post. Experience gained by practice is the only way to success. Don’t get discouraged if your first 2 offshoring projects fail. Offshoring empowers thousands of teams worldwide and you can do it too.

Scrum in ten slides

When I needed to do presentations of Scrum to executives and students, I started to look for existing ones. Most presentations I found were very good for detailed presentations or training. But what I was looking for was a presentation I could give in less than 15 minutes (or more if I wanted). Most of them also contained out dated content. For example, the latest changes in the Scrum framework were not present and what has been removed was still there.

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.

UPDATE 14th of January 2018: I updated the slides to integrate latest Scrum Guide modifications.



Here are the slides preview:

Scrum Development Team

Scrum Development Team

Scrum Product Owner

Scrum Product Owner

Scrum Process Overview

Scrum Process Overview

Scrum In Ten Slides Intro

Scrum In Ten Slides Intro

Scrum In Ten Slides Credits

Scrum In Ten Slides Credits

Scrum Sprint Retrospectives

Scrum Sprint Retrospectives

Scrum Sprint Review

Scrum Sprint Review

Daily Scrum

Daily Scrum

Scrum Sprint Planning

Scrum Sprint Planning

Scrum Definition Of Done

Scrum Definition Of Done

Scrum Product Backlog

Scrum Product Backlog

Scrum Master

Scrum Master



How to convince your boss

When you need to convince your boss about something, such as upgrading your development machine, the most common mistake you can make is to talk about your problem. You’ll face some situations in which your opinion, your problem, your pain is not really that important compared to all the other issues your boss must deal with. In fact you should never make the assumption that the person you will talk with is going to put your interests before his own. Of course you know many people that will be genuinely interested in your well being, but most of the time, convincing someone to do something you think is good can be very difficult, especially for the introverts. Coming up with a solution instead of the problem alone is not enough. You must learn to focus on other people’s interests and come armed with facts rather than opinions.

Focus on him, not yourself

Focus your argument on your boss’s interests, and avoid mentioning yours. Let’s take the example of the machine upgrade: you want a new machine because your existing one is too slow and you really dislike working on it. Don’t go to your boss and tell him: “I need to upgrade my machine because mine is too slow, it is painful to develop on it”.  If your boss cares less about your comfort than his budget, you will certainly get answers like “Maybe later” or “I’m out of budget” or even “But you are not blocked right?”. Instead, put yourself in his shoes and try to identify what’s important for him.

To help you with that, try to ask yourself how he is evaluated by his own bosses (or customers). How does he report his own performance? In that particular scenario, there are good chances that he will be praised if his team brings new functionality on time and blamed in the case of late deliveries. Your lack of productivity is the pain. Try to tell him: “I need to upgrade my machine because my productivity is really badly affected right now”. Be prepared to get another kind of answer! At best a formal acceptance without resistance but in many cases, a demand for clarification.

Come with facts

Any serious boss will ask for more information to understand your needs and eventually use it to validate their decision. You will certainly meet bosses that use them to cover their own backsides. Don’t wait to be asked for it, and augment your request with facts that demonstrate the real positive impact on the pain you identified earlier. Be sure to use real facts: articles written by an industry authority is not enough. There are good chances that your boss practices critical thinking and coming with blog posts from people he has never heard of will have little effect. For the example we used earlier you could calculate the startup time or the gain in compilation time. You must convert that time into a metric he is sensitive to: money. Multiply the time you save for one or two years by your hourly cost and compare it to your upgrade’s costs. If the gain is real, you won’t have any problem in getting your upgrade.

To increase your chances, be sure that your argument uses simple words to avoid any misunderstanding, especially if you are presenting it to non technical people. Be sure to be concise as well: you would be surprised by the number of people reading only the introduction and conclusion or who ignore any email longer than a certain size.

Formula = Boss Pain(s) * (Real) Facts * Simplicity * Conciseness

More tips

  • You should never ask your boss for permission to use a given development practice. Your boss should not impose a way to work on you but should focus on the result instead. You don’t tell the taxi driver how to drive his car. You don’t tell the hairdresser how to cut your hair. You don’t tell a coder how to work with his code. If you think your code needs refactoring. Refactor it. You are the expert, your team should decide what practices you use. Your boss is supposed to decide WHAT to do and more importantly WHY you are doing it. You should take care of  HOW you build it. If you are in the situation where your boss tells you how to work, you should ask yourself if that environment is really good for you.
  • If you want to attend a conference, try to compare the costs to formal training courses and be sure to put all the advantages such as the opportunity to network.
  • If you need a specific tool, be sure to scan the seller’s website to help you find the facts to make a good case.



Why aren’t developers paid for the value they actually provide?

There are two main reasons. One is linked to the position in the hierarchy and the second one to the very common personality of programmers. You can’t change the former, however, you have more control than you think on the latter.

Most developers are positioned at the very bottom of the pyramid. This is fine: usually, nobody expects anything from you other than writing lines of code.  But many developers are providing much more value than the person just ahead of them, while generally having no possibility to earn more and be paid what they worth. The reason is that in our societies, we still think the salary is bound to the position in the hierarchy.  The analysts or project managers are higher in the hierarchy, so they should be paid more according to the rule.  The problem is easy to spot: position in the hierarchy in many cases is not directly related to the value you provide.

But why do many developers accept to be paid less than they worth? Developers and engineers in general tend to be introverted people. Introverts are often abused by extroverts. Some are aware of their value, but feel they have no control over their destiny, while others have been told since childhood that they worth less than others.  The former are convinced there is nothing they can do and the latter don’t know there is something to do at all. This leads to stagnation. Many extroverts are intuitively aware of that and use it heavily in their interactions with introverts. You need to take advantage of your introvert personality to survive in this world of extrovert people.

As a developer you are responsible for your current situation. If you are really paid less than you worth on the market, you need act on it.

Finally, I want to illustrate how this perverted system can sometimes work against itself.  Salary grades, for instance, can be very effective in many ways, but when poorly used and/or in strongly homogeneous companies (companies with lot of different skills involved), they can lead to very difficult situations for the employer. Below is the true story of one of my best friends.

My friend started as a programmer in a big hospital. Thanks to his hard work and dedication, he quickly became Oracle DBA, which was a critical position in a company where data is both sensitive and valuable.

The hospital worked with grades. Grades are bound to your position in the hierarchy, length of employment and diplomas. Salary increases were automatic and fixed in advance. In fact, he knew how much he would earn at every step of his career.

My friend got an offer to become DBA in another company that didn’t use salary grades. By accepting the offer, his salary could be increased a lot. Because he liked and respected the hospital he worked for, he decided to talk to the boss, asking for an increase. He just asked for what he was worth on the market.

The boss refused. It was impossible because of the grades and the unions would not let that happen.

My friend left.

The hospital eventually hired an external consultant (not bound to grades) and launched the recruitment process. The consultant did not know anything about the infrastructure in place, so his learning curve was huge. The hospital lost lots of money  training him.

The hospital carried on losing.  They could not fine a qualified employee to replace my friend and are still using the external consultant at 5 times what my friend asked for.

That was almost three years ago. My friend is still at his new place and climbing the hierarchy ladder very fast doing what he loves.

The hospital is still paying 5 times more.


How to determine your current market value

What you are worth as a developer is what the target market agrees to pay to have you on board.

What the market will pay fluctuates quickly, just like the financial markets, and can’t really be generalized, so websites with indicators can’t help further than giving you an indication. It may not be in sync with the value you can potentially provide because what the market agrees to pay you is generally subjective.

Knowing what you are worth on the market is an important bit of information you can get using the two proposed techniques below. One for freelancers and another one for employees and other permanent roles.

As a freelance developer, I was always asked by head hunters what was my current daily rate. At the beginning, I used to give a random number based on assumptions in the hope it would be accepted. I quickly noticed that it was always accepted… I deduced I was under market rate. I started to increase my daily rate by 50€ increments for each mission I was offered until I faced some resistance. Resistance is not a formal rebuttal by the head hunter but some sort indication that they want to negotiate. In order to prevent myself being abused by the wheeler dealer type of agents, I always stayed firm on my position refusing any reduction. The accepted daily rate was my current market value.

For permanent roles and employees, you can’t negotiate your salary upfront without doing actual interviews. Here is the process I actually used to fine tune my method and that works very well for employees:

  • Update your resume & post it on the two main job advertising sites in your location or profession. You don’t have to be concerned about the fact that your actual boss may find it. In most cases, it will reinforce your position. The hiring process is a painful and onerous process. If he asks you why you do it, tell him the truth.
  • Try to get at least 5 interviews and find out information on the proposed compensation package. Be sure to include everything: salary should not be your main focus.  Location of the company, nature of the project, work environment, alignment with your career objectives are also things you should consider.
  • Take an average of at least 3 offers that you get, that’s your current market value.
This last technique can be used by freelancers to adjust their estimation of market value. I often noticed that the market value you calculate using the first technique is always a little bit lower that your real market value. This is due to the fact that your market value for a first 3 months contract as a freelancer is lower than what you are worth at renewal date.   The hiring process for freelancer is also very painful and pricey, so it’s often very easy for a freelancer to negotiate a daily rate increase with the agent at that time.   The agent has no extra effort to do to get an additional 3 months commission, so they won’t risk having no commission at all by refusing to increase your daily rate a little.
Please note that this is true when the market is good.  When the market is bad, they have more choice and therefore they can replace you easily with someone else.  Knowing when you can negotiate or not is a skill you will get with time.

7 telecommuting tips for developers

Working from home or a private office is probably the future of knowledge age companies. It allows you to do away with commuting completely and to work in a quiet  and non (over) interrupted environment (if you decide to).  It’s the opposite of the open space office. The gain in productivity can be huge.  Both you and your (smart) boss are potential winners in the deal, not to mention the potential real estate saving for the latter.

Unfortunately, telecommuting is not for everyone though and this may be why it is not generalized yet despite the positive conclusions of the studies on the subject.  Procrastinators may find it very difficult stay as productive as they are at the office. You will also need lot of independence and self confidence.  Some employees may also suffer from isolation.

Procrastination and isolation are the two problems I will address in this post. Other problems related to telecommuting won’t be debated here such as:

  • security concerns,
  • the fact that telecommuters are less likely to be promoted (Kreitner & Kinicki, 2009),
  • potential loss of thrust by managers
  • communication problems with your team

Here are the 7 things I strongly suggest you to try.  I have experimented with this myself during the past 10 years. They provide some tips to help avoid both procrastination and isolation. Disclaimer: you may adapt them to your particular case and not take those empirical & personal observations as a generalization of what to do. I really encourage you to share your own experiences on the subject in the comments.


1. Use a schedule – as if you were in a formal office.

If you don’t do so, you will be tempted to work too much or too little, depending on your personality. Both are problematic long term. Having a fixed schedule will not only create some sort of rule to manage your time, but also help you beat procrastination.

One of the keys to beat procrastination is to have “starters” and avoid “retarders”.  If you like to do non work related stuff such as reading news or browse internet, reserve 30 minutes before and after your fixed work time for it.  When you feel the need to do it while you are into your work time, remember you will be able to do it after.  It usually calms down the need for it and after some some time, the addiction will disapear.  When you arrive at your work time schedule, close everything and start working. This can be hard the  first few (ten) times, then after a while the habit will kick in.

In order to avoid the frustration of having to leave off work in a middle of something, I try not to start debugging or another task that has unpredictable time duration at the end of the afternoon.

2. Replace commuting by physical excercises and meditation/relaxation.

Telecommuting will free up a lot of time, and you should take it as an opportunity to take care of yourself, and certainly not work more for the same salary. Consider taking up physical excercies and relaxation or meditation. It will improve your overall productivity and will contribute to reducing procrastination (Davis & Jones, 2007).

3. Take regular breaks

Since you don’t have your environment anymore to remind you it’s time to take a pause, use the pomodoro technique. I personnaly taking a break of 10 minutes every 45 minutes, but you may setup your own schedule. I use a special software for that called Workrave that I warmly recommend to you.

The pause can be either doing nothing (it’s what I do every other break) and free your mind or do stuff off your computer such as class papers or call a colleague.  In any case, this should occur in another room, and certainly not in front of a computer.  I personally do three minutes of mindfulness or simple observation of what is happening outside (simply being in the present moment).  Feel free to adapt this to what works best for you.

At noon, take a full break and don’t eat in front of your computer.  Some of you may enjoy some cooking time while others may be very relaxed by some time listening to music.

4. Put clear limits between work and your normal life.

This means you have a dedicated office/room you don’t use for your pleasure but only work.  This is very important especially if you have kids.  Your office should not be used to anything else than working. This also means:

  • don’t work on your laptop when you are watching a movie with your family
  • avoid any professional activities during the weekend
  • remove all work thinking and be 100% mentally available for your well beloved

5. Go to lunch outside.

< Isolation is the other major inconvenience to combat if you are affected by it. To avoid isolation a great solution is to integrate a social lunch with others. Try to do this at least once a week.  Even if not with someone else, try to go outside at noon somewhere there are other people.  Why not with other telecommuters?

6. Do co-working.

Co-working is the new trend that involves a shared working environment for people even if they have independent activity. It feels like your office, but it’s not. To make this work, the co-work area must be close to your home.

7. Don’t telecommute every work day.

If you telecommute every work day, you will progressively become more and more disconnected from your company’s culture and people.  It’s inevitable and it will happen.  Be sure to dedicate one or two days on site.  When on site, go to lunch with your colleagues.


I love software development, but I hate doing it for a boss

Unless your boss is really a bad guy, you should reconsider the feeling. If it’s just that you don’t want to work for someone, don’t work at all. Because when you have your business you work for a boss much worse than your existing one: yourself. You will eventually work for many other bosses that really don’t care much about your feelings: your customers.

If you really love software development, if it’s what you are made for in life, creating your own company may be very disappointing. Today you do what you love (developing software) for most of your time. When you are an entrepreneur, you handle many other unpleasant tasks. You have no choice but to increase your work hours to be able to produce valuable lines of code. You will have to do lot of administrative tasks, handle customers (requests, complaints, questions, …), learn legal & accounting stuff, call people, sell your stuff, handle employees (requests, complaints, questions, …), think about tons of things at the same time … all of this increasing your overall anxiety and fatigue.

Here is a quick test to see if you, as a developer, are likely to succeed as an entrepreneur. Answer each question by true or false.

1. I dislike the sales part of the process and prefer to make the product

2. I’m a perfectionist

3. I won’t accept to be paid less than my market value for an extended period of time

4. I really like to take care of the details

5. I really dislike being criticized by other people

6. I don’t have any savings or personal investments

7. I have never been fired

8. I don’t have friends or family that run their own businesses

9. I am afraid of losing all my assets

10. I’m an anxious person

If you answered “True” at least three times you should seriously reconsider creating your company.

If you really want to start your own business, consider creating a consultancy company first, then create your products later. Many successful software companies started like this. It works because the services (much more easy to get money from) pay the bills while you develop your products. If the product fails, it is no big deal.