What it means to be a senior engineer

Kai Hao — Sat, 20 Jun 2020 06:13:19 +0000

Originally posted in kaihao.dev.

The title is kind of like a clickbait, I always dislike the terms of using senior or junior to describe the job titles. I believe that comparing with each other brings more harm than good. However, I have to admit that sometimes we need some comparison to allow healthy competition, promotion, or just some sense of accomplishment.

Anyway, what does seniority means? Literally, it means the rank that you have in a company because of the length of time you have worked there, but how do we measure it? At what point should we consider ourselves senior engineers? 2 years of experience? 3 years? 4? Is there any difference between working at a big tech company or a start-up? In my own experience, I have become a senior engineer with only half a year of professional experience. I also know someone whose first-ever job title is already a senior engineer. Clearly it depends on the company policy, but obviously measuring age or years of experience isn't an objective way either.

Many companies tend to measure the levels of skills of the engineers to decide their seniorities. Becoming senior engineers means that they achieve a level of skills in the industry or the technologies they use. However, every company has different standards of how skillful a senior engineer should be. Do we suddenly become junior engineers after moving to a higher standard company even though we are senior engineers in the previous company? Furthermore, how do we measure one's level of skills? Is a senior engineer guaranteed to be more skillful than a junior engineer in every single aspect? I believe that everyone can be good at something and be bad at another, being good at everything is unrealistic and nearly impossible. The same applies to seniority, personally I believe that a senior engineer shouldn't necessarily be more skillful than a junior engineer. In fact, I've seen a lot of talented junior engineers that are more skillful than some of the senior engineers I know.

So, what counts? In my humble opinion, the most important trait to be a senior engineer is to have our own perspective. Needless to say, we have to be good at what we're doing in the first place. However, being good is not enough, we also have to have our own views. We should be able to make trade-offs, make difficult decisions, and take the responsibility of the results. Having our own views also isn't enough, sharing them to the other members in the team is what make us different than the junior engineers. Convincing others is no doubt very hard, that's what make us valuable as senior engineers.

On the other hand, junior engineers often just follow the standards or guidelines from others. We can still be very good as junior engineers, if we're following the right path, of course. However, if we want to improve ourselves to a higher level, start follow our own voices. Keep learning and we will find ourselves having our own unique opinions on all the various things we learned. Opinions could be wrong, but that's why we need to keep learning from our failure and grow to be better. Don't be afraid of failing, that's the proof that we're improving.

Do you agree? What do you think it means to be a senior engineer? Tell me what you think, I would love to learn more :).

One fun trick to observe elements in realtime without MutationObserver

Kai Hao — Sat, 14 Mar 2020 09:14:06 +0000

Querying elements with selectors is quite intuitive in JavaScript. querySelector and querySelectorAll are fast and reliable.

function queryElements(selector, callback) {
  const elements = document.querySelectorAll(selector);
  elements.forEach(element => callback(element));
}

// Use it
queryElements('[data-target]', element => {
  element.style.outline = '2px solid red';
});

What if we want to be notified when there's a new element appears on the page? Both querySelector and querySelectorAll are one-off imperative commands that won't catch elements added afterward. We have to come up with another method.

Give it a minute and think about how you would do it.

Got it? Don't stop it there, how many methods can you come up with? What if we want to support legacy browsers like IE 9?

`MutationObserver`

The first solution that comes to our minds might be this shiny API: MutationObserver.

Using MutationObserver to create an observer to listen to new elements added to the page is quite straightforward.

function queryElements(selector, callback) {
  const elements = document.querySelectorAll(selector);
  elements.forEach(element => callback(element));
}

function observe(selector, callback) {
  // Call it once to get all the elements already on the page
  queryElements(selector, callback);

  const observer = new MutationObserver(() => {
    queryElements(selector, callback);
  });

  observer.observe(document.documentElement, {
    // Listen to any kind of changes that might match the selector
    attributes: true,
    childList: true,
    characterData: true,
    // Listen to every changes inside <html>
    subtree: true,
  });
}

// Use it
observe('[data-target]', element => {
  element.style.outline = '2px solid red';
});

Note that this naive solution is not highly performant, and would potentially cause the callback to be fired on the same element more than once. However, it's performant enough in our case.

According to Can I Use, MutationObserver is supported since IE 11, which is enough in most cases. In fact, in practice, we should just stop here, it's good enough, work's done. But what if? What if, just for fun, we want to support IE 9? One solution would be to use a polyfill for MutationObserver. That's perfect, but is there any other solution?

Animation

Animation? Really? Hell yeah, really!

I'll pause 3 seconds here to let you think why any of this is related to animation. 3... 2... 1, time's up!

If you really think about it, you might find that animation runs as soon as the elements being inserted into the DOM. If we can assign an animation to every element matching the selector, and listen to the event when the animation starts, then we can get ourselves an observe function without using MutationObserver.

@keyframes observer-animation {
  /* We don't actually have to run any animation here, can just leave it blank */
}

[data-target] {
  /* We just need minimal time for it to run */
  animation: observer-animation 1ms;
}

That seems perfect, all we need now is to listen to the event when the animation starts. Luckily, there's an animationstart event we can listen to. What's better is that this event bubbles up, so that we can just attach our listener to document.

document.addEventListener('animationstart', event => {
  if (event.animationName === 'observer-animation') {
    callback(event.target);
  }
});

Let's put them all together and inject the style with JavaScript.

let id = 0;

function observe(selector, callback) {
  const style = document.createElement('style');
  // Assign the animation to an unique id to support observing multiple selectors
  const animationName = `observer-animation-${id}`;
  id += 1;

  style.innerHTML = `
    @keyframes ${animationName} {}

     ${selector} {
       animation: ${animationName} 1ms;
     }
  `;
  document.head.appendChild(style);

  document.addEventListener('animationstart', event => {
    if (event.animationName === animationName) {
      callback(event.target);
    }
  });
}

// Use it
observe('[data-target]', element => {
  element.style.outline = '2px solid red';
});

Alright, this is fun! Right?

Note that this solution is not necessarily the same as our MutationObserver approach. For instance, animations will only start when the element is visible, so elements that have display: none will not fire the event. On the other hand, MutationObserver will call the callback no matter the element is visible or not. This might be either perfect or painful depends on what you're trying to do.

You probably won't have to use the tricky animation approach ever, but it also doesn't hurt to learn this simple little trick.

I want to be clear that I'm not the first one to come up with this approach, but I don't remember where I learned from either. There are already several npm libraries using both of these approaches. Take a look at them to learn more about how to further optimize the performance.

DEV Community: Kai Hao

What it means to be a senior engineer

One fun trick to observe elements in realtime without MutationObserver

MutationObserver

Animation

`MutationObserver`