We are looking to hire a few interns for the summer, and this made me thinking what approach should I take to provide great experience for them as well as get out some value for us. The culture that I am trying to establish in my company is based on the premise that software development is more than writing code. I know that this is a overused cliche but if you look around there are thousands of educational institutions and private companies that concentrate on teaching just that – how to write code while neglecting everything else that is involved in software development.
For that purpose I decided to create a crash course of good software development practices and just run our new hires through it. Being involved in quite a few technology projects over the last 20+ years, and having seen lot of failures and successes I have developed my own approach that may or may not fit the latest trends but has served me well. Also, having managed one of the best performing teams in the Microsoft Windows Division during Windows 7 (yes, I can claim that :)) I can say that I also have some experience with building great teams.
So, my goal for our interns is at the end of the summer to be real software developers, and for that experience they will get paid instead spend money. Now, here are the things that I want them to know at the end of the summer:
The team is the most important part of software development. The few important things that I want to teach them are that they need to work together, help each other, solve problems together, and NOT throw things over the fence because this is not their area of responsibility. If they learn this I will accomplish my job as their mentor (I am kidding 🙂 but yes, I think there are too many broken teams around the world).
As a software developer they are responsible for the product and the customer experience, doesn’t matter whether they write the SQL scripts, or the APIs or the client UI. If there is a problem with the code they need to work with their peers to troubleshoot and solve the problem. If one of their peers has a difficulty implementing something and they know the answer they should help them move to the next level, and not keep it for themselves because they are scared that she or he will take their job.
And one more thing – politics are strictly forbidden!
Communication is a key. The first thing I standardize in each one of my projects is the communication channels for the team. And this is not as simple as using Slack for everything but regular meetings, who manages the meetings, where documents are saved, what are the naming conventions for folders, files etc., when to use what tool (Slack, email, others) and so on.
Being able to effectively communicate does not mean strictly defining organizational hierarchies, it means keeping everyone informed and being transparent.
As a friend of mine once said: “Try to build a car with agile!” We always jump to the latest and greatest but often forget the good parts from the past. Yes, I will teach them agile – Scrum or Kanban – doesn’t really matter, important is that they feel comfortable with their tasks and are able to deliver. And, don’t forget – there will be design tasks for everything. This brings me to:
Software Design is integral part of the software development. There are few parts of the design that I put emphasis on:
- User Interface (UI) design
They need to be able to understand what purpose the wire-frames play; what is redlining; when do we need one or the other; what are good UI design patterns and how to find those and so on
- Systems design
They need to understand how each individual system interacts with the rest, how each system is configured and how their implementation is impacted
- Software components design
Every piece of software has dependencies, and they need to learn how to map those dependencies, how different components interact with each other, and where things can break. Things like libraries, packaging, code repository structure etc. all play role here
The best way to learn good development practices is to test your own software. Yes, this is correct – eat your own dogfood! And I am not talking about testing just the piece of code you wrote (the so called unit testing) but the whole experience you worked on as well as the whole product.
By learning how better to test their code my developers will not only see the results of their work but next time will be more cognizant of the experience they are developing and how can they improve it.
Build and Deployment
Manually building infrastructure and deploying code is painful and waste of time. I want my software developers to think about automated deployment from the beginning. As a small company we cannot afford to have dedicated Operations team, whose only job is to copy bits from one place to another and build environments.
Using tools like Puppet, Chef, Ansible or Salt is not new to the world but having people manually create virtual machines still seems to very common. Learning how to automate their work will allow them to deliver more in less time and become better performers.
Operating the application is the final step in the software development. Being able to easily troubleshoot issues and fix bugs is crucial for the success of every development team. Incorporating things like logging, performance metrics, analytical data and so on from the beginning is something I want my developers to learn at the start.
One of the areas I particularly put emphasis on is the Business Insights (BI) part of software development. Incorporating code that collects usage information will not only help them better understand the features they implemented but most importantly will prevent them from writing things nobody uses.
The list above is a very rough plan for the crash course I plan for our interns. As it progresses I will post more details how it goes, what they learned, what tools we use and so on. I started sketching the things on the mindmap above and it is growing pretty fast.
It will be interesting experience 🙂