What 7 years (more or less) of Pair Programming gave me

Subtitle: For doing better solo programming

This time I want to write of a big change that occurred in my way of working during this professional year.

The shift from a derived XProgramming methodology, including a strict pair programming centered way of writing code to a more common, solo programming way.

(If you don’t know what XP is or why this guy here consider it so radical and important, take a look at this)

At first I wanted to write a confrontation post between Pair and Solo with an emphasis on what is good in one against the other.

And with Mohammed Ali and Rocky Balboa pictures.

But during the writing of that first version I’ve realized that is not what one is or what the other is but actually what the first gave me of good for doing better the second.

maxresdefault (1)
The Italian stallion doing pair

The Truck Number

Project’s Truck Number = The number of devs that must be hit by a truck before some knowledge on the project is lost.

With pair programming (PP from now on) you, team member, after some time, are more or less the same in terms of importance of your mates.

If from one side this could sound quite depressing and demoralizing as you are not the Expert Of That Thinganymore (and so you cannot display any new fancy title on your LinkedIn profile) on the other it allows to delegates everything could be of your personal concern to whoever you want.

Supposing that a codebase has been fully developed in PP with pair rotation, every member of the team is able to quickly understand any part of it without reading any sort of documentation.

But this is not only related to how to write code but also to who ask for clarifications.

The guy next to you is always the right guy.

In my experience in 3 different teams working on 3 different projects using different technologies and different “visions” on how to write good code, PP helped me a lot to reach full productivity in less than 2 months.

And here for full productivity I mean being able to fully understand the business, the code visions, being able to join tactical meeting and say “can you please shut the fuck up?” to someone (in a polite way of course…).

And about the documentation, most if it was a daily journal that every couple used to write at the end of the working day.

The journal contained the outcome of the day, new ideas, plans for the day after and problems.

Of course there were some specific docs about APIs, procedures and whatever but I can say that the journal was the most important one.

I think the journal really fits with the concept of “incremental documentation for an incremental development” because it’s literally incremental documentation! Take a look at this.

So, enjoy your holidays and leave the code with the guys, they will have fun together!

Shared Codebase and the Team

I don’t know if it’s common or not to every dev to work on a codebase shared between more than 4 people.

I’m currently working on a codebase that is shared between more or less 12 devs (with some random commits from Poland or from the past) and the divisions between the teams and which codebase they touch is more than foggy, kind of shared/not shared I would say.

Is more than common when you find a piece of code that you are not suppose to touch and has not been wrote by someone in your team to just pass over it without caring, and the end is ‘ok’ to think that is not of your concern.

For peace’s sake maybe.


Pair programming showed me that when a code is shitty is shitty and you should not stay silent before it.

And you have to tell to the guy who wrote it why it’s shitty.

Because that code is also yours code, you are working on it and the results of your team depends also on that smelly crap from hell of a giant switch/case.

Simple as that.

Which means that all the team must have the shared target of improve it and improve itself as a devs team.

By studying and sharing knowledge.

Because at the end, after some time, is not only about sharing code but is about sharing successes, sharing failures, sharing skills, sharing commitment, sharing trust.

Being part of the Team.

El Team

(PS: never used Rubocop or any static code quality analyzer with PP, they are good but not really necessary with the right discipline)

From Brat to Senior

One of the best part in my opinion of PP was the mentoring.

And it’s also the one that put me in the most angry work situations ever.

Because when you have to work side by side with some fresh hired post-degree junior dev with overgeneralization and comments mania and you are the sheriff in town it’s always hard to keep your common pace slow.

But you have to, because this new kid is going to be part of your team.

And one day he will be as fast as you.


Ok, maybe this is a bit too romantic but the point is the same.

It’s just impossible to not learn something doing PP, maybe that something is not that much if you are the Senior in the pair but for sure for the other there’s no better way to grow as a developer than to be mentored in this way.

And there’s no better way to understand what are you doing as Senior than explaining it to someone.

And it’s also a great way for getting a free cake-of-gratitude-for-da-masta.


Pair Programming is tiring AF.

Because you have to deal all the time with another head, fighting sometimes, interrupt his sleep others.

And if code quality and the red-green-refactoring cycle have teached me something for sure it’s

Fuck man! Keep it simple!

Huge artifacts with absurd combinations of configurations, flavours, colors are really not necessary to the 90% of the situations.

And for the remaining 10% there’s an external module.

If I have to deal with my pair why should I lose time to implement the most complex solution, test it and fight for this stupid idea?

Probably I just need to detach from the keyboard for some minutes.

Probably I just need to kick his ass on Mortal Kombat X.


These are the results of my experience with this interesting way of doing software in team.

I don’t think is the best way ever but if you are having any kind of problems in your team related to social dynamics or knowledge sharing maybe this jabber I just wrote could be useful to you somehow.



How I moved to Berlin to be a better software developer – The Execution

After the initial period of preparation of which I’ve wrote here, I’ve started with the real juicy part: finding companies offering interesting job positions and apply for them.

For starting the search I’ve defined criteria:

  • Android or Ruby developer
  • Agile environment
  • Placed in Berlin or Amsterdam

And expectations:

  • Over 50k € yearly gross for Berlin and over 60k € for Amsterdam (based on the average salary and the cost of life)
  • Space for self improvement, like conferences budget, study material, “study attitude”, hackatons and all those kind of stuff that we dev use to look smarter.
  • New technologies with which get my hands dirty.

Having these points clear in my mind and on my papers I could be able to do a first filtering and saving time for the first search.

For the search I’ve used mainly LinkedIn and StackOverflow Jobs, wasn’t deluded by them as I found a huge amount of offers all the time from which choose both as Ruby and Android developer.

In order to arrive prepared and with confidence to the interview, I used to have a pre-interview phase during which I’ve retrieved some info about the company.

Info like:

  • Size
  • Age
  • HQ position
  • Benefits
  • Technologies used
  • Developed products
  • Who works there (same with technical blogs and also Twitter accounts)

Discovering this kind of information is super useful for some reasons:

I can easily understand if the environment offers a big space for learning new stuff.

By the size and the age I can infer the stability of the company (Not interested in the 300 employees in 1.5 years startup environment, stable as the family christmas party with the violent alcoholic uncle who promised to not drink anymore).

Some notes taken during an interview, and yep, that’s an olive oil stain. #Italy

I can prepare some specific questions to pose to the interviewer to show interest in the company and some other more generic to understand what kind of benefit they offer.

Over preparing the paper about the company, I’ve also prepared paper about me using the mind-map diagram.

My super secret mind map for replying to the “Tell me something about you” question

This in order to have an ordered, easy to read, mind flow to use when the interviewer asked me the question “tell me something about you”.

I don’t know you guys, but the “tell me something about you” question was freaking me out all the time.

This part has the same exact way of structuring a CV, you have to skip the less interesting parts, focus on the important, be ready to explain all your career shifts and at the same time impress with personal considerations.

At the end my “Interview desk” was composed by the personal mind-map on the left of the computer and the company sheet on the right.

These small habits saved me from the most stressful situations, especially the first ones.

These kind of personal interviews are what I call the “Madness discoverers” because I think there are only two reasons for which someone can be discarded: The interviewer is not really interested or the interviewed is mindfucked.

Well, by keeping away my mindfuckness I’ve always managed to get to the code challenge or to the technical interview.

I don’t have much to say about the technical interviews and code challenge, sometimes I got lucky to be interviewed by someone who knows the jobs for real, asking real question like “how would you solve this problem?” or “Can you implement this rails/android project for me?” some other I’ve been asked for the classical algorithmic solutions to absurd problems to be solved without using language constructs and with a fist in your mouth.

For the first kind you just have to resume your shit very well because the bases are something that get lost over time and for the second, well, Google is always the best friend here.

The important is to always ask for feedback at the end of the interview or code challenge because that will be the gasoline for pushing your job seeking machine to unexpected altitudes.

Stay away from something that seems to easy because if a specific company could look too eager to propose you a contract and making you sign it something suspicious could be going on there.

One time I’ve smelled the “desperate startup with money to give away” when after a catastrophic code interview I’ve received an offer for 60k euro.

The feeling was correct as that company was (and still is) risking to explode in a spectacular way.

After about 6 months and about 10 interviews I’ve managed to find a job here in Berlin as Senior Backend Ruby Developer.

It’s not exactly the kind of job I’ve always dreamed but for someone like me, who comes from a 3k souls place and from a job where everything seemed too easy and not that stimulant, the simple step of moving out and finding something else on my own has been the thing I needed to push myself forward, both as professional and as person.




How I moved to Berlin to be a better Software Developer – The Plan

After 7 years as software developer and a whole life in a 3k people village.

Recently talking with a friend of mine who made my same choice I realised how planned and technical was my migration for moving where I am at the moment.

I’ve lived all my life until the late 29 in a 3k souls village in north Italy responding to the name of Cunardo.

Here: https://goo.gl/3Qbwj9

Trust me, if you are into stuff like climbing, hiking and any kind of adventure in the nature, that’s a location I would totally recommend you.

Not the part of Italy for finding amazing food but still somewhere deserving a visit.

Anyway, the point is that at a certain moment of my not so abroad oriented life I’ve just felt the desire to take my stuff and move my butt to somewhere else.

The best and more safe way for doing this was to find another job and considering my attitude to planning and to seek safety, I didn’t wanted to move without having a safe landing spot on the other side of the jump.

That meant finding another job in the new place before moving there which of course, in my redneck mind, meant planning and preparation of the mind state.

I think the way I’ve done everything could be interesting to someone, for sure to my friend of before, so here it is.


The Planning.


My decision came in November 2015 and became stronger and stronger after the Christmas celebration with my family in the same year, I think you may know what I mean.

The defined target was to find a job in time for being able to move at earliest at July 2016 and at latest at December.

Having a strong goal helped me to keep the focus on the thing and to not lose that strong desire to move.

I planned a first preparation phase without sending any application in order to prepare myself, improve my online presence and acquiring more confidence for the future technical interviews.

Updated my CV

Obviously the first and most important part to attract some possible recruiter is to present yourself with a rich and interesting CV.

Mine was just terrible.

The English grammar was at retarded elementary student level and the contents was barely more than the first working year experience.

After a good job of polishing I’ve reached and interesting and rich 2 pages CV, after 7 years in the same company and 4 main project shifting my experience was interesting and wide enough to overfill it so I’ve just put less emphasis on the less interesting experiences simply based on what I wanted to do (2 years of C# were enough to understand that I don’t want to work in the Microsoft ecosystem).

About the format you can find a quantity of websites explaining how to write your best CV so I will just skip this part.

My conclusion on this is that is not much important the shape or the colours, the content and the emphasis on what is important are the real players in a CV.

Updated my LinkedIn profile

I think LinkedIn is still one of the best platform for finding a job in IT because it’s simply the social network with the most strong “professional aura”.

It’s simply full of swarms of IT recruiters, Tech Talent Acquisition Experts and Whatever Engineer looking for some potential interesting profile so, at least in IT, it’s quite easy to receive some offer and occasion to talk with someone and probably even find a job.

Saying this, I’ve just felt mandatory to me to update my LinkedIn profile in the same way I’ve updated my CV with the different goal of reaching a good visibility point.

At the end it’s mostly about that.

Updated my Github profile

I tended to keep the bigger part of my personal project, big and small ones, in private repositories because I just didn’t felt the need to make them available to the world.

But well, if you have to expose your skills to make you attractive as software developer, this is not the best way to do it.

So I’ve changed the most interesting private repositories to public and wrote a minimal documentation for each one of them.

Hearing some stories of recruiters checking on Github for potential candidates also this seemed something useful to me.

Created a StackOverflow profile

If Github is the best source for checking out how a developer works, StackOverflow is the best for checking how a developer communicates, personal blog excluded.

I think communication is one of the most important skill for a software developer and that’s why I opened my account and started checking out regularly questions and answers.

I can’t say to have contributed very much to the community (while I’m writing this my StackOverflow score is 119, not much but it’s something) but at least I’ve figured out a personal weakness regarding communication and this is still very very valuable.

In addition to the profile on StackOverflow I’ve created a developer story in StackOverflow Jobs, same way as LinkedIn, another way to increase my visibility and the possibility of finding an interesting job.

Created a personal website

Soon I found out how many developers have their own space to present themselves and to aggregate all their internet profiles.

Looking back today to traffic stats of my website this has been for sure the less useful thing of all but at least I’ve created a personal space on which putting my CV and all the referrals to my public profiles.

I thought would be cool to have a simple and easy to remember url so I bought http://about.marcopolita.net for almost nothing.

Easy isn’t? Enough to being able to put Foundation in my CV.

Restudied the basics.

Algorithms complexity and search algorithms, SQL (which is the base for most of us but wasn’t for me), design patterns, SOLID, code smells.

All the kind of stuff that any dev tends to forget once he or she starts working on something economically interesting.

I’ve come back to these stuff because are the basics of the common language for any dev and for this reason a good starting point to quickly evaluate dev’s skills.

“How do you measure the quality of your code?”

“With SOLID!”

“Can you explain me the O in SOLID?”

“Object Oriented!”

“Thank you”

I’ve also needed to redevelop a study methodology and to create good habits to keep the pace of a regular study.

To me writing everything and resuming the book I’ve read during the day helped a lot to develop good behaviours, maybe it’s not the same for everyone but to me just worked perfectly!

So the advice here: go back to study regularly because you are trying to sell you skill and your mind and they work the best when continuously stimulated.


So far this is everything I did for the planing phase of my migration.

In the next post I will tell you on how I started my interview phase and how I developed a feedback circle to keep learning from every interview.

I’ll close this post with an advice on the book that helped me during all the phases of my job search, Soft Skills: The software developer’s life manual, simply the best inspirational book I’ve read so far, useful not only for developers.