Pablo Fernandez

  • Be distributed because it’s cooler, not cheaper

    ,

    There are two motivations that drive the creation of distributed teams or companies:

    • it’s cheaper
    • there just isn’t any available people locally

    There’s nothing wrong with these motivations as starting point, but if they become your sole driver for being distributed the results are probably going to end badly. Remote workers will be treated as cheaper handicapped workers and nobody likes being on that position. Soon they’ll find another better company to work for.

    Also, if you expect that a distributed company behaves the same way as a local one, you’ll end up with a dysfunctional organization (something that’s happening to a lot of companies during the pandemic, they are now distributed but they behave as if they are not).

    To build an effective distributed team engage the cool factor: we are all different, we are more diverse, we bring variety and we feel very strongly about living where we live. Celebrate the distributeness. This will not happen automatically and as a manager/leader at a distributed company, you have to make it happen. Same thing with socializing and bonding: it will not happen automatically as it might if you are all in the same room, and the manager/leader is in charge of making it happen.

    Here are some examples of things you can do:

    • Create a Slack channel where people can share pictures of their food. People will show off the good and bad of the food of where they live. People might end up exchanging recipes.
    • Follow news of the countries/cities where your staff is located and if something major happens, reach out to check on their well-being. Send the signal that you care about where they are, not just that they are far away.
    • Create optional and mandatory engineered social time for people to hang out together. A small amount of mandatory bonding is a good thing, because otherwise it may not happen at all (there’s no water cooler), but don’t force people to be away from their families for a gaming night to avoid losing status at the company.
    • Embrace hobbies, activities and lifestyles. People that work remotely they often care deeply about somethings, like their families, living in rural areas, having more free time, being able to work with constraints, hobbies that are location specific. Celebrate all of that.
    • Allow extra flexibility: don’t expect them to work 9 to 5, but know that they can still work hard or harder and even for more hours. Allow someone to break away from work to go pick up the kids from school in the middle of the day but they fixed a ticket in the middle of the night.

    If you want to learn more, I highly recommend The Year Without Pants. If you want some help distributing your company, feel free to contact me.

  • My biggest hiring secret: text interviews

    , ,

    I built a kick-ass team of 6 developers in little over 6 weeks, by myself, doing all the hiring and without using any recruiters. When I tell people how I did it there’s one aspect of my hiring process that raises the most eyebrows: text interviews.

    When someones profile looks promising (CV, GitHub, cover letter) I send them a text message over Google Hangouts, WhatsApp, Signal, etc asking them if they are free for 10 minutes. I don’t even book a time, it’s a short informal text conversation. The goal is to evaluate how good they are at maintaining that type of communication which is important for all development teams and essential for distributed ones. These are some of the questions I ask:

    • How did you learn to code?
    • How did you learn programming language X?
    • What do you want to learn next?
    • What are the pros/cons of distributed companies?
    • Can you tell more about project X?
    • In your application you said X, what did you mean? Can you clarify?
    • Do you have any questions for me?

    The sad reality is that a lot of people don’t pass this stage and only a few pass it with flying colors. This makes it a good filter to put at the very beginning.

    But there’s another reason why this is a good first filter: I can hold several text conversations at the same time. I can probably interview about 4 people at the same time this way. Or, I can interview 1 or 2 as I keep on doing other work, reading documents, addressing questions, etc making it not only of high efficacy but also highly efficient.

    I didn’t invent this, I was inspired by how Automattic hires according to The Year Without Pants. If you have any questions feel free to just ask in the comments and if you need any help hiring developers, don’t hesitate to contact me, but know that I’m not a recruiter.

  • From bank to Google, what’s your staff onboarding like?

    , ,

    I remember two onboarding experiences the most. Joining Google was an amazing experience, I felt like a hero in a hero’s parade. Joining a Swiss Investment Bank made me question my life choices.

    Google

    At Google, I had clear instructions sent to me well in advance about what to expect, where I was supposed to show up. I was taken step by step like clueless tourist in a packaged tour. There was one whole week of super interesting lessons about the ins-and-outs of Google, from the amazing (how does search work) to the mundane (how do I log in to my own computer). It was like being a Disney World. My manager personally came to pick me up from the cafeteria where us nooglers (new googlers) would be hanging out to take me to my brand new desk ready for me to start learning more.

    The Bank

    At the bank I had to convince the receptionist that I worked there, get her to issue me a badge and then give me some instructions on how to find my team. When I finally did I and said hello to my manager he said:

    Oh, I forgot you were starting today. I didn’t order your computer, I’m doing that now, it’ll take 2 weeks. Go find someone to pair with.

    I was faced with a sea of 200 grumpy-looking people of which about 4 were in my team but I wasn’t sure who, or their names, and there was no way for me to find out. This is a horrible way of onboarding socially awkward introverts. It made me feel bad for weeks, months even.

    The Strategy

    When designing an onboarding process for your new staff, I believe this is the strategy to follow: don’t make newcomers do any work other than what you are paying them for.

    New staff shouldn’t spend any amount of time trying to figure out the company, navigating complex undocumented hierarchies of people, wondering what to do if their computer doesn’t start, finding out where critical information is stored by accident, learning what tools to use because they overheard someone else talk about it, not knowing where the central documentation is, etc.

    If you like to learn more about staff onboarding tactics, let me know and I’ll write a follow up post. If you need any help designing the onboarding experience at your company feel free to contact me, I’m very passionate about it.

  • How I’m testing seed data generation

    , , ,

    When I create a new Rails project I like to have a robust seeds that can be used to quickly bootstrap development, testing and staging environments to interact with the application. I think this is critical for development speed.

    If a developer creates a feature to, for example, connect two records together, you just want them to fire up the application and connect two records to see it work. You don’t want them spending time creating the records because that’s a waste of time, but also, because all developers end up having different subsets of testing data and generally ignoring everything that’s not included in them. It’s better to grow a set of testing data that’s good and complete.

    One of the problem I run into is that generating testing data, or sample data, doesn’t happen often enough and changes in the application often break it. Because of that, I wrote this simple test:

    RSpec.describe "rake db:seed" do
  it "runs" do
    Imok::Application.load_tasks if Rake::Task.tasks.none? { |t| t.name == "db:seed" }
    ENV["verbose"] = "false"
    Rake::Task["db:seed"].invoke
  end
end

    It doesn’t have any assertions, but with just a few lines of code it probably covers 90% of seed data creation problems, that generally result in a crash. I would advice against having assertions here, as they may cost more time than the time they’ll save because sample data evolves a lot and it’s not production critical.

  • The startup CTO dilemma

    About 10 years ago I took my first job as CTO but I wasn’t a CTO, I just had the title. I was a developer with ambition. I made mistakes, very expensive mistakes, mistakes that contributed to the failure of the startup. Since then I have learned and grown a lot and although there’s still a lot for me to learn, there are some things I understand reasonably well. One of those is how to be the CTO of an early and not so early stage startup.

    With this experience, though, my salary went up. I’m more expensive now than I was 10 years ago and I didn’t know what I was doing. Because of this, I tend to evaluate working for a startup not on day 1, but on day 700 or later, when they have some traction, revenue, etc. The problem is that a lot of those startups are deep in problems that are very hard or impossible to fix by that point. It’s very painful for me to see expenses that cost hundreds of thousands of dollars because someone didn’t do 30 minutes of work 5 years ago (this is a real example).

    So, the dilemma is this:

    • If a startup hires an experienced CTO from day 1, they are wasting money because they might only be spending 5% or 10% CTOing and the rest coding, doing IT, etc. which can be done by a less experienced developer.
    • If a startup doesn’t hire an experienced CTO from day 1, they are likely to make very expensive mistakes that may literally kill the startup in year 3 or it may slow it down a lot.

     I’ve been thinking about this for a while, how can this be solved?

    One of my ideas was being a sort of CTO enhancer, to be the voice of experience for a less experienced co-founding CTO, helping them a few hours a week for a few months up to a couple of years. What do you think? Does this sound valuable? Useful?

    I might be thinking a lot about this lately since I’m leaving my current job and searching for the next thing to do.

  • Nicer printing of Rails models

    ,

    I like my models to be printed nicely, to make the class of the model as well as the id and other data available, so, when they end up in a log or console, I can now exactly what it is. I’ve been doing this since before Rails 3 and since Rails projects now have an ApplicationRecord class, it’s even easier.

    On my global parent for all model classes, ApplicationRecord I add this:

    def to_s(extra = nil)
  if extra
    extra = ":#{extra}"
  end
  "#<#{self.class.name}:#{id}#{extra}>"
end

    That makes all records automatically print as:

    <ModelName:id>

    For example:

    <User:123>

    which makes the record findable.

    But also, allows the sub-classes to add a bit of extra information without having to re-specify the whole format. For example, for the User class, it might be:

      def to_s
    super(email)
  end

    so that when the user gets printed, it ends up being:

    <User:123:sam@example.com>

    which I found helps a lot with quickly debugging issues, in production as well as development environments.

  • Editing Rails 6.0 credentials on Windows

    , , , ,

    Rails 6 shipped with a very nice feature to keep encrypted credentials on the repo but separate them by environment, so you can have the credentials for development, staging and production, encrypted with different keys, that you keep safe at different levels.

    For example, you might give the development key to all developers, but the production keys are kept very secret and only accessible to a small set of devops people.

    You edit these credentials by running:

    bundle exec rails credentials:edit --environment development

    for the development credentials, or

    bundle exec rails credentials:edit --environment production

    for production ones. You get the idea.

    When you run it, if the credentials don’t exist, it generates a key. If they exist, you need to have the keys. After decrypting, it runs your default editor and on Windows, this is the error I was getting:

    No $EDITOR to open file in. Assign one like this:

EDITOR="mate --wait" bin/rails credentials:edit

For editors that fork and exit immediately, it's important to pass a wait flag,
otherwise the credentials will be saved immediately with no chance to edit.

    It took me a surprisingly long time to figure out how to set the editor on Windows, so, for me and others, I’m documenting it in this post:

    $env:EDITOR="notepad"

    After that, running the credentials:edit command works and opens Notepad. Not the best editor by far, but for this quick changes, it works. Oh, and I’m using Powershell. I haven’t run cmd in ages.

  • Talk to each other, you are missing out

    For the past few weeks I’ve been talking to entrepreneurs, trying to help with their problems. I’ve heard both of these statements repeated a few times:

    Marketing is easy, but coding is impossible.

    Marketeers

    and

    Building a thing is fun, but then I have no idea how to market it.

    Coders

    It’s frustrating to hear both this things at the same time. Even within each of the communities, inside Indie Hackers, Microconf, TWiST, we seem to have subgroups of techies and non-techies that talk among themselves but not to one another and they are both wondering where the other ones are.

    Please: start talking to one another, you need those connections, your idea need those connections.

    If you are either a marketer or a coder and want the other one to join your team as a non-paid co-founder you are asking them to make an investment. A huge investment in terms of personal wealth. A person might be able to start 10 startups in their life, so, you are asking them for 1 tenth of their resources. Act accordingly. Put the effort, show traction, show results. I see people put more effort into talking to an investor that will invest only 1% of their resources.

    The second thing a lot of us should do, and this include me, is not focus so much on our own ideas and try to work on other people’s ideas. Build someone else’s thing, market someone else’s thing. Don’t chase one idea, chase the outcome of a successful startup and accept that it might not be your idea.

    If you are a developer, know this: whatever idea you come up with, it’s an idea that another developer is likely to have, and likely to implement to compete with you. That’s why there’s so much out there in terms of Twitter clones, issue trackers, cryptocurrencies thingies, etc. A non-coder idea has the value of less competition. A CRM for a niche you’ve never heard of might be the best SaaS ever!

    If you are a marketer, know this: even in a crowded space, you can make a difference because there are a lot of companies out there that have a great product and are struggling with marketing. I often find a market need, like, “Private teachers need booking systems” and in my market research I find that the perfect booking system exists and nobody is using it. Lending your superpowers to a developer that’s charging ahead with building yet-another-whatever might be the best SaaS ever!

  • The Voyager 1 museum

    , ,

    Voyager 1 is, as of now, 22 billion kilometers away from home. One day, we’ll be a space-faring species and we’ll have Voyager 1 in a museum. It’ll be trivial for us to go and reach Voyager but we won’t retrieve it. What’s wonderful about Voyager 1 is not only the amazing science and engineering that we can see on the metal, plastics, cables, circuits, panels, batteries, etc. What’s amazing is it’s vector: direction and speed.

    We’ll build a museum around Voyager 1 for people to visit and see it travel. The museum will have to be built very carefully, bringing materials from all directions at the same time, in a balanced way, to avoid affecting Voyager’s trip. Even the visitors will have to be controlled to avoid affecting it.

    We’ll marvel at what once was the man-made object furthest away from earth, from home, from the cradle back when all of mankind lived there. Billions of minds will visit it and marvel through the millennia. The museum will act as beacon for commerce and science to stay away of its path… until that day.

    One day, Voyager 1’s path will intersect with something else. It might be a planet, an asteroid, a star, a black hole. The odds are astronomical you might think, but so is, well, space and time.

    That day unrecognizable humanity will gather to decide what to do. We’ll be mature enough to not need that piece of metal somewhere safe and instead we’ll say good bye.

    Part of humanity will gather around, for weeks, maybe even months. We’ll have a festival in space about the 20th century, about how fucked it was, marveling at how close humanity came to self destruction and still produced Voyager 1. We’ll watch movies, attend concerts, both old and new. And eventually, the museum we’ll retreat and so we’ll we. We’ll all watch is silence as a relic of our infancy reaches the end of its life, as it collides and disintegrates. We’ll celebrate it, we’ll mourn it.

  • Finding a co-founder for your startup

    ,

    Update: this list is now being maintained on it’s own page: Finding a co-founder

    Someone recently contacted me at MicroMentor with a few questions about their startup, including, how to proceed without a business partner. I told him he should probably find one and then I discovered I had more co-founder search resources than I thought:

    Any other resources you are aware of?