4 tips to begin to work remotely

A couple of years ago after a couple of email, some long skype call, a micro-project on Github, ideato hired me without ever having seen me, neither in webcam, neither in real life… and it seemed simply right.


There are a lot of things you can do without being in the same room, but it’s not simple the first time you try… these are the lesson I learned along the way to make everything running smoothly.

Remote working has its own etiquette

We are used to an implicit etiquette in colocated working, but remote working has some different rules. Work from home without pants can be ok (like the Scott Berkun book) but make a Skype call with a microphone without noise reduction is very rude (don’t let me start about not having headphones at all). Likewise, when you have a slow internet connection trying to speak with you can be a real pain. To care about these things is a way to show respect to your colleagues, exactly like having a shower before going to work.

Sometimes you need to meet physically

People and relationships are the first things to care about, and to build a trust between team members and with customers is a much more accelerated process when you pass some days physically together.
In ideato this means three things:

  • when you are just hired you work from one of the offices for 1–2 weeks
  • the kick-off of a new project is done with the team and the customer in the same room for a couple of days

Be explicit with your needs

In a colocated environment people often sees when you are stuck, when you are upset or when you need some help. In a distributed team this is more difficult or requires wider times. You need to learn to make your needs more explicit (that is anyway a great skill for your life):

  • is better to ask twice when something is not clear than to wander in uncertainty
  • is better to ask for a pause (in pair programming) when you are tired instead of loose concentration
  • is better to make explicit when you disagree, because it is possible that no one will see the doubt in your facial expression

Get the benefits

When you work in a colocated team, your social life by day, from Monday to Friday, are your colleagues. They can be intelligent, fun, kind and so on but you will see the same person day over day, for years to come. When you are a remote worker you can choose everyday who you want to see that day, you can find the most inspiring people to pass your day with. It’s not always simple, but it’s a great opportunity you can (and should) take. Remote working doesn’t only mean work where you want, it is even work with who you want.

Originally published on https://medium.com/@fain182/4-tips-to-begin-to-work-remotely-61a5e4126e9e

Programming is the easier part

Essentially, engineering is all about cooperation, collaboration, and empathy for both your colleagues and your customers. If someone told you that engineering was a field where you could get away with not dealing with people or feelings, then I’m very sorry to tell you that you have been lied to. Solitary work is something that only happens at the most junior levels, and even then it’s only possible because someone senior to you — most likely your manager — has been putting in long hours to build up the social structures in your group that let you focus on code.

So, about this Googler’s manifesto – Yonatan Zunger

The Second Law of Consulting: No matter how it looks at first, it’s always a people problem.

The secrets of consulting (1985) – Gerald Weinberg

Anyway writing software is hard, but unfortunately is the easier part.

Your software’s architecture is not MVC

Everything starts with a simple CRUD, you add the migration on the database, create the entity, insert a controller, a couple of views and everything seems fine. Then one feature after another the controller begins to grow, and begin to be more and more complicated and difficult to understand.

Rarely the software you are developing is just a CRUD, even if initially seems like this, every business domain has its own set of rules more or less complicated.

Then you realize that the framework architecture is not really perfect for your software, and you are right, because your architecture and your framework architecture are not the same thing, design your software is much more than deciding if some lines of code should be in a model or in a controller. You probably need classes to represent the concepts of your software domain, that are not pages, database tables and routes (that are the domain of your MVC framework), but maybe invoices, taxes, cost calculations or whatever your domain is about.

There are a few presentations that helped me to understand better how to put in practice these ideas:


Don’t ask your customers which features they want

Some years ago I used a soulseek client for linux to download music. It was an open source software, so when I experienced some bug I report it to the kind developer that fixed the issues. One day I thought that the UI would be much better with an option to hide some components, I opened an issue for this enhancement that was accepted and done. When I tried the updated software I discovered that my suggestion was wrong, now the UI was too crowded, it was much less comfortable to use… I slowly stopped using that software.

It may seem strange that when my suggestion was heard I was not satisfied, but this is not uncommon, because customers know their own pain and needs, but are not expert in suggesting the right solution. They are expert in their problems, but it’s much harder for them to evaluate all the trade-offs that needs to be considered.

To avoid this problem you need to understand why they want that feature instead of focalizing on what they want, and starting from it find the best solution that could satisfy the customer. So for example if you want to know in which direction develop your software, use something like UserVoice is a bad idea, because you will have a long list of features without any simple way to understand the reason they are needed, a better way is to interview some of your customers with questions smarter than  “Which features do you need?”, as Nelson Joyce suggest in this post.