I am writing this letter as a summary of my work style and expectations as a remote software engineer. Consider this post as a source of truth to the way I think about work, how I communicate, and other team culture related thoughts.

I interact with Dockerfiles every day at work, have written a few myself, built containers, and all that. But never published one on the docker hub registry. I wanted to make ugit - a tool to undo git commands (written as a shell script) available to folks who don’t like installing random shell scripts from the internet.

TLDR;

Calling out someone is fine, just try to do it in a way that resonates with collaboration more than hate or directly attacking someone or something. We all have a limited time on this planet, let’s not spend it hating each other. Spread +ve vibes everywhere 🙌🏽

So I have been interviewing for a while for my next role in tech. I have given all type of interviews by now. Take home assignments, DSA, solution write-ups you name it. I am fine with all kinds of interviews, honestly at this moment I don’t even care about what style of interviews are good or bad.

Vale is a syntax-aware prose linter built for all you writers out there. With more than 100 releases so far vale is 5 year old project and is used by writing folks in companies like Google, Microsoft, IBM, RedHat to name a few. I have recently started to use vale in my everyday writing workflow and it has a significant impact on what words I choose to convey ideas. I mostly use neovim for writing, so we will be covering how to setup vale and use it with neovim.

How many time have you been let down by your expectations?

Ever wondered how others are changing the same file you are working on? It can give insights into what a particular piece of code will look like in the future. Certainly, it can also help OSS newcomers to identify how others are building a particular feature

So from my short professional experience, I have realised that if you are working with a small team of individuals a lot of folks end-up authoring multiple pull-requests across X different repositories in an organisation which sometimes leads to managing multiple feature PRs at a time.