I still remember as boy hearing that sharks never fully sleep like humans, if they stopped swimming they could drown. They need water constantly flowing through their gills to breath. The idea of a shark never sleeping and drowning sounded ridiculous. How could a living thing never stop moving?
Unfortunately the same fate awaits developers who stopping moving forward and progressing. In many careers you can hit a plateau and decide to stay there (see public employee). Developers, at least the ones who want to stay employed, do not have that option. Technology changes too fast. Stand still for more than a little while and you become obsolete, dead to the technology sector. It takes a little progress just to stay in the same place, it takes dedication, effort and hard work to stay alive for a prolonged period. Having spent the better part of 15 years in the technology/internet industry I know this is a fact.
So how does a developer keep up, stay relevant and not suffer the fate that so many others have? It’s simple, keep moving forward. If technology is constantly moving forward and you stop moving, it’s not long before you are left behind. So how does a developer move forward? Again it’s simple. Keep learning.
Read anything
Blogs, documentation, how to’s, wikis, it doesn’t matter. You most likely won’t remember a lot of what you read, but nuggets will stay lodged in your brain and you will be exposed to ideas and concepts you might not otherwise have come across. Reading is much better than watching a video or listening to someone explain something, it takes more effort and work on your part and that effort results in better memory retention (not water retention).
Write something
The inverse of reading is writing. Write about what you read, what you work on, how you solved a problem, how you stumbled across something ground breaking (that ten other people already discovered). Writing makes you think through things and consider how other people will digest what you write. It makes you, or at least it should, double and triple check that something works the way you write it should, especially if it’s your own code. Writing about something helps you to gain a better grasp on the topic, and a better understanding of how much effort other writers put into their work.
Know enough not everything
You’ve probably heard the phrase, “jack of all trades, master of none”. In many walks of life this a bad thing, for internet developers it’s a necessary evil. You can’t be a one trick pony. Most development work involves a technology stack, not “a” technology. Even within a team environment where there are specialists for certain streams of development, most members have/need some knowledge of the other streams.
Have a core set of technologies you master and then surround those with a complementary set of skills and technologies that you’re good at. For most work, “good” is good enough. As technology changes and evolves some of the core stuff may fade away and some of complementary skills may need to become core skills. The key is being able to identify when it needs to happen. For Flash developers it was early 2010 when HTML5 jumped into the spotlight. The one trick ponies freaked out, cried the sky is falling and prepared for the worst. The savvy developers read up, experimented, honed their skills and now have more to offer their clients and employers.
Take on projects you can’t do today
What? It sounds like a recipe for disaster but it is actually a recipe for success and growth. If you know you can learn quickly, challenge yourself by committing to projects that will force you to learn. Having a fire under you is a great motivator to figure something out and make sure it works. It also promotes ulcers if you can’t handle stress. Doing sample projects is great to get your feet wet but a real live project with deadlines and deliverables is where the real learning will happen. Why do you think militaries have live ammo training?
Failure is not an option
Actually it is but who wants to be a failure? No one. Don’t let failure scare you, learn from it. Go into a project planning to hit it out of the park, but don’t cry when you strike out, make adjustments for the next time you are up to bat. Own up to your failures. You broke the build, screwed up the server, accidentally deleted the backup. Stuff happens, own it, learn from it and move on. If everyone succeeded at everything they did the first time life would suck. Accepting failure and expecting failure are two very different things. Understand the difference and steer clear of the latter. Part of the learning process involves failure so get used to it.
Keep swimming
So there you have it, one key to not becoming a dead shark and four keys to not becoming an obsolete developer: keep moving, read, write, stretch and fail.
Apologies for the heavy reliance on cliches and metaphors.
Great point about keeping moving. Many developers I know feel safe to be doing the work they do without trying to learn and keep their knowledge updated. They are the same developers who complain about not having enough opportunity and being overlooked.
Nice article, I think you have it spot on. You are down to earth and don’t act like a guru god. You speak on my level and I appreciate that.
Sharks are been systematically killed for fin soup. Keep swimming is not enough, we need to learn to fly and bite those fisherman’s hands off.
I agree, we need to stay current with technology. But I don’t know if it’s a choatic mad rush to learn the next big thing as it’s implied here. Java, C++, .NET.. etc. these are the bread and butter of our job. Most else is learnable on a need to know basis.
I would suggest, become an expert in one thing, and learn as you go as needed…
Honing your core skill set will have the best return…
This is an excellent list of tips and concisely put. Will keep the nuggets!
I agree with almost everything you’ve said.
The only thing I question is the advice under “Take on projects you can’t do today” as whilst I can see what you’re saying the problem that you often find is that if you are working on a piece of work with software/tech/tools you don’t know you can cause no end of problems and stress yourself out when trying to deliver to live deadline.
I have been on the end of other dev’s who decided they had to do ‘stuff’ in the latest and greatest and ended up pushing out a pile of rubbish that turned out to be very expensive to run due to all the support calls.
IMHO the best idea is to create live code in a new tech, as you suggested, but for a non-critical system that doesn’t necessairly have a deadline so something like a utility for a support team. By doing that you will be exercising skills for real users but are unlikely to cause ongoing problems for the business.
Too bad this kind of person is the opposite of 90% of corporate developers who only do Java.
Great article… Can we be sharks with laser beams attached to our heads?
http://www.youtube.com/watch?v=Bh7bYNAHXxw