How I moved from QA to Full Stack Engineer

After over a decade of working in software QA, and working through positions from analyst to manager, I was looking for a change. I had being working on validating someone else’s work for way too long. The change was supposed to mean a different set of responsibilities and knowledge/skills applied to software engineering. Instead of being the validator and guarantor of quality of a “finished” software product, I wanted to get involved in the discovery, design and actual building of something, to transform an abstract set of needs/wants/problems into a software solution by fusing computer science and programming with business knowledge and product perspectives.

My job was certainly part of engineering, and many of the skills I applied were — to a certain extent — the same, but I always felt it would be more exciting to be on the other side, going from a “blank canvas” to working software.

I was warned by colleagues that I would regret the decision, because the job is not all about the glory of a black templated screen with a cup of coffee on the side. But I had made up my mind.

Building up

When I approached my manager about my desire for a change, the planning and design of a training program was set in motion. After a couple of months we had something that could potentially be used as a framework for anyone else that wanted to make the same kind of transition — acquiring new skills, leveraging their current industry and business knowledge, and remaining in the company while adding a different kind of value. One that would be more satisfying for the individual, and still valuable for the company . I was to be used as the lab rat, happily.

The goal was to create a full stack engineer. Able to contribute full circle to the development of any given piece of software, with no distinction between front end, back end or any-end development. We would cover all things software engineering, ranging from programming concepts like OO and design patterns to HTTP, databases, functional programming and the use of Github, to name just a few. And in exercises and examples, we would work with the technology stack used daily at LendInvest, such as PHP, Node.js, React and CI with Jenkins, Docker, Kubernetes on AWS. We set a timeframe of 6 months as a target, to be adjusted according to my progress, my colleagues — senior professionals of varied backgrounds — were to be my instructors, teachers and supporters throughout the process.

And all of this was to happen while I was still performing my QA role. Working on the same projects as before, striving for the same quality of delivery, while making time to study and make the most of the training.

Executing

Theory started for me pretty much as any other classes would. Slow, heavy — making me like I knew nothing. But then it started to click. Exercises and practice got the juices flowing and a picture of the actual job began to form in my head. Plus, it was interesting to be able to pick the brains of the people who have been around me for sometime; I got to know how they really think about the profession, their work and how they structure the knowledge they apply day to day.

1st assessment

After completing the theory phase, the assessment was to deliver two tasks — the same ones used to evaluate the company’s candidates. One BE and one FE focused. Again, this was designed to drop me into the real practice of how LendInvest develops software, using the same tools and languages to deliver the task. For me, this meant bringing my background in QA (and its side of programming mainly with Java), dusting off my computer science degree (to revive concepts long-dormant in my head) and coupling them with the theory sessions to deliver a working piece of PHP software and a working piece of front end goodness with Javascript.

The back end task was to create a version of the interest payment feature of our investment platform, using PHP. The front end task was to create a version of the investing feature, where one could browse a few loans and make an investment. The end results were then evaluated by our team, measuring them against the pool of candidates that had delivered the same tasks in the past months.

Alongside the theory sessions and practice exercises, finding time to study on my own with articles, books, small projects and everything I could find online — like HackerRank-style websites — was vital in gaining more perspective on the job and preparing to hit the ground running. Diving into the LendInvest codebase to understand what had already been built and see the theory applied was also of great help.

Executing — 2nd phase

The 2nd phase, where things got really interesting — for me, at least — involved delivering working software that would provide real value to the business. This offered a real world delivery environment where the work would resemble the job for which my training was tailored. This involved collaborating with product management to analyse a business need, discuss solutions and decide upon the scope of work, before collaborating with the tech team to support the design and the development of the features.

Starting from a problem statement, I explored the implications of the problem before proposing potential solutions. We then discussed the feasibility of the solutions with regard to the resources, time and skills that needed to be deployed. And once we’d chosen one, we talked through the details of the implementation, considering how we could best plug this new feature into our existing technology.

From that point on, it was all about working through our beloved Kanban process to deliver all the tickets raised to craft the feature. This meant going through every detail of development environment setup, understanding the current solution, programming the new features, validating technical aspects, shouting for help when needed, working to apply the theory learned, validating functionality with product management, going through tests and finally delivering the new features — which meant gluing these into our system and making them available to our customers.

As this delivery phase went on, there were many challenges, ranging from getting used to the code base and how our team was working together , all the way to having to roll back features after deployment owing to silly rookie mistakes (yeah, learning the hard way…).

Adding value while training

But, I did it. I delivered two projects , while getting to grips with both product management (such as validation of requirements and stakeholder interaction) and technical delivery (such as code quality, functioning software, productivity). The projects I delivered were:

• A text notification feature for our bridging finance borrowers, providing updates on their applications status as it is acted upon by our case managers and underwriters (which has enough requirements to make it onto our main backlog, when priorities allow for it).
• A new version of the auction finance calculator (https://intermediaries.lendinvest.com/calculators/auction-finance/), integrated with the generation of a quote. Plus the ability to generate PDFs, share the quotes via email and, in one step, progress to making an enquiry to our underwriters.

2nd assessment

After these deliveries, the team members with whom I had worked most closely throughout the process assessed my readiness to join one of the development teams, and I ended up joining the borrower team — responsible for looking after and enhancing the experience of everyone we lend to. This meant continuing to build on my training and working directly with the same group of people, allowing for a smooth transition and delivery of value from the get-go.

“New life”

My job now is doing more of what I was doing during the 2nd phase of the training — full time. This means more responsibility for the quality of what is delivered and fulfilling expectations — mine, the team’s and the company’s — by continuing to develop my skills and improvemy throughput, increasing my contributions to what LendInvest is trying to build.

After over a decade in the QA profession, and after months of attending training sessions, making time to study and practice, and learning the ropes of the job, I can finally relax and get on with what I wanted for so long –going through our feature backlog to design and program some great software , without doing QA the way I did before. But doing it with greater ownership of the whole software, by working from influencing, questioning and helping improve the business perspectives, all the way to helping make better, the UX, the code structure and the final product.