Why I Really Like This

One thing I see a lot — especially in interviews — is people saying “I’m a senior engineer.” But what does that actually mean? It’s definitely not just about coding for a certain number of years. Seniority shows up in what you own, how you influence, how you help others grow, and how far your impact goes. It’s way clearer to break that down than to just stick a label on someone.

I really like this tool because it makes that discussion practical. Instead of arguing about titles, I can ask a candidate to map their ladder:

• How do you see yourself in Technology, System, People, Process, and Influence?
• What examples back that up?
• Where do you want to grow next?

This is so much better than just saying “You’re senior” or “You’re junior.” It turns vague self-labels into a concrete map of skills and impact, for candidates and for ourselves.

• A senior candidate can sketch their own chart before an interview.
• You can compare self-assessments with your team’s expectations.
• Or just help someone reflect: Where am I strong? Where do I want to grow next?

My Own Snapshot

When I ran my self-assessment, my radar landed around Masters on Technology, Leads on System, Coordinates on People, Defines on Process, and Multiple Teams → Company on Influence. Visualizing it this way immediately showed me:

• Where I’m leaning more into org-wide impact.
• Where I could expand (e.g., mentoring other leads, not just engineers).
• And where my growth edges are next.

It’s way more motivating than reading a wall of text!

The Nerd in Me

For years, I’ve talked through these ladders verbally, in 1:1s, interviews, or mentoring sessions. But I always wanted an automated way to generate these diagrams interactively.

Thanks to modern Python tooling (and a bit of AI help), this is easier than ever. I built a simple Python client for generating Engineering Ladder radar charts, it’s free and open source on my repo: engineering-ladder-assessment on GitHub

I honestly don’t know if there’s already something exactly like this out there, I just did it because it was fun, useful for me, and maybe useful for you too.

🚀 Try It Yourself

Give it a try, whether you want to map your own growth or assess candidates more meaningfully. Let it help you on your journey, and see what insights come up. Give it a shot, I’m sure you won’t be disappointed!

Anyway, after reading it I really started thinking about the matter a lot. I thought I’d do a lot CI/CD in the past myself, but is this really true? To be frank, only partly. I’m a huge fan of automation including:

• Unit / Integration tests
• Automated quality checks
• Custom shell extensions / scripts for recurring tasks
• Documentation creation (API docs, Plantuml etc)

And of course automating as much of it using CI. But beside a few components I never really dig into CD a lot. The answer of course is not as easy, as it partly was due to the structure of the organization I was working in, the project structure, but most importantly and that’s the true cause if I really think about it: I was afraid of it!

What if the auto deploy breaks the environment? What if people get mad because I suggested it? … and so I did not do it. Probably you had similar thoughts yourself before. Of course there are technical reasons as well, but you can solve them if you really grieve for the CD automation.

So I did read this article and recapped why I’m not doing it. In the end all reasons seem really half-hearted. Like I was usually one of the people deploying manually. That also broke the environment. And I rolled it back. I could’ve rolled it back myself as well after auto deploy. But I would’ve saved a lot of time deploying in the first step.

Luckily a college is working on CD right now on my new job. It’s actually not the same who suggested the article, and I’m super hyped about it! If I can help by any means to support this I’m all in for it! And probably it will change my way of working as much as it did when I started using CI / test automation heavily. I’m really looking forward to auto deploy my first increment of a feature on my new job next week :).

One more thing …

Actually a few weeks ago I stumbled across Upptime. If you’re interested how to utilize GitHub Actions not only as a CI/CD but also as a “Serverless” computation platform you should check it out! I’d like to be as clever as those peeps to having such a brilliant idea myself one day.

It made my brain hurt to make it work again with recent version (mocha 8.x.x and nyc 15.x.x). Don’t get me wrong I love those tools but they had several compatibility issues during the last 12 months that do make live harder for many people. Actually after researching I found out that they fixed many bugs that were happening occasionally and creating non deterministic results from time to time.

The problem that comes with it is wrong docs all over the internet. You know how it is, you find an upvoted answer on Stackoverflow and you try it out. It doesnt work cause you overlooked that the response is like 3 years old. The libs / tools changed and the response is not valid anymore. This is very much the case with docs on the combination mocha + nyc + typescript.

Let me give you one example: We had it working on my job without ts-node for ages but actually had strange issues from time to time. Also our setup never covered files that were not loaded by mocha at all (or any test of course). But the all: true setting made issues in the past. The current docs are pretty good but did also not work for me as I had custom glob patterns. So I ended up playing around in the evenings to find a proper working way also eliminating things that always bothered me. and the result is basically this config:

.mocharc.yml

require:
  - ts-node/register
  - source-map-support/register
recursive: true
color: true
exit: true
extension:
  - ts
  - test.ts

.nycrc.yml

extends: "@istanbuljs/nyc-config-typescript"

reporter:
  - html
  - lcovonly
  - clover
  - text
  - text-summary
report-dir: coverage

And of course the call config in package.json

"test": "npm run lint && nyc mocha src test",

For instance did I not know mocha can have config files in this new format. Found out that feature is not that old and I missed it. That made me actually start the repo. What about other stuff that I frequently use?

• Linting (eslint of course as tslint is deprecated)
• VsCode config
• Unit Tests using sinon for stubs / mocks / spies
• Example code for the typical webserver use case using fastify

So I sat down and started it. The final config is a lot more clean, does not need any taskrunners like gulp anymore and all config is in files where possible. Wilst sitting on that example I did actually find more small issues that made coverage suddenly broken (when starting with mocks and stubbing the demo code) and it was as small stuff as a wrong ** in the globs. Or nyc treating everything after the first . as file ending making a glob pattern like **/*.ts not match for a file like src/abc.test.ts.

As I wanted to try out Travis-Ci and codecov since quite some time I did do that in one go. The end result is my repo on Github:

https://github.com/Flowkap/typescript-node-template

It might be another template no one needs, but in the end I’m happy with my template for my private use and I would be super happy if someone can find it useful for starting with Typescript or migrating to newer versions of all our beloved open source tools. :smiley:

I’m going to switch job soon, and with it comes that I put a lot more on github lately than usual. Including some fun projects that I was asked about where the source is and so on. I wondered why not, purely for the sake of fun set up a blog?

I mean, I do know its not the most thrilling thing you can do in 2020 but maybe (I hope so) some of my former colleges will still follow me onwards after I left my current employer. And this might be a plcae for them to come from time to time. Who knows?

There where times before when I thought about doing this (especially after I started getting into Kubernetes) but I didn’t feel like it at that time.

The more I work with open source though, the more I like the idea of sharing. I just never felt that what I do might be worth it (still don’t think so to be honest) … but maybe others thought the same? So why not start talking about things that I like here and link them together. Even if its only for my personal use. Probably it is … but this brings me to one of the most thrilling things to me in open source:

“Someone did probably what you want to do before in a better way!”

And so it is like 99% of the times. As well as this time! I was sure about hosting at GitHub Pages straight away and was searching for a good template for a blog. Quickly I stumbled across Jekyll Now written by Barry Clark. It looked exactly like what I was searching for but lacking a few features (like code highlighting styles) and I would’ve needed to tweak quite a lot.

Thanks to some other people on his Issue list I then found a fork Reverie that has all of that.

And here we are. An hour or so later I have my stuff online. Isn’t open source awesome? I certainly feel it is. And I actually hope to come up with something original at some point that other people like as much as I do like others stuff.