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:
- Get to know
- Technical interview
- Personal Manager interview
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:
- You can link everything
- It gets clearer on who manages what
- I do not know everything
- Others do not know everything
- People need your opinion
- Start talking to each other as soon as possible
- The planning is working when you make it transparent
- Adapt fast to changes
- Learn and improve ourselves for the bright future (tickets)
- Learn from the (dark) past
- You develop slow at the beginning and get faster with time
- Stories get better with time: tests, descriptions, tasks, acceptance criteria, splitting, structure/templates, refinement
- We can communicate and react faster to changes on the way
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:
- writing blog posts
- help others with writing blog posts
- enrich on-boarding processes
- creating knowledge within the unit as a whole
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
- Ask questions
- anything that is unclear
- when you are struggling
- when you do not understand
- because there is never something like knowing everything
- people will help you
- it is not stupid
- There are people
- I like to work with
- compatible with me
- better than me
- understanding what I want to say
- that let me learn to grow
- Try to understand
- the company, its structure, and clients as good as you can
- the co-workers, each is a hero within your reach
- bottlenecks, try to figure out how we could remove them
- ways for improvement
- Before you start something
- think before you start anything
- use whiteboards, notes, or words to display anything, it helps best to focus
- talk to people
- Slow down
- you cannot know everything from day one
- each process might be bigger than it looks like
- split tasks into smaller pieces to move on faster
- understand the big picture
- figure out issues by analyzing and understanding it first before debugging
- structure your notes
- Talk to people in general
- they know what is going on
- consider their opinions, be open minded
- figure out where they stay and why
- Try to challenge yourself
- by projects/tasks
- view on issues
- help others by sharing experience rather than solutions only
- Do not try to
- fix everything yourself
- push your own programming onto others
- move an elephant all alone
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. ♥
Top comments (0)