DEV Community: José M. Gilgado

How to be a better remote worker

José M. Gilgado — Tue, 15 Oct 2019 15:44:52 +0000

The current scene, with so many companies working remotely, leaves the employees with some changes in how things work in a company when there's no office that are not obvious. Dynamics, habits and workflows change to some extent in a remote organization.

In this article, I share some of the things I've learnt in the last few years that helped me from the perspective of a regular employee in a fully remote company (Buffer). Let's start!

Open communication by default

How do you know if your teammate is blocked? Or if you're a manager that you're happy with somebody's performance. How does the team lead know what's the current status of a project?

These questions, as necessary as they are, are hard to answer in a remote company since they're usually answered over coffee or just by physically walking to the other person's desk if you work in an office. When you work remotely, you need to actively think about giving them their space.

By working remotely you need to change your mindset and communicate by default all you do and how you are feeling with your current workload/team/schedule. Yes, this will have an impact on your time available for other things but on the other side you shouldn't have too many interruptions. How should do this?

Any format is good as long as is easy to use and transparent to the rest of your team. There are teams that do daily asynchronous standup, others keep track of everything in a tool like Jira or Trello. It's up to you but you need to communicate way more than in a regular company. Some tips:

Have you made progress in a task? Leave an update in the card.
Are you blocked or feeling that the current task is too hard? Reach out as soon as possible and ask for help.
Have you found something unexpected that might delay the whole project? Prepare a quick document with the context and share it with the team.
Have you had an idea on how to improve something? You know the drill 😉.

The alternative to this "over-communication" are isolated teams and team members, no transparency with stakeholders, not knowing where things are and how far you're with a project and an overall feeling that the team or full company is not driven towards a particular direction and everyone is just doing their own thing.

Try to think who might be interested in knowing something, how much they know and how to share that as clearly as possible. This also implies that sometimes you might need to communicate the same thing more than once. For example, if I've just completed a task I might share:

The full context of the technical details with my teammates if it's interesting because maybe I refactored something.
The current status with the product manager and the designer.
The change that this will bring and potential issues customers might find with the customer support team.

In each case, the context I'll provide and the information will be focus on what those people know. The refactoring part probably doesn't matter to the customer support team for example.

Your schedule is yours and yours only

Use it to your advantage. I've started working sometimes at 4:30 AM because I was feeling great and finished that day earlier too. I was more productive and had more quiet time before the rest of my team woke up.

Some days I knew I had a couple of calls in the evening so I spent the first few hours of the day working out or doing something else.

The key here is finding that balance because for the most part you won't have anyone telling you need to work from 9 to 5. In a remote company, your output is way more important than the hours you put in. As long as you perform well you should be ok.

This also applies to your workspace, try different things and see what works better for you, it might be a co-working space, an occasional walk to your favorite coffee shop, it's up to you but try different things and see how it feels.

You're not alone, help others

In my experience, it's much easier to isolate yourself working on your own thing, or even not collaborating with almost anyone if it's not strictly required. At the end of the day, you're mainly focus on your output so it's easy to forget that you have the chance to learn and collaborate with your teammates. Some actions could be:

Send a message in your team channel or email group if you need help.
Reach out to one of your teammates at your level of experience to chat about vision, strategies to improve or a new book you've read that it's influencing the way you work.

If something feels off, say it

Or, as the old saying goes, give feedback 😊. I'd say this is equally important in an office but in a remote environment is slightly harder, you need to actively reach out to someone to share it, it doesn't happen casually over coffee.

Depending on the kind of company you're working, you might need to adjust this or be more or less direct. Some companies love feedback at every level and others don't but if you have the chance, sharing feedback early and often it's a great exercise to improve as a professional and you're opening the door to some feedback for you, which is even better.

It'll feel odd at first, it's hard to give and even harder to receive feedback but there's no other way to know that what you or others are doing can be better.

Some tools that helps in the company I work for, Buffer, are:

Anonymous link that we all have to share feedback anytime.
Q&A with the CEO and leaders every month or so where you can submit questions anonymously (or signed).
Anonymous survey every quarter from the company.
Retro sessions where we can share how we feel in our team and what we could improve.
A general culture of welcoming feedback.

The key realization about feedback for me was that it's not about you, your ego, your work culture or anything like that, it's just about a specific action that you did or didn't do and where you can improve next time. It's only that, don't make it bigger.

Be creative and proactive

When you're in an office, ideas flow all the time. People talk about ideas, ways to improve things, something they've read about another company that's great and they could use, etc.

When you're working remotely, you tend to focus much more on the task at hand so it's very important to take a step back from time to time and come up with some ways to improve things that might be different from what you've been doing.

When was the last time you took a couple of hours to think and plan? Make it a habit. Every x days, book some time off and do it. Paper, drawings, a whiteboard or even a walk in the nearest park with a notebook can help.
Share ideas early and often. Also related to the open communication you need to maintain, but in this case it's a great way to invite others to work on new things that will improve the company. Be specific with the kind of feedback you want to receive from the people you ask, are you asking for approval, real feedback or it's just FYI? Be sure to mention that with the people you share it. For example, for other teammates in another team something might be FYI but for my CTO or closer teammates I want their real feedback on an idea.
Innovation comes from different places, expose yourself to new ideas. Books, conferences, chats with other people in the industry, tweets!, podcasts, videos... the list is big and you don't know where the next good idea might come from. Make sure you read/watch/listen some different people and companies to get new ideas that you can try.

Find a mentor

If you have someone you admire, or someone you feel you can learn a lot from, talk to that person often and ask them questions. A mentor-mentee relationship doesn't have to be anything formal or official and you can have multiple people you respect, in or outside your company, that you can learn from. Use that to get more knowledge, improve, ask questions, learn from the same sources they learn and you'll see a lot of improvement soon.

Align with the team or company's goals

These goals are usually shared transparently and they're a very good indicator of what's most important at this point for your team or the company.

They might be focus on growth, quality, scaling the team by hiring and mentoring new people, pivot to another product or industry, etc. You'll soon discover in your career that almost all the software companies share the same problems, they only vary in degree.

Make those goals your goals as well and try to come up with ways on how you can contribute. For example:

Is the company hiring a lot? Volunteer to onboard those new teammates or even interviewing new candidates.
Is the focus on growth? Try to come up with some ideas to improve your and your team's effectiveness when working. It could automated tests, a CI system with a quick deploy process or better flows to communicate changes.
Is the company pivoting to another product/industry? Go ahead and discover people in your position working in those products. What do they know? How do they work? What are their main challenges? Anticipate to those questions in your company and bring solutions.

Focus on one thing at a time and one thing only

Constantly ask yourself, what's the most important and impactful thing I could be doing and then go ahead and only focus on that until you finish it.

Make that reflection a habit, a daily, weekly, quarterly one. There are big things and small things. Mentoring other people is a big thing, solving a problem that's affecting and delaying other engineers is a small one but both could be equally important depending on the situation.

Focus on the things that don't change

Jeff Bezos famously shared that Amazon actively focuses on the things that don't change even if it's in the long term. You won't want to wait longer in the future for a package, or have less products on Amazon so can't buy what you need, or have a slower website where you can buy products. If you focus on improving those things, customers will appreciate it and buy more from you.

There's a great exercise you can make with that idea: think about the aspects of your product or workflow that won't change in the future and whose constant improvement will always bring benefits to the team. You don't need to be in a high level position for doing this, you don't need to be the CEO or CTO of that company, even a junior software engineer or manager can contribute with this approach.

Here are some challenging questions that helped me:

How long does it take to load your main product's site?
How do you know if something fails in your product?
How long does it take from idea to execution in your team if the idea is great?
Is there a way to automatize that little thing you need to do almost daily? What would be the impact in a week if you and each of your teammates could save 5 minutes on a daily basis? And in a month? What about in a year?
From the X hours you work every day, would there be a way to come up with a schedule that makes you more efficient?
Do you need to explain that little thing that's particular to the project every time or could you just create a written resource so others won't need to ask next time?
After some time working there, if you started again in the company tomorrow, what are the things you'd like to have to be more productive from day one? Could you help creating those resources for the new people that will come?
Do you have some annoying things that fail from time to time but haven't fixed yet? How much is that delaying you and your teammates? How is that affecting your motivation?

Other ideas?

Do you have other ideas that have helped you? Reach out on Twitter! 🙂

Intro to bitwise operations

José M. Gilgado — Wed, 09 Oct 2019 13:39:47 +0000

Bitwise operations are really useful and fast for storing and operate on certain values. They are way more used in systems where resources are more limited like video-games or embedded devices.

In this first article about bitwise operations, we get a quick introduction to them with a drawing (new format!) and some written content but I plan on sharing more 🙂.

What are bitwise operations?

They're operations that deal with bits directly. Bits are 1s and 0s and it's how everything is stored internally in a computer so being able to operate with them directly is very efficient because the processor is able to do those operations natively. Wikipedia says:

...typically, bitwise operations are substantially faster than division, several times faster than multiplication, and sometimes significantly faster than addition...

The three basic operators

There are more but let's take a look today at the three most basic operators:

NOT

NOT is very simple, if there's a 1 we get 0. If there's a 0, we get 1.

It's represented by ~ in most programming languages so for example:

~0101011 = 1010100

AND

AND is like the boolean equivalent you already use in if conditions but with one difference, this operates at the level of bits:

1 & 1 = 1
1 & 0 = 0
0 & 1 = 0
0 & 0 = 0

OR

The same goes for the OR operation, represented with the | symbol in many programming languages.

1 | 1 = 1
1 | 0 = 1
0 | 1 = 1
0 | 0 = 0

How they operate with more than 1 bit

The key here is to remember that when we have a bitwise operation with more than 1 bit, we do it bit by bit. For example:

// Bitwise OR
111010
001100
-------
111110

Or in an AND operation:

// Bitwise AND
111010
001100
-------
001000

Real life example:

Full drawing here

In a future article we'll see other operators because you can do some very efficient calculations with numbers but we need more than just these three. See you soon!

CS Basics: How to refactor a boolean expression

José M. Gilgado — Wed, 25 Sep 2019 16:20:43 +0000

Intro to series

Computer Science sounds so boring, so academic, that sometimes it's hard to know if there's even any useful knowledge for our jobs building actual software.

Of course, I'm half joking. Computer Science is very important to understand what's going on in a computer but I understand it doesn't sound as attractive as learning a specific technology that's in demand in the industry.

With this series of posts, I'll try to extract from those long boring books a few things we can start applying right away and I hope you'll find useful.

I'll always start with the immediate practical part and then I'll explain a bit more about the underlying reasons and terminology.

Let's start today with some boolean expressions.

Why is it useful to refactor a boolean expression?

It has happened to me many times that, when refactoring a condition, I had to change it to create a method that makes sense in the class. Let's show an simple example.

Imagine we have the following class (in Javascript, but can be applied to almost any language):

class Person {
  constructor(name, active, email = null) {
    this.name = name;
    this.active = active;
    this.email = email;
  }

  hasEmail() {
    return this.email !== null;
  }

  isActive() {
    return this.active;
  }

  sendEmail() {
    if (!this.isActive() || !this.hasEmail()) {
      return false;
    }
    // ... send email ...
  }
}

At some point we realize that it might be easier to have an internal method that can tell us if the user can receive emails. According to the code that'd mean that it's an active user and has an email set.

We could do this:

  canReceiveEmail() {
    return ; // What do we return here? 🤔
  }

  sendEmail() {
    if (!this.canReceiveEmail()) {
      return false;
    }
    // ...
  }

As you can see the sendEmail method is more readable now, but what should we put in the canReceiveEmail() method?

I'll let you think for a second...🙂

🤔🤔🤔🤔🤔🤔🤔🤔🤔🤔🤔🤔🤔🤔🤔🤔🤔🤔

🤔🤔🤔🤔🤔🤔🤔🤨🐶🤨🤔🤔🤔🤔🤔🤔🤔🤔

🤔🤔🤔🤔🤔🤔🤔🤔🤔🤔🤔🤔🤔🤔🤔🤔🤔🤔

Did you figure it out?

What we need is the opposite value of the condition we had:

!this.isActive() || !this.hasEmail();

The negation of that expression would be:

this.isActive() && this.hasEmail();

I think intuitively we can understand that if what we were looking for is that:

The user is not active OR doesn't have email;

The opposite would be that:

The user is active AND has email.

So the final class would look like this:

class Person {
  constructor(name, active, email = null) {
    this.name = name;
    this.active = active;
    this.email = email;
  }

  hasEmail() {
    return this.email !== null;
  }

  isActive() {
    return this.active;
  }

  canReceiveEmail() {
    return this.isActive() && this.hasEmail();
  }

  sendEmail() {
    if (!this.canReceiveEmail()) { // Notice negation of the method with !
      return false;
    }
    // ... send email ...
  }
}

(see in JSbin)

We could also have created the negative version cannotReceiveEmail but I prefer to use "positive" method names since they tend to be more useful in other places of the code. Nevertheless, If we had done that the result would have been:

cannotReceiveEmail() {
  return !(this.isActive() && this.hasEmail());
}

sendEmail() {
  if (this.cannotReceiveEmail()) {
    return false;
  }
  // ... send email ...
}

Computer Science behind solution

What you just saw wasn't discovered recently, the mathematician who formulated this solution, Augustus De Morgan, died in 1871.

This rule, along with another one we'll see in a bit, are called "De Morgan's Laws". They're part of a bigger field in Mathematics and studied in any computer science course, called Boolean Algebra.

The other rule is as follows. If we have this expression:

const willDieSoon = !this.isYoung && !this.worksOut

It's equivalent to:

const willDieSoon = !(this.isYoung || this.worksOut)

If you didn't get this one, think about what would happen in all the potential conditions:

Consider isYoung is true/false and worksOut is true/false. What would be the result of the expression? Wouldn't that be the same that in the first case?

To truly understand this, it's often useful to create a small table of possibilities. The last column represents: willDieSoon.

isYoung	worksOut	isYoung OR worksOut	!(isYoung OR worksOut)
false	false	false	true
true	false	true	false
false	true	true	false
true	true	true	false

The same table can be applied to the first expression:

isYoung	worksOut	!isYoung AND !worksOut
false	false	true
true	false	false
false	true	false
true	true	false

The Morgan's Laws

So the two rules, written in a formal manner, would be:

This image is from Wikipedia since I'm not sure how to add math symbols in dev.to 😞.

So in Javascript, we could say this is:

!(P || Q) == !P && !Q

!(P && Q) == !P || !Q

We've used the second one to refactor our code.

We started with the !P || !Q and ended with !(P && Q). Let's review it now:

// we started with this condition to check before sending the email:
!this.isActive() || !this.hasEmail()

// Then, we moved the logic to canReceiveEmail()
this.isActive() && this.hasEmail()

// And used the negation of that:
!this.isActive() || !this.hasEmail() == !(this.canReceiveEmail())

// Which is:
!this.isActive() || !this.hasEmail() == !(this.isActive() && this.hasEmail());

// So:
!P || !Q == !(P && B)

Other Boolean Algebra Laws

If you didn't know about this boolean algebra laws specifically, don't worry! You're probably applying others like:

Those mean that:

(weAreInChrome() || weAreInFirefox()) === (weAreInFirefox() || weAreInChrome())

(isRaining() && isCloudy()) === (isCloudy() && isRaining())

So, intuitively perhaps, you know that the boolean conditions with two values can be switched in order and the result is the same (🤓🗯️ that's commutativity!).

There are many others boolean laws that are useful so I might do a second part of boolean logic later in the series with the ones that are not so intuitive.

Did you find this one useful? Let me know on Twitter please! 👋 🙂

References

Better Console Debug in Javascript

José M. Gilgado — Thu, 19 Sep 2019 14:04:34 +0000

When debugging an object in Javascript, you usually do something like:

console.log(myObject);

Or even:

console.debug(myObject);

If we create the object with:

myObject = {
    name: 'test',
    size: 1234,
}

And you do a console.debug from somewhere in the code, in the console you'll see:

So it might not be clear which object you're dealing with. To solve this you can do:

console.debug({myObject});

The result is the name of the object and the full object printed:

This comes from ES6, it's usually called shorthand property names and it works because the key and the object variable has the same name.

It's the same thing that saying:

console.debug({myObject: myObject});

But more convenient as you can see. 😉