ink

Mastering the Balance: Leading, Learning, and Growing in Tech Leadership

Thu, 12 Sep 2024 00:00:00 +0000

High-demand roles that combine deep technical skills with significant management responsibilities often seem like the pinnacle of professional achievement. But if you’re in one of these roles, you know the reality can be far more complex and taxing. The relentless commitment required can quickly become a double-edged sword, threatening your personal growth and satisfaction if left unchecked.

These roles demand a unique mix of technical expertise and the ability to manage teams, projects, and expectations. While the challenge is exciting, it’s all too easy for your personal learning to take a backseat. Caught up in the whirlwind of daily operations, you might find yourself neglecting your own development, leading to a slow but steady decline in your skills and a sense of personal fulfillment.

When Commitment Becomes a Double-Edged Sword

One of the trickiest aspects of these roles is their self-organizing nature. You’re expected to deliver without much oversight, and this autonomy can make overcommitment and burnout feel almost invisible. Before you know it, weeks turn into months, and your focus is solely on work deliverables, not on your own growth or learning.

The pressure to excel in both technical and managerial domains can leave you feeling:

A sense of stagnation and unfulfilled
Unsure about your long-term career direction
Constantly stressed and on the verge of burnout
Disconnected from personal relationships and hobbies
Struggling to manage time and constantly switching contexts

Choosing Between Management and Technical Expertise—or Not

At some point, you might find yourself at a critical decision point: fully commit to a management path or double down on maintaining and expanding your technical expertise. Going all in on management can lead to a rewarding leadership career, with opportunities to shape the direction of teams and projects. However, this often means stepping away from the hands-on technical work that you might still love. On the other hand, doubling down on technical skills can make you a subject matter expert but may limit your climb into leadership roles.

But here’s the thing: You don’t have to choose one path over the other. For many, it’s about thriving in the balance. Don’t view these roles as a zero-sum game—find ways to straddle both worlds. Maintaining a foot in both realms is not just possible; it’s incredibly fulfilling. The key is recognizing that you can balance these responsibilities and make it work for you.

How to Thrive in a Dual Role: Practical Strategies

Set Clear Boundaries: Establish boundaries between your technical and management responsibilities. Don’t be afraid to say no to tasks that don’t align with your goals, and set firm limits to protect your time for personal growth.
Prioritize Personal Growth: Make time for your own learning and development. Whether it’s attending workshops, conferences, or diving into online courses, keep yourself up-to-date.
Delegate to Focus on High-Impact Work: Empower your team by delegating tasks, allowing you to focus on strategic activities. Effective delegation not only frees up your time but also helps develop your team’s skills.
Seek Mentorship: Find mentors who can guide and support you. Consider finding separate mentors for technical and managerial aspects of your role to get specialized advice in each area. Start with a mentor who excels in one specific skill you want to master, then seek out others as you grow. Mentors can fast-track your learning and keep you committed.
Incorporate Reflection into Your Routine: Make reflection a habit. Regular practices like journaling, feedback sessions, and self-assessments help you stay aligned with your goals and pinpoint areas that need attention. Engage more with your engennering manager.
Implement Effective Time Management: Use time management techniques like the time-blocking or Pomodoro Technique to maintain a balance between technical work, management tasks, and personal growth. Once you’ve scheduled time in your calendar, stick to it—don’t shuffle things around. Keep your focus.
Build a Strong Support Network: Connect with peers in similar roles. Schedule lunch with peers it’s optimal way to talk shop and build rapport; Join professional groups or online communities where you can share experiences, challenges, and solutions. A strong support network can provide insights and encouragement when you need it most.
Maintain Work-Life Balance: Don’t let the demands of your role overshadow your personal life. Prioritizing work-life balance can actually boost your professional performance by reducing stress and enhancing satisfaction. Keep these tips in mind:
- Set firm work hours and stick to them
- Engage in hobbies and activities outside of work to recharge
- Prioritize physical health through regular exercise and proper nutrition
- Cultivate relationships outside of your professional circle

Stay on Course: The Power of Self-Reflection

In these high-demand roles, it’s easy to lose sight of the bigger picture. Regular self-reflection can help you understand what you’ve accomplished and what still needs attention. Here are a few ways to incorporate reflection into your routine:

Weekly Journaling: Take time each week to document your accomplishments, challenges, and key learnings. This habit can help you track patterns, identify recurring issues, and celebrate your successes.
Monthly Career Check-Ins: Dedicate time each month to evaluate your progress toward your long-term goals. Review your career roadmap, assess your skill development, and make adjustments as needed. It may sound like a lot, but remember—you’re only doing this at most 12 times a year.
Quarterly Self-Assessments: Conduct a deeper self-assessment every quarter to identify skill gaps, areas for improvement, and opportunities for growth. Seek feedback from colleagues, mentors, or direct reports.

These reflective practices help you stay connected to your goals, ensuring you don’t drift away from the path you’ve set for yourself.

Finding Fulfillment: Commit to Yourself, Not Just the Work

Balancing high-level technical and management responsibilities isn’t just about meeting job demands—it’s about aligning this dual role with your long-term aspirations. But how often do you check in with yourself? Is this balance still what you want?

If it is, now is the time to commit—not just to your work, but to yourself. Pause, reflect, and reassess how things are going. Have you been prioritizing your own growth, or have you slipped into a routine focused purely on delivery?

Finding fulfillment in these demanding roles is absolutely possible, but it takes discipline, self-awareness, and, most importantly, a commitment to your own development. Remember, the better you take care of yourself, the better you can deliver in your role. Reflection isn’t just a break from work; it’s an investment in your professional journey. Success doesn’t come only from what you achieve at work, but from the processes and habits that keep you engaged, balanced, and continuously evolving.

Now that you have this insight, it’s time to act. Take a moment to reflect on what’s been holding you back. Define your goals and set clear, achievable objectives that align with your personal growth. Talk with your engineering manager or direct report to ensure they understand your situation—take the opportunity to set these goals together, and use them as someone who will hold you accountable. If you don’t, you risk staying stuck—unfulfilled and with fewer options, as your technical skills fade over time.

Investing in yourself is the key to growth. Without it, you may look back and realize you haven’t moved forward, losing the chance to grow in the direction that truly matters.

home.arpa the TLD for home usage

Tue, 14 Sep 2021 00:00:00 +0000

TLDR: .home.arp is the special-use TLD that you should be using inside your private network according to RFC 8375.

With my latest homelab rebuild I tried to make my network address more sane, and with that I needed to replace the .local TLD that I have been using for the last couple of years with one that had none of the gotchas that I sometimes found myself getting into.

.local is defined as a special-use TLD (see RFC 6761) in the RFC 2606 suitable to be used for internal network usage but states that was designated to be used with Multicast DNS (mDNS), this means that each device in the network can grab and define its prefered hostname, making me loose control regarding the names that are registered in the network, and in the other side of things, while using .local TLD some DNS resolvers would defer the resolution the their mDNS resolver instead of the DNS causing resolution conflits.

RFC 8375 solves this by defining home.arpa has the de facto TLD for home usage:

This document registers the domain ‘home.arpa.’ as a special-use domain name RFC 6761 and specifies the behavior that is expected from the Domain Name System with regard to DNS queries for names whose rightmost non-terminal labels are ‘home.arpa.’. Queries for names ending with ‘.home.arpa.’ are of local significance within the scope of a homenet, meaning that identical queries will result in different results from one homenet to another. In other words, a name ending in ‘.home.arpa.’ is not globally unique.

Long story short, DNS resolutions for *.home.arpa hosts will not be send to public Internet, hence not leeking any kind of information about your internal network outside, and using .home.arpa will also ensure you don’t have issues with possible mDNS resolution.

Sidenote:

I would suggest not using .home, homenet, workgroup or other “fake” domain name that comes to mind because of two possible issues:
- a) If the DNS query can’t be solved inside your network, the request will be forwared to a root DNS server leeking information of your internal network outside, while also adding a delay penalty for the resolution.
- b) ICANN decided to delegate new TLDs to anyone who was willing to apply and pay the required fees, this means that in the future anyone can register your internal domain and start using it has a root TLD, see what happend with the .dev domain that got bought by Google a couple years ago.
I would suggest avoiding using a public registered domain or subdomain inside your home network, just to keep the overhead low, because this would mean that you need to update the public DNS server each time you had a device to your network (eg: Cloudflare or DynDNS), and this would also be leeking information about your home network.

Sources:

RFC 6761: Special-Use Domain Names
RFC 6762: Multicast DNS
RFC 8375: Special-Use Domain ‘home.arpa.’

Deprecation of Dockershim

Fri, 04 Dec 2020 00:00:00 +0000

A couple of days ago I found a news in Hacker News with the title Kubernetes is deprecating Docker runtime support that made me think a bit about the impact of this news, both in terms to Kubernetes and for Docker, since Docker popularized the container technology, could this be the end of Docker?

Let’s talk a bit about Docker and the container eco-system evolution to understand how we got here.

Understanding Docker

Docker is not just a container runtime, it’s a entire platform to build, publish and run containers that as a lot of features built on-top like networking, volume management, etc.

Looking at Docker from 10.000 feet, you can find two components, docker and dockerd. The docker client (is a CLI tool) allows you to issue commands to dockerd to pull, build or run a image among other things, and the dockerd is the Docker daemon process that receives client requests and performs the requested actions.

Evolution of container runtimes: OCI and CRI

Since it’s first release in 2014, docker and the entire container ecosystem have been evolving, and a set of standards emerged from it Open Container Initiative (OCI) and Container Runtime Interface (CRI).

With OCI docker broke down the monolith and separated their code for low level interaction with the Linux kernel that allowed them to run containers to a library called libcontainer and a tool called runc that became the reference implementation of the OCI runtime specification.

So in it’s core the OCI runtime specification specifies the format of a Docker image, called bundle and how the resources from the Linux kernel (cgroups, namespaces) are allocated and how to run a image. There is no network management, not image pulling specified at this level, just how to run containers.

So in December 2015 Docker Engine 1.11 got released, this was the first version of Docker supporting runc and containerd.

containerd is a high level container runtime that is available as a daemon and can manage the complete container lifecycle of its host system: image transfer and storage, container execution and supervision, low-level storage and network attachments, etc.

Underneath containered calls runc to create the containers.

Evolution of the Docker engine Monolith
image credit darshanime/notes

The release of Kubernetes 1.5 introduced the Container Runtime Interface (CRI), a plugin interface which enables kubelet to use a wide variety of container runtimes (containered, cri-o, etc), without the need to recompile. CRI consists of a protocol buffers and gRPC API, and libraries, with additional specifications and tools under active development.

Why the deprecation of Dockershim?

Long story short, Docker engine daemon (dockerd) doesn’t support CRI meaning that in order for Kubernetes to support Docker to run images they need to use a shim and maintain it at their own cost.

The Dockershim flow

Create container flow via dockershim
image based on Frank范 blog

When the kubelet wants to create a container the following steps are required:

Kubelet calls dockershim through the CRI interface (gRPC) to request the creation of the container. The dockershim is embed directly in the kubelet and acts like a CRI server, and receives the creating request.
The dockershim gets the kubelet request and translates it to something that the Docker daemon (dockerd) can understand.
As we saw in Docker 1.11, the Docker externalized the container creation to containerd, meaning that dockerd then requests containerd to create the container.
One containerd gets the request, it created a process called containerd-shim to let containerd-shim operate the container. This happens because the container process needs a parent process to attach to in order to collect stats, state, etc; and if the containerd process is the parent, if containerd hands or gets upgraded all child container processes on the host will have to exit; containerd and shim are not parent-child processes.
The containerd-shim just calls runc a command line tool that handles all the low level container operations and implements the OCI interface standard.
After runc starts the container, it will exit directly and the containerd-shim will become the container parent process, responsible for collecting the status of the container process, reporting it to containerd and taking over the of the child process of the container after the process with pid 1 in the container exists, cleaning up and ensuring that there are no zombie processes.

The containerd via cri-plugin

Create container flow via containerd and cri

When we look at the kubelet flow when using containerd 1.1+ we can see that the list of dependencies and complexity gets reduced:

The kubelet calls containerd directly via the CRI interface (gRPC) to request the creation of the container.
Before containerd 1.1 there was cri-containerd daemon process that implemented the CRI interface received the requests from the kubelet and forward them containerd. Now containerd implements directly the CRI plugin interface receiving the requests directly, it created a process called containerd-shim to let containerd-shim operate the container. This happens because the container process needs a parent process to attach to in order to collect stats, state, etc; and if the containerd process is the parent, if containerd hands or gets upgraded all child container processes on the host will have to exit; containerd and shim are not parent-child processes.
The containerd-shim just calls runc a command line tool that handles all the low level container operations and implements the OCI interface standard.
After runc starts the container, it will exit directly and the containerd-shim will become the container parent process, responsible for collecting the status of the container process, reporting it to containerd and taking over the of the child process of the container after the process with pid 1 in the container exists, cleaning up and ensuring that there are no zombie processes.

As you can see maintaining the dockershim brings a lot of pain to the Kubenetes team, they need to manage another component just to keep supporting Docker (tracking deprecations, api changes, etc) and at the end of the day Docker is not special and it should expose a CRI interface just like other container runtimes (containerd, cri-o).

So in order to continue using Docker for Kubernetes deployments in the future, the Docker client or daemon will need to become CRI compliant meanwhile everyone should start planning to transition to a CRI compatible runtime like containerd for example.

Some managed Kubernetes services like AKS or GKE already are supporting CRI runtimes others like EKS are still working supporting it.

Don’t forget to check if the container tools that you are using also support CRI runtimes and don’t just expect to find Docker.

In a last note this doesn’t mean that you for local development should stop using Docker, right now the docker platform in my understanding still gives to developers the best user experience and a huge step to tools that simply make our life easier (eg: docker-compose).

Here are some articles that try to explain a bit more in detail the reasons under the what will this entail for Kubernetes and it’s users:

References

asdf a runtime manager to rule them all

Mon, 30 Nov 2020 00:00:00 +0000

Currently I’m running multiple versions of multiple runtimes on my machine, eg: OpenJDK 8, 14 then ruby 2.7.0 and NodeJS versions 8 and 12.

Normally for each one of them I would use a specific runtime version manager, for example for Java I would use sdkman, for ruby a couple years ago I replaced rvm with rbenv and for NodeJS I simply went with nvm.

The main pain of using 3 runtime managers is the need to learn their different CLIs and nuances; With rvm and rbenv you can choose a version of ruby per project by placing in the root of the folder a .ruby-version file stating the version to use, nvm also allowed this using .nvmrc and so on, but now this is water under the bridge.

Installing asdf-vm

Simply clone the asdf repository to your home has shown bellow

# Clone the latest branch
git clone https://github.com/asdf-vm/asdf.git ~/.asdf
cd ~/.asdf
git checkout "$(git describe --abbrev=0 --tags)"

Shell integration

On a MacOS or *nix using bash edit your ~/.bash_profile

. $HOME/.asdf/asdf.sh
. $HOME/.asdf/completions/asdf.bash

If you are using zshell edit ~/.zshrc and add the following to the end of the file

# append completions to fpath
fpath=(${ASDF_DIR}/completions $fpath)
# initialise completions with ZSH's compinit
autoload -Uz compinit
compinit

Update

asdf update

Plugins

Plugins are how adsf understands how to handle different packages, meaning that if you wish to add to adsf the ability to handle java, python, mysql or even minikube you just need to install a plugin.

See the following page to view all available plugins.

Add

If the plugin exists in the plugin repository you can just add it by name, otherwise you need to add it providing it’s git repository url.

# asdf plugin add <name>
asdf plugin add java

# asdf plugin add <name> <git url>
asdf plugin-add kotlin https://github.com/asdf-community/asdf-kotlin.git

List installed

Listing installed plugins

asdf plugin list
# java
# maven
# nodejs
# python
# rust

Listing installed plugins with their repository url’s

asdf plugin list --urls
# java    https://github.com/halcyon/asdf-java.git
# maven   https://github.com/halcyon/asdf-maven.git
# nodejs  https://github.com/asdf-vm/asdf-nodejs.git
# python  https://github.com/danhper/asdf-python.git
# rust    https://github.com/code-lever/asdf-rust.git

Updating installed

You can update a specific plugin by name

asdf plugin update java
# Updating java...
# remote: Enumerating objects: 108, done.
# remote: Counting objects: 100% (108/108), done.
# remote: Compressing objects: 100% (64/64), done.
# remote: Total 289 (delta 67), reused 82 (delta 44), pack-reused 181
# Receiving objects: 100% (289/289), 192.46 KiB | 1.17 MiB/s, done.
# Resolving deltas: 100% (161/161), completed with 5 local objects.
# From https://github.com/halcyon/asdf-java
#   b050643..eedd04e  master     -> master
#   b050643..eedd04e  master     -> origin/master
# Already on 'master'
# Your branch is up to date with 'origin/master'.

Or update all plugins in one go

asdf plugin update --all

Remove

# asdf plugin remove <name>
asdf plugin remove kotlin

Versions

List all available versions

asdf list all <name>
# asdf list all java

Install

Installing a version is as simple as installing a plugin.

asdf install <name> <version>
# asdf install java adopt-openjdk-11.0.6+10_openj9-0.18.1

Install the lasted version of a stable version

asdf install <name> latest:<version>
asdf install java latest:11

List installed versions

asdf list <name>
# asdf list java

Filtering displayed versions

asdf list all <name> <version>
# asdf list all java openjdk-11

Set current version

You can set a specific plugin version globally, just in the current shell or per folder.

asdf global <name> <version>
asdf shell <name> <version>
asdf local <name> <version>

scope	description
global	writes the version to `$HOME/.tools_versions`, making the version global all shells
shell	sets the version just for this shell, but setting `ASDF_${LANG}_VERSION` environment variable
local	writes the version to the file `.tools_versions` on the current working directory

You can read more about the .tool-versions file here.

View current version

To view whats the current version of the installed plugins

asdf current
# java           adopt-openjdk-11.0.6+10_openj9-0.18.1 (set by /Users/lmm/.tool-versions)
# maven          3.5.4    (set by /Users/lmm/.tool-versions)
# nodejs         8.17.0 12.18.2 (set by /lmm/mendelui/.tool-versions)
# python         3.8.4    (set by /Users/lmm/.tool-versions)
# rust           1.45.0   (set by /Users/lmm/.tool-versions)

You can also view the version of a specific version

asdf current java
# adopt-openjdk-11.0.6+10_openj9-0.18.1 (set by /Users/mendelui/.tool-versions)

Uninstall

# asdf uninstall <name> <version>

asdf uninstall rust 1.45.0

HTML5 video, ogv, firefox and nginx

Sun, 25 Nov 2012 16:50:10 +0000

If you are having problems serving ogv video content on Firefox there are some steps that you should follow.

Serving ogg files with the correct MIME type

First you have to ensure that you are serving the correct mime type for ogv files, it should be video/ogg you can test it using web sniffer (see the return value in the Content-Type: tag, you should see video/ogg)

If not try adding the following mime types to your nginx (eg: /etc/nginx/mime.types`) and restart it.

video/ogg   ogm;
video/ogg   ogv;
video/ogg   ogg;

Handle HTTP 1.1 byte range requests and serving `X-Content-Duration` headers

Firefox or better yet the Gecko engine that powers Firefox / Thunderbird / SeaMonkey and others uses a sequence of HTTP 1.1 byte-range requests to retrieve the media from the seek target position in order to determine the duration of the media, it does this because ogv files don't contain the duration of the animation, so in order to determinate the duration of the file it retrieves a 8k chuck in the beginning of the file to determinate if the file is a valid ogg file, than based on the Content-Length header sent from the server it asks for the last chuck as you can see here, and finally it resumes the download from the first chuck as you can see in this image.

In order to reduce the amount of requests made to your web server you can send the X-Content-Duration header with the duration in seconds of the media. If your video has a duration of 1 minute and 32.6 seconds you should server the value as 92.6

X-Content-Duration: 92.6 Here is example how you can serve a media file using nginx

location /media/video.ogv {
  add_header X-Content-Duration "92.6";
}

If you're curious to see in greater detail why Gecko makes some of the HTTP requests it does, read comment 1 of bug 502894.

Consider using `preload` attribute

The HTML5 video and audio tags provide the preload attribute which tell Gecko to attempt to download the entire media when the page loads. Without the preload attribute Gecko only downloads enough of the media to display the first video frame and determinate the media's duration.

preload if off by default so to enable just add the attribute to the video tag and set it's value to auto.

<video preload="auto">
  <source src="media/video.ogv" type="video/ogg" />
</video>

ink