Today is my last day at smenso, where I’ve worked for the past 6 years (exactly, which is funny).

I thought about whether I want to write about that or not, and what are the reasons why I want or don’t want to do it – and in the end I want to write something – mainly so I can reread it in the future and remember.

I am and will forever be grateful to have worked at smenso after a time that was very challenging for me in multiple ways, that I had a place where I could shine and grow and heal from some injuries of the past.

I had the pleasure to work with great colleagues, got immense freedom, and was supported by my bosses in multiple ways, even without the question of whether that support will also benefit the company (I believe by heart that supporting your employees will always benefit the company).

Was it all rainbow unicorn fairy tales all the time? Of course not, there’s no place like that. But – and that’s the first thing I want to write down to remember – I am moving on because I changed and my needs changed, not because I want to survive or need to escape.
I wish my former colleagues and the company as such all the success in the world for the future and I hope that they reach what they dream of (or find things that are similar enough to those dreams).

I say goodbye to friends and to a place where I really liked to work.

Growth and Learning

The second reason why I want to write a short blog post is that I want to remember how I myself grew and what I’ve learned, thanks to the environment and opportunities that I got in the past 6 years.

One of the most significant changes for me was that I had the possibility of becoming a public speaker. That does not mean that my job made me become one – but it provided enough flexibility, security, and even financial support for traveling that I had enough spare energy to grow. I guess it is what you can call “work-life balance”: your job environment leaves you enough energy to focus on other stuff. It is so important and I never want to work at any place that doesn’t leave me that room.

Providing a good work-life balance also allowed me – for the first time – to connect with the communities of my trade. Going to conferences, and doing stuff next to your day-to-day job (e.g. open-source work) connects you with like-minded people. This is not only awesome for you as an employee, it also has tremendous benefits for your company. I could solve issues a lot quicker (or at all) because I had people outside my workplace to ask.
Besides this “direct” impact, there are so many indirect ones (different perspectives, ideas, knowledge, lessons learned, and deliberate practice, just to name a few).
I’m very grateful that my bosses understood that and always encouraged me in my attempts to “connect outside”.

I also learned a lot about context. When you are responsible for one piece of software for six years and in a position to also see the financial side, that shapes you a lot. On one hand, every bad software decision, every piece of technical debt hurts you in the future, and in such a long time frame you’re often the one feeling the pain (or relief) of your past decisions. On the other hand, you see that you can only spend so much time given the amount of money you will earn.
In such a situation, “best practices” can turn out to be money graves, solutions “by the book” don’t work, and trying to apply a rigid, specific framework inevitably fails. Context is what matters – you only have the tools, the people, the money, the knowledge, and the environment you have. You need to operate inside these boundaries – and I’m thankful that I could learn and practice that in my job.

Here are some more things that I’ve learned and that I want to be written down so I don’t forget them:

  • There is no universal “good” or “bad” code. Such judgements can only be done in a specific context
  • Improvements don’t go in big steps.
  • Some things I consider a smell today were fine back in the context when they were done. Be compassionate with past you (and others)
  • When you’re stuck, take smaller steps
  • When you’re still stuck, make a break. There is very likely a solution
  • Finishing over Starting
  • Have a reason for a decision and verbalize it (or write it down)
  • Trust your customer that they know their needs and their pain. When you don’t understand something, it’s more likely that you’re missing some perspective than they are stupid.
  • Automated tests without a way to run them independently, frequently and automatically lose a lot of their value
  • Shared test data is a hard dependency that can bite you in the future

There are probably many more things that I’ve learned. I’m grateful for all of them.

Keep learning and growing, everyone, and I hope we’ll meet again.


Leave a Reply

Avatar placeholder

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.