My First Project at Accenture: A Journey of Growth and Learning
Embarking on my career at Accenture was quite literally a door into the world of practical application. As a fresh graduate, I joined Accenture’s Jumpstart programme in Java, which is designed to provide freshers with the essential skills and knowledge needed to kickstart their professional journey. It included training sessions on various technical and soft skills, yet it was ultimately a very university-like experience — something I had a fair share of before joining the company. “One truly every learns while on the project” said our Java trainer, so after successfully completing the Jumpstart, I was keen on moving to the actual pastures and started looking for my first project while absolving some trainings in the process. After getting my first cloud certification, I decided that it would do good to apply my freshly acquired knowledge in a cloud-native setup which led me to specifically search for projects who work closely with AWS (Amazon Web Services). The project outlooks at that time were far from favourable as it was late autumn which meant Christmas was looming over and it was not until mid-January that I landed confirmed staffing on my first project as a cloud-native application developer.
As soon as I joined the project and started onboarding, I realised that the client is a rather big fish in the deep sea as one of the biggest German retail companies. So it goes without question that it had a plethora of different teams with clear delineation of responsibilities like shopping basket functionality, deliveries, returns, cancellations, centralised AWS account management and so forth. As a freshly baked developer, I was overwhelmed by the codebase and the multitude of decoupled processes. Furthermore, having never worked in an agile setup, I remember to this day, asking our Agile Master what a user story is? What is a story point? And why on earth are we playing poker? What added to the initial complexity was also that my team was in the centre of it all, its prime responsibility being order processing — it always had a say in an order’s lifecycle. The team consisted of an evenly matched number of developers from the client and Accenture, every single one of them having more hands-on experience than me, which meant that the start of my work was accompanied by the marvellous concept of pair programming, enabling a smooth transition, and understanding of the key services and practices.
In my first stories I worked with the central order processing service, a Spring Boot application, which ran in a continuous manner using containers on AWS Fargate, and the cornerstone of the state of being in the centre of it all mentioned earlier — it formed the backbone of order processing at the client, handling a high volume of orders efficiently. The main type of development work associated with that service was updating models, enriching its API, adding, or changing existing event-processing which often involved communication and alignment with other product teams. To me, an interesting discovery in that service was the State Machine, which handled different fulfilment statuses a given order can be in. The name itself was a clear allusion to the university times as this is a subject that often mentioned in Computer Science curriculums. I was pleasantly surprised to discover that some concepts taught in universities find practical application in business — which, admittedly, is rarely the case in most situations. Funnily enough, the user stories that involved working with State Machine were always met with reservation — or a certain degree of awe if you will: It was considered one of the more challenging aspects of the app. In my opinion, using this concept was a rather clever way of condensing a piece of conditional logic (transition between fulfilment statuses based on some condition).
The other type of stories I often worked on, were those in the serverless domain — AWS Lambda functions written predominantly in Typescript, each responsible for a specific task related to the management of vouchers, and often orchestrated by AWS Step Functions service. Despite me coming from a Java background, I found these types of stories to be more satisfying as far as AWS experience is concerned. The reason for that is that these stories often required writing tech design implementation sketches, that would decide which AWS infrastructure is going to be deployed, whether its cost-effective, or whether the degree of architecture decoupling is acceptable enough or how and if it should be orchestrated by AWS Step Functions. These were the kind of tasks that an AWS architect is generally musing upon, and I would say that exactly this experience reinforced my desire to get more knowledge in the cloud architecture and obtain my next AWS certification — Architect Associate.
Doubtless, one of the strongest points of this project was its maturity when it came to error handling and edge cases. The monitoring system in place allowed only for a few issues to go unnoticed, with AWS CloudWatch being the vanguard of error resolution. Whenever an alert was triggered, it would be propagated either to a MS Teams channel or to a central SPOC (Single Point of Contact) team depending on business criticality. Our team’s pipeline sheriff (weekly rotated team member responsible for all kind of operations issues) would make sure it was put on our task board and worked on, which allowed for prompt handling of any errors. Many user stories I worked on included setting up monitoring alerts for fast detection of potential issues, and so I had the pleasure of enhancing the system’s monitorability by configuring and fine-tuning AWS CloudWatch alarms on key metrics and logs.
Practically all user stories involved configuring or adapting AWS infrastructure (SQS queues, permissions in AWS IAM, AWS Lambdas, AWS Step Functions) and to my delight, this was done in alignment with the best practices on the market — by using Infrastructure as Code (IaC). Instead of manually configuring resources through the AWS Management Console (which is still often done according to my peers), we had an automated approach using Terraform. By using this tool, I came to understand the power of IaC and the advantages of having an immutable, clearly defined infrastructure config: When coupled with version control, this approach allows to perform code reviews and check all changes to be made to the infrastructure, deploy the infrastructure as part of the pipeline run — and revert your infrastructure to a particular state if necessary.
From Java to Typescript, from the intricacies of AWS services like SQS, Lambda, and Step Functions to the configurations of Terraform, I was constantly learning and adapting. Each story presented a new challenge and a chance to deepen my understanding of cloud-native applications and tools. The variety kept the work engaging and provided a solid foundation in modern software development practices. However, it was not just the technologies that made this project a remarkable experience — it was the team that truly made it exceptional. Working alongside experienced developers from both the client side and Accenture, I was surrounded by individuals who were not only skilled but also incredibly supportive. As a newcomer, I often found myself facing challenges that felt overwhelming. Yet, the team’s patience and willingness to guide me through these difficulties made all the difference. Pairing was a particular standout aspect of this supportive environment. It not only eased knowledge transfer but also fostered a collaborative spirit that made problem-solving a shared effort. My colleagues were always ready to dive into the codebase with me, troubleshoot issues, and brainstorm solutions. This collaborative approach ensured that I was never alone in facing challenges and could learn from the collective expertise of the team. Moreover, the culture of open communication and continuous feedback within the team was instrumental in my development. Regular code reviews and retrospective meetings provided constructive feedback that helped me refine my skills and improve my contributions. The emphasis on continuous improvement meant that every team member, regardless of their experience level, was encouraged to grow and excel. So, while the technological aspect of the project was indeed enriching, it was the team’s camaraderie, mentorship, and unwavering support that truly defined my experience. On a final note, the experience not only honed my technical skills but also instilled in me the importance of teamwork, patience, and the value of a collaborative work culture and I do not stop repeating it “One couldn’t have wished for a better first project at Accenture”.
