Last week on Twitter, I followed along from the sidelines as some developers I follow there were debating whether they wanted to still be writing code when they turned 40. As someone who passed that a few years (but not too many!) ago, and who also spends a good chunk of time every week talking with developers who would like to join us here at Art & Logic, the discussion got me thinking about the whole situation. Long ago, my dad lectured me pretty severely about thinking about my work in terms of being a career with some sort of trajectory; he was convinced that I needed to go back to school for either a MS in Computer Science, or an MBA — in the world he worked in (he was a mechanical engineer), those were the choices. There were two paths of advancement available to you, and the gateway to either was the credentials handed out at the end of a course of study. As I’ve done all my life, I ignored his suggestions.
Luckily, my natural instincts seem to have served me pretty well, career-wise, and I’m starting to see some patterns in some of the developers that we talk to but don’t have a good place for here at A&L. I was originally going to title this post “Letter to a Young Developer”, but the tiniest bit of googling pointed me toward a pre-existing article with the same title. To everything in there, I say, “Yes!”, but there’s more than that. There are more than a few anti-patterns of career development that I’ve seen over the years. It’s an easy thought to say that I’ve seen these mostly in older developers (where, let’s be honest, that’s me as well), but the fact is that most of these are just as commonly seen in young developers in the first few years in industry. I hope that the points I make here are equally of interest and pertinence to developers of all ages, but with a special reminder to younger folks that they’re going to be the graybeards before they know it.
It wasn’t that long ago that I was the new guy who was excited to actually be getting paid to write code every day, excited when the new MSDN CD (okay, writing that made me feel old) came in the mail filled with new SDKs and APIs to play with. Over the years, especially after I acquired a wife and kids along the way, it’s become more of a struggle to be that guy.
Anti-Pattern #1: Getting Comfortable
Probably the most common, and most commonly seen with developers who get into a nice, secure job using one of the more mainstream development environments. You’re working in a company with 100 other Java or C# developers, and it starts to appear that what you’re working on is the only thing that there is. We once talked to a developer who we asked how he stayed current with changes in the field of software development. His answer was that he subscribed to a magazine that covered all the new advances in Java. When an entire field of endeavor gets reduced in your head to the one tiny part of it that you work with, it’s time to lift your head off your desk and start looking around.
It’s very frustrating to talk to someone who got lured into this situation but suddenly finds themselves looking for work. Obviously, both Java and C# are marketable skills right now. Will they continue to be? Ask a COBOL developer who wasn’t looking ahead and was caught off-guard when industry left him behind. (Yes, there are still folks being paid to write COBOL, just like there are still buggy whip manufacturers. Neither are growth industries at this point).
I suppose that many people manage to get through their entire worklife like this without a hitch, but it strikes me as being too close to the early 20th century vision of working your whole life at the mill and then retiring to a gold watch and generous company pension; a vision that’s gone forever.
Anti-Pattern #2: “All Programming Languages Are The Same”
This developer understands that there are many different languages and technologies in use, but sincerely believes that they are all basically the same. “Yeah, give me a day to learn the syntax, and I’ll be an expert for you.” I once worked with someone who used to state proudly that he could write FORTRAN code in any language’s syntax. It worked out in practice about as badly as you’d imagine. We see the same thing today when some C++ (for example) programmers start writing Python code — everything is far more complex than it needs to be, classes worry far more about emulating protected/private methods and variables, and it just looks wrong to a seasoned developer.
Anti-Pattern #3: Waiting for Permission
Sometimes we’ll ask someone if they have experience with some particular technology that’s more modern than what they’ve listed in a resume. “Well, I’ve heard of that,” they say, “but I’ve never been given the opportunity to work with it.” Don’t let your career be driven by what your employer assigns you to work on. Almost anything that’s currently interesting and in use is available to you without cost other than the time spent learning it, or perhaps the cost of books if you’re like me and learn best that way.
Anti-Pattern #4: Shiny, shiny!
Perhaps the flip-side of ‘waiting for permission’ — sometimes we encounter developers who flit from shiny new thing to shiny new thing, never doing more than giving each one a quick taste before moving on. Everyone should work to acquire one or more areas of deep expertise, and be sure to use those experiments with other areas as scouting expeditions for your next area of deep mastery. The guys at The Pragmatic Programmers have recommended that every developer work to learn a new language to some reasonable egree of depth each year, and that sounds like it’s about the right schedule. Even if you never write a single line of code in one of these languages on the job, spending time in Erlang will change your ideas about handling concurrency in any other language you work with, and the same kind of spillover benefits would come from spending time with a purely functional language, or any of the other, more esoteric languages.
Anti-Pattern #5: The Panacea
A variant on ‘Getting Comfortable’, adding attitude. Sometimes we encounter folks who are devoted to one particular language to the exclusion of all others, because they believe that it is the one true perfect tool. This is an ant-pattern that we also run into at the corporate level. Earlier this summer I was visiting a potential client who was doing an exhaustive vetting of potential development firms, and partway through our presentation, their CTO stopped us cold and wanted to know why everyone else who had presented to them devoted the majority of their presentation toward trying to sell their preferred language or framework as being the key to the success or failure of the project, but we had barely mentioned anything about that. My associate and I shrugged our shoulders; both of us had seen many different things come and go over the years, each of them promising the same kind of silver bullet. We’re just about due for another wave of tools that promise ‘programming without programmers’ again, assuming that history repeats.
In the end, we’d rather pick the appropriate tool for the particular job and make sure that we’ve got great people working on the project. Like Heinlein said: Specialization is for insects.
I guess that my basic takeaway here is that:
- No one is responsible for your career except for you.
- If you’re not in a job that gives ongoing opportunities to work with different tools, languages, and frameworks, you need to invent those opportunities for yourself.
- It never ends. There’s always something new coming down the pike, and at some point, there’s a chance that you’ll be in competition for a job against someone who’s taken the time to learn it.
- The only thing that’s potentially standing between you and your own awesomeness is yourself.
- Your career is a marathon, not a sprint. Think of ways to play the long game successfully..
(photo by huppypie)
