My experience about consulting and freelancing

Why to offer a roadmapping service for Language Engineering?

There are consolidated habits that have a negative effect when doing consulting.

Lately I have been thinking about how things work during the initial contacts between a client and a consultant: the initial discussion that happens between them, before a contract is signed.

Typically the consultant does two things:

  1. On one hand he tends to enfatically promotes the necessity for his services to the client
  2. On the other hand is interest is in concluding the initial negotation in a limited time

This initial conversation is not perceived as valuable by any side, just as a cost in terms of times. The goal of the client is to evaluate the consultant, the goal of the consultant is to “sell”.

One issue is that it is typically not valued very much by the client, who does not always put the focus necessary to have an in-depth conversation.

On the other hand the consultant wants to be done with it as quickly as possible, because it is basically doing free, unappreciated work.

This is fundamentally wrong because planning is the single most important phase.

What if instead…

I think both sides should invest the focus and the energy to make the best out of it.

The client:

  • should have a discussion about his priorities
  • should figure out if the project is worth doing or not

The consultant:

  • should understand if this is a project where he can provide a lot of value
  • take the time to laid out the different options to the customer, instead of rushing to one he can sell

Roadmap Analysis

After this considerations I decided to start offering a roadmap analysis service. Someone considering doing a project related to Language Engineering can contact me so that we can sit down and look at what kind of benefits he could expect to get, at which cost, and figure out how those options align to his goals.

It is a low committment step for the client who can get a roadmap by investing 60-90 minutes and a very limited amount of money.

If you are interested you can find out more here:


Interview to Erik Dietrich on Static Analysis and a data driven approach to refactoring


Erik Dietrich is a well known Software Architect with a long experience in consulting. His blog (DaedTech) is a source of thoughtful insights on software development. In particular I was very interested by his usage of static analysis and code metrics in his consulting work.

I am myself a relatively young consultant and I thought it would be very valuable for me to hear his opinion on these topics and in general about consulting in the software industry.

So I wrote to him and he was kind enough to answer some questions.


Can you tell us about the typical projects you work on?

It’s hard to summarize typical projects over the course of my entire career.  It’s been an interesting mix.  Over the last couple of years, though, it’s coalesced into what I think of as pure consulting.  I come in to help managers or executives assess their situations and make strategic decisions.

Can you tell us about a project which results exceeded your expectations?

There have been a couple of projects of late that I felt pretty good about.  Both of them involved large clients (a Fortune 10 company and a state government) to whom I furnished some strategic recommendations.  In both cases, I checked back from time to time and discovered that they had taken my recommendations, executed them, and expanded on them to great success.  What I found particularly flattering wasn’t just that they realized success with recommendations (that’s just what you’d expect from a good consultant), but how foundational they found the seeds I had planted there to be.  They had taken things that I had written up and made them core parts of what they were doing and their philosophy.

What make your work difficult? What are the conditions which reduce the possibility of a success?

When it comes to purely consultative engagements, the hardest thing is probably gathering and basing recommendations on good data.

If I’m writing code, it’s a question of working with compilers and test suites and looking at fairly objective definitions of success.  But when it comes to strategic advice like “should we evolve this codebase or start over” or “how could we make our development organization more efficient,” you get into pretty subjective territory.  So the hardest part is finding ways to measure and improve that aren’t just opinion and hand-waving.  They’re out there, but you really have to dig for them.

Human factor

When promoting changes to a software development team how important is the human factor? Do you face much resistance from developers?

It’s the most important thing.  In a consultative capacity, it’s not as though I can elbow someone out of the way, roll up my sleeves, and deliver the code myself.  The recommendations can only come to fruition if the team buys in and executes them.

As for facing resistance, that happens at times.  But, honestly, not as much as you might think.  Almost invariably, I’m called in when things aren’t great, and people aren’t enjoying themselves.  I try to get buy-in by helping people understand how the recommendations that I’m making will improve their own day to day lives.  For example, you can reduce friction with a recommendation to say, have a unit test suite, by explaining that it will lead to fewer late night bug hunts and frustrating rework sessions.

How do you win support from people? Developers employed by the company can get defensive when someone from outside comes to suggest changes to their way of work. In your recent post What to do when Your Colleague Creates Spaghetti Code you suggest using data to support your considerations. How well does it work for you? Do you always find data to support your proposals?

Using data, in and of itself, tends to be a way more to settle debates than to get support.  Don’t get me wrong — it’s extremely important.  But you need to balance that with persuasion and the articulation of the value proposition that I mentioned in the previous answer.  Use the data to build an unassailable case for your position, and then use persuasion and value proposition to make the solution as palatable as possible for all involved.

Static analysis

Is there any typical low hanging fruits for organizations which start to adopt static analysis? Anything that can be achieved with limited experience and effort?

I would say the easiest, quickest thing to do is get an analysis tool and set it up to run against the team’s codebase.  Those tool vendors know their stuff, and you’ll get some good recommendations out of the box.

Do you work with different language communities (e.g., JVM, .NET, Ruby, Python)? My impression is that on .NET there are better tools for static analysis, and maybe more maturity in that community. Is that your feeling also?

With static analysis, these days I work pretty exclusively in the .NET and Java communities, though I may expand that situationally, if the need arises.  As for comparing the static analysis offerings across ecosystems, I’ve actually never considered that.  I don’t have enough data for comparison to comment 🙂

In the Java community there are a few tools for static analysis but I think their default configuration reports way too many irrelevant warnings and this contribute to the poor reputation of static analysis in the Java world. What do you think about that?

I don’t know that this is unique to Java or to any particular tool.  Just about every static analysis tool I’ve ever seen hits you with far more than you probably want right out of the gate.  I suspect the idea is that it’s better to showcase the full feature offering and let users turn warnings off than to give the impression that they don’t do as much analysis.  

A common problem of open source software is the lack of documentation. In your post Reviewing Strangers’ Code on Github you talk about the challenge of confronting with unfamiliar GitHub projects. Do you think static analysis tools could be used to get an overview of the codebase and familiarize faster with the code?

Oh, no doubt about it.  I run custom analysis on new codebases just to get a feel for them and gather basic statistics.  What’s the length of the average method?  How systematically do they run afoul of so-called best practices?  How do the dependencies cluster?  I could go on and on.  I feel like I’d be looking at a codebase blind without the ability to analyze it this way and compare it against my experience with all of the previous ones I’ve examined.

The role of developers

Your next book, Developer Hegemony, is about a new organization of labor and the role developers could occupy in it. Can you tell something about it? And do you think this new organization could be advantageous also for other creative jobs?

In the book, I talk extensively about the problems with and vestigial nature of the corporation in the modern world of knowledge workers.  Corporations are organized like giant pyramids, in which the people at the bottom do the delivery work and are managed by layer upon layer of people above them.  To make matters worse for software people, a lot of these organizations view their labor as an overhead cost.

I see us moving toward a world where software developers move away from working for big, product companies that make things other than software.  I see us moving out from having our salaries depressed under the weight of all of those layers of corporate overhead.  A decent, if imperfect, analog, might be to doctors and lawyers.  And, yes, I think this absolutely can apply to creative fields as well.

To add on to your post How to Get that First Programming Job what is something that the average programmer is not aware of and could improve their work ?

One of the best pieces of advice I think I can offer is the following, though it’s not exactly technical.

If you’re working and you find yourself thinking/muttering, “there’s GOT to be a better way to do this,” stop!  You are almost certainly right, and there is a better way.  Go find it.  And don’t automate something yourself without checking for its existence.

One of the most common mistakes I see in relatively inexperienced programmers is to take the newfound power of automation and apply it everywhere, indiscriminately.  They solve already-solved problems without stopping to think about it (reinventing wheels) or they brute force their way through things (e.g. copy and paste programming).  So, long story short, be sensitive to solutions that may already exist or ways to solve problems that may not always involve writing code.

You are clearly an accomplished professional. Could you share one advice for advancing the careers of someone is the software industry?

One thing that drives me a little nuts about our industry is something I described in this post.  We line our resumes with alphabet soups of programming languages, frameworks, and protocols that we know, but with little, if any mention of what sorts of business or consumer problems we know how to solve.  It’s “I have 8 years of C++” instead of “I can help your team cut down on the kinds of memory leaks that lead to system crashes.”

It will improve your career and focus your work if you start to think less in terms of years and tools and more in terms of what value you can provide and for whom.


I am very thankful to Erik for sharing his opinions. I think there are many interesting takeaways. Two ideas in particular made me think:

  • The changing role of developers: maybe some will still prefer the security of corporate jobs but there are undoubtedly many opportunities for those we are willing to go independent.
  • We as professionals have to raise the bar. One way to do that is start taking more seriously our job by basing it on data, when that makes sense. Data cannot yet provide all the answers, but it can help and it should not be ignored.

Do you agree?

5 things I have learnt working as a Consultant Software Architect


I have been working as a Software Engineer for several years, however I have been a full time consultant only for the last one year and a half. I have a background of different experiences: working for small and big companies, in different countries, getting a PhD. The previous things I have done have helped me immensely on this new adventure, however there are things which are specific to working as a consultant.

Also, over time people started calling me a Software Architect. Now, I am not strong on nomenclature and titles, however it is true that my role has changed. While code is still my main focus I spend more time looking at the bigger picture, considering how software affects a whole organization.

Lately I have been thinking on the specificity of being a consultant and a software architect. In this post I try to distill what I have learnt so far.

I. The customer make the difference

The customers you choose to work with have a large influence on the quality of your life. Working as an independent consultant you acquire the possibility to choose who you want to work with (unless you are struggling). I think it is important to use that possibility and choose very carefully your clients. Working with the right clients can be a joy: you can have open discussions, work together on finding solutions, get feedback and the necessary support for the changes you are working on. When working with the right clients you continuously see things moving forward, this helps motivating you and keep a good pace. On the contrary, less positive, less involved clients make really hard to push to achieve the goals set for the projects. Consulting is a demanding job, and all this pressure, when it is not balanced by results, and the consequent loss of enthusiasm can easily end up taking a toll on the quality of your life.

II. Relevant projects

Working on relevant projects makes a lot of difference. When you work on a project that can really make the difference for a company the resources are found, people find the time to meet you, the decision makers encourage the organization to support the change. It is so much easier. For this reason I prefer to work with companies of medium size, because of the possibility of having a big impact on the people working there. In large companies you could have the same situation when working on a project which is really relevant for a specific department, maybe something that can really affect the careers of the decision makers involved. Sure, working on relevant project also means having to endure more pressure, but most of the time this is the positive kind of pressure, the one that motivates you to push harder.

III. Receptive environment

I really enjoyed the times I worked with American companies because I found them more open to change. In an environment which welcome changes you are allowed to try things, to experiment, to drop what it does not work and continuously improve the processes. I had the chance to work with very different companies so when I can I try to bring in new realities the things I have seen working in other contexts. There are companies that are very receptive: maybe some solutions have to be adapted for their context but they are willing to try. Others instead are used to a certain way of working and are reluctant to consider changes. This does not mean that results cannot be obtained but in this case I feel I can be less useful and certainly I feel these environments as more limiting. Continuous improvement is a joy but it requires all the participants to be humble and receptive. It is very difficult to find or build such environments but they provide such a better experience and so much better results that it is worth looking hard for those.

IV. Humbleness

We all have convictions, things we believe in and which proved valuable in some contexts. We need to be able to re-evaluate them each time we are in a new context. We have to stay humble and ready to learn. Your client, the guy paying you, has much to teach you about his context. You have to learn, and be ready to be proved wrong. Your job is to add to what he knows what you have learnt elsewhere, combining all together to create a better situation for you client. Being too confident of being right make you blind to things you should learn. It does not let you improve, and you need to improve all the time to keep delivering value.

V. Ego

It is never about your ego. In some cases you will have discussions that do not lead to the conclusions you support. In some other cases you will find someone against you for different reasons, maybe because the changes you are proposing endanger his position. As a Consultant you invest a lot of energy in your projects, you believe in them and as a consequence you can become very sensible to what you perceive as attacks to your ideas and in some cases to yourself. You have just to remember that these attacks are not personal. In some cases they are motivated by someone genuinely believing his ideas  are better for the company. You have to listen extremely carefully to those. In other cases there could be other motivations and these attacks could be, after all, not in the best interest of the company. It is your duty to fight those while keeping the environment as nice and productive as possible. If this not possible to support a nice environment you should consider leaving, because it is not about you, it is about the best interest of the client and if there are not the right conditions to do your work, you should leave even if this not your fault. Because it is not about you, it is about the outcome.


I think in consulting you need to refine your human interaction skills and your professionalism. Sure, you need to know your technical stuff, this is a given, but it is simply not enough. From time to time I like to stop and thinking on what I should work next.

And you? What do you think is important for a consultant?

You may also be interested into:

How to recognize dates in PDFs

How an engineer is supposed to survive accounting

One of the “pleasures” of having your own business is dealing with accounting.
Now, to survive I tried a few things like:

One boring thing to do is to organizing receipts and invoices I had to pay: travel expenses, books, conference fees, etc. You get the idea.

Why I need a software to find dates in PDF files

Ideally I would like to have a tool that matches the receipts with lines from my bank statements and generate some report that could make my business consultant very happy.

The first step to do so is having a tool that given a bunch of PDFs can associate dates with them. Once I get dates I know which lines of the bank statement to consider and I can do the match (perhaps considering also the amount).

First step: get text out of PDFs

There are two possible situations: the PDF contains already the text or the PDF is a simple image and we need to recognize the text using OCR techniques.

In the first case things are relatively easy. We use PDFBox to extract the text:

But of course real life brings always surprises. Some PDFs containsone block per paragraph (great!) while others contain one block per letter. That means that we have to look at the position of each single letter and see if it is contiguous to another one. In that case we need to merge them to get words.

If we do not have the text in the PDF we need to employ OCR techniques. I have used tesseract which is written in C++. To used it in the JVM I used the javacpp-presets.

Once we get the block of texts we need to split it in sequences of words. This part is relatively easy but not as trivial as expected because we need to take track of the exact position of each single word. So when splitting a block in words some math is involved to find the bounds of each word.

Second step: recognize dates

We have now a bunch of words. We need to look at those and finding sequences of words corresponding to dates.

Now dates can come in all sort of weird formats. Consider also that I have receipts in English (UK & US), French, German, and Italian.

Let’s see some examples.

First the classical DD/MM/YY:

  • 15/04/2016
  • 18-06-2016
  • 01.04.2016

Sometimes you can find the YY/MM/DD instead:

  • 2016-05-13

The month could be in letters, in any language:

  • May 7, 2016
  • 18 June 2016
  • 22 Aprile 2016
  • 1 juillet 2016
  • avril 12, 2016

It could also be abbreviated:

  • 2016 Apr 14
  • 12 Apr 2016

Of course, there are dates that cannot be recognized for sure because the Americans at some point decided it was a good idea to invert the month and the day in dates. So if I read 2/3/2016 it could either be the 2nd of March or the 3rd of February. It means that some dates are ambiguous.

Third step: decide which date is the date of the order

Now, an invoice can contain many different dates. Consider this example:


One date is the voice of the order (commande in French), another one is the date of registration of the company. This is definitely a date we are not interested into.

There are other examples:



Or again:




How do we handle this cases?

Well, we use a series of heuristics which seems to work in most cases. One of the most powerful is looking for meaningful words near the date such as facture/invoice/fattura, or order/commande/ordine. We can also use the size of the font and the position of the date on the page.

Do these tricks work always? No.

Do they work pretty often? Yes, they do.


Let me first of all share with you my enthusiastic appreciation for the date format chosen by Americans. I find it a really good idea and not at all idiotic and unfortunate. In practice it is a big source of pain and the first cause of error.

Most of my receipts are in the electronic format and they contain the text. In the few cases in which I needed to use OCR it seems to be working decently enough.

In the end I am quite satisfied with this prototype because after some tuning it seems to guess correctly over 90% of the time. Not bad, not bad at all.

Oh, well, I guess I have to go back to my accounting.

Any idea of things you would like to automate to make your life easier?

My first year as a consultant in France

I think many of us are attracted by the idea to start their own business. This was something I was dreaming about for a while until the context made it possible. One year later this is how things are going.

I also wrote about my progress when I was half of the way through my first year: my first six months as a consultant

At the end of June 2015 I left my job at Groupon and I moved with my girlfriend to Lyon, France. I decided that I was going to be a consultant for several reasons:

  • I really wanted to focus on building languages and tools, because this is how I can deliver more value
  • I thought this was my chance to go independent
  • There are startups and interesting companies in Lyon but I could not find the same level of work I could easily find in Dublin and I did not want to settle for something not challenging enough

The kind of work I did

As I started I worked on different kinds of projects. I was interested in everything that was challenging: from building complex web applications to writing software that runs on millions of cars.

Over time I started focusing more and more on Language Engineering. I have worked mostly with Jetbrains MPS, ANTLR, and Xtext. I have been building new languages, editors, simulators, interpreters, test automation, documentation generators and so on. It was very exciting because it meant for me:

  • understanding the challenges of specific domains
  • collaborate with amazing people, enthusiastic and willing to disrupt their development processes
  • building tools that can help people to deliver more, making their job more enjoyable and giving them the possibility to focus on the interesting part, while the redundancy is reduced and the tools support help them reducing the errors


Starting your own business can be a challenge. Doing that while moving to another country could make that challenge even more interesting. If you want to spice up things a little bit more you can move to a country of which you do not speak the language. Extra points if this is a wonderful country with a taste for bureaucracy and a distaste for English. Yes, France, indeed. Facing everything together was not trivial but with patience and the help of my amazing business accountant I managed to survive.

Bureaucracy and language issues were the annoying challenges: they are part of the packet so I went through them while thinking about the interesting challenges. They mainly were about figuring out what I wanted to do and I wanted to do that. As I thought more and more all revolved around two questions:

  1. How can I be more useful?
  2. What I find most interesting to do?

How I feel today


When you start your own business and you keep receiving calls from recruiters you feel a bit reassured: it is comforting to know that there is always a plan B for you. Then, as months go by, you become more and more confident about the path you take. At that point you are able to say “no” to recruiters from a few very well known companies and do not feel bad about it. You smile and you keep doing your thing, happy.

I am not saying that from time to time I am not stressed or that I have figured out everything but I definitely feel happy about my choice. I am so extremely thankful to everyone who encouraged me and supported me. This would be a long list, starting with my friend Luca, including most of my clients and many ex-colleagues and friends.

What I miss from Dublin

In Dublin I could breathe IT in the air and in every single pub. Everywhere you met people from world-class tech companies. They were your colleagues, your friends, the people sitting next to you in a restaurant, the people organizing tons of Meetups. Because of that in Dublin you feel you are part of a worldwide conversation about technology. There is enthusiasm, there is awareness about what is going on in the world.

Dublin is the exception, I think there are few other cities like that in Europe. It would be unfair to ask Lyon to be the same. I have to say that Lyon is an amazing place where to live and it is very nice to talk a walk in the park, order a plate of charcuterie or drink a beer in the sun. But yes, it is not Dublin. Here I have the feeling people are less aware of what is amazing in the rest of the world, or even in the rest of France, outside Lyon. There are many specificities and a focus on what is happening at the local level: local companies, local tech trends and so on. I think this is absolutely normal, it is just that I was spoiled living in Dublin. I try to participate more in online communities and having worked with customers from different cities and countries help me feeling more part of the global conversation.

The future

It was an amazing year for me I would like to keep things going in the direction they are currently going. I want to keep a strong focus on Language Engineering. Ideally I would like to find the time to produce more open-source frameworks and content. I worked on a few pet-projects using Jetbrains MPS and use more lightweight technologies. I would like keep looking at problems from different points of view.

What is your role? How do you deliver value?

Recently I have been thinking about the way I can deliver value in the projects I take part into.

A few weeks ago I have been interviewed by Dave Rael for the Developer on Fire podcast. You can listen to the interview here.

Dave asked me:

What do you do to deliver value?

This is not an easy question to answer, but it was something I was working on for a while, as I was thinking about my consultancy business.

During the last year tools became my obsession; tools are what differentiate human beings from most of the other creatures. We use them to increase our capabilities. I build tools for the mind: editors and simulators that help people thinking about complex problems.

I realized I love to build tools because it means empowering people: you give them means to perform better their jobs or accomplish a specific goal. That seems amazing to me.

During the interview I realized something else: I also perceive myself as a tool. I take part in projects to help other people delivering value. I realized that for me it is really satisfying to work with others: taking their suggestions, their ideas, their critics and act upon them. Filter them through my experience, sure, but never let my experience get in the way, never becoming too self-focused.

To me is crucial to stay open: to remember that the best way I can contribute is by acting as a sort of magnifying glass for the ideas, the energy and the knowledge of the organization I collaborate with. Sure, I can build things listening just to myself, but the magnitude of what I can accomplish by focusing just on my skills and my abilities is limited. If I instead act as a multiplier for the skills and abilities of others I can accomplish so much more.

Being humble is the key. And listening to what people have to say. You could be surprised how many good ideas are floating around, produced by CTOs and interns. If I can help translating some of them in reality, perhaps adding a quirk or two in the process, then I can deliver a lot of value to the companies I work with.

Aside from that I talked a lot about language engineering in the interview 🙂

A template system for Google Docs: Google Drive automation and PDF generation with Google Execution API

My consulting business is getting more steam and I am starting to be annoyed by the administrative steps. Basically when I need to prepare a new invoice I have to:

  • copy I template I have in my Google drive
  • fill the data
  • download a PDF
  • archive the PDF on Dropbox
  • send the PDF to the customer
  • if the customer is in the European Union (outside France) I need to fill a declaration for the “Douane”. This is what is called an “intrastat” declaration in some places

Now, this is not the most exciting and creative part of the job so I automated some of the process.

Right now I have a script that can create a copy of the template fill it, generate the PDF and download it. I still need to automate the part in which I upload the PDF to Dropbox, but for now I could just copy the PDF in my Dropbox local checkout.

Google Developers Console

Now, this is the boring part and it is easy to miss something. I will try to recollect from memory what I did and wish you good luck. After all I do not want to make things too easy. That would be boring, wouldn’t it?

First, visit and create a project.

Then add permissions to that project, selecting the Google Drive API and the Google Apps Script Execution API.

Finally go to credentials and generate the “OAuth client ID” credentials. You should get a file to download. It is a JSON file containing the credentials for your project.

Good, enough with the boring bits, let’s start to program.

Loading the data

For now the data for the invoices is kept in a simple JSON file. Later I could store it in a Google Spreadsheet document. At that point I could trigger the invoice generation when I add some data to that file.

Right now instead my script take 2 parameters:

  1. the name of the file containing the data
  2. the number of the invoice I want to generate

So the usage scenario is this: first of all I open the data file and add the data for the new invoice. Typically I copy the data from a previous invoice for the same customer and I adapt it. Then I close the file and run the script specifying the number of the new invoice to generate. If I need it I could also regenerate an old invoice just by running the script with the number of that invoice, without the need to touch the data file.

This is the code which parses the arguments and load the data:

An example of data file:


Finding the template and cloning it

In my Google Drive I have a directory named DriveInvoicing which contains a Google Doc named Template. Here it is the first page:

Screenshot from 2016-04-12 21-47-21

The second page contains uninteresting legalese in both French and English: French because I am supposed to write my invoices in French, given that I am located in France. English because most of my clients do not speak any French.

The code to locate the template file is this:

Copying the template and filling it

First of all we create a copy of the template:

Then we execute a Google Script on it:

Finally we download the document as a PDF:

The script which fill the data is this:

This is created in the online editor for Google Scripts:

Screenshot from 2016-04-12 22-02-58

What we got

This is the final result:

Screenshot from 2016-04-12 21-49-22


Code is available on GitHub:

How to recruit freelancer for software development: where to look for them, how to find and choose candidates

Many people come to me with questions about a project they want to have developed. Perhaps they have a business idea, perhaps they need some software to simplify their lifes. I know directly a few of them, others have asked hints to someone who directed them to me, others met me at some meet up or found me online, maybe reading this blog.

Many of these people do not have a background in software development and have struggled to find someone able to answer their questions: what do you think about this idea? Is it possible to implement this? How long would it take? How much should I pay for it?

Over time I started to realize how incredibly hard is to find good freelancer software developers for people who are not programmers themselves. Where to look for them? How to select them? The unfortunate truth is that out there it is a sort of jungle and most people in the business are just not very good. While any good developer can recognize someone who is very poorly prepared in less than ten minutes this is not the same for many clients. They end up picking someone because is the only one they could find or he could talk the talk (but not walk the walk) or perhaps because it offers a low price. I understand this: when you do not understand the differences in quality what else can you consider if not the price?

I believe that software is becoming more and more important but not everyone can or should be a developer, so more people have to learn how to deal with developers. They have to learn how to describe what they need, find freelancers, selecting them, understand how much to pay and communicate with them during the development. The problem is that they have no idea how to do any of this!

I started growing more curious about this problem so I read some material online. I found an incredible collection of idiotic pieces of advice. My favorite is the one which suggests to pick some questions on Stack Overflow and ask those questions to candidates. The idea is to check if the candidate reply exactly as in the best answer on Stack Overflow. Absolutely brilliant: asking about something you do not understand and hoping to hear the exact some words so that you can mark the answer as correct. What can possibly go wrong with that?

Many other suggests to just go on and pick the candidate asking the lowest fee. For my experience you are not going to be pleased with the results you would get with this strategy.

I was so frustrated with all of this that I thought I could write myself some common-sense advices, something based on my experience as developer. Those are simple ideas which are obvious for software developers but not so much for many clients who need to buy software and do not know how. After thinking on this topic for a few weeks I selected 10 steps to follow to get your project developed for you and I started sharing the in-progress pamphlet on leanpub. It is available there: 10 Advices to hire freelance software developers.

I am thinking to rename it:

10 Steps for hiring and working with a freelance software developer

How to find, select and communicate with a programmer to get your project done

Any suggestions on a better name?

My first six months as a Software Engineer Freelance

I think many of us are attracted by the idea to start their own business. This was something I was dreaming about for a while. One day the context was right and I jumped in. Six months after this is how things are going.

How I ended up being a freelancer

At the end of June I left my job at Groupon and I moved with my girlfriend to Lyon, France. I decided that I was going to be a freelance working remotely for several reasons:

  • there are startups and interesting companies in Lyon but I could not find the same level of work I could easily find in Dublin
  • I could not speak very well in French and my ability to write it was even more limited
  • wages are considerably lower in France compared to Ireland, UK or Germany, especially outside Paris
  • I thought this was my chance to go independent

Starting your own business can be a challenge. Doing that while moving to another country could make that challenge even more interesting. If you want to spice things up you can move to a country of which you do not speak the language. Extra points if this is a wonderful country with a taste for burocracy and a distaste for English.

Customers: the real question about freelancing

There is one big fear that stops most people from becoming a freelancer: the fear that you will not find customers and you will not be able to make a living.

I really understand that: I also had this fear. However you have to realize that this is a fairly dangerous fear which leads to poor choices so you have to fight it somehow. I became a freelancer only when I had two things:

  • savings to face a possibly long slow period
  • stuff in my bag of experiences which could help me land gigs, eventually

I also had a secret weapon: a good friend who has been asking me to work with him on some projects for several years already. We had worked together on open-source stuff before (such as libav and plaid).

So, I was still scared but I was not terrified. In the worst case I knew I could get a job in Lyon, after having improved my French.

Let me stress it once again: it is very important to reduce the fear of not having enough customers because the best thing you can do is to refuse customers you are not excited to work with.

This is important because if you start working on unexciting projects you will do a poorer job, you will learn less and you will have no time to accept or look for great projects. Yes, I know you are afraid, but this is not a reason to do poor choices.

You can read more about dealing with customers in my post Good clients, bad clients: how to recognize bad clients and how to deal with them.

Your business, your rules

Getting started it is natural to try staying as flexible as possible to get more work in. However you should build your set of rules over time and stick to them.

Take a moment and think what are the aspects that matters to you the most, what do you need to do a good work and making work a pleasure.

You could establish all sort of rules for yourself but typically there a few which are common:

  • a minimum rate below which you are not willing to work
  • some clauses which you need on your contracts for your own protection
  • requiring an advance
  • limits to the kind of work do you want to do
  • working with a specific kind of clients

Personally I started by setting my minimum rate: as many passionate developers I contribute enthusiastically to open-source for free, there is no need to give away work also to companies. It is also true that normally companies who are able to get the most out of your work will be the ones willing to pay you more. Money somehow is a proxy of how relevant your work could be for someone. I think that doing relevant work is very important.

I never sign a contract I am not really happy with and I always ask for an advance for a work.

I also decided that I will refuse working with customers who are too pushy: most customers try to get the best possible deal and this is perfectly ok, but if someone try to get a 70% discount, demand unreasonable conditions and in general does not act professionally I just walk away.

It is not very straightforward to define the kind of work I accept to do: I love all kind of technologies and I do not feel that anything is “below me”. What I try to focus on is the contribution I can make to a project: can I really make a difference? The answer is probably yes if:

  • it is related to a domain I know well: language design or microservices
  • it is about technologies that I master: Java or parsers for example
  • it is an innovative project: not a classical copycat project. I think that in that case my experience with tons of different stuff can help me get results faster

What I loved

In these months I had the possibility to do different work. This is important to me because I have different skills and I believe that by facing always new problems I can learn more tricks. I think that being able to find similarities between different kinds of projects and cross-pollinate ideas from very different contexts help you identify solid and exciting new solutions. I had the chance to work in research, small companies and very established companies and in each situation I learned something I could reuse. Also having lived in Italy, Germany, Ireland and France helps because from each country I learned a way of working a bit different.

I also had some time to work on open-source projects such as JavaParser, JavaSymbolSolver, WorldEngine and others. This year I became the person with more commits on JavaParser and I created JavaSymbolSolver from scratch. Together with Bret Curtis and some great contributors we grew WorldEngine into a much better project.


I also got free stickers and a t-shirt by participating in Hacktoberfest!

I could organize my time. I was often working long hours during the week and many week-ends but I had the possibility to take a couple of days off, jump on a plane and visit a friend. That is invaluable to me.

What could be improved

Next year I would like to blog more regularly and to start speaking again at local meetups and conferences. I am not yet comfortable enough to give presentations in French and I do not think that presentations in English are that common in Lyon so probably it would be easier to give speeches outside Lyon. I have not yet definitive plans on that. I will also attend the Web Summit in Lisbon: I won two free tickets thanks to my open-source contribution. That was great!

I would also like to write about software development (a book perhaps?). I am thinking about a couple of things but it is definitely something that require more thoughts. Let’s see what come up.


It was a great experience so far and I am very happy I did this choice. As a freelancer I think I am in the position to make a difference in different interesting projects and that is simply fantastic.

I was lucky enough to have the right context to getting started so everything went smoothly and I did not have any bleak period.

In the future I would like to write a post about the difference in making business in France compared with other countries.

Are you think about becoming a freelancer? Did you already dive in? How things are going?

Good clients, bad clients: how to recognize bad clients and how to deal with them

I think that one of the core activities of freelancing is to interact with other human beings.  In many cases it means to build productive working relationships with people who you have not met before and doing it quickly.

In building relationship between professionals we have to agree on some rules and to stick to them to protect us and the customer. In most cases the freelancer and the client are two honest persons who just do not know each other, so they have to build and maintain trust to make the relationship work.

Building trust: you have to get off on the right foot

Rules help to build mutual trust especially at the very beginning: if a customer you worked with for a long time is late with a payment you just write a kind remainder and keep working on the project without worrying. If you are working with someone for the first time, he did not agree to give you an advance and the payment does not arrive by the time it was expected you will become nervous, you will start to suspect something is wrong. As a professional you will strive to keep your committment untarnished but as a human being a lack of trust could start to grow. For this reason I think that we have to realize that the initial contacts are very important: the other party will be able to judge us only by our actions towards them, not by our life of honest behavior. Of course unexpected things could happen: they have to be limited and prevented from happening when possible, but when it is not possible they have to be communicated.




A little story about a customer of mine

Let me share a story: one of my client was based outside the European Union and we agreed I would be paid by wire transfer. Unfortunately while I was expecting the second payment there was a strike of bank workers in his country and international transfers were blocked because of that. This was not an ideal situation but in that case the customer reached to me, explained the situation (also providing me links to articles from trustable sources) and he looked together with me for alternative ways to make the payment. The method for the transfer costed me a little more than the fee I would have paid to receive a wire transfer and I had to go through a slightly longer process to get the money but this is part of life: things happen and you try to find the best outcome given the situation. In the end I was very happy I was dealing with someone willing to work with me to find a solution: when difficulties arises being working with a good or a bad client make the difference.

How to recognize good and bad clients?

The tricky part is that it is often difficult to recognize bad and good clients: you could be an optimist and justify some behavior from your customer, or viceversa you could be too suspicious and think bad of someone doing an honest mistake. However sometimes hints just sum up and you realize you are working with a bad customer. Some examples?

Good clients pay you on time

Bad clients pay you late or do not pay you at all.

Good clients communicate to you if they are not happy about something.

Bad clients surprise you and sneak changes in the contracts.

With good clients you can afford to be as flexible as needed to get things done and to do whatever you need to help them.

With bad clients you have just to stick to the contract.

Good clients appreciate when you stay flexible and accomodate their requests.

If you bend your rules with bad clients they will just try to squeeze more and more from you.

What to do about bad clients?

As first thing we should realize that sometimes we are making a client become a bad client: we can act to improve the relationship, build more trust and make a pleasure to work together. My strategy for that is to be as clear as possible in my requests (e.g., I need the contract signed by this date, these travel expenses should be reimbursed, etc.) and being open and clear when a behavior of the customer makes me uncomfortable.

Once you have several hints and you start to be sure you are dealing with a bad client you have to decide why you are in business: if you are in business to get as much money as possible then you have to work with whoever you meet. I personally think that being rich is having the freedom to choose what to work on and with whom, so if I find a client abusive, if I think he is not trying to build a balanced situation I stop accepting more work from him.

There are no magic solutions to bad clients and if your economic situation requires to do so you will have to accept working with them. In that case try to protect you with well written contracts and try to stay as civil and professional as possible: you have to protect your professional image also when working with awful customers.

However, if you can afford it, just smile and say “no, thank you”.


I have been lucky in my life, not all the time but most of it: I had fantastic colleagues, talented advisors, incredible managers. Since I started freelancing I also had very good clients. I have been lucky most of the time, but not all the time and therefore I have to apply best practices also to managing customers.

As professionals we have to work to obtain the best possible outcome under any circumstance. It is also a reality that there are people with whom it is just easier to build relationships and build something positive: there are good and bad clients out there. While a great professional could produce positive results with either of them still it will have a much more pleasant journey when working with good clients.

Working with a good client is such more satisfying and I think it leads to build better products.