In 2012 I was in an IT job, in which I was not very happy, and the work wasn’t fulfilling. I was searching for new positions or opportunities to move into web development, but none seemed to be working out. I took a chance on a contracting firm, which was able to place me with a company that had a team with a good reputation for web development. I was excited about this opportunity and looked forward to learning what I could from the team.
I learned quickly that my skillset was OK, but there was a lot for me to learn from the user experience team and especially from the other developers. I jumped in head first, eager to learn everything I could. The team had several processes and functions in place that I had never considered, and was subdivided into designers, information architects, and developers.
"I would take all the pieces from the designers, the information architects, and the business and bring them together with my code to create a working product."
The designers and information architects worked closely with business areas to create a proof of concept for projects using wireframes and designs. These were new concepts to me, as I had not previously worked with a wireframe or a design. As a developer in this hierarchy, I learned that I was the mechanic of the group. I would take all the pieces from the designers, the information architects, and the business and bring them together with my code to create a working product.
Coming into the position, I was readily added to a project that required a front-end developer. I found myself in meetings with other members of my team and other developers. These other developers, as I learned, were the company’s back end developers. These developers worked closely with other groups, such as the database admins and the server admins.
I felt there was a gap between my team and the back-end developers. My team was driven by the presentation and the user experience of the project, and the back-end developers seemed driven by the data and the functionality. Yet, we were all working toward a common goal of an application that worked well, was easy to use, and gave our consumers what they needed in the end.
I found myself working very closely with the information architect and designer on the project as we moved forward. I gained a great rapport with the back-end developers and was able to bridge the gap between the teams. Never having worked with other developers this way, I was able to understand how my development affected theirs and vice versa. This allowed me to have detailed conversations regarding project requirements and the development necessary to meet these requirements.
Six months flew by, and before I knew it the project was complete and I was now looking at the end of my contract with the company. As the end drew near, the back-end developers began to talk to me about full-time positions and opportunities with the company. Not long after, I was approached by the back-end development team and offered a position. This came as a welcome surprise, but I had my concerns about the opportunity. I knew that I wanted to continue working as a developer, but wasn’t sure if my career path was in the front end or back end. After some deliberation, I opted to take the position.
This brought me to a new team, with a new set of challenges and learning opportunities. My new team worked on one of the company’s major web applications, which is used by thousands of users on a daily basis. I understood this was a high-visibility position, and the development I would be doing would be highly scrutinized. Also, this marked my first foray into C# and ASP.NET development.
The team manager believed that with the right training I should be up to speed in no time. Therefore, the first few weeks in my new position were spent in training. This included learning the business of the company, and time spent researching the C# syntax and ASP.NET.
Not long after, I was placed on my first project with a small subset of the team. We were working to add new functionality to the company’s web application. The development process was similar to the front end team, but with a focus on the data and functionality of the system. However, I continued to look for opportunities to propose usability changes or improvements. This was met with a push back at times; due to the age of the application and the concern that major changes would upset the user base. I was not deterred by this, and I continued trying to help the back-end developers think more from a user perspective while keeping processes in mind.
As more projects came down the pipe, I was tapped for my front end knowledge and skills. I was still very close with the front end team, and they welcomed my questions and concerns regarding my projects.
After a year and a half with the back-end team I was placed on a large, high-profile project that would help the company integrate better with its business partners. This required a major code overhaul of the application, and once again I was asked to work on the front-end development for the project. The overhaul required changes, including bringing the majority of the HTML up to HTML5 spec, and writing new CSS for the integration functionality. I worked closely with my fellow back-end developers to make sure they could work with the new front-end code and understood the changes. The first iteration of this project was tough, but a great learning experience for all and the changes were well received.
Soon came word of a process shift - agile was coming. After much talk, and shifting of people and processes, the team settled down and we looked ahead to the next iteration of the integration project. The agile processes allowed us to work more fluidly and to consider more usability improvements.
"Even though I had wanted this for a while, when presented with the opportunity I found the decision to be a tough one."
As I was approaching the end of the second iteration of the integration project, another opportunity within the company presented itself. The user experience team approached me with an offer to rejoin their team as a front-end developer. Even though I had wanted this for a while, when presented with the opportunity I found the decision to be a tough one. It’s not every day that you get the chance to work with such a great back-end team and then to be given the opportunity to return to the team that you started with. In the end, and after great debate, I decided to move back to the user experience team.
So here we are at the end of this journey. I’ve told you all about how I came from periodic free-lance work, to joining a company that has given me the opportunity to grow my skills as a developer in both the front-end and the back-end environments. Each day, I continue to learn more about what it means to be a developer. It’s not just heads down and code for days; it’s interaction. Not only interaction with peers or users, but interaction across the entire experience from a concept, to the implementation, to production.
I am a developer, and I make it work.