Skip to main content

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 have any dedicated time for learning. We decided that spending an hour or so in the morning for individual learning and an hour or so after lunch to team learn would help us continue to grow and have plenty of time to get work done.

I had another opportunity where I think letting the interns decide was better than leading them in a specific direction. We had been mentoring with a lot of direct involvement in how to code our stories and solve the problems we encountered. Due to a company event, all of the mentors were away from the office for the day and the interns were left to work on their own. This day allowed them to see that they could work together without our direct guidance and solve their own problems while also learning more. They unanimously wanted to continue that path of working more on their own with us as resources to help them when they got stuck. I could have suggested we take this approach as well, but having them come to that realization on their own was a better decision.

Now I have shifted more into finding opportunities to give focused training when I have seen a need. All of the interns have a good basic understanding of what they are doing and how to solve their problems, so I can give them some more advanced direction. One thing I have focused on is clean coding practices. We had a fairly complex section of code that filtered a list of data based on multiple points of that data. They were able to come up with a working solution on their own, but it was very procedural and fairly difficult to understand it all as one unit. I guided them in taking that working code and breaking it apart into smaller methods that were easier to understand in isolation. They all enjoyed this refactoring and I don't think they would have learned as much about why you want to have clean code than if we had directed them in writing it that way in the first place.

Comments

Popular posts from this blog

Converting a Large AngularJS Application to TypeScript Part 2

In part 1 I was able to take an Angular controller written in JavaScript and convert it to a TypeScript file while doing very little to change the code. In this post I am going to explore transitioning that same controller to actually use the features provided in TypeScript. This is how I left off my controller:
declare var angular: any; (function () { 'use strict'; var controller: any = function($scope){ ... } angular .module('app') .controller('controller', controller); controller.$inject = ["$scope"]; })();
While performing the translation from JavaScript to TypeScript, I would make sure at every step that the functionality I expected still worked, so if anything I did broke the system I would change it back and try again with another approach. Also if something seemed like it worked too easily, I would break it on purpose to make sure I wasn't getting a false result through browser caching a previously working fil…

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') …

Gamify TDD

I like it when things that would not normally be associated with games add concepts from games as a way to incentives you to accomplish things. Why simply go for a run if you can have an app that will track you and give you a gold star if you do better than you did the last time? Why go to the coffee shop that only gives you coffee if the other one will give you points that you can redeem for free drinks eventually?

I was recently introduced to CodeSchool, an online training system similar to PluralSight, it has video courses and challenges you can take to prove that you retained what the video taught. CodeSchool also adds badges and tracks to your learning, so as you complete a video and its challenges you get a badge. Complete a collection of courses within a specific discipline and you become a master of that discipline.

Some of these incentives are not tangible and really don't mean much in the real world, but they tend to work for me. If I start working towards a large goal a…