Since we’re on the topic of hiring and interviewing, let me regale you with a story about two developers. This is an entirely fictional tale, but drawn from real-world observation and experience over 17 years of employment.
Suppose you had two new junior developers at your company: Ren and Stimpy. Both have similar backgrounds, education and experience. Both passed the interview process and were inducted into your team. Both are bright, ambitious and self-starting. Any resemblance to the long-running popular cartoon is purely coincidental. Stay on target, Red Five.
Ren started out on the first day setting up his computer, checking out the code and understanding what his first assignment was. Within a week, he mastered it and went to his managers for more work. After a few more assignments, he started to get bored and whine about how menial his tasks were, even though he was a junior developer. He started to sulk to his manager about how he could “do so much more” than just writing unit tests for some “barely used modules.”
Ren would often interrupt have impromptu meetings with other senior developers and managers hoping to get more interesting and challenging tasks. Often times, he’d get more of the same kind of work from them. Instead of taking lunch and wasting valuable time, he would often work through lunch and stay late to get these tasks done.
Stimpy started much the same way. He setup his machine, checked out the code and worked on his first assignments. He too, asked for more work when it was finished, but he started recognizing a pattern to the work he was given. The billing system testing he was doing involved some similar functions and classes that could easily be scripted. He worked on this side project and then let his manager know that all future tests were now written. This made the manager’s job even easier, since the senior developers could now use this script to auto-test things as they came out with new requirements and designs without further delay. He spent his lunch hours socializing with members from other teams to get to know them better.
Stimpy also started looking around at other things going on with the team. He found the SVN repository was a complete mess. He started asking other developers how it ended up that way and got a broad perspective on how the company organized code over time. He spent extra hours creating a new repository that completely reorganized the code in the current taxonomy which made everyone’s lives better.
Stimpy noticed that the company’s development document files were just sitting around on a shared directory. He decided to create a wiki (after first talking with the network admins to see if one already existed, and finding the ideal machine on which to install it) and upload all the docs by project. He published this to his manager, who in turn shared it for the very first time with Marketing and Sales, so they could see the progress on engineering projects.
Stimpy was asked to sit in on several design meetings to get his input because he was able to grasp the historical significance of past development based on his repository migration (with the benefit of hindsight, he had a unique perspective that even the original developers lacked), so they wanted to know what could be salvaged from old projects and what needed to be rewritten. Ren was still working on his unit tests and complaining to his manager about it.
It’s pretty obvious which of these developers is going to make a positive, lasting contribution to the team and which might be more of a drag on productivity. Five things really separate these two individuals:
- Understanding how things work in an organization. Stimpy took it upon himself to learn about the “other infrastructure” besides his tiny module of code. He got the bigger picture, which made it easier to understand the importance of little things and which things are more critical than others.
- Knowing the roles of others and how/why they do their jobs. By interacting with others (like the network admin and the other developers outside of his immediate scope), Stimpy understood how all the parts fit together to make a unified machine. And he saw where things in that machine needed maintenance.
- Finding where gaps exist, and taking the initiative to fix them. How many times have you heard, “Well, we don’t have time to do that right now.” (Sounds a little like Habit 5: Fix It Later, don’t you think?) Doesn’t matter what the question is, you’ll get that answer a lot from most people in any company. If you’re the one person that is willing to do extra stuff (with a smile, of course) and still gets your own job done, you’ve already risen above the pack.
- Have no fear of repetitive, monotonous, or boring “dirty work”-be willing to get it done. Of course no one likes this kind of work. It would be called something different if that were the case. But honestly, what do you remember more vividly? The guy who fixes the annoying SVN problems the entire team suffered with for 3 months, or the guy that created an awesome rainbow table for his code from scratch in a weekend?
- Stepping up and taking responsibility for things outside of your job description. Arguably, they both did this, but Ren was looking for the sexy, resume-filling work, where Stimpy was just getting things done, no matter what they were. Never did he say, “It’s not my responsibility…” If you want to get ahead, actively find things outside of your job description that you can do and that would have a beneficial impact on the company and do them. Don’t whine about not being challenged by your managers (or teachers). There’s only one person in control of your life: you. Don’t give that power up, ever.
No matter whether you’re starting your first job, or your 10th, always ask yourself: What kind of developer do I want to be? Ren or Stimpy? And if you can sing the Happy Happy Joy Joy song to the delight of your team, so much the better.