How taking short-time projects will make you a better developer, and how managers should hire those brains to give a long lasting boost to the software team.
Being a good developer doesn’t end with having a deep understanding in the technologies and languages you use. It goes even further than knowing the ins-and-outs of the tools, patterns and algorithms you utilise on a daily basis. To be a great developer you have to constantly research, and adapt the new solutions and technologies others invented.
So if you are programming Java websites since university, the least you should do is writing some Android apps on the side. It might be the same language and tools, but you will surely end up looking into some UI/UX stuff that will broaden your mind and skill set.
Corporates have a good reason to keep programmers dumb
Experimenting with new technologies is not what usually happens within corporates though. Engineers are paid to provide a solution that works, within the shortest time frame and with the most certainty that the software will not break. Not exactly the best place to be creative and invent new stuff.
This is one of the key factors for most of the workplaces not using the latest software or technologies: implementing those takes time, and sure: why would they bother updating something that worked just as fine before? It may be totally understandable, but that’s how you end up with software running on Java 1.5 and office documents written with Office 2007.
Reading Hacker News? Come on. Xkcd, maybe, if it was fun.
Start small, start quick
It’s very usual to get comfortable after having the same job for years. Showing up at work just a bit late, having a long coffee break in the kitchen, starting the morning with Facebook and Twitter – and at the same time, feeling more and more tired of work
This industry has a crazy pace though and having an up-to-date knowledge doesn’t come easy. It’s already hard enough to predict which technologies will stick in the long term. Who could tell if it’s better to start with iOS or Ruby now? How many months before Nokia was going down did Symbian developers start looking into Windows Mobile code? (I actually know this last one: two.)
Cash in for what you learned
Committing for something completely new would be too much of an investment, and perhaps not very wise either. First, it’s hard to find the time in the evenings and weekends to learn. Second, with those few projects you can launch, or the 1-2 years of experience you may gain, you will probably look at a lower salary level than at your current workplace with 2+.
There is a way to learn some new tricks quickly though. They say that the only way you can get better in chess is to play with someone who is better than you – and the same rule applies very well in the field of programming too.
Good enough reason to be in the market for short-time projects. If you change your jobs every 6-12 months, you will be introduced to many more projects and even more people, exposed to new technologies on a daily basis. All of this you can learn from, and the new stuff will look great in your CV.
And a great CV eventually leads to a fat pay check.
Managers, this is what you do
If you are leading a software department, now you think you shouldn’t keep the employees for too long with the company. This is hardly the case. All you need to do is to hire some developers for a few months, every now and then.
They don’t even need to be the best fit for a project. The more experience a programmer has with other technologies the better, but the main thing to make sure about is that during the project, the outsiders should be well integrated within the team.
Everything else is magic.