September 2007, was the month I joined the 4-year-long program at the IT & Communications department of the Technological Educational Institute of Serres, Greece (nowadays part of the International Hellenic University). 5 years later, upon finishing my studies and my military obligation I found myself holding a BSc degree and looking for my first job as a Software Engineer, in a new country, Sweden! After many, many applications, a bunch of interviews and a couple rejections, Thomas Näreskog gave me the golden ticket to the market and I worked my first day as a full-time Junior Developer for Mongo Digital (nowadays Pixlo) March 2013. I have been working non-stop ever since and I have experienced quite a lot during this time. I have never been afraid of trying new things and I fail often, but every time I fail, I learn something. I started from 0 and today I hold solution and enterprise architect positions. For sure I must have written a few millions lines of code and many solutions I designed years ago are still live in prod. I really enjoy my career and I can’t wait to see what the future brings but I also like to look back and reflect sometimes. 10 years seems like a nice milestone and a good time for reflection so I thought that it would be a good idea to squeeze those 10 years and offer you the distilled version of all my learnings. Who knows? Maybe it helps someone, somehow. Let’s go!
This is no longer the case. Languages hardly matter any more and frameworks pop up from one year to another. Also, learning those new languages and frameworks is so easy that pretty much anyone can join the market in a year or so. I am not saying that this is bad thing, the opposite. I love that our market is so open, inclusive and reachable. It means however that we can never relax. We have to keep up with the latest technological advancements and dare to “kill our darlings” i.e. learn new ways to do things we already know, or even totally new things.
Work experience > education, but with a twist. I cannot argue the fact that you really learn the profession in real-life conditions. There is a lot of theory that is not always applicable and sometimes reality forces you to break rules e.g. take shortcuts to save time/$$$. Also what we learn in the university is often out of date when we make it to the market and I think that I have a good explanation for that. The professors teach us basic, fundamental topics. They cannot know that each new technology is trustworthy after only 1-2 years in the market. They need to teach what is considered to be commonly accepted and well tried techniques and it takes a few years to get there. I believe that one should focus in building a strong ground of fundamental skills while studying. Then, when in the market, we get the chance to learn more and build upon that ground.
However, there’s a twist. In my humble opinion, only the past 5-7 years of work experience are relative when it comes to software developer and architecture. Sure, being 20 years in the market gives you experience and qualities of great value, but technically, what you did 20 years ago, you should not do today. So if I had to compare 2 CVs and one had 20 years of experience working with legacy technologies and the other had 6 months if internship in a “digital warzone”, then I’d take the latter, and wouldn’t think it twice.
Nobody likes a brilliant asshole. The brilliant asshole is that colleague that knows all there is to know about a subject but they are so stubborn or opinionated or selfish that nobody wants to work with them. Everybody has their character and there is room for everybody in our big market. Imagine however, if a brilliant mind is wasted in a person who thinks that they are better than all the others and are hard to work with. What a pity.
Luckily I have only met a couple of those and only one did indeed intimidate me. I am not sure what these people try to achieve but I have never been such a person being admired and appreciated. On the contrary, they usually keep their positions because they know too much and their skillset is hard to replace.
I believe that the more one learns and advances in their career, the more they understand that there is always going to be someone who knows more about something. Also, showing off really does no good to a team or a project.
Prepare for the impossible, because it’s going to happen. I am well aware of the fact that I have a strong need of controlling situations and preventing even the most improbable scenarios but believe me, I’ve been burned more than once. Systems that were supposed to be bulletproof have collapsed and disaster recovery strategies have failed because nobody tested the recovery-part.
Regardless if you write code or design software, it is very important that you learn to consider all scenarios that are theoretically possible and the you handle those. I cannot stretch how important it is to test ugly paths as well happy paths, or someone once said, Trust nobody, Assume nothing, Check everything.
Work did not destroy my hobby. I have been in love with computers since I ever saw one. I coded first when I was 13 or something and it’s been always been a hobby I enjoyed a lot. It is said that if you convert your hobby to a profession then it will lead to you hating your hobby. This has not happened to me at all. I don’t know if others have experienced it, but the more I work, the more I like what I do.
There is however one situation that I can relate with. When working on a bad project, it can get really ugly and at points, you might find yourself hating it. But this doesn’t mean that you no longer want to code. It means that you wish that you could do this and that in another way, in the “correct” way. Yes, that’s a feeling I’ve had once or twice.
You don’t code for you, you code for the client. It can hurt sometimes, to be asked to build something that you feel is wrong. It kills your motivation when you are not allowed to implement those cool features that you really looked forward to. The earlier you realize that you do this professionally and that it’s not your baby, the easier it will be for you to implement a good solution that your client will appreciate.
This applies more to the way we build things. I see very often, mostly amongst junior developers, a tendency to do everything “by the book”. Design patterns, normalization forms, ORMs everywhere, as if it is illegal to create smaller solutions. First of all, we have deadlines and we need to do things fast. Secondly, the more you code, the more technical debt you create.
Premature optimization will kill your project. This is somehow related to the previous point. If they ask you to build a house, don’t start by graving for the garden outside. Are you sure you need that interface? Why on earth do you break a class into base class and child class if you only have one child? Who told you that this minimal API needs an onion architecture?
I feel that sometimes we try to outsmart the clients and we guess the future needs of the project so that we can say, “ha! I knew it” if and when the need arises. Unfortunately that need seldom arises and if you really see it, then you should ask the client in advance. Maybe you get a green light and then you’re good to go!
Mentoring and being mentored, cannot be overestimated. I will never forget how much help I got from all my colleagues throughout my career. I have had the luck to have very helpful colleagues who were always happy to help and explain techniques and frameworks. Their help has been invaluable to me and I never would have come where I am without them. It was my mentors who paved the path for my learning, that challenged me and that helped me avoid pitfalls. Even today, I never take any decisions about work without consulting with my mentors.
I even have the honor to be seen as a mentor by myself, by one or two younger colleagues. I get goosebumps when I interact with extraordinary talent and I feel so great when I get to discuss future choices and career options with them. It is so great to see someone bloom and raise professionally. What I need to mention however, is that mentorship cannot be forced and is meant to be requested and offered. You can’t make anybody listen to you, if they don’t want it.
If you don’t have room to grow, move. Like trees, software engineers, need space to grow. We need to work with challenging projects and with technologies and frameworks that match our skills. Ideally, one works for a company that has a suitable portfolio but an expectation mismatch may occur. It is not impossible at all, it’s just business.
I have changed employers every time I felt that my job there was done and up to now, I feel comfortable with my decisions; it was always for the better. I feel that this practice helps me keep my skills up to date and I never get too comfortable. Beware though, do not do this too often, changing employers every year is a red flag for me, unless if you are a freelancer. Being unable to stay in a place for a couple of years means something, doesn’t it?
Do it your way. If you made it this far, then either I am such an excellent writer, which I’m not, or you really found my insights interesting, which would make me really happy. The last lesson I got though, is that we should all pave our own paths. Having a mentor is fantastic and being inspired is very important but at the end of the day, it’s your career and your life.
When I was younger, I used to follow others’ advice, almost blindly, if they really inspired me. I learned the hard way, that this is wrong. You should be responsible for your own decisions and it hurts less if you a mistake was your idea.
Today, I have a number of people with whom I discuss every career decision, every professional choice and I truly listen to their feedback. But I never do anything unless it really feels ok with me and as Frank Sinatra said Regrets, I’ve got a few. But then again too few to mention...
That’s all! I made a reminder for 2033 so let’s see what it looks like when I have 20+ years in the market. Thanks a lot and please do write me some feedback!
Ps: Regarding the featured image, I pasted the whole blog post in ChatGPT and asked for an image that sums it up. I got that image and the text: Here is the feature image for your blog post “10 Lessons I Learned During My First 10 Years as a Software Engineer.” This vibrant and inspiring image symbolizes the journey of a software engineer over 10 years, capturing the essence of your career growth and the various stages of your journey from Greece to Sweden.