When adding new features to a software product, we tend to plan them by the value they bring versus the cost of development. However, it’s critical to consider that they also come with a maintenance price tag attached to them. Ignoring this cost, can affect the user experience, cause a system crash and/or make it harder to do any changes in the codebase.
In an ideal world. We’d pay for the cost of developing a feature, but once it’s out, we’d never have to spend more resources on it. And while there might be a few software products out there, that run with minimal maintenance, we should not assume this will be our lucky fate. Yet, product and development teams alike, seem to think this is the case.
Because of this misconception of pay once, enjoy forever, we constantly fail to evaluate the costs of maintenance of a product before we even start coding it and only address them when something is broken. We are even willing to cut corners deliberately to ship sooner because we believe that first to market wins the race every single time. And everyone starts noticing the problems:
Customers, experience a slow and buggy product.
Developers, have a hard time understanding and changing code.
Product, has to cut down features or cancel their development because the velocity of the team is too bad.
Instead of addressing the problems, more corners are cut, and eventually, it becomes a habit and the only way you do things. By the time you realize, you have dug your own grave and, soon enough, start talking about full-refactorings. Paying some tech-debt is hardly ever an option. Developers are blamed for building such monstrosity, but product and business were right there at the co-pilot seat too.
To avoid this situation, product and developers must work together to make maintenance part of the development process. The product team should, at the very least, have healthy buffers during units of work, so developers can address maintenance, but ideally understand it well enough, so they can be the ones planning for it. And the development team shouldn’t work without thinking of the maintenance impact of their code, and own their solutions all the way to production.
The most important thing to understand is that, doing maintenance proactively, is always cheaper than having to react. And while fully getting rid of emergencies is not possible, reducing the amount of them will give you more time for feature work and will keep the stress levels of the team under control.
Today, I’m celebrating 10 years since I moved to Europe and became a migrant worker. Living abroad helped me grow as a programmer, professional and a human being. This is a short summary about the process, challenges, and key learnings from this experience.
In 2011, I finished my first big web development project, and it left me with the feeling that there had to be better ways to build software. This is how I found out about the Ruby on Rails web framework and its community. They were talking about practices like automated testing, which for me was something new and appealing. There weren’t many local or remote Ruby jobs I could apply, so I decided to search abroad.
I reviewed hundreds of job openings (even those that were not sponsoring visas) to learn about the most requested skills and studied them. I also did a couple of pet projects and one freelancing gig. After many months of preparation, I felt confident enough, and started applying.
As a university dropout, I was afraid no company would sponsor me. Thankfully, I already had six years of experience, so I was able to apply for a skilled-worker visa. With a university degree, this would have been a tad simpler because I’d have been able to request a blue card. In practice, however, I haven’t really noticed the difference besides the length of the validity of the permits.
Challenges
While living in Europe, I’ve had one or two really challenging situations. Like the time a company decided to cancel my contract only 2 days after we signed it. But these kinds of issues put you on fight or flight mode, and you find a way to overcome them. Yes, it was stressful, but I managed to find something new in less than a month. In my experience, the things which are more likely to break you, are the daily challenges like:
Long distance relationships: My wife and I have lived a third of these years apart. It’s important to be aligned and have a vision because there will be times when you need a reminder to not lose faith.
Lacking a support circle: I saw a major difference between the time I lived in Switzerland alone, and the years when my wife has been there to go through this adventure together. We’ve also made meaningful friendships along the way. These people don’t only make it easier to be abroad, they become so close that you build some of your most significant memories together.
Cultural differences: Sometimes locals don’t understand you, and vice versa. I learned not to take any of these differences personal. It’s possible to immerse in a different culture, without having to die in the process or lose your own culture.
General knowledge: There’s a lot of general knowledge you lack when you’re in new territory. The housing market, taxes and medical system can be tricky to understand at best. Simple things like the business opening hours can be frustrating. Thankfully, there’s a lot of information online, so it’s just a matter of investigating and learning to survive a few embarrassing moments.
The feeling of not settling anywhere: The excitement of a new place eventually fades away, and sometimes you can feel anxious about not settling. I’ve seen an improvement since I stopped overthinking about the next stop in our journey and focused on enjoying the current stop.
Learnings
Even with all those challenges, the experience of working abroad is very rewarding. Living in Central Europe, you can travel to many countries nearby, learn or practice one or multiple languages, attend many cultural and technological events, and much more. And while Europe might not be the tech mecca that developers see in the US, it is a great place to learn about software development.
In Switzerland, my boss taught me a lot about Lean principles and system administration. I also learned about configuration management and hardening Apple’s OS. I wasn’t using Ruby on Rails that much, which enabled me to focus on learning Ruby and OOP.
At SUSE, I learned a big deal about Linux and tooling. This was my first experience with Extreme Programming, and I saw my technical and soft skills grow exponentially. I learned to think more like an engineer than a developer. I also expanded my horizons and played a bit with new technologies, like the Go programming language and Docker.
I then had two shorter but valuable experiences. One at Babbel, where I learned about Serverless on AWS, and another one at CloudBees, where I deep dived on the topic of CI/CD while working on CodeShip and Jenkins-X.
To finalize this 10 year journey, I’m now learning how to lead a dev team at Ring Twice. I’m also figuring out how to work together with management to do company-wide changes to improve the development process.
What’s next?
The last decade has been a fantastic experience. I’m more than satisfied with how things ended up and would recommend anyone interested in working abroad to give it a try. For those interested but not able to move, don’t despair. The world is a very different place, and it’s a lot easier to find good remote jobs. If you have questions on how to get started, don’t hesitate to get in touch (social links at the bottom of the page).
Whether we continue on our expat journey or not, it will depend on the professional opportunities that open up. While this uncertainty can trigger my anxious side, I’ve also learned to accept that much of the success we’ve had, was was just us riding a wave, and not the result of compulsory planning. Amor fati.
In terms of career, my goal is to keep growing as a software developer and to become a better leader and mentor. I’ll also make a conscious effort to create my first information product. Stay tuned!