6 Things I Learned at Vattenfall
A few years back, I was thinking about myself as a highly skilled software developer, which is underestimated and works below his qualifications. I decided to change company and started to work for Vattenfall IT Services Poland, and I could not be more wrong about my skills.
In this article, I will share my thoughts about working there for over three years. Today I am no longer working for Vattenfall, so this is more like a retrospective and, I hope, a little guidance for you regarding your career. You will not find any metrics or raw data about my personal growth. It is rather a light read with my personal thoughts. Take a cup of coffee and enjoy!
Seek people better than you
There is a mathematical joke known as “a claim of local geniuses”, which states that “for every mathematician, there is an environment in which he is most outstanding”. I think it may be transferred to any area. Around four years back, I thought that I’m highly skilled — not outstanding, but good enough to be way better than an average developer. First weeks at Vattenfall I was pretty convinced that this is true, but then I started to cooperate with other people. Suddenly my self-esteem was questioned, as their skills showed me, how wrong I was.
More amazing was that they were not bragging about their skills. People there were very keen on sharing the knowledge, guiding me and give advice. There was no mentoring program, and I think there was no need for such. Mentoring programs create a relationship in which one person is dominated by the other. In this case, it was more like cooperation, where we were challenging each other. Don't be afraid of admitting that you are not the best one, and look for people who may guide you to become better. If there are no such people, start thinking about some change or you will not develop yourself.
Extreme programming on everyday basics
Not talking here about TDD, that’s something that I find is a must for something more complex than a few lines of bash script. We were working in pairs, which is great in the matter of knowledge and experience exchange. It also improves code quality, causes fewer comments during code review and limits the bus factor risk. Occasionally, while crashing a bigger feature, we used mob programming.
Another habit that I had to get used to, was to switch from “big releases” to everyday ones. At first, this was stressful due to the tension related to releasing the application that I remembered from previous jobs. Often releases, backed by solid automated tests, are giving you the confidence to release and deploy the application. Releasing small changes reduces the stress, as there are not so many things that can break the application. In the end, we were releasing automatically our services multiple times a day — after every merge.
Be responsible for your tools
Nowadays it sounds weird to me when someone says that he needs to ask the manager/architect/anyone on a higher level when he wants to use some library or tool. When you as a developer are going to be responsible for an application, maintain it and develop, you should be able to choose the tools that will allow you to do that effectively.
In the first weeks at Vattenfall, I was working on a project that was made as PoC, and was needed to be developed into a mature application. There were no unit tests in the code at all. I decided to change that, I was collecting the arguments and data for writing them for a few days. When I felt ready, I went to talk to my manager and said “I want to introduce unit tests into a project”. I expected to have a long discussion with him about why it is beneficial. Instead of, I got a short answer: “OK”. It took me minutes to lift my jaw off the floor, as that was nothing I was used to.
This situation was very memorable for me. Giving developers the trust in their skills by something so simple as letting them choose the technology they want to use, makes them feel that they have an impact.
Bottom-up initiative
After few months in the company, I started to look for a more challenging project. There was one team that I really wanted to join, as they were using new technologies and their work was fascinating. After few talks by the coffee machine with the team members I decided to ask their Product Owner if he is willing to accept me. His answer was “if the team is fine with it, then I’m also fine”.
It was a clear signal, that the developers, who are going to work every day with a new team member should make a choice. Managers usually do not work with them on daily basics but rather ad-hoc. In case of communication issues, they will not be impacted so hard as the coworkers. It is very valuable to take the initiative by the team members, and not hesitate to talk with management about new ideas.
Another situation where bottom-up initiative produced good results, apart from selecting your new team members, was the recruitment process for a new manager. We selected a representative of each team that the new manager will be responsible for, and we, as developers, interviewed the candidates. That let us work with a person that we liked and knew that cooperation will be successful.
Business people are valuable allies
Since 2011, when I started my career, I had an opinion that the developer role is to produce code. Maybe also do a little bit of documentation. That's all. I was happy when the business analyst or manager gave me a clearly defined task, where everything was already agreed with the customer. I did not have to discuss anything with them. It was pretty often that later the customer was requesting changes as implemented feature was not exactly the thing that was needed.
Shortening the distance between business people and developer gives you a unique opportunity to have an impact on the solution. Everyone in the communication chain — the customer, an analyst or manager wants to make your work easier. That is nice but causes a lot of valuable information to be hidden from you. It impacts the solution you create and makes, as it is harder to introduce fixes or changes at a later stage. Just think about all the times that you designed a “perfect solution” for some problem, but later the customer wanted to change it because it was not working in the desired way.
Allowing the developers to consult the customer reduces the number of misunderstanding. You, as a developer, start to better understand the domain, which allows you to prepare better and simpler code. The customer on the other hand feels well cared for and understood. Together you are starting to use the same language. Shortening the distance between business and developer allows you to suggest other solutions than the ones that customers thought. You just have to leave your comfort zone and talk with them.
Tackling the problems with event storming
For the first time in my life, I was able to see another way of gathering requirements other than sitting in a room with a customer and asking questions like “what the application should do for you?”. Event storming answers that question in a very effective way. It engages everyone to work by giving them sticky notes that easily model the processes.
The joke about the customer not knowing what they want is no longer fun for me. It is your role, as a developer, to tell the customer, what they want. By understanding the business they are running you can help the customer understand his needs. You can help spot the places in the process that causes the most money loss, tackle it into a set of small problems and solve it. Believe me or not, but seeing the joy on the business people faces, when they realize what is the problem in the process is priceless.
End of my work
I left Vattenfall IT Services at the end of April 2021 in pursuit of challenges. Working in the company gave me a huge knowledge boost and changed my mentality. I learned that engagement of the team pushes them into delivering awesome stuff. Moreover, now I find that having an impact and being responsible for the solution at the same time is making the team engaged — not the other way.
Personal thanks
At this point, I’d like to say thanks to the people I’ve met and who helped me develop myself. Starting with my managers, Tomek and Kamila for pushing me forward. Sven, Abel and Mark, the Product Owners for putting trust in the teams. Marcin, the Agile Coach for questioning our approach, and most important, Mobile and The Forehand teams for great discussions, not only technical ones.
