Finding the next destination on my path as software developer was not an easy task, as there are many interesting projects and companies on the hunt for job candidates. After attending the EA Connect days to ask developers about how they feel about their work and talk with clients about how they use the product, I finally decided to sign the contract with LeanIX. In this post I would like to share my experiences from the first month of starting out.
On the first day, Thursday January 2nd, my “LeanIX Buddy” Laura showed me around the office and introduced me to the different teams. I joined the “Re:invent” team, which is responsible for frontend development. My new colleagues made me feel very welcome and the overall setting in the office was quite cheerful. Afterwards I met with Arjun, our Security Engineer, who helped me set up some accounts and educated me about the security policies within the company. Then it was time to set up my Macbook according to well structured onboarding checklists. It felt good to contribute this early by creating pull requests for missing or outdated information in these checklists.
On the second day I was given my first story to work on, it was about fixing a relatively old bug that occurred when recovering a Fact Sheet. This involved looking around and understanding some RxJS actions and reducers, which are responsible for managing the state of our Angular application. I haven’t worked on projects this large with reactive programming and it was exciting to discover how the software engineers at LeanIX are applying this paradigm. The best part was, that I was able to fix the bug on the same day, which I didn’t expect at all. I went home with a feeling of pride and surprise.
The next Monday I was assigned to help my colleague Angel on a new story, so we spent the morning doing pair programming. After lunch I was busy attending so called “Ramp-Up Meetings”, where one colleague presents a specific branch or concept within the company. I’ve had these kind of meetings every week since then, while the frequency decreased after two weeks. They helped me to understand what the different branches within the company are responsible for and getting an idea about who is who.
Once the meetings were done I was reminded that I should add unit tests for a reducer to complete my bugfix from Friday. All tests were green when I joined my team for lunch on Tuesday and by Wednesday Morning I had released my code with the help of my colleagues, who showed me what the process in JIRA looks like and how to start the relevant Jenkins jobs. There is no continuous delivery yet, but comprehensive continuous integration, which greatly supports development as well as deployment. I was happy to see that the latter required minimal manual steps to complete and that nothing is merged without the review of a developer, who was not involved in the implementation.
After lunch, Sebastian presented some learnings from his recent endeavour into bootstrapping a python project, where all developers from the company attended. Anyone can host these “Lunch & Learn” events and I think it’s a great way to share knowledge.
The rest of the day, my team, as well as our friends from Customer Success, were busy bughunting in our Angular application, which we had just updated from Angular 4 to Angular 7 on one of our testing servers. There were no major issues, just small design fixes that surfaced because of a new way of treating whitespace in Angular templates. The Angular 7 branch was merged and released on Thursday morning without any incidents. I’m happy that the developers can take the time to modernise like this, which minimises the risk of being held back by outdated tooling. Yay for Angular 7.2 and TypeScript 3.2.1!
But we didn’t stop there. I was assigned two new stories in our sprint, which will improve the development process in the frontend even further: “Enable fullTemplateCheck in the Angular Compiler” and “Increase severity of some tslint rules to error”. These stories involved touching a lot of different parts of code in the frontend, which makes them perfect for someone who is just starting out. They kept me busy for several days, as there a bunch of errors to fix with these stricter compiler rules.
On Wednesday, January 16th, we kicked off the development of a new feature, enabling users to edit Fact Sheet subscriptions in table inline editing, which required all team members to work together. Angel and Umut presented the general architecture of the table inline editing component and outlined the parts we needed to touch to implement this feature.
We decided that it would be a good idea to start the implementation in a mob programming session on Thursday, to make sure that everyone understands the core dependencies of the feature.
I’ve never experienced this style of collaborative programming before, but it worked quite well for us. After two hours we split up into two teams that would implement separate parts based on what we had achieved until then, because at that point there were too many thoughts floating around and we started to lose focus.
There was a special event that evening, as DHL, one of our clients, had invited us to an exclusive tour of the Post Tower, the most prominent building of the Bonn skyline. The picture above was taken right after the tour.
Then came the third Friday of the month, which means it’s “Thank god it’s Friday”-Friday, where everyone who likes can bring food and we have lunch together in the office. The food was very diverse, plenty and most of all tasty. I really appreciate this tradition, coming from a company where we cooked in the office every day.
I was responsible for implementing the logic for transforming the user input of Fact Sheet subscriptions in table inline editing into objects, which we could save to our backend. As the input is quite complex, there was a lot stuff to think of. What better way to keep track of every necessary behaviour than unit tests? That’s right! Me and Ali implemented this logic using test driven development, which always helps me a ton.
Once we thought that we had a presentable implementation, the whole team reviewed the code together, to make sure that we actually meet all the complex requirements. Turns out we didn’t, but after adding the missing tests, it didn’t take too long until we had the final product.
The next sprint started on Thursday, January 24th, and I was assigned the story on handling Fact Sheet revision clashes in table inline editing, meaning that you get notified upon saving if someone else has edited the Fact Sheet in the meantime and you can choose between discarding your changes or overwriting the remote ones after comparing them. As of Friday, February 1st, this feature is fully implemented, including unit tests and end-to-end tests, reviewed and merged. A lot of pair programming with Patrick was involved for this one and I feel that we are generally very productive.
I’d imagine that the details of the stories I worked on this past month might be boring to some readers but I didn’t want to leave them out, as I never would’ve expected that I was going to successfully introduce such big changes in such a short time in a project I’ve never worked on before.
Thanks to all of my colleagues for making me feel welcome, for my teammates who always take the time to answer my questions or take on stories together with me. I really enjoy my newly gained productivity and look forward to the new things I’m going to learn at LeanIX.
This post was originally published at https://blog.leanix.net/insights/developer_at_leanix