History At Cvent

This is a mostly complete history of my major work projects at Cvent. Organizing this history by project makes the most sense to me, because each major project I worked on was almost like getting a totally new job. Some things stayed the same, but technologies, tools, scrum processes, coworkers, and my responsibilities often changed with each new project. The dates might be fuzzy, and many of the details of older projects might also be a little fuzzy.

Planner Side Redesign (aka PSR, April 2013 ~ January 2015)

First project was rewriting the event planner side for cvent, known at Cvent as the Planner Side Redesign, or PSR for short. I worked on this project for about 2 years, with the later 6 months of the project being heavily focused on product bugs that were discovered after release.

Technology
We were using c# and .net MVC. All pages were basically save and edit form fields with varying levels of complexity. Some might just be a few simple text boxes, while others were variable column grids with multiple editable fields within those grids. The front end was composed of javascript components that could be called from a cshtml ‘view’ page, and any relevant parameters could be passed into these methods. The model page was usually just a simple c# object with some validation tokens. The controller would call a back end service to get the data, and do any necessary client side manipulations of that data. The backend was initially supposed to be c# microservices which would replace a lot of old and outdated SQL stored procedures. The “micro” part of microservices wasn’t working out, and rewriting it all was taking too long, so midway through the project we just switched to only calling the old SQL stored procedures.

Tools
The team I started working on was the first dev team at cvent to start using git (rather than version control). We would review pull requests with stash.  We used microsoft visual studio for all of the coding needs, and occasionally SQL Server Management Studio to look at stored procedures. We used Jira for most of our agile related things, tracking tasks in progress, backlog, sprint planning, etc.


Workflow and process
The project spent most of its time in a state of process and procedural flux. We went through many iterations of agile and scrum. We did not initially have many people experienced with running a scrum team. So our sprints would expand as much as they needed to in order to accomodate all the work we agreed to. I remember having a 2 month “sprint” at one point. Somewhere during the project we also switched to a kanban process for about half a year. This kanban process was well suited to the project, because most of the work could be broken down into discrete chunks that a developer could work on independently. After the project had been released and mostly finished we switched to 3 week sprints during the maintenance period.


Team responsibilities
This was my first real coding job out of college, so my main role was just an individual contributor on the team. When new developers joined the team, I was sometimes the point of contact for them, helping to get them familiar with the codebase and act as an initial reviewer on their pull requests. Cvent sent me to a few career fairs. During the maintenance phase Cvent sent me to their india office to work with some of the teams there for 6 weeks.



Dependency Hell Detour (December 2014 – January 2015)
During the wind-down of the Planner Side Redesign (PSR) I worked with a dev ops engineer on our growing dependency problem. The codebase was composed of 4 large c# projects that could be run independently depending on what part of the application you wanted to run. These 4 projects then referenced about 5-10 shared code packages. During PSR we created about 10-15 “micro”services, many of which referenced those 5-10 shared code packages, or just referenced each other.

Updates to the shared code packages had to be done very carefully. The dev ops engineer created a script to find unused references in these projects. I went in and removed those references and made sure the code wouldn’t break as a result, I would also stress test and find any bugs in the script.

It took about two months of time to untangle the web of references as much as we could. I worked with the dev ops engineer to setup some best practices and build pipeline requirements that would prevent this problem from happening in the future.

This work was unlike most of the other work I did at cvent. Much of the actual dev work I did was slow, tedious, and often had me working long hours. But, there were also many upsides. Being on a team of just two made me feel like we were part of a lean coding duo. Since we were both somewhat junior developers it also felt like we were given a large amount of responsibility and independence. We were responsible for verifying the integrity of code changes that could crash our entire product. We were fixing a problem that could have ground projects to a halt if it wasn’t fixed soon. And since there was so little help available online we were forging solutions that few others had found before.

I look back on the project fondly, but I’m not sure I ever want to do it again.