You just got a new job. You’re excited, it’s gonna be great! They said you will work on interesting projects. They said you will work on the newest technologies. You will learn a lot. There won’t be stress and short deadlines. The atmosphere is supposed to be great, they even have a ping pong table. Your goal: to become a better developer.
Two years later, you haven’t moved from an obscure internal framework. You’ve been jumping from project to project, stressing out because of short deadlines, not really sure if anything you’ve done so far makes a difference. Or even worse: you’ve been wasting your time and potential doing things that are not challenging at all. You became a ping pong master (or not), but are you a better developer now than you were before?
My name is Ivan Lalić and I work as the Head of Research and Development at Lemax, a software company from Croatia. Over the past few months, I have had more than 50 selection interviews with developers as we have been expanding our team quite a bit.
I remember my own experience from when I was a developer. Comparing it to the stories of the candidates that I’ve been talking to recently, a lot of the things ring a bell. Mostly in the reasons why they decide to leave their job and find happiness elsewhere. Some of those reasons were my own, too.
That is why I wanted to share them with you and explain why they bother developers and why they are important.
However, I’ve noticed some developers aren’t even aware that they have a problem. Maybe they are used to their situation: to the stress, short deadlines, to a lack of leadership or a plan. Maybe they haven’t even questioned their status, maybe they aren’t sure what they want.
Maybe they think it can’t get much better than that?
That is why I also wanted to share my current experience at Lemax and tell you what it’s like to work there as a developer.
I asked a question at the beginning: are you a better developer now than you were before?
I am asking this because I assume that most people want to become better at their jobs, but this may not be an easy thing to measure.
So, if this is a tough question, think about the following one for a while and see to what conclusion it leads you:
When you look at your recent code, do you feel proud or a little bit ashamed?
Here are some more questions regarding that:
- Do you write technical specifications before you jump onto writing code?
- Do you have code reviews?
- Do you write unit tests?
- Do you have a QA?
If the answer to the above is no, think about this: doesn’t this mean you make more mistakes than you otherwise would – that is, if you had a clear vision and plan of what you’re supposed to achieve?
Because if you don’t know where you’re going, how will you know you got there?
So what happens if you spend too much time going back and forth from what you wrote to what is actually required, and in the end, you’re not sure if what you did was good or not. Fortunately, there’s someone to check what you’ve done…Or is there? If you don’t write technical specifications, you can end up spending weeks or even months working on something that might be completely wrong. And if you don’t have another set of eyes to check what you’ve done, how can you be sure it’s actually going to work the way it’s supposed to work? You probably don’t…until it goes to production and you realize there are more bugs in your code than in a tropical swamp rainforest. And the worst thing is – some of it may even be good, but it’s not what the client wanted in the first place.
Now think about this: what would it mean for you if you could work in a team where development process is planned and structured from the very moment a client gives a requirement – all the way to production? Where you start by knowing how the end result is supposed to look like? Where you make regular check-ups to see if it’s going in the right direction, by testing it every step of the way? How would that reflect on the quality of your code? On your sense of accomplishment? Imagine the things you could do with all that extra time you would have at your disposal. The time you could invest in learning something new, in developing new skills and ultimately improving yourself as a developer.
This is exactly how our development process looks like at Lemax.
Since we all work on one in-house product, all of our efforts go into maintaining high code quality so that it remains sustainable in the years to come.
- This means that we have a defined software roadmap for the next 5 years.
- This means that we first set up a structure and a plan before we jump into programming.
- We write a clear functional specification.
- Then a technical specification which is reviewed by the software architect.
- We then make sure we’re on the right track by having daily scrums, sprint planning, reviews, and retrospective.
- We test it during the development and do a final check at the end.
And – voila! It works! Except when it doesn’t. I have to be honest, we’re not perfect – sometimes it doesn’t work out exactly how we planned it. But with this structure, we can more easily retrace our steps, discover the error and fix it.
So, when you look at your recent code, do you feel proud or a little bit ashamed?
We feel proud. And we feel like we’re better developers now than we were before. Wanna join?
If this doesn’t convince you, check out my next upcoming post with more reasons as to Why developers leave?
