Forem: Thanos Kolovos

The Bait, the Switch & the Loop

Thanos Kolovos — Thu, 16 Mar 2023 18:20:54 +0000

The Bait

You find yourself on a call with three people on a Wednesday afternoon.

One is the hiring manager, one HR representative and another person they introduced as “Page, a member of one of our teams”. They all look tired, but you notice they are trying to smile. It’s evident that this is a routine call for them. It could have been the third or fourth similar call for the day, and it looked like this one was outside their usual working hours. Or not.

Sheila, the hiring manager, describes how the teams work and that there is always an opportunity to grow and experiment. She then starts talking a lot about herself, but you choose to ignore that for now because the offer in the initial stage was impressive. A 35% raise to what you are getting in your current gig. This will be an excellent boost to being closer to your wish list.

After the diversion, she talks about the teams again and their achievements. A relief. Your mind strategically blocked the previous discussion.

The HR representative lists some of the perks, the growth plan they have in place that is carefully tailored to each individual, and how every day is a chance to learn something new. He seems proud of the work and process they have in place. He gave some well-thought answers to your questions.

Page only speaks when you mention day-to-day work. She seems happy with the result overall, which is a good sign. She asks about previous experience and some easy technical questions. This isn’t supposed to be a technical interview, but you are happy to answer.

That last session comes to an end after one and a half hours. Something feels slightly off, but you’ve done your due diligence. Glassdoor reviews seem high and legit, and overall the company has a good reputation. You managed to talk to someone that was working three years ago in the company, and he didn’t have anything bad to say.

Based on this, it’s “go” time. The money is good, and you need a change. You have been looking for some time now, so you do it. You are excited and ready to join.

The Switch

Two months into the gig, you haven’t done a 1:1 yet and haven’t seen the people from the interview again. You heard that Page, the “member of one of our teams”, resigned. These things happen. The hiring manager is usually lost somewhere in a meeting, being busy.

Your peers are amazing at their job, but they are disoriented most of the time, like no one knows why they do the things they do, and the team’s last project didn’t make it to production because of “reasons”. Four months of design and implementation are out of the window. You have no idea about the next steps. Someone will tell you, but not knowing what is coming is not your strong suit.

That week, Thursday would be a “come to the office” day - remote wasn’t really remote - and mid-day, an angry person you haven’t seen before walked into the open office space and screamed, “Who pushed the ‘a4e9c’ commit? WHO DID THAT?!?”.

You had no idea who that person was, but who behaves like that in a professional environment, and how doesn’t he know he can check the contributor for the commit in the following line? Later you learn that this was the VP of Engineering…

Perks magically disappear, and bureaucracy and hidden agendas are a thing.
Six months passed - during which similar not-so-good things happened - and you are on an interview call again. The team seems great, and there is no weird gut feeling this time. As a precautionary measure this time, you found two people on LinkedIn still working there to ask about the company. The money is not that good, but the whole thing seems more human-oriented.

Of course, you take the job.

The Loop

Bait and Switch it’s a known sales technique to get customers to buy in with low prices and then raise prices as you go towards the signing time or after you are bound with a contract. It’s used as a bad practice in UX, and It’s also used in interviews when an interviewee is not the person applying for work (who does that?!?).

This is different. This is the case of a company overselling to the candidate. Not small things about setting priorities or gym perks. I’m talking about significant differences in culture. The things that might differentiate a healthy from a toxic environment.

I used to wonder what is the purpose of hiding the truth in an interview?

Every new hire is an investment. If you hire someone and they leave after a few months, you have spent time and energy onboarding them, making them part of a team and training them. Don’t they get that if a candidate sees BS in the first months in the company, they will just bail out?

Then it hit me. They do know it.

Take 1

Once you are in, you are probably staying. Money and perks are the incentives. They depend on this being enough to retain people even if they are not completely happy. Even if a percentage of people leave, other people will stay.

Take 2

In big organizations in a growth state, hiring becomes a number in someone’s OKRs, “Hire 70 people”. This person might be so up the chain that it is probably too difficult to understand the actual situation in the organization. They do believe they have an amazing culture.

Take 3

Big organizations, big stakes. Current goals in someone’s OKRs are more important than anything else. Again, “Hire 70 people”. Every month they don’t hit this number, it translates to lost opportunities and lost revenue (crazy, right?), so they do anything to cover this number no matter what. If people leave, this can be a problem for another quarter, another person.

And this is the Loop. An endless Loop of new goals to cover the numbers of the previous goal. Every month, every quarter.

This might come up as criticizing, but it’s really not. I get it. I don’t like it, but I get it. And, of course, this doesn’t apply to all organizations. There are teams out there, even with hundreds of people, that maintain a fantastic culture in which people can thrive.

What is needed is extra caution. An interview is a two-way street. Ask questions so you can better understand what is going on. Reach out to people currently working there and make sure what you heard in the interview was legit. If you join, keep the organization accountable for their promises.

Be vigilant and keep an eye out for the Bait and Switch!

Originally posted on https://codegazerants.com/2023/03/16/the-bait-the-swith-and-the-loop/

Create a New Jekyll Post with a Simple Shell Command

Thanos Kolovos — Tue, 07 Feb 2023 18:36:38 +0000

Let's build a shell command to automate the creation of a new post in Jekyll.

This will be a short one.

Jekyll has its quirks, and I always wondered why they don't have a simple command to create a new post. I used to copy/paste the previous one, but you know how things are... If you can automate something boring in a few minutes, just do it.

Creating the Script

We first need to create a simple bash script to do the job for us.

So, create a new file. I call mine newjekyllpost.sh and add the following parts to it:

#!/bin/bash
filename=`date +%Y-%m-%d-new-post.md`

cat > $filename <<EOF
---
layout: post
title: A title
description: A description
categories: ["tag"]
social_image: add here
---
EOF

Let's rubberduck this.

The second line is a variable called filename. This will be used for our file name with today's date and the following format:

YYYY-MM-DD-new-post.md #

The third line will create the file with the contents we like. I chose to add the YAML front matter with the most used content for my posts. If I don't want something, I remove it.

And that's it. Our script is that simple. Let's now try to execute it.

Making the Script Executable

If you try to run it, you will get an error about permissions. There is one more step, which is to change the file's permissions.

chmod u+x ./newjekyllpost.sh

After that, running ./newjekyllpost.sh will create a file in the specific folder with our contents.

Adding an Alias

Let's do one more last thing to make our lives easier.

Right now, we have our script in a specific folder, so we need to write the path each time, which is also boring. Adding an alias for the script will work like magic.

Move the script to any path you want. I keep a scripts folder inside my Users folder.

Open the profile your shell is using. I'm using ZSH, so I have this line in my .zshrc file:

alias njp="~/scripts/newjekyllpost.sh"

Every time I run njp in a folder, the script creates a new file. You can choose any alias you want, of course.

Run source pathoftheprofilefile to reload the new changes, and we are done.

Improving the Script

As I was writing this, I though there is one more thing we could do to improve the script. If there are argguments to the script use them to postfix the filename.

So our first part of the script becomes:

if [ $# -gt 0 ]
then
  filename=`date +%Y-%m-%d-`
  filename+=`echo "$@" | sed -e 's/ /-/g'`.md
else
  filename=`date +%Y-%m-%d-new-post.md`
fi

In the "bash" language what that means is:

If I have arguments add the date in the filename. Then join with a space all the arguments as string with "$@" and then replace the spaces with - which is done by the sed part.

If I have no arguments, business as usual.

If we run njp this is my new post at 2022-12-30 the file will be create will have the following name:

2022-12-30-this-is-my-new-post.md

Just remember, all of this can be achieved with any language. The logic is the same. I just chose to do it in a bash script because, why not?

Originally posted on https://codegazerants.com/2023/01/01/create-new-jekyll-post-with-a-command/

Thoughts on feedback

Thanos Kolovos — Tue, 31 Jan 2023 19:12:02 +0000

Thoughts on feedback, the really short version.

Feedback is difficult and needs a lot of practice. Why? Because emotions are involved.

There are two parts to becoming better at it. The rules are simple, but it's hard to live by.

Receiving Feedback

To get feedback, you need to be and also look open to feedback. If your face changes and you start being defensive - even if you have counter arguments - when someone gets out of their way to give you some feedback, there is a chance they won't do it again. And yes, we've all been there.

Listen to what the other person has to say, even if you disagree.
Ask questions to understand more about the situation. Keep notes.
Thank the person for the feedback. They've given some thought, time and care about you.
Sleep on it.
Act if needed.

And yes, ask for direct feedback like hell! I usually mention to the people around me that even if their feedback "hurts" me, at the end of the day, if it's constructive, it will make me better. It's going to make me grow.

Giving Feedback

There is a strong possibility you have some feedback about people, but you are hesitant to share it because you are afraid of how the other person will feel and how it might make you look like not a good person.

Be empathetic, respectful and direct.
Try not to judge, but describe a situation and its effect.
Be precise and provide examples, don't be vague.

I'll let you in on a secret. Everything about providing feedback ends when you do it. After that, It's the other person's job to filter and evaluate the input. There is no need to convince or be convinced about anything.

You can't imagine how fulfilling it is to hear an honest "Thank you for pointing this out. I wasn't aware of that" after providing hard feedback.

One last note. I was lucky enough to be introduced to Radical Candor and SBI (Situation Behaviour Impact) model a few years ago, which helped me improve the way I use feedback. So it's my turn now to urge some people to give these resources a try if they haven't already.

Originally posted on https://codegazerants.com/2022/10/15/thoughts-on-feedback/

Use JavaScript to Navigate Through a Table And Other Elements

Thanos Kolovos — Wed, 25 Jan 2023 17:46:28 +0000

The browser API has given us many tools to navigate through a webpage, and if done correctly, you will have a great result without the use of any Javascript.

In some case though, you might need to enhance some of the navigation experience. Usually, this is a challenge in an application environment, or more specifically, on some elements of the application. And here is when JavaScript comes in handy.

A Beautiful Table

If you are using Gmail, then you probably have seen that you can navigate between the mail list with your up and down arrow keys. Gmail uses a table, and I have no idea what they are doing under the hood, but let's see how we can accomplish this.

We will go through some sections of the code, but keep in mind that we can use this code for various HTML elements.

The Basics

Let's get the basic stuff out of the way. We will create an HTML file. Let's call it index.html. Yes, we will do everything in a single file, no bundlers or anything.

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta http-equiv="X-UA-Compatible" content="IE=edge">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>Use JavaScript to Navigate Through a Table And Other Elements</title>
  <style>
    .is-active {
      box-shadow: inset 0 -1px 0 0 rgb(0 0 0);
    }
  </style>
</head>
<body>
  <table id="mytable" tabindex="0">
    <tr>
      <td>One</td>
     </tr>
     <tr>
      <td>Two</td>
     </tr>
     <tr>
      <td>Three</td>
     </tr>
     <tr>
      <td>Four</td>
     </tr>
     <tr>
      <td>Five</td>
     </tr>
   </table>
  <script></script>
</body>
</html>

Here, we have a simple file with a table and a CSS part with one class to visualise a selected table row.

One small addition that makes the difference is the tabindex attribute so we can focus on our table.

The Key Navigation Backbone

Let's design our navigation function. What could be the main parts of it.

  <script>
    function navigateElement(elementID, itemsTagName, activeClass, scroller) {
      function handleKeyboard() { };
      function handleScroll() { }
    }
  </script>

We have one main function here called navigateElement - which I'm sure you can find a better name for it - that takes some parameters. We could have everything hardcoded, but you will probably reuse this in other elements in your application.

elementID: The element we are going to add our key capture event listener to and includes our list items. We need to have this in case we have more than one navigateElement instance.
itemsTagName: The element's tag name we will navigate through.
activeClass: The active class we mentioned in our CSS part.
scroller: The element that is responsible for our content overflow. More on that later. Secret sauce.

The handleKeyboard does what it promises. It will handle the navigation between items, and the handleScroll will be responsible for always having in our viewport the selected element. This simple design is all we need for now.

The Key Navigation Code

Right now, our page doesn't do anything. Let's add what we promised.

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta http-equiv="X-UA-Compatible" content="IE=edge">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>Use JavaScript to Navigate Through a Table And Other Elements</title>
  <style>
    .is-active {
      box-shadow: inset 0 -1px 0 0 rgb(0 0 0);
    }
  </style>
</head>
<body>
  <table id="mytable" tabindex="0">
    <tr>
      <td>One</td>
     </tr>
     <tr>
      <td>Two</td>
     </tr>
     <tr>
      <td>Three</td>
     </tr>
     <tr>
      <td>Four</td>
     </tr>
     <tr>
      <td>Five</td>
     </tr>
   </table>
  <script>
    function navigateElement(elementID, itemsTagName, activeClass, scroller) {
      const mainDOMElement = document.getElementById(elementID);
      const scrollElement = document.getElementById(scroller) || window;
      const items = mainDOMElement.querySelectorAll(itemsTagName);
      const itemsLength = items.length;
      let selection = -1;

      function handleKeyboard(e, which) {
        if (e) e.preventDefault();
        if (!e && !which) return;
        items.forEach(item => item.classList.remove(activeClass));
        const selectedIndex = which || e.which;
        switch (selectedIndex) {
          case 38:
            if (selection == 0) {
              selection = itemsLength - 1;
            } else {
              selection--;
            }
            handleScroll();
            break;
          case 40:
            if (selection == itemsLength - 1) {
              selection = 0;
            } else {
              selection++;
            }
            handleScroll();
            break;
          default:
            break;
        }
        items[selection].classList.add(activeClass);
      };
      function handleScroll() {
        const el = mainDOMElement.getElementsByClassName(activeClass);
        if (el.length) {
          el[0].scrollIntoView({
            block: "center",
            behavior: "smooth",
          });
        }
      }
      mainDOMElement.addEventListener('keydown', handleKeyboard);
      mainDOMElement.addEventListener("focus", () => {
        if (selection < 0) handleKeyboard(null, 40);
      });
    }

    navigateElement('mytable', 'tr', 'is-active');
  </script>
</body>
</html>

If you copy/paste this code in an HTML file, should work out of the box.

Focus on the element and navigate through your up and down arrow keys.

But let's rubberduck the script in sections.

function navigateElement(elementID, itemsTagName, activeClass, scroller) {
  const mainDOMElement = document.getElementById(elementID);
  const scrollElement = document.getElementById(scroller) || window;
  const items = mainDOMElement.querySelectorAll(itemsTagName);
  const itemsLength = items.length;
  let selection = -1;
...
};

Simple things, we initiate some variables based on our parameters and set a selection to -1, which means that nothing is selected. If scroller is not defined, we get the window as our element.

The navigation part

...
function handleKeyboard(e, which) {
  if (e) e.preventDefault();
  if (!e && !which) return;
  items.forEach(item => item.classList.remove(activeClass));
  const selectedIndex = which || e.which;
  switch (selectedIndex) {
    case 38:
      if (selection == 0) {
        selection = itemsLength - 1;
      } else {
        selection--;
      }
      handleScroll();
      break;
    case 40:
      if (selection == itemsLength - 1) {
        selection = 0;
      } else {
        selection++;
      }
      handleScroll();
      break;
    default:
      break;
  }
  items[selection].classList.add(activeClass);
};
...

For each event we capture, we prevent the default behaviour. This is used to avoid browser page or element scrolling, resulting in a weird user experience. We are going to handle it ourselves in handleScroll.

Our selected item is based on the event.which or just a programmatically given which we are utilising the first time someone is focusing the element. If both of these are not set, we just return.

We remove the active class from all the items, then we have some logic checking if we are going up or down, and we decide to increase or decrease the selected. We also cover the first/last item case, and we go to the appropriate position.

After we have the selected item, we apply the active class to it.

The Scrolling Part

Now let's explain a bit the scrolling part. This is one thing I see people forgetting when creating custom navigation in HTML elements.

function handleScroll() {
  const el = mainDOMElement.getElementsByClassName(activeClass);
  if (el.length) {
    el[0].scrollIntoView({
      block: "center",
      behavior: "smooth",
    });
  }
}

Each time we use our keys to navigate, two things can happen:

The browser will catch the key event and scroll any element that could be considered valid, like the screen scroll, for example, and not our element. This is the reason why we use preventDefault in our previous code.
Since the event is not bubbling up, there is no scrolling happening, and if the content exceeds the viewport, the user won't be able to see the selected item at some point.

This is why we use the fantastic scrollIntoView. Before this, we would try to calculate the scrolling position of the wrapper, the element height, offset, and things that sound boring. scrollIntoView will solve this, and this is why we are calling it with each key press.

Adding the Event Listeners

One more thing left. To add the listeners for the key event and choose the first item when the item is focused if no selection is set.

mainDOMElement.addEventListener('keydown', handleKeyboard);
mainDOMElement.addEventListener("focus", () => {
  if (selection < 0) handleKeyboard(null, 40);
});

We are all set.

Takeaways

These small snippers are cool the first time you bump into them. After that, it gets a bit boring. You will want to make a helper for it. With some more work, it could include logic for the state if you want to combine it with a frontend framework like React, Vue or anything like that. But this is the basic logic.

If I wasn't lazy, I could also add some checks and validations with some beautiful errors for the developer, but I'll leave this up to you.

Once again, please don't forget to use tab to focus on the table first.

Originally posted on https://codegazerants.com/2022/08/18/use-javascript-to-navigate-through-table/

Chaos Engineering For Humans

Thanos Kolovos — Sat, 21 Jan 2023 19:59:35 +0000

If you came here about Chaos Engineering for your services, “it’s not what it looks like”.

Chaos Engineering

You might think I just said it’s not about Chaos Engineering, but I’m about to give some kind of definition of Chaos Engineering. Yes, I am.

Our products have become, or maybe better say, have progressed to be, a sum of multiple services and not a monolith service that tries to do everything. Core application, auth service, user service, payments service, prospects service. Name your service here.

The whole system should be resilient.

Unit and end-to-end testing should be in place for each service, but these are done in a predictable way. What I mean by “predictable way” is that we provide a specific input and expect a specific output. And this is what we test.

Don’t get me wrong, this is a great state. But what would be the next step?

Here is where Chaos Engineering comes in. The essence is that you create a situation for your whole system, for example, latency or absence of a service. You observe what happens, and then you prioritize improvements.

This helps increase confidence, have a more predictable system and protect customers from a total failure of your system if your 10th service down the road underperforms.

Getting Closer to A Point

What is a team? A group of individuals that work together have an input (a goal), a throughput (their work, processes etc.) and an output (results).

A team is a system.

When all parts work, we have great results. When something is wrong with a part of the system, then the whole system starts to show signs of latency.

Do you see where I’m going with this?

Teams as Systems

This all began when I started thinking of what would happen if someone from my team left tomorrow or a new team was created, and we had to do an internal restructuring? What would happen if a manager had a sabbatical? What if someone was on medical leave for two weeks?

Would that absence block the team? What could we do to remove some uncertainty? Can we get some ideas from Chaos Engineering and apply them to a team?

The idea is to find a way to observe when limitations arise in a team and understand where we can optimize.

Here are some simple metrics you can have, but of course, it varies based on each organization:

Can the team groom a feature?
Can the team deploy a feature?
If specialization is missing, can the team find a way to bypass that?
Are the initial milestones on track?
Is team morale high?
What are the main areas the team struggled with?
Can the team self-organize and communicate with the stakeholders if leadership is absent?

The Organic Way

There is an easy and organic way to observe and draw some conclusions without changing anything in your team.

Try to observe when someone has Paid Time Off or, for some reason, cannot contribute to the problem at hand. Is there sufficient documentation? Do you have a bus factor one? Having one person less, will reduce the capacity of a team, but is it in the danger zone?

Note down the observations, share them with the team and create action items.

The More Creative Way

Create the circumstances that will create some “planned turbulence” for the team.

Once a quarter, throw all the team’s names in a randomizer, and the winner gets one or two weeks of having to work on a project they choose or join another team. During that time, they should not interact with the rest of the team.

There are no secrets or sketchy areas here. The team should know the goals and the metrics.

Final Notes

Please remember that this is not a way to calculate individual impact, create mayhem or stress your team. It’s one more tool to create the circumstances for a team to observe and improve. Low impact initiatives might also be a good start.

Keep your team in the loop if you want to try this out. If they don’t feel comfortable, abort.

I would consider this suitable for an environment with a great culture. You need safety and team maturity. This is a next-level approach. You wouldn’t try Chaos Engineering for your system if you didn’t have a good system in place first, would you?

And one last thing, in case this wasn’t clear. You can apply this to any kind of team, not just Engineering teams.

Happy experimenting!

Originally posted on https://codegazerants.com/2022/10/09/chaos-engineering-for-humans/