Written by Federico Tomassetti
in Consulting

    Normally in this blog I write about technical stuff: mostly tutorials and ideas on software design.
    Sometimes however I share what is going on with my professional life: I wrote about what I learned working at TripAdvisor, and about my first year as an independent consultant, before I co-founded Strumenta.

    Over the years I had many different experiences, which taught me a lot. I picked things here and there but there are three simple rules that I realized helped me a lot in acting as a better professional. They helped me obtain better results when working in a team and creating a better environment for collaboration.

    Some or all of these rules could seem obvious to some of you. I heard variations of them since I started my career. However, it is very different to hear them and to interiorize them. That’s way I would like to share the reasoning behind these rules. I would do so as a reminder to myself and, who knows, maybe as something that could help someone in the early stages of their career.

    Rule One: Share Credit

    I know that sometimes we put a lot of work and a lot of skills in what we do. We fight to get a result and so when we obtain it we feel it is exclusively our merit. Well, it is very rarely so.

    We are always working in environments that are larger than us.

    One or more of these things could have happend:

    • we reached a certain result in a project because a client spent years preparing the condition for that project to start and succeed,
    • we did a great job because our direct manager protected us from external distractions and created a situation where we could do our best work,
    • a colleague helped us by picking up some work, so that we could focus on this particular project we liked so much.
    • an experienced colleague could have given us a tiny suggestion, that helped us steer the project in the right direction from the beginning and we never realized from which pitfalls he saved us.
    • we received useful comments in code reviews, or simply our colleagues took the time to work on reviewing our code in a timely manner, permitting the project to move forward.

    There are for sure a lot of people around us that enable us to do what we do.

    How did you get where you are?

    On a more general level. I believe in the saying It takes a village to raise a child. To me it means that whatever achievement we obtain, we obtain them because of the support and the teaching we constantly received from people around us.

    As a student, did you ever ask for help to a more seasoned professional? Did you ever receive advices? Did someone give you a chance that lead to greater things later on?
    Probably yes. We are inevitably the results of our environment, and we had to receive so much before we were ever able to give something back.

    This does not mean that our results aren’t our own and the effort we put, the skills we developed or applied do not belong to us. But we should not get a false sense of confidence: we can get results in an environment that permit us to get results. Sometimes it is hard to see it because someone worked hard to eliminate all roadblocks on our way. As consequence we are under the impression the road was always straight and clean. Well, it probably wasn’t. So be grateful and share credit to the people surrounding you.

    Rule Two: Take the Blame

    It is important to take the blame for your mistakes.

    I understand that this is difficult, especially for people at the beginning of their careers or unsure about their position.

    When you win the internal resistance and you admit your own errors you will realize one thing: nothing bad happens. People will not have a worse opinion of you, you will not get fired or miss your next promotion. At the contrary, people will know they can trust you to be upfront about your mistakes.

    I think that taking the blame is also useful to disarm others from the possibility to use your mistakes against you. In my experience when you point out your mistakes and take responsibility the consequences are minimal or none. Things are much worse when you keep your mouth shut or try to actively avoid the blame for your mistakes. Sooner or later people around you will realize that you are responsible for some mess. They could rub your face in it or not, but anyway your reputation will suffer.

    Another advantage of taking the blame is that it fosters a better environment. One where people are not afraid and take more responsibility for what they do. Over the long run this lead to people working more carefully, which is a good thing.

    …but that will not work at my company

    I understand that some environment makes this particularly difficult. However, I would invite you to consider this: if you are in a negative or even toxic environment either you change it as much as you can with your behavior or you leave it. If you don’t, it will inevitably affect the professional you are. If you have to believe less professionally because of the atmosphere your co-workers create or because of the culture of the place this will change you over time. At the very minimum it will limit who you can become. Being a professional means also taking the difficult decisions necessary to improve. Either you do or you don’t.

    Rule Three: Spell Out the Problems

    I know, no one likes to be the bearer of bad news. It is something that if not pleasant and feel awkward. Nevertheless, I think it is very important to point out problems. Not only that; we should also keep repeating them until we are sure that everyone is aware of them.

    You should shout from the roof all possible existing problems but also all limitations in solutions you create. If you solve a bug with a patch that will work until a certain corner-case is met, be absolutely sure to point that out in the clearest terms possible. Otherwise this thing will bite you later.

    What happens when we are upfront about problems?

    Why is so important to point out problems? For various reasons:

    1. Someone could be able to find a solution or could start planning for one
    2. Someone could explain to you what this is not actually going to be a problem, removing this from the pile of things you have to worry about
    3. This communicates to your team-mates that they do not need to feel anxious from hidden problems coming from you, because you are not the kind of person hiding the dirt under the carpet

    The last point is crucial for me: when people start hiding problems you develop the feeling the problems could be hiding anywhere, that you need to double-check everything. If instead someone has an history of being very upfront about issues you know that the moment he is silent there is nothing to worry on that side. This is a big relief.


    I did not just hear these rules. I saw people living by them. As a young professional I was afraid to taking the blame when I did a mistake. This was the case because I feared it could have impacted how I was perceived by colleagues and managers. I did not stress problems for the same reason. It took a lot of examples to learn that it was possible to live by these rules.

    I have seen some of my best people I worked with living by these rules in very different environments. After years of experiencing that I could finally see the patterns more clearly. Of all the places one that I particularly remember for having a very positive environment, one where professionals were acting as great professionals all the time was TripAdvisor. Let me tell you once again: I am very proud I worked in that company and with that people. So, my advice is: keep working on being someone that your colleagues will be proud to work with.

    Download the guide with 68 resources on Creating Programming Languages

    Receive the guide to your inbox to read it on all your devices when you have time

    Powered by ConvertKit
    Creating a Programming Language

    Learn to Create Programming Languages

    Subscribe to our newsletter to get the FREE email course that teaches you how to create a programming language