Route to production! - as a developer

I have heard many stories and quotes in the past that directly points to the title of this post. This is my take of the subject.

There is no doubt that every developer (including myself) would like to spend many hours perfecting the software engineering art. We love our design patterns, SOLID principles, frameworks and runtimes. Any passionate developer can spend hours talking about these subjects. These aspects of software engineering is so important that without it, any project can get out of control and possibly fail.

My journey

I was fortunately to be a developer on a very large and complex enterprise solution. I also played the role of technical architect and solution architect in two separate medium/small solutions. In this post I would like to share my role in getting the solution into production.

As a developer

Being a developer is a fantastic experience. I read in many articles that we stand on the shoulders of giants. I think that is absolutely correct. The open source movement, stack exchange has brought the developers of the world together.

I loved being a developer of the large and complex solution. It was a payment system which had numerous integrations and challengers. In fact the solution may look quite complex at first glance, but it was broken down by context (e.g. refunds, payments). This breakdown allowed any developer to focus on one area of functionality.

The team itself was large, and had an amazing breadth of knowledge. Some days I would spend hours going through my colleagues code as it was an art!

I was happy and joyous. I would have long lunch breaks and discuss the latest trends (e.g. microservices, functional programming) in the industry with my colleagues.  Sometimes, the debates inevitably got heated! but that was the fun of it.

The solution was owned by a solution architect and a business analyst. I never took too much notice of these guys, as the stories and tasks that were allocated was descriptive enough. Once in a while I would consult and ask the intent and the context.

The colleagues outside the team did not like the solution architect. I heard stories of him storming out of meeting and being rude to some. This was very strange as none of us in the technical team felt any hostility. The solution architect use to tell us that few hours he spends with the technical team was the best time of the day! We took it as a pinch of sugar and salt!

The solution had multiple components deployed across various systems. I never had to worry too much about the deployment topology. The code I wrote, went through the normal development cycle and ended up in production. I did know the end-to-end system. I could describe each component and how it relates to the business function and why it is needed.  I was proud of my work, and I received positive feedback from the customers. That was a great feeling! Each day, I would take a cursory look at the logs to ensure there is nothing odd.

The deployment pipeline was a heavily automated. From the engineering aspect, the only manual step was the selection of the appropriate package to test, stage and push to production. The quality assurance (QA) activity was mixed (automated and manual) as we had to depends on other teams to confirm.

Keeping aside my social life, I had the opportunity to look at the next shiny thing! The life was great!

Reflecting on the title of this post, I was not too involved with how and where the solution got deployed. I had queries from other teams but nothing to pull my hair out. Most of the queries were related to check whether this or that feature is working, what account, what permissions etc.

The solution now sits in production serving millions of customers each day without a sweat. Perfect!

Whats next

The times change, how teams are organised change and yes, change is everywhere. In the next post I am going to discuss how my role changed and what impact that had on myself.