There is no way to run software in full isolation in today’s world. Regardless of how the software is built and deployed, it will always depend on other things. It will depend on the environment it runs in, it will depend on other software that runs in that environment, it will depend on resources like network, CPUs, Memory, etc. This interdependence is not new, it is expected,, and still fascinating.

You don’t have to be thick-skinned in order to take criticism and doing a lot of retrospection doesn’t cover for the feedback others can provide. It took me a while to realize this but, as hard as it is, being able to listen to what others have to say is a liberating experience. We have to constantly re-evaluate ourselves, our actions, and the areas of our life that can be improved.

I was once asked, during an interview, what would need to happen for the company to “convince” me to work with them. The common interview process goes something like: first talk to recruiters, then talk to management (screening and whatnot), then technical interviews, then HR and endless negotiations. This structure, while effective for companies, can distract people from their big picture and what’s important for them. This question could be answered with an endless list of things that would go from the stability of the company, its future, to personal goals and desired.

Definitely not an expert in recruiting or interviewing processes, despite having been on both sides of interviews multiple times already. Interviewing is a process that I don’t enjoy regardless of what my role in the process is. As someone interviewing for a job, I find it uncomfortable to be asked question that I know I would never ask someone. Furthermore, I am extremely bad at coming up with quick answeres, that would really represent my thoughts.

Speed and comfort are much appreciated during the early days of a startup. Being able to move fast is the key to success for many startups and one of the easiest ways to achieve this is by picking the technologies we feel the most comfortable with. It’s not a coincidence that most startups use the programming language that the founders were more fluent in, or the technology stack that founders were familiar with.

Trust is the latest word that I have been studying lately. I have written down some thoughts on the topic already, and I think I’m ready to expand these ideas here. These are the thoughts I have written so far: 2020-12-03 2020-12-12 The easiest way I found to reason about trust was to break down the various properties of it, rather than trying to form a generic concept. I find it hard to generalize Trust as its properties and impact depend greatly on the context (people involved, situation, space, time, etc.

If you spend most of your meetings taking notes, you are not making the most out of the meeting. Sure, of course, obviously, there are exceptions. Put those aside for a bit, and read through for a bit of more context. Plenty has been written about why taking notes is a good practice. It would be hypocritical from me to go in details on why you should do this considering that I’m guilty of not taking enough notes myself.

What’s more important about your carreer title? The title itself or what it actually represents? This question sounds silly but it’s significantly deeper than what it sounds like. The technology industry uses a set of common titles that may vary from company to company: Software Engineer, Senior SE, Principal SE, Senior PSE, Distinguish Engineer, etc. These titles mean different things to different people, to different companies, and to different cultures.

DevOps engineers judge software communities the same way people judge each other’s cultures. As a member of an operations team, it’s common to hear things like: This community is quite friendly to feedback, This project is not to be trusted when new releases are cut, things always break, This community has great documentation. Software and the communities working on this software are often put into buckets in order to make it easier to reason about them.

Human interactions is, perhaps, the part I find the most interesting, challenging, and exciting about the technology industry. Unless you are working alone, more than 70% of your day is likely spent interacting with other humans. Even when you are working on your daily tasks (operations, coding, etc) you are interacting with other humans. People that may have touched the same part of the architecture that you are touching, people that would be affected by your changes, etc.

You can think of this article as a reassesment of On working styles: big communities vs smaller teams. You don’t need to read the latter. One would think that work habits are transferable from one organization to the other. One would hope that time spent developing a work strategy is a one time investment that will payoff throughout one’s entire carreer. Sadly, none of these are true and they may result in frustrations, disappointment, and demotivation.

My working style has changed throughout the years, not only because of things I have learned but also because of the projects that I have been working on. Not too long ago I was being paid to work on open source projects and be part of multiple open source communities, whereas now I work on “downstream” projects, which are developed, planned, and used within the company. Estimating how much time a task will take is hard in itself, it’s a skill that needs to be worked on constantly and one that doesn’t produce precise results.

Operating on live environments should not be a fire-and-forget task. Care and attention has to be put into every release to production (even to staging) environments as releasing to any of these environments requires operating on a living system that has to keep functioning during this process. These environments will, hopefully, be in a better shape at the end of the process. To put it in perspective, doctors operate on living systems too; the risks and the scale are different, but the principles are the same.

Code is written by humans, to be read by humans. It has to be formatted functionally, but also in a way that is readable and enjoyable. If readability wasn’t important, we would not spend so much time arguing about the beauty of some languages in terms of their syntax, the best way to format code, and language maintainers would not spend so much time studying how to make the language syntax more legible.

You would probably be annoyed if I started this post with a phrase like: The most important characteristic of thought-leaders is that they don’t use suprelatives This outright excludes me as a thought-leader (which is fine and correct) and it also instructs you that this thing I am pointing out is, in isolation, the one thing you should worry about if you wanted to be a thought-leader. Such phrase excludes many other important aspects of thought-leaders that only work well when put together.