Skip to main content

Intern Project, a look back.

This summer I was able to be the Lead Developer for our intern team. The team consisted of a developer that was chosen as our Leader, he was able to show his leadership ability in a setting that he would not have otherwise had access to. Myself and another full-time developer helped to mentor the interns and build out the site. And, of course, four interns that are studying software majors at their universities. These four had very limited experience with developing a website before coming to work here and also did not really know what it means to work in an enterprise-level team environment.

Over the course of 11 weeks, with roughly 50 working days we were able to design a new website and build it from nothing into a fully functioning site that will add value to our business. Everyone had amazing opportunities to learn and grow and come together as a team. The people that we were at the start of the summer are so much better with more knowledge and experience to draw upon now at the end of the summer.

Here are some interesting stats for the summer.
  • We completed 94 stories, almost 2 per day
  • 634 commits to master, with over 30 branches to master
  • Over 35,000 lines of code
  • 6 deployments to Production

Work completed by environment

The chart above shows the lag in getting work from lower environments through to the higher environments with the green being what is in production. As you can see, we did not have too many large gaps between getting work done and getting it into production. This was a high priority for the team leadership, to get our code out often and not wait until the end of the summer to push 1 large deployment.

Even though we were not officially launched, it was important to us to get our work in front of users and gain feedback. Our first 2 deployments had some minor hiccups, but solving those issues made the later deployments a breeze.

The feedback we gained from the early releases by users also helped shape the website. What we designed early on was not what the final product looked like, and we would not have been able to make those changes had we waited until the end of the summer to get our work in front of users.

The interns grew a ton as developers over the summer. At the beginning none of them was familiar with web development at all, but by the end they all had a good foundation that will serve them in the future. They all got experience with front-end working using Angular as well as server side code written in C#.

One thing that I took away from the summer was the importance of making sure everyone is on the same page. Too often, I think that I am explaining something clearly, but others are not following along with what I am saying. To help with this, taking multiple different approaches to explaining my ideas is important. Nothing was quite as useful to understanding this summer than when I would draw out the architecture behind what the code was doing, just having a simple visual representation of what I was describing went a long way to getting that understanding we needed. Another valuable tool I used was walking through the code line by line to detail what each line did and why I had chosen to do it that way. Or, reviewing their code in a similar fashion, and asking questions of what could be done differently.

Lastly, this summer I wanted to learn for myself if I wanted to be a Lead Developer.  Was I a good Lead Developer? Could I help those I was leading become better developers while also succeed at creating a good product. I believe the answer to all of those questions is yes. I would like to be a Lead Developer, I think that I did a good job this summer guiding the interns as the project as a whole. I still have room to improve and working with other experienced developers is different than working with interns, but I think that given the chance I would be able to adapt to those challenges.

Comments

Post a Comment

Popular posts from this blog

Converting a Large AngularJS Application to TypeScript Part 1

I work on a project that uses AngularJS heavily. Recently we wondered if using a preprocesser like CoffeeScript or TypeScript for our JavaScript would be beneficial. If our team is going to switch languages, we would need to be able to convert existing code over without much pain and we would have to find enough value in switching that it would be worth the conversion. I had read an article that stated that because TypeScript is a SuperSet of JavaScript, you could convert a plain JavaScript file to TypeScript by changing the extension to .ts and not much else would need to change. I wanted to test out this claim, so I took a file that I was familiar with, an Angular Controller, and tried to convert it to TypeScript to see how much effort it would take and then try to figure out where we would benefit from using TypeScript. This is what the controller JavaScript file looked like to start out with: ( function () { 'use strict' ; angular .module( 'app'

Interns: Taking off the training wheels

My intern team has been working for several weeks now on our new website. We have already completed one deployment to production and are finalizing our second one. We started with a plan to release often adding small bits of functionality as we go and so far that plan has been working really well. We already feel like we have accomplished a lot because we have completed many of our project's requirements and should easily be able to complete the rest giving us time to do even more than just the original requirements. One of the things I have had some difficulty balancing has been how much to lead the interns and how much to let them figure out on their own. In deciding what our team process should be and how we should allocate our time, I think it was important for me to do more leading. I saw some deficiencies in how we were currently working and brought up some ideas for how we could address them. We had moved into spending all our time just working through stories and did not

My idea for Hearthstone to add more deck slots

Recently someone asked the Blizzard developers for more slots for decks in the game Hearthstone. The response was that they are talking about it and looking into it, but no decision has been made yet. One of the concerns over adding deck slots is that it could complicate the UI for Hearthstone and make it more difficult for new players to understand. I have what I think would be a good solution to add more deck slots without increasing the learning curve for the game much if at all. First I would take a look at the current selection screen for starting to play a game. It defaults to showing the decks that are custom built by the player if they have any custom decks, and there is an option to page over to the basic decks. This basic deck screen is perfect for how I would change this process. Instead of having 2 pages of decks, 1 for basic and 1 for custom, you would just see the select a Hero screen. Then once you selected the Hero you wanted, you would see all of the decks that