How to Train your Interns!
I have been working in Brain Station 23 as a Unity Developer for a little over a year. So far I was working alone. But recently I’ve been assigned 8 trainees to prepare for my work field. I’ve never trained or taught anyone anything officially before let alone 8. So this was my first experience as a Mentor.
I was given 10 days to assess whether they are right for my task or not. I don’t know about others but it’s almost an impossible task to teach anyone anything properly over this short time. So I didn’t try to achieve the impossible. Instead, I did what was possible for me to do, to observe if it’s possible for them to move forward with me. I kinda had to do some stress testing on them. I had no idea what to do. I knew I wanted to ensure that they know the best of software engineering some git and a bit of Trello.
DAY-1 : MIGRATION
First of all, I had to know if they already knew C#. If they didn’t I had to teach them the basics at least. If they knew I’d have to teach them at least one less thing. Sadly 90% of them didn’t know. But the good thing was they knew JAVA. The way I usually learn something new is I try to map my old knowledge with the new. So I told them to create a Stack Data structure over C# and they can use Java as a reference. Actually, I told them to copy the whole java code over and try to convert it to C#.
The reason behind this was, I don’t really want them to waste their time over thinking about logic. That ain’t my goal. I want them to migrate to new syntax as soon as possible. I strictly told them to check C# syntax from the docs.
After 3–4 hrs everyone had finished converting some version of the stack from Java/C++ to C#.
Now I took a look at one code and every other trainee with me. It may sound like a waste of time but it was more fruitful. Because each trainee had different mistakes and everyone could learn something new from it even me.
I wasn’t really concerned about the code running. Honestly, I didn’t even try to run any code, to begin with. I was just checking if they could make their code better with C# syntax.
By the end of Day-1, everyone learned the followings
- Not to use static variables randomly
- The use of Properties instead of getter and setter methods of Java
- Use of encapsulation
I didn’t really know what I was going to teach until the end of the day. And it seemed like everyone learned a lot better by fixing mistakes than being taught some feature blindly. I followed my findings on the second day too.
Since our plan is to prepare them for game development. I had to ask if they played games. Well, sadly their answer was, hardly. So I told them every day they have to play some games I’d assign them to play and write their feelings about it in a document as a report so that I can see. The goal was to make them understand Game Feel which would be required later in the phase. For the first day, I gave them these games to play,
- Super Mario
- Contra
- Bomber Man
- Battle City
I carefully picked old NES games of different genres for them to experience the thrill of original ideas. Also, I was planning to bomb them by showing how the game was made after the 5th day.
DAY-2 : THE ACT
Initially, I had planned to give them some problems to solve and that way they would be well versed in the syntax. Then I realized, The best way to optimize the time we have with learning is by working on a project individually and fixing the mistakes they make and teach the best practices as we go. How can someone feel what’s the best practice if they don’t see the bad practice first? It’s important to let people make mistakes before teaching them the best way. Otherwise, they won’t ever be able to truly understand the beauty of it. The light is valued only because there’s darkness. And even if AIR is more important it’s hardly given value because it’s too available.
Well anyway, I thought the smallest project we can work on would be a Calculator. Just a simple framework that lets you do the basic addition, subtraction, division, and multiplication.
Oh yeah. I forgot to mention. So I wanted them to experience some client meetings. So I asked a colleague of mine to act with me to simulate some client is asking us to develop a Calculator app. We both had our fair share of experience to simulate such a play. And if I must say we really did a good job in the acting because the trainees could hardly believe that it was an act.
Well after the act I explained that we are gonna make a calculator and they have to make it individually. It only had 4 operations (+,-,x,/). I was very certain that they would make a rigid application that can’t be extended. And I was planning to give them some change requests that would require a rework!
And my instructions were the same. If you wanna see logic check out any language you want. If you want syntax check docs. That’s probably the best way to mind map the syntax.
By the end of the day, everyone made a class with four functions that just did the operations. I on the inside was just waiting to drop the bomb on the next day. *Evil Laughter*
By the end of Day Two, I again gave them some games to play. The games are as following
- Galaga
- popeye
- PacMan
This time someone actually asked me how the games were made of that age. I only gave them a smile and told them to wait. Deep inside I was grinning.
DAY-3 : The Open Close Principle
So at the beginning of the day, I told them. Yeah, it’s cool that you can add double numbers but I need to add some Complex numbers too. The way the code was done mostly it would need a lot more new logics to add that feature. Well duh, I was planning to do that in the first place. So now I went ahead and told them these wise words, “ Your code should be closed for modification but open for extension.”
Then I proceeded to show how they could do it via interfacing. To keep this article readable I’m always going to skip the technical bits.
Anyhow one of them was pretty advanced on the take and did the thing appropriately just like I would have wanted to. So instead of writing all the code myself. I just used that to explain why should everyone write it this way. Initially, the code looked very stupid in normal eyes. Because we were making lots of files where the whole thing could be done in one file. But soon they realized that once they have this, they will never have to touch it again. It’s a perfect calculation machine that doesn’t need to know anything else that what we are teaching it right now. If needed they can be taught new features later without modifying the code.
By the end of the day they learned the followings:
- Open Close principle
- DRY principle
- Use of Interface
- Factory Pattern
I couldn’t make time for them to play games this day.
DAY-4 : Couldn’t find in stack overflow
First time in my entire life. I searched for a problem that I couldn’t find an answer on stack overflow. I felt quite achieved. We traced back the problem to an open-issue of a Language feature. Here’s the link.
We were trying to enforce Operator Overloading through interface/abstract class. Alas C# didn’t yet provide the feature.
I was assigned a new trainee on this day as well. Now I have 9 kids. But I don’t think I can do much to help him at this point. The stage has been set. The show must go on.
By the end of the day they learned the followings:
- Operator Overloading
- Abstract Class
- Filtering with Interface
On the fourth day, we played some hardcore games.
- Ninja Gaiden 3
- Teenage Mutant Ninja Turtles
- Donkey Kong
- Donkey Kong Jr.
I even played Ninja Gaiden 3 for some time myself. I must admit I lost my touch. I could barely go to stage 3.
DAY-5 : THE REVIEW
This day I was planning to review everything we did so far. instead of reviewing everything they did. I just hijacked a meeting room. Plugged in my Laptop and started doing everything from scratch.
I actually made a fake Trello board to develop a calculator library with 5 operations. Yep. If you think I went overboard. I made a git repo and made branches for each function I developed and merged with develop branch.
Well…
About git… It went horribly wrong. I must say I’m not that good with git myself either. I just know the basics. So somehow I messed up one merge request and ended up showing them how we Really use Git. We don’t.
I didn’t really plan out everything. I was doing mistakes as I go and fix them. I didn’t want to act like some perfect know all teacher. I wanted to make them understand we are as confused as they are. We look up to google for almost everything. And stack overflow is overflowed with answers.
After fighting for 5 hrs we finally had made some kind of library for a calculator. Here’s the git repo if anyone’s interested.
There was something interesting I noticed myself too. One of them said, “when we refactor, the code gets more if-else, but now when you are refactoring the codes are getting rid of if-else”.
It seems like, Good codes have less conditional statements.
By the end of the day we had the followings:
- A Calculator Library that we can use in the future project
- Lots of re-factoring mechanics
- Trello
- Git?
- Unit Test
- Lots of brainstorming about writing good code.
I believe the 5 days I gave them were fruitful. Even if they don’t become a game dev they would make fine software engineers. And the community will be benefited none the less.
