Notes to Myself on Software Engineering

I came across these “Notes to Myself on Software Engineering“, with which I agree wholeheartedly. Some of these I’ve learned “the hard way”. For most of these, I wish I knew them earlier. They would make my life a lot easier. Here a few to get you started, but make sure to read the whole list, as many of these apply to other areas of IT and life in general.

It’s okay to say no — just because someone asks for a feature doesn’t mean you should do it. Every feature has a cost that goes beyond the initial implementation: maintenance cost, documentation cost, and cognitive cost for your users. Always ask: Should we really do this? Often, the answer is simply no.

Invest in continuous integration and aim for full unit test coverage. Make sure you are in an environment where you can code with confidence; if that isn’t the case, start by focusing on building the right infrastructure.

Simple things should be simple, complex things should be possible. Don’t increase the cognitive load of common use cases for the sake of niche use cases, even minimally.

Because code is communication, naming matters — whether naming a project or a variable. Names reflect how you think about a problem. Avoid overly generic names (x, variable, parameter), avoid OverlyLongAndSpecificNamingPatterns, avoid terms that can create unnecessary friction (master, slave), and make sure you are consistent in your naming choices. Naming consistency means both internal naming consistency (don’t call “dim” what is called “axis” in other places) and consistency with established conventions for the problem domain. Before settling on a name, make sure to look up existing names used by domain experts (or other APIs).

Career progress is not how many people you manage, it is how much of an impact you make: the differential between a world with and without your work.

Software development is teamwork; it is about relationships as much as it is about technical ability. Be a good teammate. As you go on your way, stay in touch with people.

When we find ourselves in a conflict, it’s a good idea to pause to acknowledge our shared values and our shared goals, and remind ourselves that we are, almost certainly, on the same side.

OPP – Other People’s Problem

I really liked “OPP (Other People’s Problems)” article which talks about handling of responsibility for things that other people should be responsible for.

If you’re reading this looking for advice, you’re probably a go-getter. You consider yourself a responsible person, who cares deeply about doing things right. Your care may be focused on software and systems, or on people and organizations, or on processes and policies, or all of the above.


This attitude has probably served you well in your career, especially those of you who have been working for a number of years. You’ve been described as having a “strong sense of ownership,” and people admire your ability to think broadly about problems. You try to think about the whole system around a problem, and that helps you come up with robust solutions that address the real challenges and not just the symptoms.


And yet, despite these strengths, you’re often frustrated. You see so many problems, and when you identify those problems, people sometimes get mad. They don’t take your feedback well. They don’t want to let you help fix the situation. Your peers rebuff you, your manager doesn’t listen to you, your manager’s manager nods sympathetically and then proceeds to do nothing about it.


That kind of grinding frustration can wear you down over time. I know, because I’ve been there. 

Not only the article describes the problem, but it provides a practical approach to dealing with it.

In the last few years, I was going through a very similar thinking process in my head, but I’m nowhere near the well-defined suggested approach. I wish I read this much earlier in my career. Much much earlier.

Time for a new adventure

This week I’ve handed in my resignation letter, marking my last working day as February 28, 2019. After 4.5 years as a Chief Technology Officer at Qobo, I feel it’s time for a new adventure.

Looking back at the last 4.5 years, it feels like there is enough to fill several lifetimes – so much has been done, so much has changed, so many people met, so many ideas tried, and so many things accomplished!

Have a look at my annual posts summarizing just the most noticeable changes:

Or, if you feel like it, take a deeper dive into more blog posts, varying from Instagram pictures to some deep technical brainstorming and solutions.

Obviously, I can go on and on for hours, but here are a few high-level points just to keep things in context:

  • Offices. We’ve opened a new office, or moved to a new office, pretty much every year. First, Nicosia office was moved and expanded. Then Limassol office opened. Then London office opened. Then Limassol office moved and expanded.
  • People. From a small team of 7 when I joined, we’ve expanded to over 20 now. But it wasn’t only about the headcount. We’ve grown the number of roles in the company as well – sales, support, QA, etc.
  • Clients. We’ve built an impressive portfolio, with many large, medium, and small clients, across a variety of industries from a several countries.
  • Technology. We’ve built an impressive set of technology, both internally and externally. Our Amazon AWS cloud infrastructure nearly doubles every year. We have integrated a number of excellent tools to help with project management, quality assurance, development cycle and continuous delivery. And we’ve made Qobrix from scratch into a recognizable brand and force to be reckoned with.
  • Open Source. True to our Open Source believes, we have made significant contributions to Open Source, both via our own repositories, and through the tools and libraries that we use and build on top.

I have met and worked with some really amazing people and teams, true professionals, and inspiring individuals. I have learned a great deal over the years, and have grown both personally and professionally.

So, why am I leaving then? I feel it’s time. It’s time for a change both the company and for myself.

When I joined Qobo, it was a tiny startup, like many others, trying to find its identity, develop, and grasp some luck. It was also still trying to survive the catastrophic consequences of the “Cyprus haircut“, which killed many stronger, more mature businesses. Gladly, we managed to pull through all of that. It wasn’t easy by any means, but we’ve done that. The company has survived, grown, and matured.

It is now well on the way to success, with a clear vision, great products, strong client portfolio, good reputation, and an amazing team.

I think I have done enough to help Qobo to get here. There are now many new people, ideas, and approaches, which will take it forward in a smoother, faster, and more efficient way.

As for myself, it’s also been quite a ride. There has been countless nights and weekends of tight deadlines, non-stop work, lack of sleep, nervous breakdowns, alcohol abuse, emotional highs and lows, and so on. (All kind of expected in a startup.) But I need to step back and recover a bit. On top of that, over the last few month, my focus was mostly needed in non-technical areas. I want to get back to my routes for a bit, and dive into the hands-on technology – things that I like the most: writing code and administrating infrastructure.

Where am I going then? To tell you the truth, right this moment – I don’t know yet. The decision to step down as a CTO and to leave Qobo took quite a bit of thinking, consideration, and preparation. I haven’t looked at my new options or opportunities yet. But given the state of the IT industry in Cyprus and a growing deficit of developers, devops and system administrators, I’m sure I’ll find my next adventure soon enough. (If you have any suggestions or recommendations, please do ping me either here or via LinkedIn).

I would like to take this opportunity to say a huge thank to you to everyone I’ve met and worked with while my years in Qobo. I am truly humbled and honored to have had the opportunity to work with you and to learn from you! I’m sure our paths will cross again.

Awesome Interviews

Awesome Interviews is a curated awesome list of lists of interview questions. Technical interviews, mind you. It covers a wide range of areas from a variety of programming languages, frameworks and databases, to operating systems, data structures and algorithms. There also coding exercises and much more.

This list links to some really great resources for both candidates, who are preparing for the interviews, and interviewers who want to make their interviews better.