Ylan Segal

On Remote Work

A few months ago I changed jobs. My previous job was at a large software company, with offices worldwide. My day-to-day activities routinely included conference calls with people in the Americas, Europe and Asia. For the most part, these were coordinations meetings. My most meaningful collaborations were with the people sitting around me: The members of my team.

My situation now is quite different. I work for a much smaller company, in number of total employees. My team all works at headquarters, but I come in most days to a company office located in a different city. In practice, this makes me a remote worker. I’ve had time to make some observations about that type of work. My experience relates specifically to software engineering, but I imagine that it could also apply to other similar type of work.

Embrace Asynchronous Communication

When working in the same office, it’s relatively easy to tell when it’s appropriate to interrupt someone: They are preparing coffee, returning from a break, or are in between meetings. When working remotely, I am more careful about other’s time, since I don’t want to break their concentration. This is especially true if I need some input, but don’t need it right now.

Asynchronous, written communication helps. I can send someone an email or ask a question in a PR. While they respond, I can continue with other tasks. At first, this switching between tasks was difficult. With practice and a good organization system, this has become much easier. Now, I generally work on my tasks until I need input, request it asynchronously and switch to something else in the meantime.

Work At The Same Time

While asynchronous communication makes it easier to work remotely, there is such a thing as too much of a good thing. If members of a team work in widely different timezones, effectively collaboration can be very slow. I’ve experience this before, when I was assigned to lead and teach a team based in India – 11.5 hours away. It was challenging, because all the communication was in written form and, for all intents and purposes, delayed for a full work day. No matter how small the question was, it was never answered until the next day.

Working at the same times as your co-wokers – at least for a portion of the work day – allows for faster feedback cycles and the possibility of jumping on a call when written communication just doesn’t cut it.

Video Calls

The next best thing to in-person communication is video calls. There is a certain awkwardness inherent in them. In particular it bothers me greatly that because of where the camera is positioned, participant never seem to look each other in the eyes. That nitpick notwithstanding, video chat is much richer than just audio: Seeing other’s facial expressions conveys a lot of meaning. Using your computer as a communication device has some issues. I always have many windows open. When on video calls, it’s easy to allow myself to get distracted and peak into another window: Email, chat, the code I was working on. Pretty soon, I’ve stoped paying attention to the conversation. To avoid that, I’ve started combating the temptation by minimizing all windows except for the video call, having the video window in my laptop’s screen while sitting directly in front of it– to simulate as much as possible looking at the other people in the eyes. This has made me much more engaged in conversations. If I still need to fidget with something, I doodle on paper or turn to my current favorite fidget: A Rubik’s cube.

For video calls to be effective, they need to be high quality. A reliable internet connection is needed, but not enough. There is no shortage of video call providers. I’ve tried many. Their quality is much different, and it makes a big difference. Poor audio quality, or “lossy” connections make it hard to have good conversations. In my experience, Zoom quality is much better than others, including Slack and Skype. Google Hangouts seems to have good quality, too, but I’ve only used it a handful of times.

In the same vein, as a software engineer, I find myself talking about code a lot. Sharing my screen, or seeing some else’s screen, has been essential to good communication. A picture is worth a thousand words.

Everyone Needs To Be Onboard

Collaborating remotely only works if others are willing to collaborate with you in that way. On teams were this is effective I’ve observed that: - All meetings are by default remote, even if most participants are sitting in their desks in the same building. - Any agreement reached or significant exchange of information exchanged in person needs a follow up for the benefit of remote workers. Posting about in Slack, email, or commenting on the next standup is usually enough. As a bonus, this minimizes misunderstandings for the original participants.

Occasional In-Person Collaboration

In-person communication is still the highest-bandwidth form of communication. I travel roughly every two-months to spend a few days with the team. Eating lunch or dinner, and having the occasional beer with teammates helps for closer relationships. I consider some travel to be a necessary evil of remote working.


So far, I’ve been really happy working remotely. Most challenges I’ve faced, have been solved easily, not in the least because I am lucky to have a very supporting team and manager.

If you are thinking of working remotely, I recommend you prepare yourself for it. I recommend reading Remote, by Jason Fried and David Heinemeier-Hanson.

The REPL: Issue 47 - June 2018

How to GraphQL

GraphQL is an alternative to REST that aims to be more efficient than traditional APIs and allow fast development, both for the server and its clients. This is a fantastic tutorial introduction and hands-on tutorial, with just enough code samples to get a sense of what it is like to write back-end or front-end code in GraphQL. The content is presented in both written and video form. Nice touch.

Arel with Wharel

ActiveRecord, the ORM that ships with Rails, is an implementation of the ActiveRecord pattern. It’s elegant API is one of the things that makes getting started with Rails very convenient. Expressions like user.posts.where(published: true) are readable and expressive. When trying to write more complex queries it falls short. In those cases, I usually fall back to Arel, the relational algebra library that Rails uses under the hood. While technically, it’s considered by the Rails core team to be private API, it’s usually very stable. Unfortunately, Arel has a more verbose API. Wharel attempts to fix that. Like Squeel before it, it adds a bit of syntactic-sugar to make interacting with Arel more expressive. It accomplishes this with a minimum amount of code, making it more attractive to use. The author, Chris Salzberg, explains in his blog post the motivation and code behind the library. I look forward to using it.

The impact of the ‘open’ workspace on human collaboration

The findings presented in this paper are that open-office workspaces actually reduce the number of face-to-face interactions and increase the number of electronic interactions. The belief that this is not the case has always baffled me. In crowded spaces, like a big-city subway, stadium lines, or elevators, people tend to avoid eye contact, protect the little personal space that they have, and generally keep to themselves. It’s a defense mechanism. It’s not that people are unfriendly – it’s just that when you clearly don’t have any personal space, you don’t want to give up your mental space! Clearly, this applies to workspaces as well. If I am sitting with people typing in their keyboard all around me in close proximity, you bet I am going to have headphones on and keep my eyes pointing at my keyboard.

The REPL: Issue 46 - May 2018

The Economics of Writing a Technical Book

I’ve often wondered what it would be like to be a published author. Writing a book is a time consuming. Is it worth it? In this post, Justin Garrison covers in a lot of detail the economics of writing a book for O'Reilly Media. I found it very valuable, as discussions about how much money some makes are hard to come by. The bottom line: After a few months of the book being on sale, he has made ~$23/hour invested. The number would probably go up, since the number of hours it took is not going to change, but the number of sales keeps increasing. My understanding is that that flatten out rapidly after release, though. Food for thought!

GDPR Hysteria

hysteria | həˈstirēə, həˈsterēə | noun exaggerated or uncontrollable emotion or excitement, especially among a group of people

Last year, while working for my previous employer, I spent about half my time working on GDPR compliance. The work involved adding features for data export, data deletion for former customers, notifications around both, etc. The General Data Protection Regulation is a big deal for any company doing business in Europe, even if not located or incorporated there. As Jacques Mattheij points out – in a lot of detail – in the tech blogosphere there is a lot of hysteria around what it means. The post does a good job of explaining what it means and how it’s often misunderstood. Don’t miss the follow-up, with actionable advise on GDPR.

What is a Blockchain

I am not bullish on crypto-currencies. Actually, if I trusted that there was a reliable way to bet against them, I would. But what is a blockchain anyway? David Bryant Copeland starts from the ledger and builds his way up to explaining how it all ties together and what problem it solves. The article’s subtitle says it all: A novel solution to a problem no one has.

The REPL: Issue 45 - April 2018

the Origins of Opera and the Future of Programming

Jessica Kerr writes eloquently about how some groups of people in music, painting, science, and programming produce extraordinary results, like the invention of a novel genre of music. She goes deep into the theory behind it and introduces the concept of symmathesy:

Nora Bateson points out that there’s more to a living system than parts and interrelations: the parts aren’t constant. We grow and learn within the system, so that the parts don’t stay the same and the interrelationships don’t stay the same. She gave a word to this, something deeper than any mechanical or model-able system, a learning system composed of learning parts: symmathesy.

I am still processing what this all means. My immediate takeaway is that some teams have dynamics in which positive outcomes are amplified to form a virtuous cycle. I believe this is equivalent to what people mean by “synergy”.

How I Write SQL, Part 1: Naming Conventions

This post covers a lot of detail on the naming conventions Sehrope Sarkuni prefers when writing SQL, including the rationale behind for each convention. I agree with most of the conventions. In reality, I am more interested in my team having conventions in the first place.

How To Index Your Database

The slides for Baron Schwartz’s presentation at PostgresConf US 2018 cover a lot of detail on what indexes are, how databases use them and in the uses cases where indexes help: Read less data, read data in bulk, and read data presorted. This is one of those slide decks that contains enough information and context without needing to see the talk – not available on video at the time of writing.

The REPL: Issue 44 - March 2018

Mistakes Rails Developers Make in Elixir Part 1: Background Jobs

Background jobs in Rails are a common patter. In this post Desmond Bowe explores some of the available patterns in Elixir that can be used instead of reaching for a background queue. The information is very good. In my experience, every time I reach for background jobs, I also need to ensure that jobs survive node crashes. For that, the author still advises to use a traditional background queue.

A Career Cold Start Algorithm

Andrew Bosworth (Boz) advocates a simple way to start a new job: Ask everyone what is it that they think that you need to know, what are their challenges and who should you talk to next. This is a great idea, especially in places where a robust knowledge transfer process is not in place.

Elapsed time with Ruby, the right way

Luca Guidi explains why the naive use of Time.now to measure elapsed time between starting and ending an expensive operation is wrong. What to use? Monotonic time.

Remember: wall clock is for telling time, monotonic clock is for measuring time.