DEV Community: Kristian Ivanov

Cognitive Biases in Software Engineering: How They Impact Developers and Managers

Kristian Ivanov — Tue, 15 Apr 2025 08:10:25 +0000

Cognitive Biases in Software Engineering: How They Impact Developers and Managers

A practical guide to recognizing and mitigating the mental shortcuts that undermine technical decision-making

Let’s face it

We developers and tech managers love to think we’re the most logical people on the planet. After all, we spend our days working with machines that operate on pure logic. But here’s the uncomfortable truth: our brains are just as messy and biased as everyone else’s, maybe even more so because we don’t expect it.

I’ve spent many years both writing code and managing teams, and I’ve seen firsthand how cognitive biases can totally derail technical projects. So let me break down the most problematic mental shortcuts I’ve witnessed (and more often than not in myself, but hey the first step is admitting you have a problem), with a particular focus on how they manifest differently depending on whether you’re the one writing the code or the one managing the people writing the code.

The 10 Cognitive Biases That Are Probably Screwing Up Your Code or Team Right Now

1. Recency Bias

Ever noticed how your team suddenly becomes obsessed with fixing that one bug a customer complained about yesterday, while ignoring the critical issue affecting hundreds of users for months?

For Developers:

You’re ready to rewrite the entire codebase using that shiny framework you read about on Hacker News this morning
You focus all your energy on that bug Karen from Marketing reported yesterday while ignoring the performance issue affecting thousands of users
You’re convinced Pattern X is the best approach to every problem because it worked well in the last project (which, by the way, was completely different)

For Engineering Managers:

“Our last retrospective revealed X, so clearly X is our biggest problem company-wide!”
You prioritize whatever feature was mentioned in the last executive meeting
That developer who did great in the last sprint must be your star player (never mind the six months of mediocre performance before that)

2. Confirmation Bias

When you know you’re right and spend three hours googling just to find that one random forum post from 2011 that agrees with you.

For Developers:

You write tests designed to confirm your code works rather than trying to break it (that would be, you know, the actual point of testing)
“Users are just using it wrong” is your go-to explanation for negative feedback
You somehow always find documentation that supports your approach while missing all contradictory evidence

For Engineering Managers:

You hear what you want to hear in status updates, filtering out warning signs
You keep pushing a technical direction despite mounting evidence it’s turning into a disaster
The team members who agree with you are “insightful” while those who raise concerns are “not seeing the big picture”

3. Availability Heuristic

That one time the production database crashed and became the stuff of company legend? Now you’ve got three engineers dedicated to database optimization while your frontend is held together with duct tape and prayers.

For Developers:

You’re certain SQL injection attacks are the biggest security threat because you read an article about one last week
You build elaborate protection against edge cases you’ve personally encountered while ignoring more common scenarios
You keep solving problems from your last job even though your current company faces completely different challenges

For Engineering Managers:

The bug that caused the CEO’s demo to fail gets five engineers assigned to it immediately
You completely restructure support processes because one customer with a dramatic story complained loudly
“We’re never hiring junior developers again” after one bad experience

4. Anchoring Bias

“It’s just a simple CRUD app, right? Should take a couple of days!” — Words that have launched a thousand death marches and countless weekend deployments. This ties very well with the Dunning-Kruger effect, and often then leads to the sunk cost fallacy.

For Developers:

You committed to the “couple of days” estimate and now you’re working nights and weekends to avoid admitting it was wildly unrealistic
Your first solution becomes THE solution because you’ve already mentally committed to it
You “optimize” code until it matches some arbitrary benchmark you set before understanding the actual requirements

For Engineering Managers:

You promise delivery dates based on when marketing wants the feature, not on what engineering says is possible
You lowball salary offers based on what candidates made at their previous jobs rather than what they’re worth
You judge team performance based on their first few sprints, ignoring all evidence of improvement or changing circumstances

5. Sunk Cost Fallacy

Sometimes it’s better to cut your losses and start over with an updated approach. This can also be applied for giving up on your startup — if it is failing cut it. Close it down. Don’t stay simply because you’ve already invested X years into it.

For Developers:

“I’ve already spent two weeks on this approach, I can’t switch now” (even though a better solution would take days instead of weeks)
You keep using a problematic library because “we’ve already invested time in learning it”
You continue debugging using the same approach for days, despite making zero progress

For Engineering Managers:

You keep funding projects that no longer align with business goals because “we’ve already spent so much”
You maintain ancient systems requiring expensive specialists rather than migrating to something maintainable
You stick with failing processes because admitting they don’t work feels like admitting failure

6. Dunning-Kruger Effect

This effect is especially dangerous because it follows a predictable pattern: beginners with minimal knowledge often have maximum confidence. As engineers gain experience, they realize how much they don’t know (the “valley of despair”). Truly senior engineers tend to have measured confidence — they know what they know, but also recognize the boundaries of their expertise.

What makes Dunning-Kruger particularly toxic in software teams is that those most affected are least equipped to recognize it in themselves. The same knowledge gaps causing overconfidence prevent accurate self-assessment. This is why peer review processes are essential — they provide external reality checks that help calibrate your internal confidence meter.

For Developers:

You roll your own solution for everything instead of using external solutions, because ‘how hard can it be’?
You dismiss industry best practices as “overkill” because you don’t understand the problems they solve
You write “clever” code without comments because it seems obvious to you now (future you and your colleagues will hate you)

For Engineering Managers:

You override technical decisions made by your specialists because “how complicated could it be?”
You commit to deadlines without consulting the people who’ll do the work
You evaluate engineers’ technical skills in areas where your own expertise is limited, often favoring those who speak confidently over those who are actually competent

7. Self-serving Bias

Come on, this is the description of your favorite co-worker.

For Developers:

“The deployment succeeded because of my brilliant code, but it failed because ops screwed up the configuration”
You take credit for all the features users love while blaming “unclear requirements” for the parts they hate
When your code has bugs, it’s because of “edge cases,” but when others’ code has bugs, it’s because of incompetence

For Engineering Managers:

Your team succeeded because of your amazing leadership, but they failed because they didn’t execute properly
You claim credit for on-time deliveries but blame “unforeseen technical challenges” when deadlines slip
You view successful quarters as proof of your strategy and unsuccessful ones as market anomalies

8. Survivorship Bias

Who hasn’t heard of a failed start up doing the best and most glamorous architecture, instead of something simpler and easier to maintain, because all of the bigger companies are doing it?

For Developers:

“We should use microservices because that’s what Netflix does!” (ignoring that Netflix evolved to that architecture after years of learning and has hundreds of engineers to support it)
You learn programming by following success stories without studying the far more common failure patterns
You adopt complex architectures used by tech giants without considering whether they solve problems you actually have

For Engineering Managers:

You build development processes based only on successful projects, ignoring what went wrong in failures
Your hiring process favors candidates from successful companies without evaluating their actual contributions
You apply management techniques that worked at your last company without adapting them to your current team’s context

9. Status Quo Bias

Who hasn’t joined a company and tried to suggest an improvement only to be cut down with the argument of — we are used to doing it this way?

For Developers:

“We’ve always used this approach” becomes the single most annoying phrase you’ll ever hear
You resist learning new tools or techniques because your current workflow is comfortable
You defend problematic legacy code because rewriting it would disrupt your routine

For Engineering Managers:

You maintain inefficient processes because changing them would require effort
You block organizational improvements because they’d disrupt established team dynamics
You stick with obsolete technical approaches because everyone already knows them

10. Bandwagon Effect

Who hasn’t had a colleague that want’s to use something so cutting edge that has a handful of stars and forks on GitHub instead of something that was tried and tested?

For Developers:

You choose technologies based on Twitter hype rather than project requirements
You implement patterns because “everyone is doing it” without understanding why
You follow trendy opinions on best practices without critically evaluating them

For Engineering Managers:

“We need to be doing agile!” (without understanding what that actually means for your specific context)
You let the loudest team members dictate decisions regardless of merit
You prioritize features because competitors have them, without asking if your users need them

How to Not Be a Walking Cognitive Bias Disaster

For Developers

**Document your assumptions
— **Write down what you’re taking for granted before you start coding
— Future you will thank present you when those assumptions change

**Actively seek contradiction
— **Don’t ask colleagues “Does this look good?” Ask “What am I missing?”
— The goal isn’t validation; it’s finding problems before your users do

*Set time limits for explorations
— *“I’ll spend exactly two hours evaluating this new tech” prevents rabbit holes
— Your excitement about a new framework is a terrible decision-making tool

**Break down tasks to expose complexity
— **If you can’t explain exactly how you’ll implement something, you don’t understand it well enough to estimate it
— Details reveal the dragons hiding in seemingly simple tasks

For Engineering Managers

**Require written proposals for major decisions
— **Force articulation of alternatives and trade-offs
— Make implicit assumptions explicit where everyone can see (and question) them

*Assign devil’s advocates
* — Make it someone’s explicit job to argue against the prevailing view
— This lowers the social cost of dissent and surfaces important counterarguments

**Track estimate accuracy
— **Compare estimates vs. actuals as a learning exercise (not a blame game)
— Look for patterns in what types of tasks consistently fool everyone

**Diversify your information diet
— **Seek input from people with different backgrounds and experience levels
— Build teams with complementary biases to counterbalance each other

The Bottom Line

Cognitive biases aren’t character flaws — they’re part of the standard human operating system. The difference between average and exceptional engineers isn’t the absence of bias, but the awareness of it.

By recognizing these patterns in ourselves and our teams, we can build guardrails that compensate for our predictable irrationality. The most powerful tool against bias isn’t more technical knowledge — it’s metacognition, the practice of thinking about how we think.

I’d love to hear what biases you’ve seen derail technical projects and what strategies you’ve found to combat them. Drop your experiences in the comments!

If you want to help out, read it out and clap at Medium as well

Chrome’s Offscreen API: The Hidden Powerhouse for Modern Extensions

Kristian Ivanov — Mon, 24 Feb 2025 14:13:47 +0000

Photo by Markus Spiske on Unsplash

While building Web à la Carte, I discovered that service workers can’t do everything we need in modern extensions. Enter the Offscreen API — Chrome’s solution for running DOM operations in the background. Let’s dive into how this powerful API can transform your extensions.

The Background/Info

Offscreen API

— Released: Late 2022

— Part of Manifest V3’s solutions

— Designed to replace background page capabilities

— Currently in stable release

Why Do We Need It?

With Manifest V3’s shift to service workers, we lost the ability to:

— Use DOM APIs in the background

— Play audio (something I’ve used heavily in an older ( no longer supported ) extension of mine)

— — Something to keep in mind is that if you are usingthe AUDIO_PLAYBACK reason it will close the offscreen document after 30 seconds without audio playing.

— Create canvases

— Make AJAX requests with certain headers

— Use WebSockets

The Offscreen API solves these problems by providing a real DOM environment that runs in the background.

What Makes It Special?

The Offscreen API is unique in several ways:

— Creates a hidden document with full DOM access

— Runs in the background without opening new windows

— Inherits extension permissions (with some limits)

— Only uses chrome.runtime API for communication

Important Limitations

Before diving in, there are some key things to understand:

You can only use static HTML files from your extension
Only one offscreen document can be open at a time*
Documents can’t be focused
The window.opener property is always null
Only chrome.runtime API is available

*Note: In split mode with an active incognito profile, you can have one document per profile.

The Basics

First, declare it in your manifest:

{
  "manifest_version": 3,
  "permissions": ["offscreen"],
  "background": {
    "service_worker": "background.js"
  }
}

Then create an offscreen document:

// background.js
async function createOffscreen() {
  // Check if we already have an offscreen document
  const existing = await chrome.offscreen.getOffscreenDocument();
  if (existing) return;

  // Create an offscreen document
  await chrome.offscreen.createDocument({
    url: 'offscreen.html',
    reasons: ['AUDIO_PLAYBACK'], // Or other reasons
    justification: 'Playing notification sounds' // Explain why you need it
  });
}

Real World Examples

1. Audio Notifications

// background.js
async function playNotificationSound() {
  await createOffscreen();
  // Send message to offscreen document
  chrome.runtime.sendMessage({
    target: 'offscreen',
    type: 'PLAY_SOUND',
    sound: 'notification.mp3'
  });
}

// offscreen.html
const audio = new Audio();
chrome.runtime.onMessage.addListener((message) => {
  if (message.target !== 'offscreen') return;

  if (message.type === 'PLAY_SOUND') {
    audio.src = message.sound;
    audio.play();
  }
});

2. Image Processing

// background.js
async function processImage(imageUrl) {
  await createOffscreen();

  return new Promise((resolve) => {
    chrome.runtime.onMessage.addListener(function listener(message) {
      if (message.type === 'IMAGE_PROCESSED') {
        chrome.runtime.onMessage.removeListener(listener);
        resolve(message.data);
      }
    });

    chrome.runtime.sendMessage({
      target: 'offscreen',
      type: 'PROCESS_IMAGE',
      imageUrl
    });
  });
}

// offscreen.html
async function processImage(url) {
  const img = new Image();
  const canvas = document.createElement('canvas');
  const ctx = canvas.getContext('2d');

  await new Promise((resolve) => {
    img.onload = resolve;
    img.src = url;
  });

  canvas.width = img.width;
  canvas.height = img.height;
  ctx.drawImage(img, 0, 0);

  // Apply image processing
  const imageData = ctx.getImageData(0, 0, canvas.width, canvas.height);
  // ... process image data ...

  return canvas.toDataURL();
}

chrome.runtime.onMessage.addListener(async (message) => {
  if (message.type === 'PROCESS_IMAGE') {
    const processed = await processImage(message.imageUrl);
    chrome.runtime.sendMessage({
      type: 'IMAGE_PROCESSED',
      data: processed
    });
  }
});

Mastering the Offscreen API

The Art of Resource Management

Think of the Offscreen API like a smart assistant — don’t keep them around when you don’t need them. Here’s a pattern I’ve found incredibly useful:

class OffscreenManager {
  constructor() {
    this.activeOperations = new Map();
    this.retryAttempts = 0;
    this.maxRetries = 3;
  }

  async execute(task, timeout = 5000) {
    const operationId = crypto.randomUUID();

    try {
      // Create offscreen document if needed
      await this.ensureOffscreen();

      // Set up task tracking
      const operation = {
        startTime: Date.now(),
        status: 'running',
        timeout: setTimeout(() => this.handleTimeout(operationId), timeout)
      };

      this.activeOperations.set(operationId, operation);

      // Execute and track
      const result = await task();
      this.completeOperation(operationId);
      return result;

    } catch (error) {
      if (this.retryAttempts < this.maxRetries) {
        this.retryAttempts++;
        return this.execute(task, timeout);
      }
      throw error;
    }
  }

  async cleanup() {
    if (this.activeOperations.size === 0) {
      await chrome.offscreen.closeDocument();
      this.retryAttempts = 0;
    }
  }
}

// Usage
const manager = new OffscreenManager();

// Process multiple images in batch
const results = await manager.execute(async () => {
  const images = ['image1.jpg', 'image2.jpg', 'image3.jpg'];
  return Promise.all(images.map(img => processImage(img)));
});

Smart Error Recovery

Instead of just handling errors, let’s make our offscreen operations self-healing:

const smartOffscreen = {
  async createWithFallback(options) {
    try {
      await chrome.offscreen.createDocument(options);
    } catch (error) {
      // If creation fails, check if we have zombie documents
      const existing = await chrome.offscreen.getOffscreenDocuments();
      if (existing.length > 0) {
        // Clean up and retry
        await Promise.all(existing.map(doc => 
          chrome.offscreen.closeDocument(doc.url)));
        await chrome.offscreen.createDocument(options);
      }
    }
  },

  // Or automatically retry failed operations
  async withRetry(operation, maxAttempts = 3) {
    for (let attempt = 1; attempt <= maxAttempts; attempt++) {
      try {
        return await operation();
      } catch (error) {
        if (attempt === maxAttempts) throw error;
        // Exponential backoff
        await new Promise(r => setTimeout(r, Math.pow(2, attempt) * 100));
      }
    }
  }
};

These patterns make your offscreen operations more robust and self-managing. The key is to treat your offscreen document like a valuable resource — use it wisely, monitor it carefully, and clean up when you’re done.

When to Use the Offscreen API

Use It When:

— You need DOM APIs in the background

— You’re playing audio or processing media

— You need WebSocket connections

— You’re doing complex canvas operations

— You need to use certain web APIs unavailable in service workers

Don’t Use It When:

— Simple data processing is enough

— Content scripts or a background script can handle the task

— You don’t need DOM capabilities

Final Thoughts

The Offscreen API bridges the gap between service workers and traditional background pages. While it shouldn’t be your go-to solution for everything, it’s invaluable when you need DOM capabilities in the background.

Remember:

— Only create offscreen documents when needed

— Clean up resources when done

— Use appropriate reasons and justifications

— Consider performance implications

If you found this article helpful, feel free to clap and follow for more JavaScript and Chrome.API tips and tricks.

You can also give a recent chrome extension I released that uses a lot of the functionalities from the articles — Web à la Carte

If you have gotten this far, I thank you and I hope it was useful to you! Here is a cool image of cats next to a screen that is off as a thank you!

Photo by Rhamely on Unsplash

Content Scripts vs chrome.scripting: Understanding Modern Extension Development

Kristian Ivanov — Mon, 17 Feb 2025 03:07:33 +0000

Photo by Swello on Unsplash

While building extensions, I keep seeing a common question pop up: “Should I use content scripts or chrome.scripting?” The answer isn’t as straightforward as you might think, especially since content scripts are more powerful than many developers realize. Let’s dive into the real differences and when to use each approach.

The background/info

Content Scripts

— Released: December 2009 (Chrome Extensions Launch)

— Part of the original extension system

— Updated in Manifest V2 (2012) with more options

— Updated in Manifest V3 (2021) with additional features like world: "MAIN"

chrome.scripting

— Released: January 2021 (with Manifest V3)

— Designed to replace chrome.tabs.executeScript

— Part of the move away from background pages to service workers

— Considered the modern approach to script injection

The Basics

Both content scripts and chrome.scripting let you inject code into web pages, but they serve different purposes and have different strengths.

Content Scripts

Content scripts can work in two ways:

Isolated World (Default):

// manifest.json
{
 "content_scripts": [{
 "matches": ["<all_urls>"],
 "js": ["content.js"]
 }]
}

Main World (Page Context):

// manifest.json
{
 "content_scripts": [{
 "matches": ["<all_urls>"],
 "js": ["content.js"],
 "world": "MAIN"
 }]
}

chrome.scripting

Chrome’s scripting API provides dynamic injection:

await chrome.scripting.executeScript({
 target: { tabId },
 func: () => {
 // Your code here
 }
});

The Real Differences

1. Execution Timing

Content Scripts:

— Load automatically when pages match

— Can run at document_start, document_end, or document_idle

— Stay active throughout page lifetime

— Can be dynamically injected too

Manifest-based injection

{
  "content_scripts": [
    {
      "matches": ["<all_urls>"],
      "js": ["early.js"],
      "run_at": "document_start"
    },
    {
      "matches": ["<all_urls>"],
      "js": ["late.js"],
      "run_at": "document_idle"
    }
  ]
}

Dynamic injection

chrome.tabs.executeScript({
  file: 'dynamic.js',
  runAt: 'document_start'
});

chrome.scripting:

— Runs on demand

— Single execution context

— Cleanup after execution

— Better for one-off tasks

async function modifyPage(tabId) {
  await chrome.scripting.executeScript({
    target: { tabId },
    func: () => {
      // Do something once and finish
    }
  });
}

2. State Management

Content Scripts:

let state = {
  observers: new Set(),
  modifications: new Map()
};

// State persists across functions
function addObserver(target) {
  const observer = new MutationObserver(() => {
    // Handle changes
  });
  observer.observe(target);
  state.observers.add(observer);
}

function cleanup() {
  state.observers.forEach(o => o.disconnect());
  state.observers.clear();
}

chrome.scripting:

// Each execution gets fresh state
async function observePage(tabId) {
  await chrome.scripting.executeScript({
    target: { tabId },
    func: () => {
      // State only lives for this execution
      const observer = new MutationObserver(() => {
        // Handle changes
      });
      observer.observe(document.body);

      // State is lost after execution
    }
  });
}

3. Context Access

Content Scripts (Isolated):

// content.js (default world)
// No access to page's variables
window.pageVariable; // undefined

// Need message passing for page communication
window.postMessage({ type: 'getData' }, '*');
window.addEventListener('message', (e) => {
  if (e.data.type === 'response') {
    // Handle data
  }
});

Content Scripts (Main World):

// content.js with world: "MAIN"
// Direct access to page context
window.pageVariable; // Works!
document.querySelector('#app').shadowRoot; // Works!

// Can modify page functions
window.originalFunc = window.someFunc;
window.someFunc = function() {
  // Modified behavior
};

chrome.scripting:

chrome.scripting.executeScript({
  target: { tabId },
  func: () => {
    // Always runs in page context
    window.pageVariable; // Works!

    // Can modify prototype methods
    Element.prototype.originalRemove = Element.prototype.remove;
    Element.prototype.remove = function() {
      // Custom remove logic
    };
  }
});

4. Performance Considerations

Content Scripts:

Loaded with the page, always running

const observer = new MutationObserver(() => {
  // Constant monitoring
});

observer.observe(document.body, {
  childList: true,
  subtree: true
});

chrome.scripting:

Only runs when needed

async function checkPage(tabId) {
  const results = await chrome.scripting.executeScript({
    target: { tabId },
    func: () => {
      // Quick operation and done
      return document.querySelectorAll('.target').length;
    }
  });
  return results[0].result;
}

Real World Example

Element Removal

Content Script Approach:

// manifest.json
{
 "content_scripts": [{
 "matches": ["<all_urls>"],
 "js": ["darkmode.js"],
 "world": "MAIN" // We want page context
 }]
}

// content.js - Always running, waiting for commands
chrome.runtime.onMessage.addListener((message, sender, sendResponse) => {
  if (message.type === 'removeElement') {
    const { selector } = message;
    const elements = document.querySelectorAll(selector);
    const count = elements.length;

    elements.forEach(el => el.remove());
    sendResponse({ count });
  }
});

// background.js - Sends command to content script
async function removeElement(tabId, selector) {
  return new Promise((resolve) => {
    chrome.tabs.sendMessage(tabId, {
      type: 'removeElement',
      selector
    }, (response) => {
      resolve(response?.count || 0);
    });
  });
}


// Usage:
chrome.action.onClicked.addListener(async (tab) => {
  const count = await removeElement(tab.id, '.ad-container');
  console.log(`Removed ${count} elements`);
});

chrome.scripting Approach:

// background.js - Direct injection and execution
async function removeElement(tabId, selector) {
  const results = await chrome.scripting.executeScript({
    target: { tabId },
    args: [selector],
    func: (selector) => {
      const elements = document.querySelectorAll(selector);
      const count = elements.length;
      elements.forEach(el => el.remove());
      return count;
    }
  });

  return results[0].result;
}

// Usage - exactly the same:
chrome.action.onClicked.addListener(async (tab) => {
  const count = await removeElement(tab.id, '.ad-container');
  console.log(`Removed ${count} elements`);
});

Final Thoughts

The choice between content scripts and chrome.scripting isn’t mutually exclusive. Modern extensions often use both:

— Content scripts for persistent features and state management

— Chrome.scripting for heavy lifting and one-off operations

— Communication between the two for complex features

The key is understanding their strengths:

Use Content Scripts When:

You need persistent monitoring
You want automatic injection on page load
You’re maintaining state across operations
You need early page load intervention
You want declarative injection via manifest

Use chrome.scripting When:

You need one-time operations
You want to pass data directly to injected code
You’re doing heavy DOM manipulation
You need cleaner error handling
You want better performance for occasional operations

Use Both When:

Building complex features
Handling both persistent and one-off tasks
Managing state while doing heavy lifting
Optimizing performance for different operations

If you found this article helpful, feel free to clap and follow for more JavaScript and Chrome.API tips and tricks.

You can also give a recent chrome extension I released that uses a lot of the functionalities from the articles — Web à la Carte

If you have gotten this far, I thank you and I hope it was useful to you! Here is a cool image of a cat (no scripting pun though) as a thank you!

Photo by Chris Barbalis on Unsplash

MutationObserver: The Silent DOM Watcher (And Its TreeWalker Friend)

Kristian Ivanov — Thu, 28 Nov 2024 01:33:17 +0000

MutationObserver: Your DOM’s security camera. Watch elements change, appear & disappear without polling 🔍

Continue reading on Level Up Coding »

TreeWalker: A Practical Guide to DOM Traversal

Kristian Ivanov — Mon, 18 Nov 2024 06:45:57 +0000

Recently I've started working on a new Chrome extension in my free time and in the research on how to handle some of the functionalities, I've started discovering more and more functionalities that JS has in dealing with the DOM of the page.

Given how an overwhelming number of people using JS are using it only through a framework, this would make an interesting topic for a series of short articles for people to learn a bit more about the underlying technologies that the frameworks they rely on are actually using.

We've all been there — you need to find specific elements in the DOM, but querySelector and getElementsBy* aren't quite cutting it. Maybe you need to find all text nodes containing a specific phrase, or you want to traverse elements matching certain conditions while skipping others. Enter TreeWalker - a powerful but often overlooked DOM traversal API.

What is TreeWalker?

TreeWalker is a DOM interface that lets you efficiently traverse and filter DOM nodes. Think of it as a more powerful and flexible alternative to methods like querySelector. While querySelector gives you elements matching a CSS selector, TreeWalker lets you:

Navigate the DOM tree in any direction (forward, backward, up, down)
Filter nodes based on custom conditions
Skip certain parts of the tree entirely
Access text nodes directly (something querySelector can't do)

Creating a TreeWalker

Let's start with a basic example:

const walker = document.createTreeWalker(
    document.body, // Root node to start traversal
    NodeFilter.SHOW_TEXT, // Only show text nodes
    {
        acceptNode: function(node) {
            // Only accept text nodes that aren't empty
            return node.textContent.trim().length > 0
                ? NodeFilter.FILTER_ACCEPT
                : NodeFilter.FILTER_REJECT;
        }
    }
);

The three parameters are:

Root node — where to start traversing
What types of nodes to show (text, elements, comments, etc.)
A filter function that decides which nodes to accept or reject

Real World Examples

1. Find and Replace Text

Here's something you'll actually use — finding and replacing text while preserving HTML structure.

function replaceText(root, search, replace) {
    const walker = document.createTreeWalker(
        root,
        NodeFilter.SHOW_TEXT,
        {
            acceptNode: function(node) {
                return node.textContent.includes(search)
                    ? NodeFilter.FILTER_ACCEPT
                    : NodeFilter.FILTER_REJECT;
            }
        }
    );

    let node;
    while (node = walker.nextNode()) {
        node.textContent = node.textContent.replace(search, replace);
    }
}

// Usage
replaceText(document.body, 'old text', 'new text');

This is much more efficient than using innerHTML and won't break event listeners or form input values.

2. Custom DOM Query

Need to find elements matching complex conditions? TreeWalker has you covered. Let's build something more complex — say you need to find all <span> elements that contain specific text, but only if they're inside <div> elements with a certain class, and ignore any that are inside <button> elements:

function findElementsByComplexCondition(root, config) {
    const results = [];
    const walker = document.createTreeWalker(
        root,
        NodeFilter.SHOW_ELEMENT | NodeFilter.SHOW_TEXT,
        {
            acceptNode: function(node) {
                // Skip nodes we don't care about early
                if (node.nodeType === Node.ELEMENT_NODE &&
                    node.tagName === 'BUTTON') {
                    return NodeFilter.FILTER_REJECT; // Skip button and its contents
                }

                // Check for matching span elements
                if (node.nodeType === Node.ELEMENT_NODE &&
                    node.tagName === 'SPAN') {
                    // Check if parent is a div with required class
                    const parent = node.parentElement;
                    if (!parent ||
                        parent.tagName !== 'DIV' ||
                        !parent.classList.contains(config.parentClass)) {
                        return NodeFilter.FILTER_SKIP;
                    }

                    // Check if span contains the required text
                    const text = node.textContent?.toLowerCase() || '';
                    if (!text.includes(config.searchText.toLowerCase())) {
                        return NodeFilter.FILTER_SKIP;
                    }

                    return NodeFilter.FILTER_ACCEPT;
                }

                return NodeFilter.FILTER_SKIP;
            }
        }
    );

    let node;
    while (node = walker.nextNode()) {
        results.push(node);
    }
    return results;
}

This would match:

✅ Will match:

<div class="message-container">
    <span>Error: Invalid input</span>
</div>

❌ Won't match all of the following:

<div class="other-container">
    <span>Error: Invalid input</span>
</div>

<button>
    <span>Error: Invalid input</span>
</button>

<div class="message-container">
    <span>Success!</span>
</div>

[Rest of code examples...]

The Swiss Army Knife of DOM Traversal

TreeWalker isn't limited to forward traversal. You can move in any direction:

// Move to next node
walker.nextNode();

// Move to previous node
walker.previousNode();

// Move to first child
walker.firstChild();

// Move to last child
walker.lastChild();

// Move to parent
walker.parentNode();

When Should You Use TreeWalker?

TreeWalker shines when:

You need to find text nodes (querySelector can't do this)
You have complex filtering requirements
You need to traverse the DOM in a specific order
Performance matters (TreeWalker is generally faster than recursive DOM traversal)

TypeScript Support

Good news for TypeScript users — the types are built right in:

interface TreeWalker {
    readonly currentNode: Node;
    readonly filter: NodeFilter | null;
    readonly root: Node;
    readonly whatToShow: number;
    firstChild(): Node | null;
    lastChild(): Node | null;
    nextNode(): Node | null;
    nextSibling(): Node | null;
    parentNode(): Node | null;
    previousNode(): Node | null;
    previousSibling(): Node | null;
}

Final Thoughts

TreeWalker is one of those APIs that, once you know about it, you'll find yourself reaching for more often than you might expect. It's particularly useful for building accessibility tools, content management systems, or any application that needs to analyze or modify DOM content programmatically.

While it might seem complex at first, TreeWalker's power and flexibility make it worth adding to your toolkit. Next time you find yourself writing a recursive DOM traversal function, consider whether TreeWalker might be a better fit.

P.S. If you've made it this far, here's a pro tip: Combine TreeWalker with MutationObserver to create powerful DOM monitoring tools. But that's a topic for another article... 😉

If you found this article helpful, feel free to like and follow for more JavaScript tips and tricks.

Cover photo by Branko Stancevic on Unsplash

Cover photo by Branko Stancevic on Unsplash
Cat photo by Jan Gustavsson on Unsplash

Express <> NextJS <> NestJS Cheatsheet for beginners

Kristian Ivanov — Sun, 29 Sep 2024 10:00:52 +0000

Intro

I recently had to learn NestJS to get ready for a project that was written on it. Not NextJS, mind you, but NestJS. Like some of you, I’ve heard about it, but never had a chance to actually use it. It has been growing in popularity for quite a while now, catching up with the grandfather of NodeJS back-end development — ExpressJS just earlier this year. Here is their official tweet:

That being said, there is a big discrepancy on npm in terms of pure downloads — Express stands tall at 32,397,019 weekly downloads at the time of writing, Next is at 7,263,688, and Nest is at 3,579,676. Now Nest really is tied to Express to some extent, which will be mentioned in the article.

I want to highlight that NestJS has excellent documentation (filled with cats as a bonus, but only on desktop…) that provides more than enough information to get you started and explain all of its basic and advanced use cases. Always a great place to start!

If you are like me, after an N number of frameworks and languages, the easiest way to learn a new one is to compare and match it to the things you know. Because of that, I thought a comparison between NestJS and the more popular/traditional/established JS frameworks could be useful to understand some of the concepts.

Context

Express.js is great for lightweight, flexible APIs or small projects with minimal restrictions.
Next.js is ideal for React-based apps where SEO and server-side rendering are crucial.
NestJS excels in large-scale, enterprise-level applications with a focus on modularity and maintainability. It is also by far the most opinionated. A lot of those opinions are coming from other languages that some of the more experienced (to avoid saying older devs) are familiar with — inversion of control, dependency injection — Java + Spring, .NET Core, Angular (the main inspiration for NestJS), PHP + Laravel or Symfony, etc.

Let’s start with some basic simple examples and work our way up.

Starting a Simple Server

And finally NextJS -> next dev

In NestJS, the server is bootstrapped by creating an application using NestFactory and specifying the main application module. The structure is more organized with AppModule at the core.

ExpressJS is more straightforward, creating the server directly by invoking express().

Next.js doesn't require manually setting up a server unless you're using a custom server—its built-in server handles everything under the hood.

2. Handling a Route

Where most of your work lies.

NestJS uses the @Controller and @Get decorators to map routes to controller methods, offering more structure with modular routing. Get used to the decorators and annotations for NestJS. They are a critical part of the language (same as Java + Spring for instance).

ExpressJS allows you to define routes freely using app.get(), which provides flexibility but less built-in structure.

And in Next.js, routing is file-based, where the file name in the pages directory automatically maps to a route, giving you simplicity but less control over route definition.

3. Handling Query Parameters

ExpressJS relies on req.query to access query parameters, offering a more manual approach.

Next.js uses the useRouter hook to retrieve query parameters within the component, aligning more with React conventions.

NestJS uses the @Query() decorator to easily extract query parameters in a controller method.

4. Handling Path Parameters

In ExpressJS, path parameters are defined in the route itself using :paramName. For example, app.get('/users/:id') defines the id as a dynamic parameter. You can then access this parameter using req.params.paramName, which is flexible but less structured than NestJS.

In Next.js, path parameters are handled using dynamic routes. To define a path parameter in Next.js, you create a file with square brackets, such as [id].js, inside the pages directory. The file name ([id]) is used to create a route that dynamically matches any value passed as id. You then use the useRouter() hook to access the parameter within the component. This approach is simple and React-friendly but not as explicit as the NestJS approach.

In NestJS, path parameters are defined using the @param() decorator in combination with the @get(':id') decorator. The @get(':id') specifies that the id is dynamic, and @param('id') is used to extract the parameter in the controller. Path parameters in NestJS are explicitly defined and tied to controller methods, making them highly structured.

5. Adding Middleware

With a lot of the basics out of the way, let’s get to something more interesting. Middleware is used for various things — checking permissions, validations, logging, and much more. While in Express it is just middleware, in NestJS several different things are doing similar work.

Next.js doesn’t have built-in middleware support in the same way that NestJS and Express do. Middleware functions are generally implemented in custom servers (like Express).

Notice how both Express and Nest have a very similar structure. It is time to share the fact that Nest actually uses Express or Fastify under the hood.

In ExpressJS, middleware is more flexible and can be applied globally using app.use() or scoped to specific routes by passing the middleware function as a second argument in route definitions. Express is more unopinionated, giving developers freedom in how middleware is structured.

NestJS offers a highly structured and modular way to handle middleware, integrating it into its dependency injection system, which is ideal for large applications requiring reusable middleware logic.

6. Dependency Injection

This is one of the more opinionated parts of NestJS when compared to the other two frameworks.

NestJS heavily relies on Dependency Injection (DI), which is a core part of its architecture. You can inject services using the @Injectable decorator. Meanwhile, neither Express nor Next support it out of the box, so typically, you’d pass dependencies manually.

The dependency injection is one of the core design patterns used NestJS. It fits into it the following way:

NestJS uses an IoC container to manage dependency lifecycles, automatically injecting dependencies where needed. This shifts the responsibility of creating and managing dependencies from the developer to the framework, streamlining the setup, and reducing manual effort when wiring services, controllers, and other components.
With DI, NestJS enforces a consistent pattern across the application, ensuring that all dependencies are handled the same way. This makes the architecture predictable and reduces confusion.
As your application grows, the IoC container in NestJS efficiently handles an increasing number of dependencies, ensuring smooth scaling. This prevents the chaos of manually managing complex service dependencies, making the codebase more maintainable and reducing the likelihood of errors.
DI in NestJS encourages loose coupling by separating services and their dependencies, making it easier to modify or replace parts of the system without breaking the entire application. This decoupling also enables easier testing and mocking of service.

While all of these points are great for large-scale applications, the DI pattern can be a complication for smaller projects, especially if you are not used to it.

7. Inversion of control

NestJS automates dependency management using an IoC container, while ExpressJS and Next.js rely on manual instantiation of dependencies. Notice how we are just saying that userService or userRepository are of a specific type. After that, all of the additional handling is taken care of by NestJS. We don’t have to think about when to spawn those components, how many instances of them will be there, or anything else. We do have control over those of course.

This makes the last example much more scalable, modular, and easier to test.

The obvious cons to this approach are — the increased learning curve. This is true for all opinionated frameworks, as well as that it might feel like an overkill for small applications.

8 — Permissions Management

While we are on the subject of differences between NestJS and the other two frameworks, I think it is time to mention Guards. Guards are a core feature for managing permissions. They provide a clean, scalable way to control access based on user roles or any other condition. Guards are highly reusable and can be applied to specific routes or globally across the application.

Express and Next are relying on middleware or manual checks on the session, which makes it easier for small apps, but grows in complexity for the larger the application scales up.

9— Data transformation — Pipes

Similar to how Guards work, Pipes are NestJS specific feature. Their main goal in this example is to manipulate or transform the data before passing it onto the controller.

While the same can be achieved in ExpressJS and NextJS with middleware, using Pipes provides for better error handling and easier maintenance at scale.

Not to mention you have the freedom to create your own custom pipes.

10 — Data validation — Pipes pt.2

Notice that while the annotations/decorators can be odd at first, depending on where you are coming from, the larger the code grows, some things are actually easier to maintain and read. Personal opinion, but while the example in NestJS is longer by a few lines, each line is much shorter and easier to follow.

Additionally, it is once again highlighting how things are more maintainable at scale with NestJS.

You can check NestJS’s official docs to see a longer version of this example with additional explanations. It involves a longer explanation than what I am aiming for in this article, so I’ll just be linking it.

Thank you for making it to the end! I was aiming for a few examples between these mostly recognized frameworks and NestJS. This is the first article in a short series I’ll be making on NestJS and trying to tie in its concepts to more common frameworks as a way to illustrate and make it more easy to remember and understand.

If you have gotten this far, I thank you and I hope it was useful to you! Here is a cool image of a cat as a thank you!

15 Linux commands I’ve used most recently and love in general

Kristian Ivanov — Tue, 24 Sep 2024 13:58:27 +0000

Intro

I’ve been using Linux for 15+ years. Not because I am a hacker or anything. It is just easier to set up dev environments compared to Windows, it has better hardware options than Mac. There is the occasional Nvidia driver issue, but as long as you are using it for work and don’t expect it to have a good gaming performance, despite a lot of advancements in Proton, Lutris being amazing and Steam having Linux support for some titles like Dota2.

It provides extreme flexibility and options to configure everything to your liking. It also provides tens of thousands of commands (based on the number of man pages).

The problem with this is that, as a biology teacher of mine used to say, the main function of the brain is to forget things it doesn’t need all the time. Because there are so many different commands, there is always something new to discover and a lot of things that were forgotten, because they aren’t used on a daily basis.

So with all of that in mind, I’ll try to share N number of useful commands I’ve discovered or used last week or so from time to time.

Reading large files —less

When dealing with large files, such as logs, opening them in an editor can be slow and memory-intensive. less provides an efficient way to view and navigate large files without loading the entire file into memory.

less largefile.txt

In this example, /error can be used to search for the keyword "error" within the file, and F allows you to follow new lines as they are added (similar to tail -f).

You can efficiently scroll through and search thousands of lines of logs to find specific errors without opening the entire file in a text editor. This is especially useful when working with large system logs or data files.

Try opening something large with nano or vim and see the difference.

Link for more details

Find Files by Size — find

Disk space can quickly fill up, especially on systems with large media files, backups, or logs. Instead of manually checking file sizes across directories, you can use find to locate large files that might be hogging space.

find / -type f -size +500M

In this example, we are searching for all files larger than 500MB across the entire file system.

Automatically find and address large files taking up space without manually traversing directories. It’s especially helpful when performing system maintenance or managing disk space on servers.

Recently I had an unpleasant experience files taking tens of gigabytes of storage space. It took me quite some time to figure out the root cause, and have since remembered that command fondly.

You can also use find to recursively remove files based on pattern

find /path -name "*.log" -type f -delete

This finds and deletes all .log files under the specified directory and its subdirectories.

Link for more details

Search Inside Compressed Files — zgrep

Instead of decompressing these files every time you need to search for something inside them, zgrep allows you to search within compressed files directly.

zgrep "ERROR" /var/log/system.log.gz

Example of a return

Jun 23 10:15:22 ERROR failed to start service

The matched line from within the compressed file is returned, without needing to extract the contents first.

Link for more details

Preview File Contents with Head/Tail

When analyzing logs or large files, sometimes you only need to see the first or last few lines, such as in cases of debugging or inspecting recently added log entries. head and tail make this quick and efficient. This is particularly beneficial when dealing with large files where only the start or end matters (e.g., logs).

head -n 20 access.log

tail -n 20 access.log

In both examples we are showing up to 20 lines of data. In the first one, from the start of the document and in the second one, from the end of it.

Link for more details

Bulk Text Replacement with sed

When working with configuration files, scripts, or large datasets, you may need to replace certain text patterns across multiple files. Instead of manually opening each file, sed automates the text replacement process in bulk.

sed -i 's/oldword/newword/g' *.txt

This replaces all occurrences of “oldword” with “newword” in all .txt files within the current directory.

Link for more details

Find and Replace for Complex Patterns — perl

When you need to perform more complex text replacements, such as matching patterns using regular expressions, perl is a powerful tool. It handles advanced search-and-replace scenarios that sed might not handle well.

perl -pi -e 's/(abc\d+)/xyz$1/g' *.log

This replaces all instances of “abc” followed by digits (e.g., “abc123”) with “xyz” followed by the same digits (e.g., “xyz123”) in all .log files.

Link for more details

Sort and Uniquely Count Lines

Analyzing log files or datasets often requires identifying unique lines and counting their occurrences. It’s useful for tasks like understanding user activity or identifying common patterns in logs.

sort access.log | uniq -c

The sort command sorts the file, and uniq -c counts how many times each unique line appears.

10 127.0.0.1 — — [23/Jun/2023] “GET /feature1”
5 192.168.1.1 — — [23/Jun/2023] “GET /feature2”

Link for more details

Monitor Multiple Log Files Simultaneously with— multitail

Using multitail, you can view and track changes in multiple log files in real-time in a single terminal. Let’s be honest, after a while the terminal is the same as the browser — too many tabs opened. This way, you can keep things more maintainable.

multitail /var/log/syslog /var/log/auth.log

This command opens both syslog and auth.log in separate panes within the terminal, showing updates to both logs as they occur.

Link for more details

Parallel Processing with — xargs

When performing tasks like file deletion, backups, or processing large numbers of files, doing these tasks sequentially can take a long time. xargs allows you to run commands in parallel, significantly reducing execution time.

find ~/files-to-transfer/ -type f | xargs -P 4 -I {} scp {} user@remote-server.com:/remote/path/

The command will transfer multiple files in parallel to the remote server.

find ~/files-to-transfer/ -type f: This finds all the files in the ~/files-to-transfer/ directory.
xargs: Passes these files as arguments to scp.
-P 4: This runs up to 4 parallel scp processes, speeding up the file transfer.
-I {}: This tells xargs to replace {} with the name of each file found by find.
scp {}: Copies each file {} to the remote server (user@remote-server.com:/remote/path/).

Link for more details

Batch File Renaming with — mmv

mmv is incredibly powerful when you need to rename large sets of files with complex rules. It allows you to use wildcards and placeholders for advanced renaming tasks, such as adding prefixes, changing parts of file names, or moving files across directories in bulk.

mmv ‘backup_*.txt’ ‘#1_$(date +%Y-%m-%d).bak’

'backup_*.txt': This pattern matches all files starting with backup_ and ending with .txt.
1: This is a placeholder that captures the part of the filename after backup_ (i.e., report1, report2, data1, data2).
$(date +%Y-%m-%d): This shell command inserts the current date in the format YYYY-MM-DD.
.bak: The new file extension for the renamed files.

Link for more details

Search for Text in Multiple Files with — grep

When debugging or searching through large codebases, logs, or configuration files, you often need to find specific keywords or patterns across many files. grep allows you to search through multiple files quickly and efficiently.

It is basically ctrl+shift+f for your terminal

grep -Hnr “ERROR” /var/log/

This will recursively search for the word “ERROR inside all log files in the specified directory.

Link for more details

Filter Log Files with — awk

Log files and datasets are often structured in columns (e.g., CSV files or tab-separated data). awk allows you to extract specific columns and apply filters based on conditions, making it ideal for data analysis and report generation.

awk ‘$3 > 100’ file.txt

This command prints only the lines where the value in the third column is greater than 100. A return from it can look something like

line 5: 120
line 9: 133
line 13: 101

Link for more details

Extract Specific Columns from Files with — cut

Similar to awk. Cut can be used to extract only certain columns/fields from files. The difference is the lack of filtering available without the filtering.

cut -d’,’ -f2,3 file.csv

-d',': Specifies the delimiter (in this case, a comma).
-f2,3: Extracts the second and third columns.

Link for more details

Convert Images from One Format to Another with — convert

If you need to convert images from one format to another, such as converting .png files to .jpg, or resizing images for web optimization. The convert command from ImageMagick makes this easy. You can also use it for converting, resizing, optimizing, or applying other transformations in bulk.

convert image.png image.jpg

This one is self explanatory.

convert input.png -resize 800x600 -gravity southeast -draw “image Over 0,0 0,0 ‘watermark.png’” -quality 85 output.jpg

This one is a bit more interesting. Here are some details for it:

input.png: The original image you want to process.
-resize 800x600: Resizes the image to 800x600 pixels while maintaining the aspect ratio (if the dimensions don't match exactly).
-gravity southeast: Positions the watermark in the bottom-right corner of the image.
-draw "image Over 0,0 0,0 'watermark.png'": Draws the watermark image (watermark.png) onto the original image at the specified position.
-quality 85: Sets the output image quality to 85% (a balance between quality and file size for web use).
output.jpg: The final processed image in .jpg format.

And another one:

for img in *.png; do convert “$img” -resize 1024x768 -colorspace Gray “${img%.png}.jpg”; done

This one is a bit complex as well:

for img in *.png; do ...; done: Loops through all .png files in the current directory.
convert "$img": Refers to each image file in the loop.
-resize 1024x768: Resizes each image to 1024x768 pixels while maintaining the aspect ratio.
-colorspace Gray: Converts each image to grayscale.
"${img%.png}.jpg": Saves the output image in .jpg format with the same base name, but replacing .png with .jpg.

And my favorite use case — creating a .gif out of images:

convert -delay 20 -loop 0 frame*.png animation.gif

Link for more details

Killing process in a UX friendly way — xkill

Speaking of my favorite use cases. The command I have used the most over the last 15+ years is xkill.

Running xkill turns your mouse cursor into a crosshair (X), and you can click on any window to immediately force-close it.

Why I love it? Because I can just click on the problematic window instead of manually searching for processes.

Link for more details

If you have gotten this far, I thank you and I hope it was useful to you! Here is a cool image of a cat as a thank you!

Simplify Chrome Extension Development: Add React without CRA

Kristian Ivanov — Mon, 23 Sep 2024 12:38:26 +0000

Intro

We all love React, right (except for the Primeagen). It simplifies building complex UIs tremendously by providing an easy approach to handling states and access to a giant library of modules and components you can use from npm. It even comes up with CRA to bootstrap and make even the initial setup just one command.

I am a fan of Create-React-App (CRA). It is great for most web apps and after having seen a lot of ejected apps from it, or ones that have been building/bundling it with gulp (I feel old sometimes) even without using TypeScript, I’ve grown to appreciate its simplicity and how easy it has made my life when starting any new project.

However, it doesn’t really cut it when building something like a Chrome extension and generates far too much bloat. Additionally, in something like an extension, the UI can be just a fraction of the project, with most of the logic being wrapped in the background/service worker or in the content scripts. This means adding a ton of bloat and tying up everything with the way React is easiest to use is not always the best approach.

Additionally, what if you started with something really simple on the UI side (just a few lines of HTML and tailwind) to try and test your idea, you wrote a bunch of code for the other parts of the extension and then decided to make the UI easier to maintain and scale and add React to it?

In this guide, we’ll build a Chrome extension using TypeScript, Webpack and Tailwind, and only then will bring React without CRA in much more lightweight way.

Setup

I recently wanted to start a very simple Chrome extension to explore some potential use cases Mutation Observer to customize pages. I also wanted to use this opportunity to play around with TypeScript since I haven’t had the chance to use it in a while.

1 — Set Up the Project
Let’s kick things off by creating a new directory for our project and initializing it with npm:

mkdir ts-chrome-extension
cd ts-chrome-extension
npm init -y

2 — Let’s add TypeScript

npm install --save-dev typescript

Once installed, we need to create a TypeScript configuration file. This file will tell the TypeScript compiler how to behave. Let’s create the tsconfig.json file:

{
  "compilerOptions": {
    "target": "es5",
    "lib": ["dom", "es2015"],
    "module": "esnext",
    "strict": true,
    "esModuleInterop": true,
    "skipLibCheck": true
  },
  "include": ["src/**/*"]
}

More details on the tsconfig.json file can be found in the official docs

3 — Let’s add the basic files

mkdir -p src/scripts && mkdir src/popup && touch src/manifest.json src/scripts/{background.ts,contentScript.ts} src/popup/{popup.html,popup.ts}

Notice the multiple creates with touch in the same command. This is a neat way to save time that I’ll cover in a different article soon.

At this point, the structure of our folder should look like this:

├── package.json
├── package-lock.json
├── popup.ts
├── src
│   ├── manifest.json
│   ├── popup
│   │   ├── popup.html
│   │   └── popup.ts
│   └── scripts
│       ├── background.ts
│       └── contentScript.ts
└── tsconfig.json

4 directories, 9 files

You can list like this with the Linux tree command.
In this case with added *-I node_modules *to avoid the usual npm bloat.

What Each File Does:

background.ts: This script runs in the background to handle extension events like installation or message passing.
contentScript.ts: This is injected into the web pages to allow the extension to interact with the page’s content.
popup.html: The HTML file that defines the UI layout for your popup window.
popup.ts: Initially, this file handles direct DOM manipulation or event listeners. We’ll later replace this with a React component.

4 — The Manifest File

The manifest file is the backbone of your Chrome extension. It tells Chrome what your extension does and where to find its scripts. We’ve created ours, so let’s fill it out

{
  "manifest_version": 3,
  "name": "TypeScript Chrome Extension",
  "version": "1.0",
  "description": "A Chrome extension built using TypeScript.",
  "action": {
    "default_popup": "popup.html"
  },
  "background": {
    "service_worker": "background.js"
  },
  "content_scripts": [
    {
      "matches": ["<all_urls>"],
      "js": ["contentScript.js"]
    }
  ],
  "permissions": ["storage"]
}

Here’s a breakdown of what’s happening:

Action and Popup: The "action" key tells Chrome where the popup HTML is located. The popup will load when users click the extension icon.
Service Worker: The "service_worker" in the "background" key is needed for background tasks.
Content Scripts: These allow the extension to interact with web pages.
Permissions: The "storage" permission enables the extension to store user data via Chrome’s storage API.

You can find the Chrome extension’s manifest.json full documentation here.

5 — The Popup Files

Since we’re not using React yet, the popup will be simple and handle basic DOM interactions.

5.1 —popup.html

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>Popup</title>
  </head>
  <body>
    <div>
      <h1>Hello, Chrome Extension!</h1>
      <button id="alertButton">Click me</button>
    </div>
    <script src="popup.js"></script>
  </body>
</html>

This is a simple HTML page with a button and a script reference to popup.js (which will be bundled from popup.ts).

5.2 — popup.ts

This file will handle basic interaction for the popup:

document.addEventListener('DOMContentLoaded', () => {
  const alertButton = document.getElementById('alertButton');

  if (alertButton) {
    alertButton.addEventListener('click', () => {
      alert('Button clicked!');
    });
  }
});

This simple script waits for the DOM to load, then adds a click listener to the button that triggers an alert. This structure sets the foundation for the popup functionality before we add React.

6 — Compile TypeScript

Let’s compile the TypeScript files into JavaScript. Run the following command:

npx tsc

This will transpile your TypeScript files into JavaScript. The popup.ts, background.ts, and contentScript.ts will be compiled to popup.js, background.js, and contentScript.js, respectively. But since we’ll soon add Webpack to manage the bundling, this is just a temporary step.

7 — Adding webpack for Bundling

Now that we have the basic structure, we need Webpack to handle bundling all our scripts into optimized files that Chrome can load. It can handle the copying of icons, transpiling ts into js, automatically injecting script or style files and much more.

7.1 — Install Webpack and necessary loaders

npm install --save-dev webpack webpack-cli ts-loader html-webpack-plugin mini-css-extract-plugin css-loader postcss postcss-loader copy-webpack-plugin

webpack: The core bundler.
ts-loader: Transpiles TypeScript for Webpack.
html-webpack-plugin: Helps generate HTML files with injected script tags.
CSS and PostCSS Loaders: For handling CSS (we’ll use these later with Tailwind).
CopyWebpackPlugin: The CopyWebpackPlugin ensures that the manifest.json and any other assets (like icons) are copied from the src folder to the dist folder.
— We define patterns, such as copying manifest.json from src/ to the root of the dist/ directory.
— If you have icons or other assets (e.g., images, fonts), you can add similar patterns.

7.2 — Webpack Configuration

Next, we need to configure Webpack to bundle everything. Create webpack.config.js at the root of your project:

const path = require('path'); // <-- This is missing and causes the ReferenceError

const HtmlWebpackPlugin = require('html-webpack-plugin');
const MiniCssExtractPlugin = require('mini-css-extract-plugin');
const CopyWebpackPlugin = require('copy-webpack-plugin');

module.exports = (env, argv) => {
  const isProduction = argv.mode === 'production';

  return {
    entry: {
      popup: './src/popup/popup.ts',
      background: './src/scripts/background.ts',
      contentScript: './src/scripts/contentScript.ts',
    },
    output: {
      path: path.resolve(__dirname, 'dist'),
      filename: '[name].js',
    },
    resolve: {
      extensions: ['.ts', '.js'],
    },
    module: {
      rules: [
        {
          test: /\.ts$/,
          use: 'ts-loader',
          exclude: /node_modules/,
        },
        {
          test: /\.css$/i,
          use: [MiniCssExtractPlugin.loader, 'css-loader', 'postcss-loader'],
        },
      ],
    },
    plugins: [
      new MiniCssExtractPlugin({
        filename: '[name].css',
      }),
      new HtmlWebpackPlugin({
        filename: 'popup.html',
        template: 'src/popup/popup.html',
        chunks: ['popup'],
      }),
      new CopyWebpackPlugin({
        patterns: [
          { from: 'src/manifest.json', to: 'manifest.json' },
//          { from: 'src/icons', to: 'icons' },  // Copy any additional assets
        ],
      }),
    ],
    mode: isProduction ? 'production' : 'development',
    devtool: isProduction ? false : 'inline-source-map',  // Disable source maps in production
  };
};

Explanation:

Entry Points: We’ve specified the entry points for popup.ts, background.ts, and contentScript.ts.
Output: The bundled files will be output to the dist folder.
Loaders: We use ts-loader to handle TypeScript and css-loader/postcss-loader For CSS processing (later on when we introduce Tailwind CSS).
HtmlWebpackPlugin: This plugin automatically injects the bundled popup.js file into the popup.html file, ensuring that our scripts are correctly linked.

7.3 — Build the Extension with Webpack

Let’s bundle everything using Webpack by running:

npx webpack --mode development

This will output the bundled files into the dist directory.

If you are having issues because of the icons section, you can either remove it or put some placeholder .pngs for now.

You will have something like this

If you click the button you will get an alert. Twice. But why?

Remember how I said that webpack can inject script tags among other things? Check out your built popup.js in the dist folder and you will see the popup.js has been injected twice (once from the HTML file itself, and once from webpack).

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>Popup</title>
  <script defer src="popup.js"></script></head>
  <body>
    <div>
      <h1>Hello, Chrome Extension!</h1>
      <button id="alertButton">Click me</button>
    </div>
    <script src="popup.js"></script>
  </body>
</html>

To fix this, simply remove the script tag in the popup.html in the src/popup folder so it looks like this:

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>Popup</title>
  </head>
  <body>
    <div>
      <h1>Hello, Chrome Extension!</h1>
      <button id="alertButton">Click me</button>
    </div>
  </body>
</html>

Don’t worry. Webpack will still add it inside.

Test it out.

Take a look at the dist folder as well.

8 — Adding Tailwind for Styling.

Tailwind CSS is a utility-first CSS framework that allows you to style your UI without writing custom CSS for each component.

Over the years people have fallen in love with it. Sure, it is easier to add some basic styling on your own, but when you know you will be spending time on that project, Tailwind makes it easier to scale later on and keep it consistent for other people if they join you (the same class will always mean the same thing, vs when you implement it yourself, font-size-small can mean any number of things.)

8.1 — Installing Tailwind

npm install tailwindcss postcss postcss-loader autoprefixer

8.2 — Configure Tailwind and PostCSS

Next, we need to initialize Tailwind and configure PostCSS. Start by initializing Tailwind with the following command:

npx tailwindcss init

This will create a tailwind.config.js File in the root of your project. Open this file and modify it to include the paths where Tailwind should apply its styles (in our case, inside the src folder):

module.exports = {
  content: ['./src/**/*.{ts,tsx,html}'],
  theme: {
    extend: {},
  },
  plugins: [],
};

The content key tells Tailwind where to look for classes in your files.

Next, create a postcss.config.js File in the root directory and configure it to use Tailwind and Autoprefixer:

module.exports = {
  plugins: {
    tailwindcss: {},
    autoprefixer: {},
  },
};

8.3 — Create the Tailwind CSS Entry File

In src/styles, create a new file called tailwind.css. This is where we’ll import the basic Tailwind styles:

@tailwind base;
@tailwind components;
@tailwind utilities;

This file will include all of Tailwind’s utility classes.

8.4 — Modify the Webpack Configuration to Handle CSS

We need to ensure Webpack knows how to process CSS files using PostCSS. We already installed postcss-loader and css-loader earlier, so now we just need to make sure it’s properly configured.

Change this:

{
  test: /\.css$/i,
  use: [MiniCssExtractPlugin.loader, 'css-loader', 'postcss-loader'],
},

To this:

{
  test: /\.css$/i,
  use: [MiniCssExtractPlugin.loader, 'css-loader', 'postcss-loader'], // Process Tailwind CSS
},

This ensures Webpack can process Tailwind CSS when we include it in our popup. Speaking of this…

8.5 — Import Tailwin into the Popup

To start using Tailwind, we need to import the tailwind.css file into our popup script (popup.ts). Open popup.ts and add this import statement at the top:

import '../styles/tailwind.css';

8.6 — Add Some Simple Tailwind Styling

Let’s update the popup.html file to use some Tailwind classes for some basic styling. After all, all of the configs we just wrote and connected will be almost useless without it.

Can you guess or explain why it is ‘almost’ and not completely useless if we add tailwind but not any tailwind classes? Discuss it in the comments ;)

This is what our popup.html should look like now:

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>Popup</title>
  </head>
  <body class="bg-gray-100 p-4 w-80">
    <div class="flex flex-col items-center">
      <h1 class="text-xl font-bold mb-4">Hello, Chrome Extension!</h1>
      <button id="alertButton" class="bg-blue-500 hover:bg-blue-700 text-white font-bold py-2 px-4 rounded">
        Click me
      </button>
    </div>
    <script src="popup.js"></script>
  </body>
</html>

Here, we’ve added some basic Tailwind classes to style the popup:

Background: The popup’s background color is a soft gray (bg-gray-100).
Centered Content: Flexbox is used to center the content vertically and horizontally (flex flex-col items-center).
Styled Button: The button has Tailwind’s built-in button styles for hover effects, colors, and rounded corners (bg-blue-500, hover:bg-blue-700, text-white, rounded).

Let’s rebuild it and check the difference. -> npx webpack --mode development

Isn’t that better?

9 — Adding React to the Popup

We’ve got a functional extension with Tailwind styling and TypeScript for some syntax niceties and early problem detection. We also even have postcss and autoprefixer, which I’ll cover in a different article. And everything works.

Imagine however you need to make the UI more complex to manage loading and unloading data, handling tabs, and showing different UI based on the user’s subscription status. We might be getting ahead of ourselves, but for the sake of this guide, let’s assume there is a reason for it and add React to solve all of these problems. In my use case I added React to handle loading a dynamic set of data (which could’ve been done as a simpler template, but in combination with color pickers and switches of the UI based

9.1 — Install React and ReactDOM

npm install react react-dom @types/react @types-react-dom

9.2 Update Webpack for React

We need to update Webpack so it can handle .tsx files (React with TypeScript). Remember, this was the main goal we set up to do.

To handle this, modify the webpack.config.js file to include React as an entry point:

entry: {
    popup: './src/popup/popup.tsx',  // Update this to point to the new React component
    ...
  },
  resolve: {
    extensions: ['.ts', '.tsx', '.js'],  // Add .tsx to resolve for React files
  },
  module: {
    rules: [
      {
        test: /\.tsx?$/,  // Handle both .ts and .tsx files
        ...

9.3 — Convert popup.ts to React

Now we’re going to convert popup.ts to a React component. Rename popup.ts to popup.tsx and update it with a basic React component:

import React from 'react';
import { createRoot } from 'react-dom/client';
import '../styles/tailwind.css';

const Popup = () => {
  const handleClick = () => {
    alert('Button clicked!');
  };

  return (
    <div className="flex flex-col items-center bg-gray-100 p-4">
      <h1 className="text-xl font-bold mb-4">Hello, React Chrome Extension!</h1>
      <button
        className="bg-blue-500 hover:bg-blue-700 text-white font-bold py-2 px-4 rounded"
        onClick={handleClick}
      >
        Click me
      </button>
    </div>
  );
};


const container = document.getElementById('root')
const root = createRoot(container as HTMLDivElement)
root.render(<Popup />);

This simple React component mirrors the functionality of the original popup.ts but uses React’s onClick event for the button.

9.4 — Update popup.html

We don’t need to change much in popup.html except ensure it has the proper div to mount our React component. Here’s the updated popup.html:

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>Popup</title>
  </head>
  <body class="bg-gray-100 w-80">
    <div id="root"></div>
  </body>
</html>

9.5 — Update tsconfig.json

We need to add "jsx": "react" and "moduleResolution”: “node"to our tsconfig.json It should look like this:

  "compilerOptions": {
    "target": "es5",
    "lib": ["dom", "es2015"],
    "module": "esnext",
    "strict": true,
    "esModuleInterop": true,
    "skipLibCheck": true,
    "jsx": "react",
    "moduleResolution": "node"
  },
  "include": ["src/**/*"]
}

9.6 — Rebuild with Webpack

Once the changes are made, run Webpack to rebuild the extension -> npx webpack --mode development

Now, when you reload the extension in Chrome and open the popup, you should see a React-powered UI styled with Tailwind CSS.

Conclusion — Why Not Use Create-React-App?

CRA makes a lot of assumptions about how you’re building your app, bundling everything into a single page with dynamically injected JS. This approach works great for a React web app but doesn’t mesh well with Chrome extensions, which use separate HTML pages for the popup, background scripts, and sometimes even options pages.

The best parts of building without CRA? Control and learning.

You decide what gets included, how the bundling works, and how lean or rich your extension becomes.

I also believe it is a good idea to try and see how difficult something is without the library, framework, or bootstrapping helpers. It helps learn a bit more about all of the technologies that are being used indirectly and hidden from you.

If you have gotten this far, I thank you and I hope it was useful to you! Here is a cool image of a cat as a thank you!

Hiring for remote work in 2022

Kristian Ivanov — Sat, 17 Sep 2022 10:36:17 +0000

I've written twice about remote work so far, but only from the perspective of an engineer looking for work.

Last year me and old co-worker of mine decided to start something on our own. It started as something to be done on the side. However, after I cashed out from a previous start up that I was an employee of, it became a full time job, and earlier this year we started doing our first hires for the engineering department to speed up the development process. I'll try to cover what platforms we used, which were better and some notes so people could eventually skip some of the wasted time we had.

I'll break down the different options in several categories to make it easier.
Edit: Even though I didn't intend it at the start. The options are ordered from worse to best (in my humble experience of course).

Remote working platforms

This would be your average platform for posting jobs and looking for jobs. I have been a fan of We Work Remotely when I had to work for a job before, but the list of them is pretty long. Some of the ones that spring to mind are

Angel List
Remote Tech Jobs
Otta
No Desk
Dice
Remote Work Hub
javascriptjob.xyz/remote/jobs
remoteok.com/ You can check a detailed breakdown from a candidate perspective here Finding remote work in 2022

Pros

High traffic and visibility, especially if you pay for a promotion
The post would usually be up for an entire month

Cons

Cost! As I've mentioned, I am a fan of we work remotely when looking for a job. From a recruiter's perspective, things are a little bit different though. Most (all that I've tried) platforms will require you to pay for your posting. This is normal, as the website needs to be profitable to exist. However, based on your funding and recruitment needs, $448 per month for a job posting and an upgrade to show it among all of the postings that have a promotional listing, which are more of them, can be pretty steep. Especially when you post on multiple platforms at the same time. It is true that an early stage start up has plenty of expenses (especially the legal ones), but 4 similar platforms would still sum up to $1500-$2000 per month.
No guarantee. You have no guarantee if and how many candidates will apply to your posting.
Most of them require a company page and details. If you are still in stealth, this can be annoying.
Angel List has a particular low quality of applicants, despite it's fame as a start up place.

With the pandemic over the last few years, the world migrated more and more towards remote work and so did LinkedIn.

Pros

Visibility. More and more people are using LinkedIn to find a job, especially after they added the easy-apply option.
Cost! It is cheap and the billing is based on the number of days, the posting is up. The moment you cancel it, you stop being charged, unlike the platforms, which are charging per month.

Cons

It requires a company page. If you are still in stealth, this can be annoying. You can circumvent this by using something like Stealth Startup
It still requires location for the employees! This is my biggest gripe with LinkedIn, as it limits the remote working, even though it shouldn't.

Recruiters

They will be searching proactively for people, and should (theoretically at least) find more people faster than a simple job post. +/- Cost (this can be a con as well). Most of them won't charge you unless they find a candidate. If they do, however, their cost will be calculated based on the monthly salary of the candidate. In the case of an early stage start up, this can be beneficial, as most of the early employees prefer having more shares instead of a bigger salary, which in turn reduces the payment to the recruiter.

HackerNews

This one is a bit more complicated as it has a few different parts:

https://news.ycombinator.com/jobs / https://www.ycombinator.com/jobs
Ask HN: Who is hiring? (September 2022) - new thread each month
Ask HN: Who wants to be hired? (September 2022) - new thread each month

Searchers build on top of the information from those threads

You can have several different approaches with this one.

Passive - you can post on it for each monthly thread and check/wait for responses.

Proactive - you can check the listings of who is looking for a job. Then research them, see if they are matching your criterias and then reach out to them. It shows a lot more personal approach.

Friends/Old co-workers

This should be your first stop. If you have any people you've worked with before or any friends that you think would be a good fit, try and talk to them. Still, make them follow as much of the recruitment process you have set in place as possible. You can skip the first couple of stages, but always have them talk with your co-founders as well to make sure everyone is on board. Make it clear that this is a working relationship and is completely separate from your friendship in the case they are a friend.

General recruitment notes:

Try to be as accommodating as possible for the candidate in terms of time of the meeting and duration. Don't make them bend backwards by asking them to stay until 3 AM so they can meet you up after you've had morning coffee! Try to find a time that works for both you, and them.

Don't ask them why they are excited to work for your company! In my experience (sorry for being cynical) people are looking for a job based on this criteria (in order of importance):
1 - Salary
2 - Title/company structure - is it a step up, or how easy it would be to step up based on the company structure
3 - Technologies (for engineers) - is the company using something they find interesting and have or want to have an experience with.
4 - Direct managers - How easy would be for them to work with you. This brings things back to the be as accommodating as much as possible point and leaving a good impression. And old HR friend of mine had the saying that "People don't leave companies, they leave their bosses".
5 - What is the company product or what the company does. So don't expect them to focus on this one as much as you want.

Don't go overboard with the technical take at home test. People most often than not already have a job that they want to change. Try to keep it as simple as possible and within 2-3 hours.
I got into the habit of specifying only the tech stack and some basic complexity requirements and letting the candidate run wild with it. It showed much more of what they are interested in and comfortable with than otherwise and was a better source for a discussion during out next in person interview.

Don't go overboard with the cover letter (same reasoning as the technical take at home test), but do ask them to write something. Focus on a few key points and don't provide too rigid of a structure. I believe this also shows much more about them and it would be a lot more interesting read than the usual stock cover letter.
I am mentioning it for another reason - the remote work leads to a lot of written communication. Be it slack, emails, specifications, jira tickets or anything else, they should be able to read and write well. The same goes for the recruiter too, by the way!
It is worth mentioning I've started working at a company before and liked another company before that, simply because of the cover letter requirements and that I honestly had fun writing it and telling a story within it.

Be quick to reply to their emails. Nobody wants to wait for 6 months to hear back from a company. I expect the same from candidates, as well.

Don't go overboard with the recruitment process by having a million steps. The bigger the company, the more complex this tends to become, but still, do your best to keep it simple and easy moving. Also, do your best to let the applicant know what the next step is and what would be expected of them during the next meeting, to put them at ease.

Be transparent - in your requirements, expectations, when rejecting them, or when offering them the position at the end.

P.S. Everything written above is from my own limited perspective after recruiting and interviewing for a couple of start ups and now doing it for my own. So far I've had to handle 2000+ candidates for several positions. It is not a lot, so take everything I've said with a grain of salt. I would love to discuss what others have come across while searching for new colleagues in the comments below or on Twitter

Last disclaimer - The image at the top of the article is from Eric Prouzet at Unsplash

Finding remote work in 2022

Kristian Ivanov — Sun, 11 Sep 2022 15:07:11 +0000

A few years back I wrote how to find remote work in 2019 after a personal research of having to find a remote work for the first time not by being approached by a headhunter, but on my own. That article did better than a lot of other things I've written. However, recently I had to hire people about of a very very early stage startup (the very first hires other than the co-founders), and noticed the list and feedback I had on my original article needed some updates, especially with the business world embracing the remote work more and more after the pandemic.

So here they are - in this article I'll cover the most popular platforms I've noticed as being used and their pros and cons and in another one I'll cover the perspective of someone looking to hire and the pros and cons of the platforms then, as they more often than not are quite different.

We Work Remotely

Still my favorite several years later! I've found most of my job opportunities through WWR.

Pros
+All companies I have contacted for job postings on this website were fast to +respond.
+All had a quickly moving hiring process.
+It has several types of jobs - marketing, programming, etc.
+It also has the benefit of showing where candidates must be located for the job.
+It has kept growing over the years. It now has 28,530 postings

Cons
-It doesn't allow for an easy apply like other entries on the list.
-The increased number of companies leads to a bit of a dilution of how often companies reply and how quick their process is.
-There is no streamlined way of applying for a job. The button for applying can lead to anywhere - outside platforms or even just email addresses without any guidance on what information is of interest to the company.

Remote Tech Jobs

Built as a replacement of Stack Overflow jobs, based on their description.

Pros
+It has much better filtering capabilities than other options, to find what you are looking for
+All jobs get taken down after 30 days at most, ensuring fresh listings.
+Has a lot of open opportunities. Almost 5 000 at the time of writing, which when the previous point is considered is a lot of activity from companies looking for candidates.
+Has an easy-apply option.

Cons
-They also aggregate jobs from 11 other platforms, aiming to be the go to place for finding remote work. However, when tested with several postings from We Work Remotely, they didn't appear in the results of Remote Tech Jobs.

Pros
+The most obvious candidate for everyone.
+The number of companies looking to hire through LinkedIn has increased over the last several years.
+Has an easy-apply for a lot of the open positions
+Can filter by location as well (in case you need/want to go to an office as well or are looking for a simpler legal process (when both you and your employer are in the same country), or if you are just considering moving there)
+Can easily research the company's profile right there in LinkedIn, including for active or past connections to get some inside information

Cons
-It still has mostly permanent positions
-A lot of early-stage startups don't post on LinkedIn while they are still in stealth mode, so if you are interested to be one of the first hires at a company, other entries such as AngelList or HackerNews would be better options

AngelList

Pros
+Has a lot of active listings
+Companies are required to list their salary range for the posting, so there is less of a chance of surprises
+Companies also list expected bonuses in terms of stock options
+Has a streamlined application process

Cons
-There is a lot of competition especially because of the easy application process so you'll need to stand out
-Most of the companies on AngelList are early stage start ups. This can be viewed as a benefit for some people as well

Otta

Pros
+Each company posting jobs at Otta is screened by them so the quality feels a lot better than some other platforms
+Extremely good filtering
+Streamlined application process

Cons
-Lower number of overall job postings

HackerNews

This one is a bit more complicated as it has a few different parts:

https://news.ycombinator.com/jobs / https://www.ycombinator.com/jobs
Ask HN: Who is hiring? (September 2022) - new thread each month
Ask HN: Who wants to be hired? (September 2022) - new thread each month

Searchers build on top of the information from those threads

Pros
+More personal approach for each position
+You'll most likely get interviewed by the actual people you'll work with and not an HR, recruiter, or a headhunter
+A lot of open positions and overall active community

Cons
-No easy filtering like other options on the list
-Some listings might have expired and not been closed
-No easy way to find still opened listings (from the end of last month for instance)
-If you are posting your own profile to get contacted, you'll need to do it every month (if you don't find a job right away)

Other noteworthy mentions that have declined over the years

No Desk
Dice
Remote Work Hub

Pilot
Upstack
Gun.io

Notes:

Always read the job posting in its entirety! Some companies would ask questions in their listing that they'd like to get an answer to when applying. A sort of a replacement for the usual stock cover letters.
Prepare yourselves for a lot of companies not closing their job postings after finding a candidate. Especially on HackerNews.

P.S. Everything written above is from my own limited perspective when I have applied for different jobs or noticed when deciding on which platform to post a job to get the maximal result. It may vary for different disciplines and/or cases. I would love to discuss what others have come across while searching for job opportunities in the comments below or on Twitter

Last disclaimer - The image at the top of the article is from Ostap Senyuk at Unsplash

The interview is a two way process, what to look for and what to watch out as an interviewer or a candidate

Kristian Ivanov — Thu, 09 Jul 2020 13:25:29 +0000

Intro

For about an year I've interviewed a lot (and I do mean A LOT of candidates at Chili Piper, before that I've did interviews for my previous employers and I had a period of experimenting with different platforms to find remote work (which led to plenty of interviews). You can read more about it here Finding remote work in 2019. I've also talked a lot with friends, co-workers, etc. on job hunting, recruitment and so on. What is listed below is what I've noticed is a good or bad indicator for both candidates and interviewers.

Pre-interview

The job posting

The way a job posting is written tells you about the company. This can take several posts on its own, but in general if the listing is using every popular framework and language, it was most likely not written by an engineer, but by an HR, so expect that initially you'll have to deal with HR, before actually talking with your future co-workers. If it was written by an engineer, it is highly likely that the company will have issues in the future. For instance I recently had an offer with the following tech stack - FE with experience with WebGL graphic libraries such as Three.js, Babylon.js, Paraview, etc. DevOps stack including Jenkins, JFrog, GitLab, Docker, Kubernetes, Ansible. Understanding of 3D Math, ReactJS/React Native, Angular, NodeJS with Express, Flask, Django, Rails, Spring or PHP. Any SQL or NoSQL (list them here). Languages as JS, Python, .Net core or Java. Since this wasn't written by a recruitment agency or an HR, it makes me wonder how many projects a single dev has to work on, how are they being maintained, how is the tech stack being chosen, how you find new devs, how you onboard them, etc.
After a while you'll get to decipher the usual lingo of competitive salary, growing environment and so on.

Requiring you to write a cover letter

If they (the company) requires for it to not be a stock letter it is a huge Pro. The template cover letters are boring to both write and read.
From a company perspective, this automatically filters most of the candidates that are just applying on every position they see. The cover letter requires the candidate to read and follow your instructions. It is also a great way to evaluate the candidate's writing skills. After all a lot of the communication in a company is in a written form. This is especially true for remote companies.
From a candidate's perspective, this is a great chance to hone your writing skills and dazzle them by telling them a short story about yourself. Cover letters typically come with a set of guidelines or question telling you what to focus one. This can be used as a great indicator on what the company values are and whether or not you really want to work there. Additionally this will give you something to talk about on the interview.

Speed

Speed of replying, setting up meetings, how far the meetings are in the future, how fast they reply if you follow up with questions, etc. As everything else, this is valid for both the employer and the candidate.
As a candidate I typically avoid companies that are taking a couple of weeks to get back to you and are setting up your first interview or even the follow ups several weeks in the future. If they do that you can typically expect a higher amount of bureaucracy involved not just in the hiring process.
If a candidate takes so long to respond and set up an interview, they are most likely not that interested in working for/with you.

Testing (Pre-Interview)

If you are using coderbyte, toggle hire, hacker rank, etc., try to tailor the coding exercises and questions to your actual needs. For instance, asking what the "S" in the SOLID principles stands for or is 0.1 + 0.2 equals 0.3 in JS isn't really an accurate representation on the candidate's knowledge. The coding questions are finite and after a while people start getting use to them.
Alternatively you could set up a barebone repo and give people a task to complete something with it and then run automated tests against it (typical for clevertech) This was you can learn a bit more about the candidate's skills.
It all depends on how much you want to filter developers before talking to them. You'd be surprised how useful a simple writing exercise to write a function that finds if two strings are anagram can show you about a person. People almost always try to overthink and over complicate it.

Interview

Questions

In general open ended questions are better. They require a bit more thought before answering and are closer representation to actual human communication.
Examples for interviewers - tell me a bit about yourself (it is interesting what the candidate will focus on), what would you do in situation X, how would you react to Y, What do you thing about Z, how much supervision do they expect, etc.
Examples for candidate - what is a typical day at Company X looks like, what is your approach on Y, how do you handle Z, how are you financed, client revenue or investors fund, how many people have you highered (to see if they are overreaching, because they have received financing or they actually need people), how many people are working on something, how hands on are they, ask them about their technology stack (even though it is already listed) follow up on why they picked the technologies they did, how did that work out for them, etc.
Asking question as a candidate means that you care about where you are working and is not just about the paycheck.
The questions you ask tell the other as much about you, as you'll learn by the answers.

Do some research

As an interviewer you can check the candidate's previous companies and especially their side projects and ask them about it. People love being asked about their passion projects.
As a candidate, try to learn as much as possible about the company before the interview. You'd be surprised how much a well timed question about the billing system they are using or something else that you noticed on their product will make you stand out of the crowd. If you are applying for a startup, you even have pretty good chances to ask the person that had actually develop the thing you are curious about.
In both cases it shows that you did some preparation before hand and makes (or it seems to make) you more caring and interested.

Bad phrases

As a candidate be wary of interviewers (especially on a higher level) that use "I" too much. For example - I pay well, I pay on time, I've highered X amount of people, I've interviewed. It speaks volumes for that person ego. Some adjustments for non-native English speakers are needed of course, but you can understand if it is a mistake or intentional based on the tone of voice, speaking patterns and general context.
As a candidate you can do that as well. Some applicants love to use "I". Usually, no matter how much of a superstar someone is, they didn't work completely alone. Using a dash of modesty when giving the overview of what you've done, by using "WE" or something similar and then filling up your specific role by another means, either in the follow up questions or something similar can do wonders.
In general "WE" as a company, or a team, etc. are great or terrible. Individualism, especially in the leadership positions isn't good.

Live Coding (optional)

Not every company has it.
If you have it, as a company, try to use tasks that have more than one right solution and that are not usually used in online tests, articles, etc. This will help you reduce the chance that the person would have already done something similar. After a while (20-50-100 interviews) you'll start associating the chosen direction of the solution with other personality aspects. Additionally, try to keep it short and sweet. If you plan to interview someone and set up 1-1.5 hours of live coding and this is after work hours, that person can perform a bit worse on the questions after, simply because they are exhausted.
If you do it, as a candidate, try to explain what you are doing it to some extent. It will speak to your thought process. Especially if you hit a snag at some point of doing it. Don't worry, live coding reduces everybody's skills. Even if they are not being interviews, but are just working with a colleague.

Subsequent interviews

Take home coding task (optional)

Not every company has it.
If you have it as a company try to incorporate some open ended questions in it. If you want to be sneaky you could always try to make it a bit vague and see how many people will ask you questions and try to clarify it and/or how they'll interpret it. After all, this will happen sooner or later during the time they work with you. Either way, try to keep it short and sweet here as well. Chances are your candidates are working somewhere at the time and everything longer than one or two hours would make it difficult for them to find time for.
As a candidate - try to do it in a repository, even if it is not required, try to make some github issues for it (if you are using github), do make multiple commits (it will help show your work process) and definitely do it as soon as possible after the interview that "assigned" it to you. This way your next interviewer will have plenty of time to go through it and you'll have a linchpin for the next interview.

Avoid repetition

As a company - try to streamline your interview process. Let the people that interview candidates sync between them what each of them will tell and ask them. When you get the same story told two or three times by an engineer, CTO and the CEO or get asked the same few questions by all of them, it makes you question the planning abilities of those people. It is super a super easy pitfall to avoid, by sending an email with your feedback to everyone else in the process for that candidate with your feedback and then just replying to it. This way you have all of your information in the same place. As a candidate - try not to say the same thing that is on your CV. They have already read it. If you do talk about the same things, tell them in a different light. Depending on the questions they have asked you, try to talk about the things that the company will need. They have problems with X and Y? Great! Talk about how you solved something similar before, and of course, try not to make it too obvious what you are doing.

The payment expectation question

I've been working remotely for ~3 years now. I hate that question! Most of the time I am based in Sofia, Bulgaria. You'd be surprised how much the IT sector is driving the average salary for the country upwards. I get that companies are trying to save as much as possible and are trying to pay the salary of a region + X, but often times, devs don't know the average salary for their own region. This calculation becomes even messier, when you take into account that when you are working remotely, usually you'll have to pay your own taxes, social security, etc.
My typical dodge of this is to find out if they have other people at the same position. Be it FE, BE, leads, product owners, doesn't really matter. Then explain that it depends on the workload, the company, etc, and you'd prefer for the company to make you an offer. Many companies would be OK with that. If they are not, you could ask them to just average out the salary for your position and make you an offer. Most of the companies would be OK with that. If they are not, don't give them your direct expectation, but a ballpark. Otherwise if you ask too much, they can just stop the interview process and if you ask too little, you may be unhappy.
Most decent companies will raise your salary to the average level if you ask for too little anyway, so there isn't anything to be afraid of.
Keep in mind that this will usually take some back and forth for all sides to agree. Even if it is several sentences in the span of 5-10 minutes. Don't be afraid to discuss it and to hear "no". Things are rarely given when you don't ask for them.

These are just my two cents on the topic. Take them with a grain of salt. I would love to hear what you have come across and what good or bad sings you have noticed in your career.

Making your life easier with a Makefile

Kristian Ivanov — Mon, 13 Apr 2020 14:07:21 +0000

Intro

Recently I have been spending more time on one of my side projects. This lead to completely refactoring it and expanding the initial simplistic vanilla JS Chrome Extension to Chrome Extension bootstrapped with CRA, android hybrid version and (since last weekend) a web version.
All of this means playing around with yarn watch | build, cordova run | build, different methods of generating build files - .apk for the Android playstore and .zip for the Chrome webstore, different imports and start ups based on the environment and so on. Updating the app version across multiple files in various folders.
My immediate dev response to all of that was to try and bootstrap all of this as much as possible in any way. First of all this would make it less prone to errors and more consistent, and secondly I am too lazy to be bothered to execute several commands over and over for every build and try to remember all of them.
My education had touched makefiles only in the context of C++ and when talking with friends of mine, it turned out that they had similar experience. Here is a super short description of what a Makefile is, what you can put inside it and how you can use makefiles to make your life easier by bundling sections of logic together to avoid repetition.

Enter Makefile

From Wikipedia:

A makefile is a file (by default named "Makefile") containing a set of directives used by a make build automation tool to generate a target/goal.

The simplest way to look at it is - If you can type/do something from your terminal, you can put it into a makefile. If something is too complicated, you can put it into a script file and execute it from the makefile.

Another way to look at it is - a way to keep a set of shell aliases in your repository so you can re-use them across multiple machines and/or users.

Basic anatomy of a Makefile

Commands:

Commands are defined by a string, followed by a colon. What the command would do are the next lines. They are typically prefixed with a tab. You will see examples of commands bellow.

You can define a default command to be executed. It will be run if you execute "make" without any params:

.DEFAULT_GOAL: help
default: help

The most common definition of the help command inside a make file I've seen and used is the following

help: ## Output available commands
    @echo "Available commands:"
    @echo
    @fgrep -h "##" $(MAKEFILE_LIST) | fgrep -v fgrep | sed -e 's/\\$$//' | sed -e 's/##//'

This will read all commands listed in the make file and display them in the terminal. It is useful if you have forgotten what the appropriate syntax is to quickly check it, or if you are just getting familiar with a makefile somebody else had added to list all options without reading the makefile itself. For instance, for me it outputs the following:

help:  Output available commands
extension-clean: remove old build of the extension
extension-build:  build the chrome extension
android-clean: remove old build of the android app
android-build:  build the android app
bump-version:  update the version for the chrome extension and the android app
make android-debug: debug android
make extension-debug: debug chrome extension
make web-clean: remove old build for the web
make web-debug: debug web version
make web-build: build web version
make build: build all platforms

You can bundle commands together. You can notice that I have 4 separate build directives listed above. One for each platform and one to build everything. Here is what the one to build everything looks like:

make build: ##build all platforms
    make extension-build
    make android-build
    make web-build

It will call each of the build commands one by one and do whatever is described inside them, bootstrapping the logic even further.

Variables

You can add variables into your makefile. The most common use case from my perspective is to avoid typing long path names over and over. For instance, I have this in mine

unsigned-app-path = platforms/android/app/build/outputs/apk/release/app-release-unsigned.apk
android-app-folder = android-app

Makefiles can also get variables from the shell when executing them. If you run a makefile directive with

make bump-version version=1.1.1

You will be able to use ${version} as a variable in the bump-version command in your make file. More info on that in the next section.

Combining Makefile with Nodejs

I mentioned in the intro that updating the version to a newer one means editing several files and trying to keep it consistent between all of them. This is inherently error prone, "messy" and requires you to either remember where the files are or their names. Alternatively you can also bootstrap it using something in the lines of:

const fs = require('fs');

const files = [
    {
        path: 'android-app/public/manifest.json',
        versionLine: `"version": "`,
        postLineSeparator: ','
    },
    {
        path: 'android-app/config.xml',
        versionLine: `version="`,
    },
    {
        path: 'android-app/package.json',
        versionLine: `"version": "`,
        postLineSeparator: ','
    },
]

const version = process.argv[2]

if (version) {
    files.forEach(config => {    
        fs.readFile(config.path, 'utf8', function (err, data) {
            if (err) {
                console.log(err)
                reject(err) 
            }

            const separator = '\n'
            const newContent = data.split(separator).map(line => {
                if (line.includes(config.versionLine)) {
                    return `${line.split(config.versionLine)[0]}${config.versionLine}${version}"${config.postLineSeparator ? config.postLineSeparator : ''}`
                }
                return line
            }).join(separator)

            fs.writeFile(config.path, newContent, 'utf8', function (err) {
                if (err) {
                    console.log(err);
                } else {
                    console.log(`updated ${config.path} version`)
                }
            });
        });  
    })
}

Although it is a bit hackish it would take of updating the version across the three listed files. But what if you want to go even further? You can combine it with a Makefile directive into something like that:

node versionBump.js ${version}
    git add $(android-app-folder)/config.xml
    git add $(android-app-folder)/package.json
    git add $(android-app-folder)/public/manifest.json
    git commit -m "version bump to ${version}"
    git push -u origin master
    git tag v${version}
    git push origin v${version}

The code above takes 1 additional argument which is the version code and passes it into the short Nodejs script we saw earlier. Then it commits the three files containing the version and uses the version we passed when executing it for the comment as well. It also generates a git tag with the version code. This takes care of several annoying little steps of preparing for a release by executing only 1 command in the shell.

Combining a Makefile + any scripting language means that the options to automate/bundle a sequence of things that you are doing frequently is limitless.

Outro

What I want to leave you with is that we devs are lazy when it comes to do the same thing over and over and we try to find ways to not have to do it. If you think about it, software development is trying to make things easier for all kinds of people and professions by taking care of the repetitive tasks so people can have more time to focus on what really matters. The things listed in the article, although limited by my own use cases, can help you to do the same in your own indie or company projects.