Today I bought a dehumidifier. I have a quite solid smart home already and Sonoff humidity/temperature sensor was reporting crazy numbers. Now with the dehumidifier (Tesla Smart Dehumidifier XL) it looks the Sonoff SNZB-02 sensor is ~10% off the reality. Haha.

Naturally, I would say the dehumidifier will have a better sensor, but who knows. Anyway. Since it's "smart" I went on a journey to reverse-engineer it to have it in Home app along with my other devices. Btw Proximan is an insanely awesome tool for network interception...

...it supports SSL proxying, and it's super powerful – you can easily proxy iPhone through it. It has even a companion iOS app, everything in a slick design. Really, one must love quality software like this. Well after a few minutes I discovered it's actually Tuya-powered.

From that moment it was quite easy, there's an official plugin to get it working within Homebridge (❤️) – just the support for the dehumidifier was missing, so I hacked it together: https://github.com/tuya/tuya-homebridge/pull/328. Really ugly piece of code, but it works. 🫡

The funny part was testing. Homebridge has actually awesome feature – isolated child bridges. So I enabled it for the plugin and via VSCode/SSH remote session I was editing it directly in the node_modules, restarting the isolated process without killing my whole HB instance.

Really, throw a stone who never touched code in node_modules as a part of the development flow. 😆

To close this thread; I really enjoy moments like this, being able to whisper to machines and make your life better feels cool and it's fun.

Hacking dehumidifier to Homebridge

If you are designing engineering interviews – don't forget to put humans first. 👩‍💻

I had a chance to explore the concept of async interviews, where you record your screen with a camera&voice on and try to crack the algorithm exercise within 30 mins. 

Don't do it, not worth it.

The guidance goes as follows: it's a "real-life problem", but basically it's a leetcode-like thingy. You are allowed to google and do whatever you would normally do. But would you dare to google the exact problem? Would you use Github's Copilot? 🤷 I doubt it, but in a real life.

The whole experience is basically based on you having a monolog with yourself during the attempt to solve it along with recording it to Loom, and staring at the ticking clock. There's no one to discuss it with, no one can save you from the misery of exploring dead paths.

I'm not saying all algo interviews are crap, but I would at least let people lead them. It's a bit of a depressing experience to wipe yourself from the process way before you hit on humans.

If the candidate has relevant code on Github, I am highly suspicious this would tell you something extra. It kinda aligns with the false promise that a good engineer is someone who can write Dijkstra from the top of their head. Oh boy! There's much more of it, right!

I know it's tempting to optimize every bit of the interview – I fell into the same trap as well. If you care about a culture you build I would recommend not optimizing on human aspects. Otherwise, as you sow, so shall you reap.

Human-first engineering interviews

Ever wanted to change something in third-party dependency of your Node project but forking it would be too much hassle – or you were rather bending something which wouldn't make sense to contribute back at all? 

🧶 Yarn 2+ has "patch" command to help you do exactly that.

And as you guessed correctly, in that case, you need to make sure those patches are versioned with the rest of your code so it gets correctly patched in every environment you ran the code, similarly to "yarn.lock". https://yarnpkg.com/getting-started/qa#which-files-should-be-gitignored

Also a little small tip – if you don't want yarn binary (which should be versioned in ".yarn/releases" – https://jukben.codes/one-yarn-to-rule-them-all) to skew your Github stats you can override it in ".gitattributes" like this. 😎

Btw does this all sound familiar? In the past I used https://www.npmjs.com/package/patch-package but it's nice to have it built-in, isn't it. 🤓

Happy hacking!

Patching a third-party dependency with style

So after more than 2 years in the engineering management track, I decided to do switch back to an IC role again to dive into (almost the same) problems from a bit different perspective. It feels super exciting. Like meeting a good old friend you experienced so much with. 🧵👇

It's something I was thinking about for some time already and I'm glad I was able to get the courage to do this, especially given the fact I'm doing it within the same organization. I truly believe everyone involved, including my ex-direct reports, got something from it. 

In meaning, it's a great opportunity for all of us. Interestingly, I got into real management more likely from the organizational need back then rather than it was something super thought through. I was optimizing for the impact, and that's what I'm doing now as well.

The company grew like hell, and I was one of the company's self-grown middle managers before we started to hire them at a faster pace. I was reporting to CTO back then and some started to report to me, for the first time ever in my career.

Generally speaking, I'm convinced that it was the best I could do back then to accomplish what I wanted to accomplish – in hindsight, I'm super glad for the opportunity.

As time went by I realized that I'm surrounded by great managers which are great partners who enable me to focus more on leadership from the IC perspective where I felt a lack of. If you would ask me 2 years ago, I had the same feeling about the management track. 😆


So similarly like before, even now I optimize for what I believe can push me and the company forward. Which is actually an extremely interesting lesson. The company evolves, its needs and challenges as well. I think this is exactly what's a startup for me. Constant challenge. 🚀

And I think it's not the last time I flirted with the management, honestly, I feel that leadership is such a universal skill that can be easily transferred back and forth. To some degree, I feel that the perspective I got gives me superpowers, so let's see how it goes. 💪

You can read the unrolled version of this thread here: https://typefully.com/jukben/AUIWfz3

IC to EM; there and back again

We have joked that we need CI for CI because it happen to us that our pipeline update broke our main pipeline (hard to test it from the feature pipeline, right 🤓). Luckily @kepkap found out there is an API for that https://docs.gitlab.com/ee/api/lint.html

We quickly wired it into our Danger (danger.systems/js/ rules, and viola I hope this will catch the future bug.

CI for CI

I finally got my hands on Dev Containers in #VSCode and it's pretty solid! I decided to put some effort into learning Ruby so I thought it would be nice to explore it and try to use it for my use case so I avoid polluting my whole setup. Here are my learnings. 👇🧵

First of all, what is it all about? Dev containers basically let you use a Docker container as a full-featured development environment. Great thing is that it works flawlessly with extensions, they can run in the context of the container with access to files and platform.🚀

Why it's so awesome? Imagine your project is preconfigured for it. Anyone who just pulls the repo gets all the experience out of the box. Everything works, the configuration of Dev Container can also carry predefined settings and extensions. They can immediately dive into it! 🤿

It's super easy to start with it, all you need to do is to open the command pallet and spin off some preconfigured ones by Microsoft. There's Node, Python, C++, Java, Rust but more of them (Ruby included) can be found here https://github.com/microsoft/vscode-dev-containers/tree/main/containers.

In my case, I tried to set up a simple Ruby project but ideally with decent DX so I can learn fast and it's somehow fun. 🥳 I read a bit about it and then put together a boilerplate for my experiments. It has a language server, unit tests, linting, and debugger ready. 👌

I discovered https://exercism.org/tracks/ruby. Completely free, very easy-to-use platform full of coding exercises to help you pick up a new language fast. I signed for Ruby track and I made myself a promise to complete it in my spare time. Wish me luck! 🤞🤓

In case you would like to take a look at how it works, try it or you even want to join me in my Ruby journey feel free to take a look. It's on my Github https://github.com/jukben/ruby-101. In case you have Docker and VSCode installed you should be ready to go. I really like the concept.

You can read the unrolled version of this thread here: https://typefully.com/jukben/QQ5AIPx

💭  Thoughts on Dev Containers in VSCode

Releasing in continuous delivery fashion is nice... but how do you deal with outdated clients? What's your strategy for it? We do several deploys per day (+-30) and although it's nice to be able to iterate so fast it also creates some challenges.👇🧵

We are releasing the first bits of GraphQL into production, to be concrete we are trying to gradually roll it out to prevent some big mistakes. You know the drill; 5%, 10%, 20%... 🤨 . We soon realized we missed one data loader and we also refactored the query to ask for less.

No problem, we have pretty good observability (DataDog and APM ftw!) we have deployed a fix on the backend and soon after it, we fixed it on FE as well. So we tried that again. At first glance, the metrics were much better. Until they weren't. I was like – what? 🤔

So I quickly pulled another chart and immediately realized what was going on. We were still firing the old query which should be dead. But it's not, it's still loaded in browsers of our clients. Because both codes are effectively living under the same feature flag.. soo. Bazinga!

So back to the topic. We don't have a good strategy to inform users about the new version and I guess it can't be super naive (e.g inform about every). For example, I hate Spotify's "blue dot".. but I update it anyway every time I see it. I would be curious about their data. 🥰

By the way, if you are curious we will probably release it under the altered feature flag, that should do the trick. But I would like to prepare a strategy for future me because this will happen again. 🤓

Continuous delivery and outdated clients

I had a chance to drive a couple of major technical initiatives in a rapidly growing startup. I joined as #35 and the company grew 10x since then. I still have plenty to learn, though, I have a few tips which I would appreciate a few years ago. So I'm sharing them with you now.

Usually, such initiatives are quite a big spanning. It's essential to keep the momentum by being able to break it down into smaller parts – milestones that are deliverable within one quarter or faster. And don't forget to celebrate them!

Crucial is to get leadership on board. Without executive support, you are marching towards burnout. Create a pitch presentation, write one pager. Iterate. Make sure you solve the right problem. Make sure the solution is right. Ask for feedback.

It's easier when you have a track record already – you can make bigger bets. Educated bets. It's all educated bet, isn't it?

There's no such thing as over-communication. Especially at this time. It's the key to find your way to meetings and be present to always revive the mission we're at. Why we're doing it. What are the next steps and how to stay in the loop.

Of course, it's not just about meetings. It's about async communication as well. Make sure you have Slack channel where you support the momentum, share progress, and celebrate success. I like to repost such messages into more broad channels to continually build the brand.

You need to be strong and wait for the tipping point. The bigger the initiative, the longer you usually need to wait. In the beginning, it's important to be really hands-on and support initial adoption. Partner with someone and ensure they are successful with it.

Promote success of projects building on top of your technologies. Create testimonials. Make sure you have a system for onboarding. Q&amp;A channels. Notion pages with step by step guides. Egghead-like videos.

Last but not least, work consciously on its brand. It's much easier if it has an original name. Something catchy. Something people can relate to. And make stickers and other swag. Folks love stickers, you know it! You love them too.

One example for all; we've been working on Federated GraphQL architecture for more than a couple of months now. We call it The Ring. You know, like the one you need to throw to Mordor. That's the data-fetching we need to fix – something that has been bugging us for so long.

It has its emoji on Slack, at this point everyone knows it, it's the company's strategy. And we have stickers. Because everyone loves stickers. 