DEV Community: Martín Pérez

So your manager has asked you to be on-call. Now what?

Martín Pérez — Wed, 11 Nov 2020 12:20:52 +0000

I still recall the first time I was dragged into a live incident call. It was many years ago but I still remember it as it was yesterday. That terrifying feeling of being pulled into a live conference full of strangers that will probably expect from you to be the superhuman expert that you are meant to be and not a scared person more strangled than ever by an overwhelming impostor syndrome. I mean, are they even amicable at all? Are they pulling you into this call for blaming you and the rest of your team? Will you even have a job after today?

I'll be honest. Looking back and reflecting on that time, I did everything I could absolutely wrong. Took me ages to understand what was the issue. Spent an awful amount of time trying to debug it. Spent even more time writing a patch and deploying it. And, yes, it did work, and it fixed the problem. But it also left very clear that I had many things to understand and improve about incident management.

Let's be clear. No one. Absolutely no one, likes being on-call. Who wants to be awaken at 2AM for troubleshooting a live production issue? Nobody. However, truth is, modern engineering practices ask for engineers to be on call. And believe me, it is a good thing. In my whole career, there hasn't been a place where I have learnt more about our products, about our operations, about other teams and even about the source code I write like on incident calls.

So, when your manager announces a new on-call policy that is going to include the engineering team. That is not bad at all. But, on the other hand, it is very important to set some rules. There are definitively things, that your manager and the company need to guarantee for this to be good and not rather become a toxic measure.

Let's look into the things that the team should demand from an engineering leader to be met before getting on-call:

1. Off-hours on-call time must be paid

This one is simple and there isn't really much to add up. On-call time is work and it must be paid. Let's repeat it. It must be paid. That should still hold true when you don't have to deal with incidents.

Being available for on-call purposes demands you and your beloved ones to be ready for interruption at any time. You will need an internet connection and some device, likely a computer, nearby and of course to be ready to sacrifice your leisure time for supporting your company. The bare minimum ask incident handling time paid, but bear in mind that, although with different rates, most companies will pay employees for just the sake of being ready to take incident calls. Finally, usually incident handling time should be paid at an extra when compared with regular working hours work.

2. Prepare runbooks for your services

A runbook is essentially a set of clear instructions that help to operate a service. Part of a runbook is usually the process that determines the steps to take in case something goes wrong with that service. With a properly documented runbook, a person not familiar with the service itself can still have good changes to address the issues by going through the troubleshooting steps.

Things like "what to do when service foo takes 100% CPU?", "What are the steps to redeploy service bar", ... That's the kind of information you want other people to find in those runbooks, so you don't have to actually jump into the call and have to those things yourself.

3. Training and guidance on how to resolve incidents

Knowing what to do and what not to do while you are trying to troubleshoot a live urgent issue is very important. And spoiler alert, usually the solutions will be either rolling back or redeploying.

Most of the time, services go down due to unexpected change. It could be that a new version of the service has been deployed and it has a bug. Or perhaps deployment happened 10 hours ago and a resource leak has slowing degrading performance. But once change is identified the most obvious solution is to roll that change back. Sometimes you won't be able to roll back but perhaps there are some toggles or config variables that you can turn off before triggering a service redeployment to get the issue fixed. Some other times you will need to scale up your service, vertically or horizontally, either to buy time or because it really needs due to healthy natural usage growth.

The above solutions have something in common. They are based on understanding changes, not on understanding source code. You don't need to be an expert in the internals of some particular piece of software to operate it. This sort of thing, that wills sound totally natural for an ops guy, is a fundamental paradigm shift for a software engineer who is used to mentally map everything that happens in a service to lines of code.

Learning and being trained on how to operate successfully a service in a simple manner is a fundamental ask that any manager or leader should address and help its team with.

4. Have a clear changelog

If we are saying that change is the main cause for failure, then having a clear list of all the changes that any system goes through seems like a very basic and fundamental thing to have.

A changelog can be implemented in many ways. It ca just be a wiki page, or it can be done via JIRA tickets, or perhaps via Github issues, or just built from a list of notifications that are dumped into a Slack channel that people can go to for checking what has changed. You can go as fancy as you want. What is really most important is to have a centralised place where anyone can find what has changed with clear timestamps and if possible also authors.

Needless to say, those changelog entries shouldn't be just meaningless titles. Whatever relevant information it can be added to the changelog might be crucial for others to understand the change, and for being able to deal with failure more effectively. I know, it is kind of silly and obvious. Adding as much information as you can. But it will likely be the difference from you being woke up at night to help troubleshooting something that nobody understand vs your same self having wonderful sleepful night

5. Schedule a periodic on-call handover meeting

Having a large team for incident handling is great. A large team means that it will take longer for any individual engineer to be on-call. For example an eight people team, doing one week on-call shifts, implies that every engineer will be on-call just one week every two months. That's not too bad. But it also means that is very easy to loose context when you happen to start the on-call shift. What has happened last two months? I mean... did anything happen last week?

Doing a weekly handover meeting where the person exiting the shift explains to others how the week has gone and what were the main problems observed will give context to everyone in the team about the overall service status and most importantly it will give the person going into on-call some expectations for the next week.

6. Leaders must be on call, but they also must not

Sometimes things will go south. That's unavoidable. And at those moments, where things are tricky and problems become very hard to solve, and the calls to be made are big, well that's usually were escalations and leaders are needed.

Typically, on-call rotations on reasonably large systems are tiered. You will have a first tier with software engineers familiar to the daily service activities and operations, then you would have a second tier, maybe with technical leaders and engineering managers, then third tier with directors, and so on.

I honestly can emphasise with a person feeling that leaders should be in those incidents. I mean, who wouldn't be pissed if you are on a call at 2AM while your boss is sleeping, right? Specially if the causes for the incidents might be due to leadership choices like postponing technical debt grooming and such things.

But at the same time, I do also believe that having a single tier or having leaders as part of the normal rotation is not really a good thing. It might be something needed when the team is small. For example when a two people team will greatly benefit from having an additional person on-call. But when the team is larger, then it becomes less-relevant to have the engineering leader regularly on-call.

In fact, it is way, way more important that the engineering leaders are always on-call, but just when needed.

7. Have internal retrospectives

When incidents happen, it is important to do some retrospective thinking on why that problem happened. Some teams choose to write RCA ( Root Cause Analysis ) documents and then having some internal session to analyse an incident.

Another technique that has become very popular with time is to run a 5 Whys Session where multiple stakeholders, internal or external, might meet to go into a process where candid questions are asked trying to find reasons for what has happened.

Whatever the format, it is very important to bear in mind that in these sessions, blame is never the final goal. Mature organisations know that failure happens every day. The most important goal for any retrospective, whatever the shape, format, or stakeholders involved, is to understand why and to learn to preventing similar incidents from happening again. That's also why it is important to get clear action items as an outcome from any retrospective and make sure those items are prioritised over any of the ongoing regular tasks.

8. Address technical debt

An Error Budget process is key to make sure incidents won't happen again. More often than not, change originating incidents is caused by engineering debt. Debt can be technical, as for example some code that is causing performance issues or some algorithm that has become too inefficient due to increased usage.

Debt can also happen due to inadequate processes. Examples of process debt are teams letting code in that does not meet quality standards, perhaps because code coverage rules are not enforced, or static analysis is not executed, etc. Process debt can also comprehend usual practices used for releasing software safely but that, for whatever reasons, the team hasn't embraced yet. Practices like launch canary releases first, or using feature toggles to gradually turn features on or to turn features off when something goes wrong, or having the capability to change configuration dynamically without redeployments. All those practices can help to avoid incidents or to react much faster when incidents happen.

On an error budget process, when a certain service or team does not meet the expected quality thresholds that have been set, then that team must commit to stop development of any functionality that is non related to the incident. It does not matter how important that functionality is or how big is the customer asking for it. The team needs to stop whatever is doing and start working on addressing the technical issues. That might take just a couple of days, but could also take many weeks. Having a process that allows team to focus on technical debt is healthy. Although, caution, it should not be driven by incidents alone.

9. Rely on multi-timezone support teams.

Getting to an end here but this is probably the luxury ask and certainly something that not every team can afford. But when you can, it works great. When you trump all the points given above, it becomes easier to have engineering teams in other timezones for covering multiple services. When you have done your homework setting clear rules and processes for handling failure and for dealing with incidents, and when everyone is trained and knowing what to do, then supporting services that you are not aware of is not a scary thing any longer.

And when that happens, you don't need the core service team to be the only ones supporting a particular piece of software. It is now possible, provided you have the size and the budget, to have other teams in other different timezones doing on-call in such way that engineers can have their night-shift covered and they only have to do on-call work in working hours.

Again, this is common in large corporations but really a luxury ask.

Wrapping up

Being on-call might be a scary thing but it should not be if you have the support of your company and a good leader. Reflecting back, I can only see my on-call time as level-up experiences. For a software engineer, it is unbelievable the amount of knowledge ande experience that it can be gained by escaping our personal source code bubbles and jumping into trying to solve our customers' pains.

At least that has been my experience. Hopefully you found this essay useful. Best of luck with your on-call!

Photo by Obi Onyeador on Unsplash

Measuring high-performance engineering teams from a value perspective

Martín Pérez — Thu, 25 Jun 2020 16:47:36 +0000

Is your current team a high-performing team? I believe this is a fundamental question every engineering lead should be asking themselves. Thankfully, over the years we have discovered many metrics that hint us whether our teams are high-performing or not. I'm going to bring some unfortunate sad news though. Sometimes, high-performing teams don't equal to unexpendable ones. It is extremely important for any leader to understand what is the value that their teams are providing and be able to quantify that value in terms of business impact. Otherwise, without you noticing, your high-performing team might be the perfect candidate for being dispensed in the next re-organization within your company.

Maybe you are already doing OKRs, or perhaps reporting SLOs and SLIs. But are those key results and indicators really showing that your team is high-performing and valuable or just showing that is high-performing?

Common Engineering metrics

Let's look at some of the usual indicators for engineering teams.

Code metrics: Here we find things like the number of tests, code coverage, code smells, duplications/bugs/vulnerabilities over time, etc. Static analysis tools provide this sort of information. In my view, these are excellent metrics to understand how good your engineering practices might be and how committed to quality your team is. But there is very little business value that we can take out of these.
CI metrics: These metrics can be obtained from your build server and version control system. Indicators like the number of successful/failed PRs, successful/failed builds, build time, commit-to-deploy time, deployments to production per day, etc. These are good indicators for how efficient your engineering pipeline is and they do also provide good information on how fast you can deliver changes into production but again from a business point of view, there is not much we can scratch here.
Operationability metrics: Metrics like number of successful deployments, number of failed deployments, number of rollbacks, etc. Very useful again in terms of operability insights. But as with the previous ones, it's doubtful if they provide much direct business value.
Service metrics: Typically the metrics used for reporting SLOs. The number of server errors, average CPU, average or percentile latencies, and so on. These are invaluable for running a service. That's unquestionable. But on their own, business leads can't do very little with that. Yes, surely your CFO understand that a faster service is better, but how to translate that into money? That's a different matter.
Project Management metrics: Here we get a bit closer to what our directors like to see. The time that takes to complete epics or initiatives, velocity statistics, burnt-down completion rate, bugs over time, etc. All these metrics help to identify how our teams are completing the work they have assigned. They try to measure team efficiency, or at least project management efficiency.
Support metrics: How many production incidents did we have? How many of those are critical? What are your MTTR, MTTA, MTBF times? How many production bugs have been reported by customers? These are just a few examples of metrics related to support a product in production. Most business owners will agree that these definitely have a direct impact on the value of their business.
Engagement metrics: Some engineering teams need to or are built for the purpose of giving service to others. Whether these teams build frameworks, build APIs, or build documentation, they share a common factor which is, their performance largely depends on how others feel about their work. Here, we would use metrics like a Net-Promoter-Score, the number of promoters and detractors, or simply gauges on how others rate your service in terms of support, documentation, availability, etc. These metrics are helpful to understand how others value your work. These are extremely important but I also believe they do provide no quantifiable business value that we can use.

A fictitious example

So, let's put ourselves in an imaginary scenario. Your director has decided to own a project to optimize some internal flow that everyone complains about. It's a great improvement on the internal way code is handled and generated. Your team will drive this project. Everyone agrees, not just within your team but outside it, that it will be huge if you deliver that project in time. Your team does great and gets high notes in all the metrics described above. After 6 months the project is completed as it was promised. Everyone is super happy.

Then, as it happens every 12 months, directors go to an off-site and discuss the state of things. Your director comes from that offsite with some bad news. The business is not doing well. Managers have gone over the different projects executed by the different units over the last year. Other product-related projects have been very successful. They are not that well-executed but the projects were customer-facing and product management sees those as essential.

Your director feels very sorry about it but there are going to be job cuts all across the different units and your team will be impacted more than others. Your director couldn't fight against all other teams which could communicate clearer business value gains in their projects. In fact, none of the product managers could understand what you and your team have been working on during the last six months. You feel very frustrated. How can these folks be so ignorant not to see the obvious?

Ok. I know. The tale above is likely too extreme. Certainly, I hope it is. But it tries to show something that is generally true within most engineering teams. Many teams don't know how to measure the real value they are providing. Engineers, we do perfectly understand that large code coverage is a good thing because it demonstrates people are working on tests and worrying about those corner cases. We do know that a low rate of build failures is good because it means people are being dedicated to quality and also that a low commit-to-deploy time tells us we are deploying very frequently and can react very fast, or that a low rollback ratio means customers are not experiencing issues. We know all that is great. But, engineers, we are not that good at translating those great things into dollars, euros, people effort or other metrics like MRR, Churn Rate or ARPA to name a few. That is where the disconnection point is.

Translating effort into actual value

Those teams that know how to express the value they are providing are going to be in a better position within the corporate ladder than those that are unaware or can't communicate that value. But how can we change this? How can we translate all the cool things our engineering team is doing into an actual value that business folks can understand?

I'm afraid there are no magic recipes. At least not one I know of. It all depends on what your team is doing and what measurable metric you might avail of.

If we look back at our fictitious example. The work our team did was essentially alleviating other workloads from different teams. How much? After some digging, we could have found that every time the process we did optimize had to be executed it would take three different teams to spend each of them 1 person-month of work. After doing some analysis we also might have found that this same process had been executed more than 30 times over every year during the past 5 years. With the changes we did, this process now only requires 5 minutes of work. That's actually a lot of value!! Let's do some basic math:

30 times x 3 PM = 90 PM spent last year due to inefficiencies
Our team did spend 5 * 6PM developing that solution.
With the new process the new cost is 30 times x 5 minutes = ~2 hours and a half work every year
We could also assume that 1 extra PM is needed to support the solution during the next years

Those simple numbers tell that the new solution will save 78 person-month (previous cost minus new cost) every year. That can easily be translated into money. Not only that. The previous numbers also tell us that as soon as the new process is executed 10 times the cost that we have incurred in would be already completely amortized.

That information should be enough to defend the project and the value of our unit. This can be used not only retroactively, but it is a great exercise to defend future engineering investments.

Value measurements

So, what are measurements we could use to reflect value? Here are some that come to mind:

Time saved: Person-month sucks as a predictive metric but it serves the purpose here. If you run a project that is saving people's time, then do a calculation on how much time you are going to save them with respect to how things are right now. The difference will be the value you are providing. Subtract the cost you are approximately going to incur in and that will tell you how long will it take to make the project self-paid.
Direct income: Sometimes our efforts might win large contracts. Don't take the bait when your product manager tells you that big corp Acme will sign up once your project is delivered. Most PMs will tell you that. You should really find it out. After releasing the project, you should ask your management how many customers really bought our project due to the newly released shiny feature. Surveys and some other tools can help with that. Was your feature the primary decisive factor? Then it's fair to take that customer's income as yours. Was your feature a secondary factor? Then you should weigh how much your feature might have contributed to win the deal, if contributed at all. It's important to go through this exercise to understand whether your team is an important player within your organization or if on the contrary, you might have a problem with your current situation.
Indirect income: Indirect income might come in non-obvious ways. For example, maybe the latest UX remake caused an increased number of sign-ups and a reduction in the churn rate. This is indeed very difficult to measure. As in the previous case, customer feedback is essential to understand how the different features might have impacted on the overall solution. Evaluating what has had an impact on the business and what hasn't is crucial. Usage can be used to extrapolate the value of some of the features. Tools like amplitude and many others can be used to tell if people are using features. Usually, popular features are adoption drivers. If you can agree on a quantitative measure for those actions then you will be able to get an indication of the value. What it will always be clear is that something that does not get used has very little value.
Cost saving: Some initiatives are meant to reduce costs. Whether we are migrating from an expensive commercial database to an open source one or we are moving from a SaaS telecommunications vendor to another different vendor, those initiatives will provide cost savings but will also carry some cost. The difference is the value we provide. If you are saving millions by switching database vendors and you are not making your managers aware of it, then you need to act immediately.
Shared service: This is a flavor of time saved. When your team is implementing a shared service that everyone else is meant to use, you are incurring a cost that will save others. How much would it cost for all others to do that work? That's roughly what you will be saving to the company if you subtract your own cost. For example, your team is implementing a feature toggle service? How much would it cost to others to implement feature toggles by themselves? How many services do you serve? The more the services, the larger the value you provide.
Error reduction: Errors usually come with a cost. Whether that comes from customer loss or from our operations team trying to help to failover some service to a secondary datacenter, it does not matter. There is a cost. The key here is to calculate how much is the cost of the particular pain that we are fixing. How much did it cost this in the past? Are we reducing the number of incidents? Then we should agree on an average incident cost and estimate how many incidents we will reduce with our improvements.

Those are just some ideas. I would love to see any others you might have if you want to share them in the comments section.

To finalize. A high-performing team is great. It makes us, engineers, proud. I love sound engineering practices. But it is important to make sure that everything we do in our team is sustainable from a business perspective. It does not matter how exciting is the new thing we might be doing if it is not going to provide any value. Similarly, it does not matter that you are doing everything your product manager tells you to do if nobody ends up using it. Value metrics are crucial but also a healthy exercise for engineering leads to reflect, to think whether they are providing value or not, and to consider their current role within the organization itself and act if that role needs to be changed.

Picture by quinoal @ unsplash

The 3PM code review rule

Martín Pérez — Fri, 11 Oct 2019 15:27:44 +0000

Recently I was giving a talk at a local engineering group about the software practices we do at our team and it did surprise me how many people came back saying they did like a lot this very little thing we do to accelerate the whole pull request / code review protocol.

In reality, the idea is super simple:

Every day at 3PM is Code Review time.

But, wait, how does that exactly work?

For us, it essentially means that at 3PM we have scheduled a fixed 1h slot in everyone's calendar. This forces everyone to stop what they are doing and to dedicate that time to peers that are waiting for valuable code review feedback. Having the time officially allocated helps people not only to remember but also to realize that code reviews are very important for a healthy delivery pipeline.

Before this practice, we had a few problems with code reviews:

People forgot about code reviews. Initially, we tried to insist on pushing peers to spend some time in the code reviews. To insist. It worked at first but soon both ends would forget. The reviewee would jump into some other story and forget about telling reviewers to get into action. On the other hand, the reviewers would instinctively wait to be pushed interpreting that otherwise, the pull request was not that urgent to be reviewed.
We do gate PRs by having two approved code reviews. Sometimes people that were too deep into their own user stories would play sneaky and wait for the other reviewer to do an initial review hoping that they can jump into reviewing much later once the initial details have been sorted. Of course, sometimes both reviewers would also try to play that game. You know how it ends.
As a consequence of the above points, most of the user stories were closed later in the sprint. Burndown charts had very usually the shape of a big step. But more importantly, as the sprint end approached, people would rush into trying to get their stories reviewed while at the same time they were being pushed to review other stories and rushing to fix review comments. This usually ended with code with lesser quality than expected to get into master.
As an engineering lead, I try to keep an eye on reviews. I always look at the critical ones and give feedback but I do defer approvals to the team. Very often I was being asked to review without anyone having looked at the stories yet. Usually, the reviewer would do this as an attempt to move things that got naturally stuck by the way we were working.

Now with the new policy in place, I believe we got people into some much better habits. These are some comments on how the team is executing the policy and some personal observations:

The 3PM review policy does not prevent people from doing their code reviews at any other time. People can do code reviews earlier, or even later. But at least from 3PM to 4PM they need to stop and do that work.
Code review time, which is one hour for us, can be used to review either alone or in a group. Now, very often the reviewee and reviewers will join in a pair reviewing session to discuss the changes. This enforces some good dynamics as before there was no fixed time for meeting and people did rarely pair.
If someone does not have anything to review that day then the time can be used on any other tasks.
Since we have established this policy we have managed to keep a much shorter queue of open PRs. Burndown charts still have steps. I will not lie. But these steps are not as steep as they used to be, especially at the end of the sprint.
The hour is totally arbitrary. We did choose 3PM because we thought at that time people would have spent already a good amount of work on the daily tasks and would be a good moment to do a context switch.
Finally, now I do have to review much fewer PRs. I can keep an eye on the critical ones without being asked to review for expediting things.

I don't think this technique is original. In fairness, I got the idea from somewhere that I swear I can't remember, we just formalized into a rule. The 3PM code review rule.

What about you? What techniques do you apply to try to expedite code reviews? Would love to learn from others.

Photo by: Sarah Pflug

Want to run a kata at your company? I did it. Here are some tips.

Martín Pérez — Tue, 28 May 2019 13:35:21 +0000

So, a month ago I was visiting my company headquarters and I encouraged my team to hold a TDD session. TDD is kind of hard for many developers. It is a habit, and habits need to be exercised. If you don't exercise it frequently then you fall back into the old and unproductive behavior: write - manual test 10 times - write a test.

Tip 1: Sell it to your manager first

My manager was a bit skeptical. The conversation was a bit like this:

[MGR]: "What is that half-day long session you guys are having?
[ME ]: "Oh, it's a TDD session, we will settle ground on common test practices and then approach problems trying to write the test first."
[MGR]: "What type of practices?"
[ME ]: "The usual. Writing small tests, enforce single responsibility on tests, make sure proper names are used, make sure there are comments, and so forth"
[MGR]: "Don't they know such things? They are senior developers".
[ME ]: "It does not matter how senior you are if you have been exposed to bad practices your whole life".

I was a bit surprised by the seniority question, and it is actually a great point. But the truth is over my last years managing different types of senior developers I found that it really does not matter how many years of expertise you have or how solidly you deliver features. Even for myself, if I don't practice I keep accumulating bad habits. Moreover, as new people join from different companies and with different habits, it's always a good idea to settle some common ground in terms of code practice expectations. So the TDD session still looked like a good idea to me.

Tip 2: Set rules and expectations

You are the master of ceremonies. As such, you should facilitate the session. I am guessing, or at least that was my case, that most of the folks in your team might not be that used to how a kata works. Some rules and limits should always help to put some order. In our case, for example, we started limiting the exercise in time. We would use a maximum of two hours. Teams will also be pairing in teams of two or three people and the person typing would switch every 20 minutes.

We also did hold an Intro to TDD session before starting with the Kata which helped to set what were the expectations for the quality of the tests written. Hence when doing the Kata we would be practicing how expressive our tests were too.

Tip 3: Add some incentives

Add some incentives. Some incentives should make that exercise more fun. Perhaps some prize to the team that finishes first, or maybe having a sponsored lunch if all teams finished their kata which always helps to have more experienced people helping people not that familiar with these exercises ;)

Tip 4: Avoid the usual katas

If you are regular at agile events and familiar with TDD then you surely are familiar with names like Fizz Buzz, Bowling, —Game of Life_, etc. Likely, you are also familiar with all the nice kata directories out there. But you know what? Do you want people to be offended? Then choose one of those.

Don't take me wrong. Those katas are great and some are nicely targeted to certain skills. But those do only work on a neutral ground. A ground, with no roles or grades, where everyone works on different companies and industries, where every attendee is passionate about agile practices.

But getting your coworkers who might even be wondering what are they doing there at a "kata" and making them code a Fizz Buzz could be a recipe for disaster. Some could directly take it as an insult. Pretty likely some will find it frustrating as approaching these exercises is usually not as easy as it seems and then will blame the irrelevance of the exercises chosen as silly algorithms for recent graduates.

In my opinion, if you want the practice to be less aggressive it is simply better to work on some real-life problems for the people you are going to work with. This requires some work on your side. You will have to choose real problems. Things you are facing every week. In my case, for example, I did choose three real user stories we had to complete that same week and divided them amongst the team members. Each team would approach that story as a kata trying to solve the problem with a complete TDD approach.

You might actually find that some user stories are not easily testable. And that is a bad smell too that might need to be worked out. If stories are difficult to test, then how can we expect our developers to embrace TDD?

Tip 5: Have solutions ready for your kata stories

You will have to be ready to help with the user stories you chose. Again, this is work on you, but it will pay off. Some teams will get stuck with their tests, so you need to know how to unblock them. This is pretty important to avoid frustration so in advance to the exercise you really need to know how to approach the test. In the end, the test might be written entirely different from what you had thought of, but if people are having difficulties with the testing practice you need to be ready to unblock them.

The least you want is to approach a problem with TDD and find out that the teams cannot address it. Again, TDD is great, but it needs to be reinforced, and reinforcement comes with success, not with frustration. If you are finding hard to find user stories that are easily solvable for you, then I would argue there is some technical debt in the testing infrastructure that needs to be tackled first.

Tip 6: Repeat. Make this a habit

If this is a one-off thing then, well, it's not bad, but it's not good either. As mentioned before, practices need to be reinforced, otherwise, they will not become habits. You don't need to go to extremes like doing a Kata every week. But I believe that having a team activity for practicing writing code together is something really good and promotes some nice habits like teamwork, pair programming, settling on common approaches, etc.

So definitely if you have the chance, try to do this more often. I'm trying too and hopefully, we will have another one real soon.

I hope this helps you! Good luck!

How to create effective Pull Requests

Martín Pérez — Tue, 09 Apr 2019 15:38:49 +0000

Pull Requests, from now on referred to as PRs within this article. That unsexy but necessary step that sits between your wonderful shiny new commit and your master branch. PRs are unsexy because we actually know that our code is neat and tidy, and we don't want those evil code reviewers to come up with all those useless and nasty comments about our beloved codebase, or do we?

Of course, we do. Code reviews are not evil, in general :) Code reviews are a way to spread knowledge across the team and also help to get several extra pair of eyes into your code. Some people may argue that pairing is an alternative to a code review. And that is right, as long as you are good with only one person of the team knowing about your piece of code. And yet, you might pair with someone for a few hours and then that person can still come up with something totally different to what you worked initially in. So, code reviews are an opportunity to make sure everyone is on the same page and also to get quality feedback for your work.

Pull requests' quality is often overlooked. A badly written pull request can not only cause friction when it comes to code review ( arguments, fights, time wasted and ultimately burn down), but it also decreases productivity and increases the chances to introduce issues in production. Clean and tidy Pull Requests contribute to a faster pipeline, quicker code review cycles and increase the overall quality of our product.

So, here are some tips on how to write effective Pull Requests ( Note that the samples in here are totally fictitious).

Make sure your PR is supported by tests

This is a big one for me. Probably the most important. If you have to pick one tip, pick this one.

All of us, are busy people. Right? We have tons of stuff to do. Then, have you ever received a Pull Request that is changing code (i.e. not a trivial typo-fixing type of thing) and has no tests? I have. Plenty of times. And these days, my reaction to those is pretty much the same: "Please, can you include some tests that prove that the change you are doing is indeed verified".

Why am I being so harsh? Well, really because, with no tests, I am actually forced into doing a big effort trying not only to understand the logic but also to figure out any minor thing and dependency that could actually break the code. This might happen especially if you are the subject expert in some area. In such case, there is a considerable chance that you are always going to get these type of PRs where the submitter actually just wants you to verify the overall approach and the source code before even bothering to write any tests for it. Needless to say that this is bad. Quite bad. Don't take me wrong, there is nothing bad on asking for help, but there are better ways to do it like asking for a pair programming session or doing an unofficial code review in pair. That way, the reviewer's time will be used more effectively than with an out of the blue totally asynchronous PR.

By writing tests along with your PR you are providing the reviewer actual proof that you have gone through the exercise of testing the code yourself. The tests you write should go beyond the usual happy-path scenarios. Again, by providing negative testing, you are giving proof that your homework is done and that you have been thinking about what might happen when things go wrong. Tests will also help you with your logic and they will surface hidden issues that might go unnoticed.

Most importantly, tests will provide not only proof but also great documentation for your reviewer about what you are trying to prove and why you think you are indeed proving it. And both things, the why and the how provide fundamental information to decide whether the PR is valid or whether it might be incomplete or just missing some part or be missing entirely the point.

Write a meaningful PR title

This sounds kind of trivial but it's actually common and overlooked a lot of times. Especially when working on a single-person project when you are rushing and don't put that much attention on the details. But again, if you think about the future, chances are people will join later and if you don't put much attention on the titles then you end up with things like this:

Can you tell what I was doing there? Well, you can tell I was refactoring some code, doing some bug fixing, but you have absolutely no clue about what the changes were. Now, that is a fictitious example. But, as a general practice, something like that implies having to click on each and every PR to figure out what is going on. Imagine that you are new to the project. Exhausting.

A title needs to be short, concise but at the same, it needs to communicate the overall purpose of the change. If you cannot summarize your PR in a single title, then it's very likely that your change is doing too many things and at that point, you should reconsider whether you should be splitting your work into multiple PRs.

Write a meaningful description

PR's descriptions should be meaningful. Bear in mind, that after the PR title, the next thing the reviewer will see is the description. A good PR description should tell us:

. What you are trying to do.
. How you are doing it.
. Why you decided to do it that way.
. How you are supporting this PR.

For example, compare these:

With this one below:

So whereas on the first examples there was no description, or some cropped description from the PR title or a totally useless description pointing to some demo happening in the future, here, the engineer gives some good context about the problem, explains why this PR was needed and why it has been done that way. And finally, it also provides some information about why the PR is safe and the tests attempted. Probably not perfect, but certainly more useful and explanatory than the other examples.

Avoid huge and tiny PRs when possible

Who does not fear the mythical 100+ files PR? I've done some of those and I'm not proud of it. Huge PRs are usually the result of long-lived branches, big refactorings, heavy new functionality or simply could come from extremely creative contributors that have that ability to create complex code and tests very quickly. However, none of those are real reasons justifying huge PRs. Even if we are fortunate enough and have highly skilled engineers that can create code as fast as a kid can devour a candies box, that does not mean our reviewers are going to have that same mental ability to process PRs with hundreds of modifications.

On the other hand, if every code change is going to be a single PR, then that puts a lot of burden in the code and PR review process and might impact development with constant interruptions. Unlike with huge PRs, there are occasions in which there is no other choice than having a tiny PR as maybe we need to change just one file and very little of it. That's totally fine. What we should not do is, for example, to create five different PRs with one file each for some functionality that is cohesive enough and logically related and hence could fall within the same PR.

I will not set an ideal PR size as I don't think there is one, but I believe as soon as we go over 20 files it starts to be complex for a reviewer to actually have a mental map with all the changes and consequences that these changes carry over. Having tests alleviates this issue, but before sending a PR that is starting to feel large then we should ask ourselves if we would be comfortable reviewing that many files or not. In case we feel that it would be too much for ourselves then we should be considerate with our reviewers and divide the PR in smaller related chunks.

Apply Single Responsibility Principle to your PRs

Single Responsibility Principle is in some sense also applicable to PRs. Just as you want a module, class or function to have and to encapsulate a single responsibility, you want your PR to encapsulate and own a set of logically interrelated and encapsulated changes. In other words, you don't want to have a PR containing multiple logical changes that are not related.

One typical problem with merging non-related changes in the same PR is that if the code review takes longer than expected then all the functionalities that are enclosed within the PR will get blocked. So, imagine an urgent bug fix committed along with a non-related PR that has several parts that need review. The important bug fix will get blocked while the PR is fixed. Whereas if you submit two separate PRs then the quick and easy bug fix can proceed to the master branch while the longer and more conflictive PR gets reviewed.

Typically this issue might happen, many times involuntarily, when you are always working from the master branch on your fork. That is perfectly fine if you are going to deliver sequential changes. But as soon as you foresee multiple parallel changes then you should consider switching to temporal local branches on your fork which will allow you to submit multiple independent PRs.

Avoid void changes

Changes like new lines added or removed, spaces, tabs, etc. add which don't change the file at all, are just adding noise to your PR and make it look longer than it is. You should avoid this as such changes contribute to your PR to look messier and careless. And you are not careless, are you? Honestly, when I get a review where I see those patterns my internal self becomes immediately wary about the whole PR. I don't know why. It's probably one of those psychological patterns, like those that explain that the food that looks neat on a plate tastes better. In a similar way, PRs that look bad from their cleanliness look worse overall and raise alerts.

Avoid formatting changes

Similar to the above point, at least certainly in the psychological aspect, you should avoid doing code formatting changes in your PRs. If you need to do changes in formatting then open a PR solely for that purpose and discuss it with your peers. Formatting changes like replacing tabs with spaces, or replacing spaces with tabs, or changing brackets positioning, or splitting a line into two or two lines into one, all contribute to diverting the attention from the reviewer into topics that are not related with the PR itself.

Guess what changed above? Yes, you guessed it right. Nothing, or almost nothing, or certainly nothing relevant.

Remember, the reviewer is likely already doing a good mental effort to follow up with your PR and trying to understand what you are trying to do. The less you want to do is to add confusion by introducing irrelevant style changes.

Make sure your code is commented. Especially the difficult parts.

Communication is key for software engineers. I cannot say this often enough. And while I totally agree with clean and self-documented code principles there are many times that naming and structure are not enough and the engineer needs to provide a few lines explaining what the code is trying to do or why it was done that way.

Again, you need to put yourself into the skin of the reviewer and think: "If someone gives me this same code to review, would I burst into tears?", "Would I be able to understand this if I had absolutely no context of what is being done?". We probably don't have to go to extremes like "a toddler should understand it" but hopefully you get the idea.

The easier and the more effective we can communicate what we are doing, the quicker the PR will be reviewed and the quicker mistakes will be detected. So actually spending some time trying to communicate on an effective manner will have a huge return one way or the other. Needless to say, after this step the code ends documented, which is a huge bonus when new hires come in. Everyone loves an elegant and nicely documented piece of code.

Provide context providing own PR review comments in advance

Most source code management systems like Github allow you to review your own PRs. You can take advantage of this to provide feedback in advance. That is, information going beyond the PR description and that might be contextual to the task itself, or may be specific to certain files, or might be just general context, external comments, history, etc.

For example, comments like "This is the asynchronous task executor approach we discussed in the Start of Sprint the other day", or "The metrics aggregator thread that Joe suggested is implemented on this file", should not be in the code itself and might be too contextual to be on the description. However, adding these as comments can provide important and useful context for the review and we can put them just as our own code review attached either to the top of the PR itself or to individual files.

Leverage external tool integration

Some tools understand and can link pull requests with the existing tracking system. For example, in JIRA if you include the ticket id within the PR title then JIRA will auto include all the PR information within the ticket itself. This is extremely handy to track the different tasks and map them with actual engineering work.

Most of the project management tools have some sort of integration with Git, so go ahead and make use of it!

Bonus: If you integrate your source code management tool ( e.g. Github ), with your collaboration tool (e.g. Slack, Webex Teams, Microsoft Teams...), and your PRs are tidy, then you get a wonderful team space containing all the code changes ready for your team to review, or to just be aware of, or just to revisit back after a few months to check something in the past. All for free, as long as your PRs are treated well.

Treat Pull Requests as valuable documentation

A PR can be a very important source of documentation when created in a responsible manner. It provides a meaningful description of what you are trying to do. It does contain a set of changes that are meant to achieve your task and it includes a set of tests that verify that indeed the requirements are met.

When done right, existing engineers or new hires can go easily through the list of closed PRs for a nicely historical segmented view of the most notable changes that have been introduced gradually into the project by the team or by an individual person over the last few months or years.

However, for being valuable, Pull Requests really need to be as good and tidy as our code is meant to be.

Hopefully, the tips above will help you with that. Thanks for reading.

Finding a remote job is hard, here are 6 tips for having a better chance

Martín Pérez — Sat, 23 Mar 2019 16:33:44 +0000

As with my previous post, 10 years of remote working this is what I learned so far let me start with the bad news. If you are not already remote or if you are not very senior, you should re-consider your search, as you barely stand a chance of finding a remote working job. This is not something many of the sponsored blogs, or remote work sites, will tell you. Think about it, these places live from growth and capturing as many job applications as they can. But I have to tell you, and hopefully, you won't mind and take it personally.

So, why is that there is little chance for the non-senior or not already remote? Well, it is really a mix of several things. Remote companies are interested in people that have remote experience because remote working is hard and not for everyone. Also, experienced people are theoretically easier to ramp-up and would come up to speed much quicker. Remote working positions are also scarcer which means there are fewer companies for applying to, and many candidates competing for the same position. If you are lacking both seniorness and remote experience, your application might be discarded straight away and at best it will be at the bottom of the list. And let me tell you something, that is bad.

Many inexperienced people do apply to job offers without really thinking about the consequences. But when you get discarded from a company, there is a considerable chance that you might not be reconsidered for other positions. Usually, your record stays within their hiring databases. And as I mentioned, there is not that many remote companies for applying to as there are regular companies. So you need to be careful with your remote job applications as you don't want to waste all your bullets too soon.

If you are already remote and senior, this post is not for you. There is little I will add to what you already know. If you are senior and willing to work remote, this post might help you to get more chances, but if you are ready to find a job just go to the usual websites remoteok, HN who is hiring thread, We Work Remotely, remote.co, github, Stack Overflow, RemoteTechJobs, etc. There are quite a few websites and referenced everywhere. I'm focusing here alone on the software ones.

So, let me try to put here five things I think they might work for getting a remote job. Honestly, they really apply to most jobs, not only remote. But if you want to go remote, and you don't have experience, then either you do 1) below, or you need to become really really special, which are 2) to 4). Let me expand on this.

1. Relocate then go remote

This is by far the most common way to go remote. It is the simplest. Does not require any extra learning effort but it is also the hardest in consequences. Nevertheless, most of the people I know that are currently remote, have done it this way. You find a job you like, in a place you like, and you move there. You move with your boyfriend, your girlfriend, your family, or just alone. You spend a few months working hard, maybe years. People start trusting you. You become relevant, well known, a friend, a core part of team. Then, at some point you bring the news. "I want to move back home. These are my reasons. I love this company and would love if I could work from my place." If you have done a great job and the company is flexible, they will allow you working from home.

But hey WARNING, make sure you do some research before moving elsewhere. You must check that the company is indeed flexible with regards to working location. Maybe, you can check whether there are other people already working remotely. That would be a huge bonus point. Beware that some companies have remote working banned so you should definitely skip those. If when bringing the topic the company refuses to let you work remotely and there happen to be other several people doing remote work, then you should consider why. Is it that your team is not flexible? Is it that your manager dislikes it? All those factors are things that you will have to learn and act upon. Maybe you have to change teams. Maybe you have to leave the company. As mentioned above, this option is by far the easiest in execution, but you should have a plan and have actions very clear especially for the case when things don't go as planned.

2. Learn skills that are difficult to find

Many companies will hire remote workers for positions that are very difficult to fill from only local talent or for positions that are difficult to get people relocating for. You can try to jump into those if you fancy any of the topics and you are willing to be working on a non-remote company, which is hard.

Usually, if we focus on tech, companies on legacy platforms or legacy languages would be willing to hire you from wherever you are. However, there will be a tax paid on working in those stacks. This price is one of yourself going obsolete. It is not something I would recommend. There are some languages like C++ that I've noticed companies are still willing to hire remote and that are kind of legacy but not that bad at all and still hot in some environments. Frontend and design are some other positions for which you might see exceptions in companies. But personally what I would try to focus is on new or rarer programming languages or frameworks, especially if you know you will fancy these. For example, Rust, Clojure, Erlang, Elixir, Scala, or really kind of any functional programming language. All those are languages and frameworks for which it is difficult to hire.

If you find yourself becoming knowledgeable or expert on a stack that is difficult to hire for then your chances of being able to work remote have considerably multiplied.

3. Certify yourself in some valuable technology

This works as the previous point does. Again, you are trying to make yourself special and valuable to companies. Something that has always worked is to become certified in some demanded technology. Certifications as with many assets lose value over time. Of course there are exceptions, but for example, a Java programming certification is almost useless today if you ask me, but 18 years ago when I got it was amazingly valued. I was one of the first 10 people in Spain that achieved it. After getting it, I got a job with pretty much no interview. When I did ask my boss later, he was very clear: "We are a consultancy and you were one of the first 10 people in Spain with that certification. That alone provided us huge return. We knew we had to hire you."

This works today too but you need to find the appropriate tech. It needs to be new, modern, there needs to be demand. In summary, it needs to provide value to the company hiring you. I will not enter on whether Certifications are worth or not. But definitely, hiring managers do appreciate to find that people have spent some time learning and doing the exams, even when we perfectly know there might be many other non-certified people that surely can be much better. And as mentioned, for some cases like with consultancy companies, certifications have extra value.

So find something you love, something you can afford, something modern and hot. Maybe AI, maybe data intelligence, 5G, security, IOT, connected cars, i.e. some area that is soaring and that might have fewer candidates and get certified on whatever certifications might exist there. That will make your application more attractive and in any case, it will help you with local jobs too.

4. Engage in local communities

Social networks are by far the most used way to find and hire employees. I cannot guarantee you that by going to local events you are going to find a remote job, or any job. But what I can guarantee you is that by engaging with local communities you will have a much better chance to find a job and you will likely learn a lot too.

Maybe you are lucky and you end up connecting with people that are working remote. Those people might want to refer you to job offers that they know of, either in their company or in other companies. Prove yourself valuable and capable. Demonstrate passion and eagerness and opportunities will come. Local speaking also helps and opens many doors. And, who knows. You might actually find that you are really good at speaking. That really helps too. Did I say that developer advocates is a profession that has got really popular on the last few years and that is mainly done remotely? It is. It requires a lot of travel too. But if that is your thing then start contributing to a local community is certainly a good way to get into that world.

5. Contribute to Open Source communities.

This is another very usual way to go remote. Find something that you are passionate about. Check the open source community for projects around that topic. If we are talking about software, for example, go and download some of those projects. Get familiar with the sources. Learn how to build these projects. How to install them, how to debug them.

At some point you will find yourself comfortable with the code and able to answer questions and solve issues. Engage with the community. Sooner you might find yourself doing contributions and sending pull requests. Hey, if those get approved, you will be an Open Source Contributor!! Very few things look cooler on resumes, believe me. ( on programmers' resumes, of course :))

If you are a contributor, you might get changes to speak. If you like it you might even become popular. But believe me, before even speaking or being popular I wouldn't be surprised if you get a few job offers to come from other people from that same Open Source community where you started to work at. When I was contributing to Open Source I got quite a lot of those, some even from very cool projects and companies. And it felt really great, both contributing and being appreciated for it.

6. Build your real side projects

On my job, I do have to review many job applications. Some of them actually come with Github profiles. Those, always call my attention. However, that attention usually fades away when I see that the Github repos from that profile are just a bunch of exercises or forked repos.

If you really really want to be special and therefore to have unique chances to be hired remotely ( or locally ) then the best way is to have real side projects. With real, I mean real things that people can browse, download, install or use. Something real. That might be a website, an iPhone or Android app, some command line utility. In summary, something that the person doing the hiring can actually go and try. That will demonstrate that not only you have a good resume but you can actually execute things.

But wait, what should you create? Well, you should start with something that you like. Try to solve maybe a problem that you have. Or perhaps something for your beloved ones. For example, I currently run a website which happens to be the biggest community for Spanish speaking cake crafters. I just created it because I wanted to see how it looked like to run a real node.js app in a production-like system. So as my wife liked baking I went ahead and created a website for her. Recruiters proactively searching for talent still question me about it when they get in touch.

Or for example, I always struggle trying to book holidays for my family. Trying to find a suitable place for two kids that pleases them and both my wife and me has always been exhausting. So I just went and I did create an app that specializes in booking places for kids. Will it be super popular? I doubt it. But it solves my problem and also helped me to learn what it really means to write a mobile app.

So, try to find some technology you want to learn. Find some problem you have and then go and create a side project. There is nothing more effective than this when it comes to calling a hiring manager's attention. You will learn tons of stuff and you will demonstrate that you are not only theoretical but you actually have real proven experience.

Wrapping up

Wrapping up, pretty quickly. Finding a job is hard. Find a remote job is even harder. You should consider really if you want to go remote. You can check my previous article if you need it but overall if you don't have experience then, in my opinion, your options are either to become really special or to relocate and then try to force a move.

In any case, I do hope this article has given you some ideas on how to do one or the other and hope you the best of luck!

Thank you for reading.

10 years of remote working. This is what I have learned so far.

Martín Pérez — Fri, 01 Mar 2019 12:53:46 +0000

Follow up article: Finding a remote job is hard. Here are 6 tips for having a better chance
Don't have time to read? Here is an auto-generated audiocast thanks to Miguel Piedrafita

It seems as if it was yesterday when I started to work remotely. It was in March 2009 though. Since then, I have had my own startup ( which failed ), I have worked as an early engineer for another startup ( which got acquired ), and now I'm working at a big corporation ( that acquired the startup ). Over these years, I have worn many hats, from self-proclaimed startup "CEO" to a principal developer, tech lead or engineering manager. I have worked with great people, and also with some others not that great. I've paired with junior people and senior people. I had the pleasure to lead and to be led by people in several continents. I think this anniversary deserves some writing and I have decided to publish it here, at dev.to.

During this time, I have benefited from uncountable articles about remote working. But all in all, I found many of the articles that are around are biased. Many are indeed still valuable, but also a good amount of these articles happen to come from remote-first companies, which of course try to lure you into their talent pools, whereas some other articles come from people who run remote working communities, or job boards. In summary, there are some interests behind these and in many cases, the articles will focus on the good parts but ignore the bad parts. On this essay, I'm attempting to be super honest with myself and with you about remote working, but still, bear in mind that this is just my experience, so take it with a pinch of salt.

Are you starting your career? Then simply, don't go remote.

This opinion is very personal and of course, maybe you disagree. I totally respect it. But my view is that if you are starting your career then you should not consider remote working unless you have very important reasons for doing it ( see next section ). Also, of course, you can ignore me if you are such a badass to go traveling the world while working, which is something I loved I would have done.

Honestly, working from an office might end up being a terrible experience, or not. It really depends on where you live and what company you end up working. But still, it is going to be an incredibly valuable learning experience that everyone should go through. Otherwise, how are you going to value working remotely at all if you never have worked on an office, right? :) And also, usually and especially at the very beginning, you will make a lot of friends that hopefully will last for your whole lifetime.

Let me even go further. If you can, then you should consider working in an office, abroad. Maybe relocating to a tech hub. In fairness, adding international experience to your resume will always be hugely positive, and so will be the enriching experience of working and living abroad. Again, if you can, I will strongly recommend the experience. I did it in the past, I only regret having not done it even earlier in my life.

Think about your reasons before going remote

Yes, think twice, thrice, and any number of times you need. Especially, if you find yourself with the main argument for going remote being "I have a friend that is working remotely, he is doing really well and it looks so much fun". Believe it or not, and despite all the fun pictures we remote workers tend to post online, the truth is that remote work is work after all, and I would say that it is way more demanding than office work.

My opinion here is that you should consider working remotely only if it is going to make a big substantial improvement in your life. Otherwise, the cost of the extra work, the cost of working off hours or the lack of social interaction might end up being too heavy. But wait, what is a substantial benefit? Well, it really depends on the person. For me, the huge benefits I've got by going remote are:

Family friendliness: Over the last 10 years my wife and I did raise two kids. Remote work here has helped a lot. It would have been almost impossible for both of us to keep our jobs if I hadn't had the flexibility that remote working gives you.
Chance to get a higher salary: A remote job might get you closer to big-city like salaries, or to salaries that in your country or region would not be even possible.

Those were the two main drivers for me. But other people might actually favor other important benefits from remote working:

No commuting: In some places like big cities commuting can be a nightmare.
Work for dream companies. There are some very cool companies that offer remote work and you don't need to relocate. There is some great projects to work on too. Remote working is very popular for open source contributions. If this is what you love to do then I find it a very compelling reason to go remote.

But believe me, for succeeding in remote work, then one or preferably more of the points above need to be imperative benefits. Remote working comes with many negative points that need to be weighted in. I already mentioned a lack of social interaction. But there are many others. You will find that remote friendships come in very fast but they also fade out very quickly as you will lack the real interactions that solidify relationships (yes, drinks!). Career advance is tougher too. Remote management comes with a lot of challenges and in some circumstances is almost impossible and you might find yourself stuck in your career. So, seriously, think thoroughly about what is making you want to go remote working and what are your long and short term goals, and make sure the reasons to go remote are actually strong reasons for you. Reasons, that will make you really spark joy --Marie Kondo mandatory reference these days.

Learn to prove and defend your work

Office workers get some things granted pretty easily. For example, office workers need to just show up at the office space and it seems like they are working. For remote workers this is much more challenging as the shade of doubt will always be there cast over us. Oh, is Martín really working, or is he going again mountain biking?

As a remote worker, you will have to be ready to prove not only that you are working but also that you are delivering value. For me, this has been relatively simple as I was already doing contracting work before going remote, and a contractor has pretty much the same need. A contractor needs to demonstrate every week, or month, that there is value on the work delivered. Otherwise, the contract ends. And incoming money ends flowing in too. For a remote worker, it just works the same way, the remote worker needs to prove that is providing value.

With time, you will get trust from your team, but I have always found that the skills needed to prove your work are nice skills to have. Here are things I do regularly:

Learn to communicate what you have done. Many people are over shy about this. There is some stigma around talking achievements. People that do this sometimes are being seen as if they are trying to make their way up on the corporate ladder. But, if you want to be remote, you'll have to get over this. Your manager will actually appreciate knowing what you have been up to and knowing that you might still be living thousands of miles away but you are delivering important value.
Document everything you do. At the companies I've been working, I've always been renown by writing good wikis. I don't think it's that much that I write that well but that I actually do write. It's always useful to document your last learnings, or the new technology you have learned, or the latest results for that load test that you might have run. Yes, documentation gets obsolete quickly, but so it is true that while it is up to date it is incredibly useful for newcomers and for existing employees. I always try to document everything and do the best I can to maintain up to date those docs or to deprecate them. And overall, it's been very helpful for me to prove that I deliver value. Bonus: Documentation also makes interruptions shorter as you can always refer people to the guide ;)
If you are doing software, add tests. I'm not going to defend writing tests or doing TDD, I think these are standard fundamental engineering practices these days. Being remote means only that these practices become even more important to be able to defend your work. There is no better way to defend your software than start writing tests. So if you are not doing it, and you are considering remote then it is going to be about time ;)
Demo what you have done. Any time you do some nice achievement that can be useful for someone else do not hesitate in sharing that knowledge with others via live demos. It will help other people and also you will be again providing important value. These demos are usually a part of Agile so you can use the demo-day for this, or if it is not in the scope of a particular Sprint you can simply call up for a brown bag session.
Chat, talk, collaborate. I won't go further than that on this one. Being on your own office, you will have to do some extra efforts to keep in touch with people and to collaborate. There is plenty of tools to do this. Choose your own poison.

Flexible working must not mean work at any time

I live in GMT+1. In my remote journey, I've moved from same-timezone work, to EST-GMT-CST timezone work, and to PST-EST-GMT-CST. As you can imagine, as the timezone availability band spreads out, so it do the times at which you might get requests for meetings or interactions. I did not control this at the beginning of my journey as it wasn't that annoying, but once I moved into collaborating with PST times, then it got really complicated for me especially when having to coordinate meetings with dinners, kids bath or go-to-sleep hours, etc.

So, my advice to you is that if you need to work in different timezones then make sure you block time in advance on your calendar for personal use. So no-one will actually try to schedule or interact with you in those hours. That way you can separate your personal life from your work life and at the same time still be flexible with working hours.

Blocking an hour at lunchtime, a couple of hours at dinner time and any time beyond 11PM is probably the best decision I've done so far.

Make sure you spend time on yourself

Following on the above topic, especially when you need to work on multiple timezones, you might end up in situations as I did get into. You find yourself not leaving your computer in the mornings because you need to work on some issues with the team in Asia, then you want to spend some valuable work-time during the afternoon doing some stuff quietly, and then you start getting requests by the team in the USA timezones as they wake up, and without realising it the day is over and you have worked 12 or 14 hours. And if you don't take care of this, it will go on and on and on, until you are burnt out.

The way I solved this is planning the week in advance and to allocate flexible breaks according to how the week is going to look like. For example, if I have a lot of tasks and meetings during the morning then I may block some time in the evening for the kids. If on the other hand, I am going to have a lot of evening tasks then I block some time in the morning to doing things at home or doing some sports, etc. In summary, you will have to be very creative with your time if you work cross-timezones, making sure that you work a reasonable amount of hours ( no longer than 8), or otherwise you will get burnt out sooner than later.

Being the only remote person is difficult

I'll be crudely fair and straight here. If you are interviewing for a remote role and you are going to be the only remote person or just one of just a few remote people, then consider the offer very carefully because most likely you will suffer.

"Satellite" workers are becoming a common situation. Companies usually resort to this model when they can't find talent for a certain skill, so they resign on their efforts to hire local-only and concede on hiring remotely but only for those roles that are difficult to fill. The consequence is that you will end up being a second-class citizen within the company, no matter how hard you and they try. And it will not be because the company wants to, but just because you are and will be the exception to the rule.

There is not much you can do really about this. It's your choice. It might be worth for that substantial reason I related further above. Other than that, with time, an alternative is creating a small office around your location if the company allows it, but frankly, it would likely be difficult if the company only resorts to remote work for exceptions.

Being a remote manager is tough if your team is not remote

Over these 10 years, I've had the pleasure of collaborating and leading some small teams located in different continents. I've had the pleasure to work with very senior colleagues and also very junior people. Some of them are used to remote work, some of them aren't. But no matter their expertise, my experience has been reasonably constant. Whenever the team members are used to work remotely then all will flow reasonably seamlessly. On the other hand, trying to manage people that are not used to remote work or are not willing to be flexible has always been a big challenge for me.

The main challenge with this is flexibleness. When people want to have an office work lifestyle than to adapt then as you can imagine having someone trying to remotely manage the team is going to be a hell both for the lead/manager and for the team. Also, the truth is that being a manager that connects by videoconference every day to a room full of onsite people is incredibly awkward. Personally, I still don't get over this very well and I find myself much more comfortable for example when my team joins calls from their homes.

This is everything I wanted to share with you guys. I love this community and I see tons of articles about remote working which are actually very honest and far away from those "sponsored" go-and-work-remote articles that are usual to see around. I have been very honest too and hopefully, this might help someone to decide to go remote, or to decide to go to an office job.

Would I go remote again if I were back 10 years? YES Will I stay working remote for the next 10 years? I HOPE SO. Will remote work be your thing? I don't know but hopefully, my article has helped you.

In any case, good luck!

What are the books about software engineering history that you have enjoyed most?

Martín Pérez — Fri, 22 Feb 2019 10:19:26 +0000

One of the genres I enjoy most reading is books about software history. Books that tell you real stories and experiences from software companies which relate how they got into what they are or how they released that product that you always have used.

I defined them as teenage nostalgia books. Books that maybe describe how those games in which you spent countless hours when made. Masters of Doom and The Making of Prince of Persia are gold if you ask me. But there must be more! Making it Big in Software is a great set of essays about well known software leaders who narrate their stories.

So, I'm asking this community. What books about software history do you recommend for reading?