A whole year.

It’s been a whole year since my last summer finished. First, there were 6 months as an intern and then 6 months working full time.

Transitioning from a carefree state of mind to one of duty and determination was no small feat, mind you. Becoming a working adult was hard and it took some getting used to. I took the freedom of student life for granted and didn’t realize that being an adult is a commitment. Every day you wake up and decide to get dressed. Decide to get to work. But most importantly, you decide to be at that place for 8 hours (for most people).

Honestly, I’m really lucky. I ended up loving my job.

I love what I do every day and I’m fortunate enough to be doing it with people who share my passion for our profession, software engineering. Mind you, software developers come in all flavors and personalities but the bunch that you find at Verve are exceptional. We are currently a team of 5 with 1 project manager, due to increase to 6 devs by January 2022.

It’s fascinating that 5 people from 4 different countries can so fluidly collaborate on many projects simultaneously. Of course, we all speak English but I think it all comes down to the environment that our Chief Technical Officer Cristian Cirstea and our Project Manager Kevin Chen have developed. We have a culture of support and kindness, an environment where learning is encouraged and new solutions or ideas are welcome. To sum it up in one word: a team.

When I first joined the team as an intern I was fortunate enough to be given my own project. I had to plan and execute a significant restructuring of a chrome extension written using the Angular framework. The idea was to replicate the features and functionality of our internal Angular/Ionic application but in Google Chrome, the browser. To put it bluntly, it kicked my ass. I had never touched Angular or Ionic. I had worked with JavaScript, not Typescript. But most importantly I had never worked on an existing codebase. At university, you start every project from scratch, a blank canvas. If you’re fortunate your teacher might give you some interfaces to implement but you’d never be given a full codebase and are told to modify it.

I felt lost, truly. I kept looking at the code hoping for it to make sense. After 3 days of trying and failing I was starting to lose hope. That is until Tibor Kadar, my colleague, explained something to me and it just clicked. With a few sentences, a complex HTML component that I was having trouble understanding lost its complexity and the logic suddenly made sense. To this day this part of my job still amuses and fascinates me: the thrill of finding the solution, finding the last piece of the puzzle.

After about a month of constant work, lots of ups and downs, tons of research and google searches, as well as countless questions and discussions, the project was complete. Version one was ready to be released.

The first time you do a release is stressful. The only thing I could equate it to was submitting an assignment at university: there is a task which you need to complete and submit for someone else to judge. However, building something you expect a grade on is not the same as building something that has to work for someone else. When you complete an assignment the project has to work within a strict set of standards and a context defined by your teacher. Instead, when you are creating a piece of software for public use you have to consider a different set of constraints and unfortunately, often there are none. You might be building for a target audience but the audience might include several device types, different operating systems, etc… There are many more things to consider and things you simply forget to consider.

This first project was a real eye-opener. It allowed me to quickly get to speed with our tech stack and our general way of operating. I learned about our Git methodology, our CI/CD pipelines, the Angular/Ionic frameworks, and Typescript. However, the most important thing my first project taught me is to be resilient and not to give up. I know for a fact now that if I don’t understand something all I need is some time and I’ll figure it out. A lesson I am fortunate enough to have learned early in my career.

Having expressed a larger interest in backend work at the start of my internship and being about halfway through it at this point I was keen to dig my hands into Scala, the programming language. Once again, as if it were providence, a backend project presented itself before me: an integration with Dealroom, a global provider of data and intelligence on startups and tech ecosystems. This project was launched for two reasons. The first was to enhance the quality and quantity of the data we have on the thousands of startups we track. The second was to enhance the quality of the decision-making of our Deals team by providing them with more accurate and up-to-date information.

Development-wise there were two main goals to this project: integrating Dealroom’s API into our ecosystem and backfilling thousands of data points in our database.

It quickly became clear that a data mapping from their data models to ours was necessary (looking back… duh!). However, Scala is so poorly equipped for JSON manipulation even with Play Framework. So, I had an idea. I built a configurable JSON manipulator/extractor in Scala. It did the job but it wasn’t pretty. It was my first time writing Scala and I was still learning. Without fault, Cristian, enthused by my interest and passion for this piece of code made me feel accomplished even if it wasn’t the best. Having since revisited this piece of software with some more knowledge and practice I can honestly say that it is one of the coolest pieces of code I’ve written so far, something I’m really proud of, and something I hope to keep improving in the future.

With a way to manipulate and extract JSON values I was ready to start work on the first task: integrating the Dealroom API into our ecosystem. The main challenge with the integration was making it easy enough to use so people would want to use it but robust enough to be reliable. The goal from the start was to fetch, display, and download all the information necessary about a company from Dealroom with a few clicks. To do this I had to automate the whole fetching process and find a middle ground between displaying real and erroneous results, something which took time to fine-tune. However, this project taught me a lot about collaboration in software engineering.

We, as developers, often get the short end of the stick. We receive business requirements and are simply expected to implement them. However, it doesn’t have to be like that. The best projects are born out of teamwork and collaboration between the development team and the team the feature or software is being developed for. It’s logical: if the engineering team takes the time to refine the received requirements and the business team takes the time to test the software as it’s being developed, better and more useful software will come out of the process. For this first project, I was fortunate to collaborate with Thomas Meier from our investment team. Step by step we refined the requirements and then, through trial and error, we completed the integration into our internally-used Google Chrome extension and were left with a result that left us both satisfied. Thomas was happy his team had a new powerful tool at their disposal and I was happy with the structure and quality of the code.

Having finished the integration I began with the real challenge: backfilling thousands of data points about the companies we track with data from Dealroom.

Whenever a backfill is performed there is always some anxiety in the room and this happens for one reason. The solution for a backfill is often a script. Whether it’s a script that directly manipulates data in the database or one that goes through the backend API makes no difference because either way there is no human involvement. Obviously, a human wrote the script but when you run it you are trusting a machine to execute this piece of code independently and perfectly to manipulate thousands of records of production data. Just writing this is making me stressed. Given the scale of the backfill and that updating an element through our backend API creates a new version of the element rather than replacing it, I opted for this method for traceability. I must have tested that script at least 100 times before running it but once it ran it went without a hitch and 67,000 new data points were added, a significant amount of fresh data.

Once again I found myself feeling ecstatic. Another project had come and gone and I had contributed to its fruition. There’s a specific feeling that every developer knows characterized by satisfaction, happiness, and pride. It comes and goes and doesn’t always show itself when you finish a project. But, when it does, you realize why you love the job.

Despite being closer to now, the next six months were blurrier. As a junior software engineer, I began taking on more responsibilities while maintaining my existing ones. My first hotfix in production, my first release of our main platform to production, conducting my first interview with a potential intern, and of course my first ‘WTF’ moment looking at a piece of code only to realize it was mine from a year ago…