• Originally my book was called “Building and Managing Distributed Teams“. I loved that title and people in my social circle loved it too. A friend of mine even told me something along the lines of “I’m so envious I wish I had that title”. And for the two years or so that it took me to write, abandon, restart, abandon again, restart and finally finish the book, I was happy about the title.

    I had three different people ask me what I meant by “distributed”. The first time I ignored it, the third time I panicked.

    As I finished writing the book and it went into proof reading phase, I thought I should try to market it a bit. I’m self publishing, doing everything, including promotion and marketing (hint: I can use your help in getting the word out). During conversations I had three different people ask me what I meant by “distributed”. The first time I ignored it, the third time I panicked.

    I’ve been working from home since the early 2000s. I’ve been building remote/distributed teams and companies since 2011 or so. At the beginning we were called and we called ourselves remote workers. But that soon started to carry a stigma. Companies would have in-office workers and remote workers and remote workers were second class citizens.

    This created a division between being a remote worker and working for a distributed company. The latter was much better.

    The companies that wanted everybody to be remote, the companies that were remote-first, the companies were being remote didn’t mean second class citizen started calling themselves distributed. This created a division between being a remote worker and working for a distributed company. The latter was much better. The movement of distributed work was growing, Automattic, Github, and many other companies were charging ahead… and then the pandemic happened.

    I don’t think the amount of people using the term “distributed” changed during the Covid pandemic, but the amount of people using the term “remote” did and might have turned “distributed” into a rounding error. The natural change of title for my book would have been from:

    Building and Managing Distributed Teams

    to

    Building and Managing Remote Teams

    I wanted to measure this, but I couldn’t find any way to do it. I tried Google Ads but I couldn’t make it work and no other method seemed to even be feasible. One of the problems I had is that I believe polls would be useless, because once you give context to “distributed”, I think everybody understands it, and it might sound better. I wanted to see how they behave in isolation. At any rate, “remote” won in polls, but not overwhelmingly.

    Since I was going to change the title, I may as well consider any and all possible titles, not just a single word change, right? My friend, Justin Megawarne, came up with a very important point: the title doesn’t contain the value proposition. Think of the book “The Four Hour Work Week” by Tim Ferris. If it would have had a descriptive title, like “How to Delegate Work”, he would not have been a bestseller author.

    I tried to find a value proposition name for my book and I gave up

    I tried to find a value proposition title for my book. Companies struggle to hire, grow and manage in-office teams. This is a pain that exists. My friend and advisor works with many companies like that, he wants to recommend them my book, but he knows they don’t believe a book by that title has the solution to their problems. I tried to find a value proposition name for my book and I gave up.

    If I remember correctly it took Tim Ferris weeks of research to come up with the title and cover of his book. I don’t have weeks to dedicate to this, in part because even with the perfect title and cover, without an editor and publisher, with just my own ability to market, it’s not going to have a positive return on investment. And thus, the new title was selected:

    How to Hire and Manage Remote Work

    I did introduce some extra changes. From the conversation with Justin I switched “Building” for “Hiring”, to have the keyword of the pain point a lot of companies are going through. I also asked Ana Bibikova for her opinion since she’s both a marketer and an author. She advised me to switch from imperative phrasing to “How to”. I’m not sure what the effect will be, I don’t have a strong opinion and I trust hers.

    And now, the list of explored and abandoned titles:

    • Building and Managing Distributed Teams (current)
    • Building and Managing Remote Teams
    • Hiring and Managing Remote Teams
    • Find the Best Talent Everywhere
    • Hire the Best and Keep Them
    • Stop Struggling to Hire and Managing Remote Teams
    • Hire Remote: Manage Remote: Stay Remote
    • Hire Remote, Manage Remote, Stay Remote
    • Doing It Better Remotely
    • Hire, Manage, Stay: Remote Working and What It Should Look Like
    • Do Better: Hiring and Managing your Remote Team
    • Remote Teams Done Really Badly (A How Not To)

    I think some of those might come back as titles of blog posts.

  • I’ve hired about 20 developers in my career so far (and I’m looking forward to hire more). When job applications arrive I separate them in three piles: Yes, No, and Maybe. It’s better to do Yes and No piles, but it’s a luxury that I haven’t had (if curious, drop a comment and I’ll write another blog post about it).

    In the No-pile I put all those people that are obviously not a match, people that explicitly tell me they never wrote code before, people outside the time zone target, applications with grammar so bad I can’t understand them, etc.

    […] the most important bit: I find some evidence that they have written code before.

    In the Yes-pile I put all those that show promise. Their application looks good, their profile match and this is the most important bit: I find some evidence that they have written code before.

    The rest of the applicants go to the Maybe-pile. They are not discarded, but I’m going to focus on the ones in the Yes-pile first because I believe I’ll find more successful candidates there than in the Maybe-pile. This doesn’t mean that someone brilliant isn’t in the Maybe-pile. It only means that I couldn’t find any evidence about their potential brilliance.

    Landing on the Maybe-pile is almost as bad as landing on the No-pile

    Here’s the kicker: I never get to the Maybe-pile. I always find all the candidates I want from the Yes-pile. Landing on the Maybe-pile is almost as bad as landing on the No-pile.

    There are many ways in which you can make yourself go from the Maybe to the Yes pile. These are the best ways: blogging about code you write, writing tutorials, contributing to open source software. Having done all of that will not only put you in the Yes-pile, it’ll probably put you at the front.

    But those are things that require a lot of time an effort. There’s another thing that may only require a couple of minutes. If you’ve been using your GitHub account for work or for university, that account has a lot of activity. You may not be able to show code from work and you may not want to show code from university, but you may show the activity. Go to your Public Profile settings and tick “Include private contributions on my profile”:

    This, if you have any private activity, will turn your public GitHub profile from something that looks like a ghost town:

    into something like looks more lively:

    The latter looks like a developer that wrote some code. It will not send you to the top of the Yes-pile, but if the rest of your application looks good, it might be enough to send you to the Yes-pile and it’s a change that requires only a few seconds.

    Now, if you are in the know, you might object that this is completely fakable, and you are right. Yet, I don’t see people faking it. I see lots of empty profiles looking sad and empty, so it’s still a useful signal.

    I’m not trying to find a perfect way to evaluate candidates, I’m trying to find a heuristic to help me find which ones to evaluate first

    Even if some people fake it, I might still continue using the signal. It’s not like you don’t have to pass all the interviews after this anyway. Remember that I’m not trying to find a perfect way to evaluate candidates, I’m trying to find a heuristic to help me find which ones to evaluate first because it’s impossible to evaluate everyone.

    Now, if you decide to fake it, you have two paths. The first one is to just fake, essentially lying about it. That’s a deception. The second is to troll. You can spell out your name or draw something in that part of GitHub. I won’t know if you have real activity or not, your profile won’t look as empty, but at least I know you know enough about coding to pull off that.

    You could argue that because some people wrote the code to make that happen and uploaded to GitHub, all you have to do is find it and run it, and it doesn’t prove that you are above script kiddie. And then again, most applications I have don’t even have script kiddie level of a display of ability, so you may still be coming ahead.

  • I started coding when I was 7 years old and until I was 29 or so, my whole professional life was coding. Then, the startup I co-founded had to hire some people because it was doing well and I became a manager. I discovered I love managing as much as coding, but there was an ongoing issue: at the end of a day coding, I could look back at my code and feel productive, whereas at the end of a day managing, mostly meetings, I felt exhausted and with nothing to show for.

    I highly recommend it to all managers: write down notes.

    I’ve been managing for 10 years, taking over and building teams from scratch, being hands on and hands off and that feeling of not being productive is rarely there and I think there’s one habit that I have that helps a lot and I highly recommend it to all managers: write down notes.

    I go into every meeting with some note taking tool. If the meeting is face to face, I prefer to stick to pen and paper, because a computer can stablish a divide. The other person doesn’t know what I’m typing, I may be chatting with a friend. With pen and paper it’s immediately obvious I’m taking notes and there’s no wall (the screen) between me and the other person.

    But now we are all remote, and the notes are digital. This is so much better because it cuts down (but doesn’t completely remove) the need to process notes post-meeting. Depending on the type of meeting, I even share my screen so the other person can look at the notes I’m writing. You have no idea how many misunderstandings were caught this way. They said something, I misunderstood them, wrote it down in front of them and they corrected me. If you are not sharing notes, repeat what you wrote to the other person to have the same effect. This is similar to active listening.

    There are a few more things that I do with my notes that I highly recommend.

    I try to make all my meetings 50 minutes long, with 10 minutes to review and action notes. If we reach the 50 minute mark, ideally, I want to just book another one to continue. Having meetings overrun and everybody being late to the next meeting is very bad to the morale of a company but being the only person enforcing the strict end of meetings can be hard.

    When I review the notes, if the meeting was just the two of us or sensitive, I write them down on an email and I send them to the other people in the meeting. This helps have a shared record of what happened. Otherwise I write them down on a public record in a centralized documentation system, like Confluence or Notion.

    Looking at my written notes gives me the same feeling of accomplishment than looking at my written code. I’ve done something.

    Once a week I go through my week worth of notes to see if I have missed something. If they are written on paper this is when I digitize them for permanent record. This also informs the report to my boss about what happened that week. Looking at my written notes gives me the same feeling of accomplishment than looking at my written code. I’ve done something.

    If you found this valuable, you may be interested in my book: Building and Managing Distributed Teams.

  • All of them, of course, depending on what you are reading. Here’s a short overview of when to use each of them inspired by a Twitter conversation with Tania Dsouza.

    If the book is amazing and you need to highlight stuff, buy the Kindle version.

    If it’s a book that you lend or give away, buy paper versions

    Here’s my workflow for choosing:

    1. Use Audible whenever possible, because going through audiobooks is much easier than going through any other format.
    2. If the book has code or diagrams, most likely the audiobook won’t exist, but if you need to chose between Kindle and paper, choose paper. Big pages, diagrams, code, thumbing through pages are things that paper beats Kindle any day.
    3. If the book is amazing and you need to highlight stuff, buy the Kindle version. If it’s amazing, re-reading it is probably a good idea and Kindle is really good at highlighting sections. If you need to write notes, the Kindle device is not that good, but the Kindle app on your phone is and they do synchronize, so you can switch back and forth. If you are a non-linear note-taker, the paper version might be better.
    4. If it’s a book that you lend or give away, buy paper versions. Digital can’t be given away (not easily).
    5. If it’s fiction or something you’ll read very linearly and you won’t listen to the audiobook, buy the Kindle version. This is where Kindle is the best.
    6. If you want it signed by the author, or on your shelf, buy the paper version. A few times I listened to a book and it was amazing and I bought the paper version just because I want it sitting on my shelf. This is more book collecting than book reading and there’s nothing wrong with it.
    7. If you are in front of it at a shop and want it, just buy it. Don’t be dogmatic about using a single format for everything, be a multi-format reader.

    And now, the background story…

    I’m a book lover, I grew up in a house that didn’t have a library, it was a library. When I was a kid my mom told me “We always have money for books”. I actually found the limit of that statement, but that’s another story. By the time I moved out of my parent’s house, my own collection was about 200 or 300 books. I’m not sure, I didn’t keep it. I gave most of it away to a friend that was setting up a used book store during the 2001 Argentina financial crisis and the only reason it didn’t break my heart was because helping my friend came first. I like paper books, their feel, their smell. I have a small collection of signed books that a prize possessions.

    For a while I tried switching to one format to rule them all, but it doesn’t work.

    But I also love tech, I’ve been coding since I was 7 years old, and always playing with the latest technologies. Reading from an electronic device where I can access all books and all information gets me excited. I bought some of the earlier ebook readers, made by Sony, before Amazon dominated the industry with the Kindle. And like most of us, I’m very busy, and sitting down to read a book is not something that comes easy. When I started to use Goodreads I realized how little I was actually reading and I didn’t like it. Audiobooks came to the rescue. They allow me to read a book while doing mindless but necessary activities, like chores, working out, commuting (not a lot of that happening lately).

    For a while I tried switching to one format to rule them all, but it doesn’t work. Books are not all equal. Some work very well as audiobooks, some work very well in Kindle, and some require paper to be consumed. My method of reading books might seem a bit inefficient in that if I want to write notes, I end up reading a book twice. But if the end result is that I read more books, that lower inefficiency doesn’t matter because I increased my efficacy.

    If you are reading this blog post, I expect you are very familiar with paper books but considering Kindle and Audible, so I’ll just talk a bit more about them.

    With Kindle, you can have apps on your computer, phone and tablet as well as dedicated Kindle e-readers. They all connect to your Amazon account and they all get the same books and synchronize in which page you are. That means you may do most of your reading on a Kindle device, but open the app in your phone when you find yourself with some time to kill (better than doom-scrolling). You can start to experience Kindle with just your phone or tablet and buy a Kindle e-reader only if it’s working for you, but let me tell you, the screens on those e-readers are so much better for reading than your phone, they are much closer to paper.

    Kindle Paperwhite: to me this feels like the Kindle. It has some very important features: waterproofing and warm light. This is the one I recommend to most people.

    Understanding Kindle

    Amazon offers several Kindle e-readers:

    • Kindle: the most basic e-reader. If you want to save money, if you want to try, maybe this is a good starting point.
    • Kindle Paperwhite: to me this feels like the Kindle. It has some very important features: waterproofing and warm light. This is the one I recommend to most people.
    • Kindle Paperwhite Signature Edition: ok Amazon, you need to get better at naming things. What happened here? I don’t see why anyone would get this one to be honest. Auto-adjusting light? meh, I will adjust it anyway. Wireless charging? I plug my Kindle every other week. 32GB instead of 8GB makes no difference, books are tiny (unless you are storing audiobooks, which I don’t think you should).
    • Kindle Oasis: this is the top of the line, the most expensive, the luxury version. This is the one I have and it was a present. What used to be its killer feature, warm light, is not present in the Paperwhite version. It has some nice features, like the auto rotate page, the buttons, the mobile connectivity, but those only add value if you actually use them. Auto-rotate and buttons may be useful depending on how you hold the book. They are useful to me, but it’s hard to predict if they’ll be useful to someone else.

    Some extra things to keep in mind when buying a Kindle:

    You can store audiobooks in them, but then you need to pair your headphones to your Kindle. I have enough trouble with my headphones being paired to my phone and computer, I don’t need another device. When I’m listening to audiobooks I’m on the go, working out, doing chores. I have my phone on me, but not my Kindle on me. I don’t think this is a very valuable feature.

    All Kindles come in two versions, with and without ads. I don’t know if you can upgrade to not have ads, I always bought mine without ads. Make sure you choose what’s appropriate for you. They also tend to have deals with Kindle Unlimited. Kindle Unlimited is like the Netflix of books, where you don’t pay for each individual book. The catalog is hit or miss and I never got it. My partner reads way more books than me and she got it for a while. If you start a free trial, make sure to set a task to stop it to allow paying for a subscription you don’t want.

    Screenshot of amazon.com showing the options to buy a Kindle.

    When purchasing a Kindle, you can choose to have it tied to your account already. It’s a sort of pre-setup that they do. If it’s a present don’t chose this option. If it’s for you, it’s convenient.

    Kindles have two ways of connection to the Internet: wi-fi and mobile. Mobile now is only available in the Oasis, the most expensive one. I never got a Kindle with mobile connectivity but I had friends that did. If you are a person that’s on the go a lot, that might be convenient, because it’ll keep your page synchronized even when wi-fi is not present. If I’m on the go and I want to buy a book, what I do is make my phone into a hotspot, connect my Kindle to it, and then buy and download the book. This is very rare.

    I can’t comment on the Kindle for Kids since I never tried. Amazon lets you form a family and then everybody in the family can see the books of others. Unfortunately an Amazon family can only have two adults, which I find frustrating.

    Understanding Audible

    Amazon bought Audible, but it’s not completely integrated into the Amazon ecosystem yet. There’s a separate app from Kindle called Audible that you use to listen to audiobooks although the Kindle e-readers can also play the same audiobooks and I believe the Kindle app can do it as well. I still recommend you just use the Audible app on your phone, because you already have your headphones connected to your phone and your phone on you, what you need to listen to books.

    You can buy audio books one by one, but they are quite expensive. Audible offers several memberships that are much cheaper per book. There are four offerings:

    • Audible Premium Plus: 1 credit per month.
    • Audible Premium Plus—2 Credits: 2 credits per month.
    • Audible Premium Plus Annual—12 Credits: 12 credits per year.
    • Audible Premium Plus Annual—24 Credits: 24 credits per year.

    Who named these plans? This names are terrible, but that’s for another blog post.

    These plans give you credits. Once upon a time, books could cost 1 or 2 credits, depending on the length. I haven’t seen a book costing more than 1 credit in ages, so when you see “credit” you can read “book”.

    The higher you go in plan, the cheaper per credit they become, as you would expect. But the annual ones have an extra benefit. Credits accumulate so if you don’t use them, they’ll just pile up (at some point I think they expire, but that’s not a problem I had). If you find yourself with 0 credits and you are in a monthly plan and you want a book, you’ll have to buy the book, at its cash price, which can be as bad as double or more what a credit costs. If you have an annual plan, you can renew early. For example, I have the 24 credits per year, but if I run out of credits, and this has happened, I just click the renew button and start another year of subscription on that day.

    If you have an annual plan, you can renew early. For example, I have the 24 credits per year, but if I run out of credits, and this has happened, I just click the renew button and start another year of subscription on that day.

    My recommendation is that you get the 1 credit per month plan to give Audible a try, and if it’s working well for you after 3 to 6 months, switch to the 12 credits per year. If you run out of credits, then consider renewing early or switching to 24 credits per year.

    Some books in Amazon have a feature called whispersync. This allows to synchronize the page in Kindle with the position in Audible. You can be listening to a book in the car, get home, pick up your e-reader and continue reading. When a book has whispersync and you own one of the two mediums, generally the other one is much cheaper. I think buying audiobooks on deal through whispersync after you bought the Kindle version is cheaper than a credit (but Kindle + audiobook is way more than a credit). If you only use Audible with whispersync-ed books, a membership might not make sense at all. I can’t comment beyond that because I have never used whispersync.

    And that’s all. I hope this post helps you become a multi-format reader and that allows you to read more. It certainly help me:

    Picture showing my reading challenges since 2011 until 2022, all completed, where I read a total of 362 books.

    Happy reading!

  • This blog post is a sample chapter from my book:
    How to Hire and Manage Remote Teams

    The term one-on-one evolved to refer to a specific type of meeting and does not mean any general meeting that has two people on it. One-on-ones are the regular meetings between a manager and each of their reportees. One-on-ones are always important but in a distributed team they become critical – mainly because you are not going to be able to run into your reportees on the hallways and have a quick meaningful conversation opportunistically.

    A one-on-one has several goals and I recommend the relevant chapters on The Hard Thing About Hard Things (Ben horowitz) and High Output Management (Andrew Grove) in order to understand more about how to conduct them and their importance.

    The main and most critical role of the one-on-one is to identify problems, or potential problems, as early as possible. By the time one of your employees tells you they have another job offer, more often than not, it’s way too late to do anything about it. The issues leading to their moving posts will have started long before, perhaps months, and the opportunity to address them will have been when it first arose. If you’re not aware, and not providing the opportunity for your worker to make you aware, a problem can fester beyond the point of salvation. The one-on-one aims to reduce this possibility.

    A one-on-one is the time when an employee can bring up small issues:

    • I’m not happy with our project.
    • Work is boring.
    • I feel my ideas are ignored.
    • This person is being rude to me.
    • The way we work just sucks.

    And from that information it is your job to start fixing it. 

    However, it is unlikely your employee will feel empowered to say any of this unless they already trust you. For this reason, one-on-ones should not be reserved for only dealing with critical issues, or when you suspect there could be a problem. Routinely meeting is an exercise in building the rapport that will be required for the worker to bring up any real problem.

    For those uneventful one-on-ones, it is important that you keep a balance between listening and sharing. If you don’t share anything at all, you’ll end up coming across as an interrogator. It is through sharing that you show them that you are listening and empathizing with what they are saying.

    The opposite tends to be a bigger problem. If you as the manager go into long monologues during the one on ones most of your employees will respectfully listen and hate every minute of it. Many of us tend to have a bias that means that if we feel we spoke for 50% of the time, we actually spoke 70% of the time, so you might need to rein it in.

    Since you are doing this remotely, you could get a stopwatch and during a couple one-on-ones measure how much you talk or how much they talk. Don’t worry about getting too precise (for example, when switching back and forth quickly during clarifying questions). This is just a rough approximation. Your performance during those one-on-ones will be distracted, so this isn’t something to do regularly, but it can be a useful self-test to show yourself your baseline.

    To achieve a good balance, here’s a recipe you can follow:

    1. Start with the pleasantries: How are you? Fine, you? Fine. This is neither sincere nor useless. It’s a protocol to start communicating, it establishes cadence, tone of voice. Don’t ignore it, but also don’t take it at face value.
    2. Ask one or two questions to let the worker become comfortable talking. “How was this week?” or “That was a good release, wasn’t it?”
    3. Re-ask them how they are doing: “Now, really, how are you doing? All good in your life?”. Now is when you need to start practicing silence.
    4. Ask them if they have any questions for you. Continue practicing silence.
    5. Ask them what was the best or worst part of the week. Again… silence.

    When I say practice silence, what I mean is that you ask the question and then shut up. Different people take different amounts of time to start talking. Especially if they need to bring up a difficult subject, which can require mustering some courage. Give them time and space. This will feel uncomfortable, but it’s a skill you need to master. There are some stereotypes that introverts are more comfortable with silence than extroverts, but I’m not sure how true it is. If you are a manager, you are probably more comfortable talking than the worker (if they are developers for example), so you might need to put up with more discomfort.

    The initial “How are you?” question is part of the protocol of starting a conversation. There are some studies that show that it establishes speed cadence, tone of voice and other aspects of communication. What it’s not is a sincere question of how someone is doing. Don’t expect people to answer it truthfully; if they do, great! But most people need to be asked twice. But… avoid asking twice in a row. When we are asked the same question twice in quick succession, it engenders the feeling of being accused, as though we are lying or are being unreliable – so most of us will dig in our heels and avoid changing our answer. Most of us need to warm up to a conversation before we can answer truthfully. So ask some other benign questions, and then circle back round to it. 

    If at any point during that recipe your worker takes off on a tangent that is useful, as in it’s providing you with the information you need about their wellbeing, drop the recipe and follow their lead. The recipe is there for the cases where a worker is being more passive, which is likely to be true when you are just starting to work together.

    I recommend taking copious notes during the ones-on-ones and following up on things that were happening. These notes should be strictly private.

    I tend to run one-on-ones in two different schedules:

    • Weekly but optional.
    • Every other week but mandatory.

    Every other week but mandatory is the default way I use to schedule one-on-ones. Weekly but optional is a scheme that I use under many special circumstances:

    • The employee and I don’t know each other well.
    • The employee is new to the team.
    • I am new to the team.
    • There’s an ongoing issue or conflict.
    • They are a junior employee needing more guidance.

    The optionality has limitations: we can skip one, if they are being productive and have no pending issues to discuss in the one-on-one. Once it’s skipped one week, the next week it becomes mandatory.

    Normally I book one-on-ones to last 25 minutes with five minutes for me to finalize my notes. If someone reaches the end of the one-on-one and there are pending issues to resolve, book another meeting straight away to continue working on it (this rarely happens).

    It’s very easy for one on ones to become status reports. It’s something easy for the worker to say, and it’s something easy for the manager to consume, but the one on ones are not about performance or what got done. To drive that point: imagine the situation in which the line manager and the project manager are different people, the line manager does the one-on-one but the project manager cares about the status reports of what has been done. 

    Instead, I suggest you just say something along the lines of: “This is not about a progress report, but was there anything you enjoyed or that annoyed you this week?”

    That last part of the question allows the worker to do a retrospective and instead of talking about having achieved tasks A, B and C, they can talk about how whilst doing C they had a conflict with another worker; or how they loved doing B and wished they were doing more of that. Those are important signals for you.

    The one-on-ones cannot be extremely transactional. It takes time for someone to be comfortable to tell you about a problem they have. This is normal: people literally go to the doctor, where their confidentiality is protected by law, and still procrastinate on sharing something because it’s uncomfortable. So don’t expect that a worker will just show up and tell you there’s a problem because you have an “open door” policy. You need more than that. You really need to prove yourself approachable proactively, and that happens through repeated positive small interactions.

    If, like me, you have a terrible memory, write down the names of their spouses, children, pets, birthdays, what’s going on with their lives and ask them about it the next time (“how was your holiday to Mallorca?” or “How was [daughter’s name] school play?”). These are notes that I consider extremely private; not to be shared with employers or other managers. I don’t even write them on a medium they could gain access to (normally I use paper). For me, it’s the same as with any other friend: I have a calendar with their birthdays, because it’s important that I don’t miss them.

    In Summary: one-on-ones are often neglected or perceived as only necessary when something is already wrong. In fact they are a vital means of establishing rapport with your team and keeping on top of what’s going on with your employers. This is really the only way you’re going to be able to identify minor issues before they become big problems, and has knock-on effects on employee retention, team morale, and productivity.

    This blog post is a sample chapter from my book:
    How to Hire and Manage Remote Teams

  • I just figured out how to use Font Awesome 6 in a Rails 7 project that uses importmaps. I’m not entirely sure why this works and why some of the workarounds are needed, but my googling yielded no results when I was searching so hopefully here I’ll be saving the next person some time.

    If you search Rubygems for gems with the name “font awesome” you’ll find quite a few but I didn’t like any of them. They all use the font version of the icons, instead of the SVG, or they are very outdated, or they expect you to use SCSS, which I’m not using at the moment. But ultimately, the team at Font Awesome maintains the NPM packages and we should use those directly, not re-wrap packages that will always be out of date.

    For me, using NPM packages directly was higher priority than using importmaps. That’s how strongly I feel about it. I would have installed Webpacker to use Font Awesome’s main package.

    I managed to make this work, but if I’m frank, I’m not 100% sure why the workarounds are needed, so if you have any insights about it or how to improve this, please drop a comment.

    Font Awesome’s documentation says you should install the fontawesome-free package:

    npm install --save @fortawesome/fontawesome-free

    Instead we are going to pin that package, but also some of the dependencies we need later:

    ./bin/importmap pin @fortawesome/fontawesome-free \
                        @fortawesome/fontawesome-svg-core \
                        @fortawesome/free-brands-svg-icons \
                        @fortawesome/free-regular-svg-icons \
                        @fortawesome/free-solid-svg-icons

    This adds the following lines to your importmap.rb:

    pin "@fortawesome/fontawesome-free", to: "https://ga.jspm.io/npm:@fortawesome/[email protected]/js/fontawesome.js"
    pin "@fortawesome/fontawesome-svg-core", to: "https://ga.jspm.io/npm:@fortawesome/[email protected]/index.es.js"
    pin "@fortawesome/free-brands-svg-icons", to: "https://ga.jspm.io/npm:@fortawesome/[email protected]/index.es.js"
    pin "@fortawesome/free-regular-svg-icons", to: "https://ga.jspm.io/npm:@fortawesome/[email protected]/index.es.js"
    pin "@fortawesome/free-solid-svg-icons", to: "https://ga.jspm.io/npm:@fortawesome/[email protected]/index.es.js"

    Then Font Awesome’s documentation says you should add these lines to your code:

    <script defer src="/your-path-to-fontawesome/js/brands.js"></script>
    <script defer src="/your-path-to-fontawesome/js/solid.js"></script>
    <script defer src="/your-path-to-fontawesome/js/fontawesome.js"></script>

    Which might make you think this is a good idea:

    <script defer src="https://ga.jspm.io/npm:@fortawesome/[email protected]/js/brands.js"></script>
    <script defer src="https://ga.jspm.io/npm:@fortawesome/[email protected]/js/solid.js"></script>
    <script defer src="https://ga.jspm.io/npm:@fortawesome/[email protected]/js/fontawesome.js"></script>

    But it doesn’t work. It fails with this error:

    Here I’m a bit confused. How come it fails with that error? Any ideas?

    What did work was editing app/javascript/application.js and adding::

    import {far} from "@fortawesome/free-regular-svg-icons"
    import {fas} from "@fortawesome/free-solid-svg-icons"
    import {fab} from "@fortawesome/free-brands-svg-icons"
    import {library} from "@fortawesome/fontawesome-svg-core"
    import "@fortawesome/fontawesome-free"
    library.add(far, fas, fab)

    I can’t help but feel that there’s a function or method in fontawesome-free that I could call that would do all the setup automatically with less imports and less library building, but I couldn’t find it yet.

  • I’m an avid reader and I review every single book I read. I force myself to write at least two paragraphs. This is useful to me because sometimes I forget I have read something; seeing and reading back my own reviews answers the ‘did I already read that’ question but also refreshes my memory on what I thought of it. I do this in Goodreads, where I’m asked to provide a star quality rating of the book, and that’s where the problem starts.

    Normally, I rate them for myself and my rating is this:

    • 5: Amazing book, humanity is better off because this book exists and everyone should read it.
    • 4: Great book, will recommend it to most people.
    • 3: Good book, I enjoyed reading it.
    • 2: Bad book, I didn’t enjoy reading it.
    • 1: Terrible book, this is actively harmful for humanity and should not have been written.

    This naturally means most of my books get 3 stars, some 4 and 2 and even less 5 and 1. It’s a bell curve! Which should surprise no one. Actually, I think there are way more books in the 1-star category out there for consumption, it’s just very rare I accidentally read one. 

    But this is not how most people use star ratings. And it is also not how we are encouraged to use them either. Take Uber: in the event you did not give five stars, it specifically requests you to answer what was wrong with the trip. If the trip was perfectly adequate, it is expected that this be rated five stars. The upshot of this is that there is no way to reflect service that went above and beyond, or was otherwise better than ‘fine.’

    So most people give 5 stars unless there’s something wrong, in which case they start removing stars. 1 thing wrong? 4 stars. 2 things wrong? 3 stars. I think this is a bad way of rating things because, as mentioned above, it means you have no way of differentiating good, great and amazing: they all get the same 5 stars. For a service like Uber this is not such a problem, but for artistic works and for books it doesn’t fit. 

    I used to just do the rating for myself so I didn’t care I was using a different system to the rest. But when publishing on Goodreads and interacting with other people it became rather controversial: I have received both praise and criticism for this. Some people caught on and they know that when I give 4 and 5 stars, it’s a rarity and worth taking a look. Some people asked me why a book that I enjoyed, and recommended to them, is getting only 3 stars.

    What’s really bothering me with my discrepant system is that an author gets a (small) penalty for me being interested in them. Granted, this is tiny and unlikely to be noticed in the grand scheme of readers, but it still bothers me. Their average will go down, which negatively affects public perception, even though it really shouldn’t be perceived that way (to my mind). It also bothers me that an author might see 3 or 4 stars and be hurt and then confused by my positive review.

    Should I give up and remap my review system to what everyone else is doing? I dislike losing a way to signal “This book is amazing” By all means send your suggestions.

  • When I was a kid, my dad and I had a (friendly) argument. I said that digital displays were better and I wanted them everywhere, for example, as the speedometer of a car. My dad said that dials were better and he made his point:

    Dials are faster to read and remember and if the needle is oscillating, you can still read it and now what the average is.

    — My Dad

    He was right. If your speed was rapidly oscillating between 98km/h and 102km/h on a dial, it was trivial to read, on a digital display, it would be a blur that looks like 199km/h. You could solve it by dampening oscillations, but that creates other problems (lags) and it’s a boring solution.

    My dad was right, so I decided to solve the problem. I spent years thinking about and came up with a solution when I was 13 or so. A numbering system where only one digit changes at a time. Let me demonstrate. 0 through 9 is the same: 1, 2, 3, 4, 5, 6, 7, 8, 9. But the next number can’t be 10, because that’s changing two digits at the same time, so it’s 19… now what? Now you go down until you hit 10 and then you can go to 20, because between 10 and 20 there’s only one digit difference. Here’s from 1 to 30, highlighting the ones that are different:

    Normal PSDC
    0 0
    1 1
    2 2
    3 3
    4 4
    5 5
    6 6
    7 7
    8 8
    9 9
    10 19
    11 18
    12 17
    13 16
    14 15
    15 14
    16 13
    17 12
    18 11
    19 10
    20 20
    21 21
    22 22
    23 23
    24 24
    25 25
    26 26
    27 27
    28 28
    29 29
    30 39
    31 38
    32 37
    33 36
    34 35
    35 34
    36 33
    37 32
    38 31
    39 30

    The way it works is that when a digit is odd in the original normal decimal number, the next digit is PSDC is inverted. This is the Python code to convert numbers to PSDC representation:

    def convert_to_psdc(number):
      digits = [int(n) for n in list(str(number))]
      new_digits = []
      for i, digit in enumerate(digits):
        if i == 0 or digits[i - 1] % 2 == 0:
          new_digits.append(digit)
        else:
          new_digits.append(9 - digit)
      return int("".join([str(d) for d in new_digits]))

    Here are a few interesting PSDC numbers:

    Normal PSDC
    0 0
    1 1
    9 9
    10 19
    11 18
    18 11
    19 10
    20 20
    21 21
    99 90
    100 190
    101 191
    189 119
    190 109
    191 108
    999 900
    1000 1900
    1001 1901
    1900 1090
    1901 1091
    9999 9000
    10000 19000
    10001 19001
    99999 90000
    100000 190000
    100001 190001
    999999 900000
    1000000 1900000
    1000001 1900001
    9999999 9000000
    10000000 19000000
    10000001 19000001

    Problem solved! Not really, this is useless… but for some reason 13 year old me started to be obsessed with this and I still think about it frequently.

    If you want to see all the PSDC numbers up to 10k, I published a table on this site.

  • When you are building a B2B SaaS product it’s very hard to know what the appropriate price for your product is. Even if you magically found the correct one, it might not be the correct one next month when you made the product better and you are providing new values. That’s why you need to be constant experimenting with prices on your app.

    When I started my career I was afraid of raising prices, of having to justify why they went up (I wasn’t even aware of grandfathering). When I started to learn that most entrepreneurs set their prices too low, my partner and I decided to set the price too high and then lower it if it was necessary. Without realizing we painted ourselves to a corner.

    We didn’t want to just lower prices, we wanted to experiment with prices (switching from per-user to 3 plans, things like that). The problem was that anything we would come would cost a different amount for each customer. For some customers it would go up, and that wasn’t a problem, because we would grandfather them in. But for some customers it would plummet.

    There were two options for those customers:

    • Lower their prices according to the new plans and lose the revenue.
    • Don’t lower their prices and risk them being very angry about overpaying.

    Because we were a bootstrapped startup living month to month, every time we discussed this we would get stuck in a cycle of what-ifs one or the other situation. Eventually one day we made a rule of forbidding talking about pricing (trying to get some work done, because we would spend days and days discussing pricing).

    Eventually I found myself wishing that instead of starting with a high price and lowering it for experimentation, that we started with a low price and raising it for experimentation. We would have experimented much more. There’s another obvious solution which is not depend on the sweet revenue of those high prices. But even though it’s simple, I don’t think it’s easy… like sitting in front a pizza and not having a slide. Yeah… right!

    Next time I want to increment prices over time and even then try to give myself room for experimentation.

  • Almost every time I tell someone what Dashman, one of my startups, was, their response is: “Oh, I really needed that back in 20somethingteen”. Yet I didn’t manage to make Dashman a commercial success.

    I collected several hundreds of email addresses over years of people interested in Dashman. Yet it failed, nobody bought it.

    How can a product show that much demand and have no sales?

    I’m purposely not telling you what Dashman was, because it doesn’t matter.

    I think the problem is that Dashman had a demand curve with a shape I didn’t predict. People would find themselves needing Dashman to solve a problem and would happy become a subscribing customer if Dashman was right in front of them… but… and this is the important part…. if Dashman wasn’t, they would find a workaround and not need it anymore. If I came a year later with Dashman they would buy because the workaround was working and switching was not worth the effort because their current pain around this issue was 0.

    Dashman solved a pain that generally stayed around for a couple of weeks and then disappeared. It didn’t matter if the pain was intense or not, it went away. You know what market behaves like that? Weddings. If you have a great idea for a product for Weddings and you spend 5 years collecting people that want to use it, once you release it, how many would start using it? Maybe the last couple of months of interested people. Everyone before that is already married and your product is worthless to them.

    I have heard weddings being a bad industry to work at but in all the books about building products in which they tell you to find the customer first I never read “make sure your demand doesn’t dissipate with time“.