Let's face it, your company is not a Big Tech company. You, the reader, are probably not working for Google, Microsoft or Facebook and it's ok. A lot of companies not so big have a huge impact and very high tech challenges.
But not being a big tech company also means you probably won't be good at what you're doing if you act the same way Facebook or Amazon does. This is true for tech choices and system architecture. This is also true for recruiting software engineers.
Container technology is great. It let us build immutable artifacts where processes are isolated and scalable when running from an orchestrator like Kubernetes.
In my journey looking for the best way to manage my to-do list, I recently tried to create a Trello board where to put all the new tasks added to my personal backlog. My choice of using Trello was based on several needs:
Being able to follow up all the in progress tasks
Being able to order tasks by priorities
Since Trello is very flexible, I thought that I could create one card by item and three columns: to-do, work in progress, and done. But then, I started to have lots of cards in my to-do column and thought I needed to re-order all the cards to be able to quickly see which have a high priority and which can wait.
I first tried to create an intermediate to-do column called “today” where to put the item I needed to be done by the end of the day. I quickly found out I still had to deal with all the other cards in the “to-do” column which needed review each morning. Thus, I moved once again and created three to-do column :
Backlog
Priority #3
Priority #2
Priority #1
For a while, this system seems perfect. Each time I had completed a task, I was able to see which one will be the next to focus on by looking at the priority #1 column. I had a clear view of what I really needed to do at any time. Every week or so, I reviewed my to-do lists in order to move cards from lower priority to higher. Or, at the contrary, I lowered the priority of some tasks considering they were supposed to be priority #1 but I hadn't time to work on it and the world didn't stop.
The more I talk with engineering managers around me - in my own company, during interviews or around a beer - the more I see tow patterns, two different ways to talk about their team: those who say “they” about people they manage and those who included themselves in a global “we”.
I recently had to refactor the way one of my app print logs. My idea was to use logrus as it is a very well known lib to produce logs with Go.
Logrus let you print nicely color-coded and structured logs and is completely API compatible with the standard library logger.
My first question was about log level and how to setup it once across all sub-directory/package of my project.
Under the hood, logrus instantiate a new variable log. Once done, calling the logrus.SetLevel() function will store the level directly in this newly instantiated struct.
Thus, we have a global struct, available across all sub-package making the level automatically shared without having to use dependency injection.
If you need to set a different level in a sub-package (for example), you just need to instantiate a new logger :
var log = logrus.New()
//...
log.Debug("debug log")
