DC

My journey of four years at diconium

Posted on
Tags: career , experience

After my graduation and work as a 3D artist in 2011 I started my career as a professional web developer in an international publishing company and after seven years I quit there. Why? - actually, for many reasons, it accumulated: While the payment could have been better and the technology became less engaging over time, I saw it as an opportunity to broaden my horizons and work with a new tech stack. Plus, I was excited about the prospect of collaborating with others who shared my passion for this direction.

I accepted a recruiter’s offer for a company called diconium in Stuttgart. I agreed to go to the interview.

Job interview

The job interview had three parts:

My future director interviewed me first, also as a get to know. The vibe between us was good and I said I would take the job. The technical interview was around the normal path of: do you know this and that? - OK, that is fine, and if not, you will learn it on the way.

It felt different, like your word had a meaning and trust to the persons on the other side.

New job, new life

After the switch it took time to get into the unfamiliar environment from a PHP developer with HTML and CSS skills into a full JavaScript environment. It was a tremendous change for me. At that time, I never used JavaScript so heavily and tried to avoid it wherever I could.

My first task was to learn for an Angular project. That took time, but on the way, it changed to a React project.

I stayed with that project. With two other developers we created a demo shop within two months before the presentation. We proved that we could deliver what the customer wanted. I dedicated myself to creating something great, went on as the lead developer of the team.

Jack of all trades

At the beginning I was doing like everything: coding, Jenkins Pipeline, composition and integration, discussions about concepts and architecture and code quality, because it was necessary for the project. It was a good start, but not everybody liked this pace. The lack of experience also made it hard for others to work together, as there was a demand to have a stricter workflow than they were comfortable with. As a team we decided to concentrate more on coding and less on people management to deliver code quality. The client liked it. It was decided to increase the team.

I experienced separating parts of the work and bringing the responsibility to others more suited for it. We split the teams because of size, added more lead developers, created groups of core members to control the projects vision with multiple teams and continued.

Then scrum game came

As we went on with our work there was a change coming: we had to use an agile way for all teams: SAFe with scrum. I liked what I saw, we left the “lead developers” and put our trust to the agile way. I got my certification and continued to use the framework to our needs.

On the way I learned a considerable number of things, what it means to be agile, and how I need to adapt with my own workflow. To my surprise I worked already in an equivalent way but having a framework to show you with images made it again a nice addition.

Agile is not making the development process faster, but a little rounder. Why a little? Because it was more transparent than expected. It was a struggle at the beginning. Developers without the experience to change their workflow could not adapt and left.

The team found a way to adapt to our unfamiliar environment. There were people who adapted well, they understood the parts what that agile framework was for and how to use it.

This helped me personally to achieve a great deal of points:

Before I moved to another team

After our first demo presentation I wanted to improve the product but was disappointed for a long time. I presented simple future issues from time to time. People were not seeing the issues at the time. In my mind issues were increasing. Then I realized: it was only in my mind. We could have planned these things, but the project members were not there in mind, until things started really to crumble. We mentioned this to a big round, that we needed to improve.

The team found a way to communicate with others. There was a way for all of us to make things transparent without getting on the bad side of the client. It took the fear out of everyone to talk with others, rather than stay within the team.

It still took quite a while until this was set in motion, which put me again in a disappointed state. Of course, we needed to achieve other topics, create new features, and evolve the product. Because of the complexity of the code base, it got worse again. It felt impossible to fix the developer experience for everyone all alone.

Yes, everyone wanted to have it better, but the teams did not plan it, so: will not do. Sometimes it felt to me that people were scared because of reasons unspoken.

I talked to other developers about it. The team itself seemed to have no power to change this situation. What power? The teams have the power! Why do we not use it? Trying to make the customer happy is of course our job, but that does not mean the customer does not need to see that we are struggling until it boils up and we then are fixing the breaks on the speedway. When the developers are happy, then the customers will be happy too.

I got triggers to move on.

The triggers

There were multiple components that I created. Multiple of these lasted for a year, just updated like an extension, not changing anything. This made me think, as I saw the changes in the MR: my components are still alive, is that now boring or impressive?

In another part I fought with the pipeline, unit tests, linting, workflows, and got angry about it. I tried to fix it, but in the end, I got the answer to the task: the client did not allow it within the planning. We had it planned in the Definition of Done (DoD), but:

Nobody reads the Definition of Done.

This was an important statement within the team. We had that DoD ready, but no one used it, even if they should. Why was that so? Team members needed to set up more workflows = need to remember more things rather than coding. The process of remembering and doing more, rather than working on code only, made developers ignore the DoD.

Not everyone liked to do more than coding. That is understandable, but that was our role in this agile project. And I understood that even if I did this way of work, I would never be able to change the team, as single individuals did not want to change. The team stood still, and steps of improvement took a long, long time.

After three years on this project, I did not want to give up. I can be very stubborn. But I learned my lesson. There was a way, a trigger to move on.

There was a new team created from within the project, but with a slightly different goal: A design system team. I love these things. You create a design system, and it gets boring when you have it running. That wording feels negative, but thinking about my old components, that still lived on, it was exactly the thing I wanted: a stable code base standing and not failing anyone.

I asked to join the team and went on.

The new team

The design system team had a bunch of people with separate roles: UI, UX, developer, tester, product owner, scrum master. There was everything within it. It felt great. I could concentrate, improve, and learn the things I saw were important.

Next to the new experience I received, I looked at the other teams, and they saw improvements in the code. This was unexpected and it felt like their mindset changed. People saw us achieving things and getting a moment that the others were missing.

The design system team did remarkable things. We adapted new processes to improve our pace. I dove more into design systems and tried to make our product what we dreamed about as a team, not as an individual.

Other tasks

Next to the main work I had other tasks, like:

All these tasks made me open to people. They started to see me as someone not too strict anymore on all that process stuff, but as someone who wants to improve the developer experience and make the client happy. To reach that it took time - time - I liked to invest.

The end

My personal priorities started to change over time. I looked over my life and decided that it was time to move on. The time I spent on the first team felt wasted, personally. The reason was quite simple: it took exceptionally long to reach the state I had in mind. The general project developed into the direction I imagined that I did not want to.

With the design system team, I was more than happy, and I still feel great to have been a part of them. It was the most fun time I ever had since working as a developer. But that is it. It was the highest state I could achieve. There were more things I wanted to do and might even reach higher levels of what I am now, but I knew I had to move on.

I felt lucky with the team I joined so heart-fully. I will not deny it was a hard decision and I do not regret the move. I understood my reasons well.

Things I learned on this journey

The next thing

In my new job I wanted to do things with something in mind which I could not achieve before. From here on I want to evolve further, see myself in a higher light within the next year. This is something I want; this is something I need. A goal that motivates me to push myself. I saw the time was right, and I had the motivation to do so.

Each change brings new challenges, meeting new people, creating new possibilities and the growing not only as a developer, but also as a person in general. I thank you all for that.

The greatest thank you goes to my family: especially my wife, for pushing me to move faster towards new challenges and solutions, and our kids who made me completely rethink and readjust communication skills, looking inside and outside of the given frame. It was not an easy decision, but I know it was the right one.

Let us look ahead into a great future, together. ♥