10 Things To Improve Your Development Career

---

Cruising the Web late last night, I ran across "10
things you can do to advance your career as a developer", summarized below:

1. Build a PC
2. Participate in an online forum and help others
3. Man the help desk
4. Perform field service
5. Perform DBA functions
6. Perform all phases of the project lifecycle
7. Recognize and learn the latest technologies
8. Be an independent contractor
9. Lead a project, supervise, or manage
10. Seek additional education

I agreed with some of them, I disagreed with others, and in general felt like they
were a little too high-level to be of real use. For example, "Seek additional
education" seems entirely too vague: In what? How much? How often? And "Recognize
and learn the latest technologies" is something like offering advice to the Olympic
fencing silver medalist and saying, "You should have tried harder".

So, in the great spirit of "Not Invented Here", I present my own list; as
usual, I welcome comment and argument. And, also as usual, caveats apply, since not
everybody will be in precisely the same place and be looking for the same things.
In general, though, whether you're looking to kick-start your career or just "kick
it up a notch", I believe this list will help, because these ideas have been
of help to me at some point or another in my own career.

10: Build a PC.

Yes, even developers have to know about hardware. More importantly, a developer at
a small organization or team will find himself in a position where he has to take
on some system administrator roles, and sometimes that means grabbing a screwdriver,
getting a little dusty and dirty, and swapping hardware around. Having said this,
though, once you've done it once or twice, leave it alone—the hardware game is an
ever-shifting and ever-changing game (much like software is, surprise surprise), and
it's been my experience that most of us only really have the time to pursue one or
the other.

By the way, "PC" there is something of a generic term—build a Linux box,
build a Windows box, or "build" a Mac OS box (meaning, buy a Mac Pro and
trick it out a little—add more memory, add another hard drive, and so on), they all
get you comfortable with snapping parts together, and discovering just how ridiculously
simple the whole thing really is.

And for the record, once you've done it, go ahead and go back to buying pre-built
systems or laptops—I've never found building a PC to be any cheaper than buying one
pre-built. Particularly for PC systems, I prefer to use smaller local vendors where
I can customize and trick out the box. If you're a Mac, that's not really an option
unless you're into the "Hackintosh" thing, which is quite possibly the logical
equivalent to "Build a PC". Having never done it myself, though, I can't
say how useful that is as an educational action.

9: Pick a destination

Do you want to run a team of your own? Become an independent contractor? Teach programming
classes? Speak at conferences? Move up into higher management and get out of the programming
game altogether? Everybody's got a different idea of what they consider to be the
"ideal" career, but it's amazing how many people don't really think about
what they want their career path to be.

A wise man once said, "The journey of a thousand miles begins with a single step."
I disagree: The journey of a thousand miles begins with the damn map. You have to
know where you want to go, and a rough idea of how to get there, before you can really
start with that single step. Otherwise, you're just wandering, which in itself isn't
a bad thing, but isn't going to get you to a destination except by random chance.
(Sometimes that's not a bad result, but at least then you're openly admitting that
you're leaving your career in the hands of chance. If you're OK with that, skip to
the next item. If you're not, read on.)

Lay out explicitly (as in, write it down someplace) what kind of job you're wanting
to grow into, and then lay out a couple of scenarios that move you closer towards
that goal. Can you grow within the company you're in? (Have others been able to?)
Do you need to quit and strike out on your own? Do you want to lead a team of your
own? (Are there new projects coming in to the company that you could put yourself
forward as a potential tech lead?) And so on.

Once you've identified the destination, now you can start thinking about steps to
get there.

If you want to become a speaker, put your name forward to give some presentations
at the local technology user group, or volunteer to hold a "brown bag" session
at the company. Sign up with Toastmasters to hone your speaking technique. Watch other
speakers give technical talks, and see what they do that you don't, and vice versa.

If you want to be a tech lead, start by quietly assisting other members of the team
get their work done. Help them debug thorny problems. Answer questions they have.
Offer yourself up as a resource for dealing with hard problems.

If you want to slowly move up the management chain, look to get into the project management
side of things. Offer to be a point of contact for the users. Learn the business better.
Sit down next to one of your users and watch their interaction with the existing software,
and try to see the system from their point of view.

And so on.

8: Be a bell curve

Frequently, at conferences, attendees ask me how I got to know so much on so many
things. In some ways, I'm reminded of the story of a world-famous concert pianist
giving a concert at Carnegie Hall—when a gushing fan said, "I'd give my life
to be able to play like that", the pianist responded quietly, "I did".
But as much as I'd like to leave you with the impression that I've dedicated my entire
life to knowing everything I could about this industry, that would be something of
a lie. The truth is, I don't know anywhere near as much as I'd like, and I'm always
poking my head into new areas. Thank God for my ADD, that's all I can say on that
one.

For the rest of you, though, that's not feasible, and not really practical, particularly
since I have an advantage that the "working" programmer doesn't—I have set
aside weeks or months in which to do nothing more than study a new technology or language.

Back in the early days of my career, though, when I was holding down the 9-to-5, I
was a Windows/C++ programmer. I was working with the Borland C++ compiler and its
associated framework, the ObjectWindows Library (OWL), extending and maintaining applications
written in it. One contracting client wanted me to work with Microsoft MFC instead
of OWL. Another one was storing data into a relational database using ODBC. And so
on. Slowly, over time, I built up a "bell curve"-looking collection of skills
that sort of "hovered" around the central position of C++/Windows.

Then, one day, a buddy of mine mentioned the team on which he was a project manager
was looking for new blood. They were doing web applications, something with which
I had zero experience—this was completely outside of my bell curve. HTML, HTTP, Cold
Fusion, NetDynamics (an early Java app server), this was way out of my range, though
at least NetDynamics was a little similar, since it was basically a server-side
application framework, and I had some experience with app frameworks from my C++ days.
So, resting on my C++ experience, I started flirting with Java, and so on.

Before long, my "bell curve" had been readjusted to have Java more or less
at its center, and I found that experience in C++ still worked out here—what I knew
about ODBC turned out to be incredibly useful in understanding JDBC, what I knew about
DLLs from Windows turned out to be helpful in understanding Java's dynamic loading
model, and of course syntactically Java looked a lot like C++ even though it behaved
a little bit differently under the hood. (One article author suggested that Java was
closer to Smalltalk than C++, and that prompted me to briefly flirt with Smalltalk
before I concluded said author was out of his frakking mind.)

All of this happened over roughly a three-year period, by the way.

The point here is that you won't be able to assimilate the entire industry in a single
sitting, so pick something that's relatively close to what you already know, and use
your experience as a springboard to learn something that's new, yet possibly-if-not-probably
useful to your current job. You don't have to be a deep expert in it, and the further
away it is from what you do, the less you really need to know about it (hence the
bell curve metaphor), but you're still exposing yourself to new ideas and new concepts
and new tools/technologies that still could be applicable to what you do on a daily
basis. Over time the "center" of your bell curve may drift away from what
you've done to include new things, and that's OK.

7: Learn one new thing every year

In the last tip, I told you to branch out slowly from what you know. In this tip,
I'm telling you to go throw a dart at something entirely unfamiliar to you and learn
it. Yes, I realize this sounds contradictory. It's because those who stick to only
what they know end up missing the radical shifts of direction that the industry hits
every half-decade or so until it's mainstream and commonplace and "everybody's
doing it".

In their amazing book "The Pragmatic Programmer", Dave Thomas and Andy Hunt
suggest that you learn one new programming language every year. I'm going to amend
that somewhat—not because there aren't enough languages in the world to keep you on
that pace for the rest of your life—far from it, if that's what you want, go learn
Ruby, F#, Scala, Groovy, Clojure, Icon, Io, Erlang, Haskell and Smalltalk, then come
back to me for the list for 2020—but because languages aren't the only thing that
we as developers need to explore. There's a lot of movement going on in areas beyond
languages, and you don't want to be the last kid on the block to know they're happening.

Consider this list: object databases (db4o)
and/or the "NoSQL" movement (MongoDB).
Dependency injection and composable architectures (Spring, MEF).
A dynamic language (Ruby, Python, ECMAScript).
A functional language (F#, Scala, Haskell).
A Lisp (Common Lisp, Clojure, Scheme,
Nu). A mobile platform (iPhone, Android). "Space"-based architecture (Gigaspaces,
Terracotta). Rich UI platforms (Flash/Flex, Silverlight). Browser enhancements (AJAX,
jQuery, HTML 5) and how they're different from the rich UI platforms. And this is
without adding any of the "obvious" stuff, like Cloud, to the list.

(I'm not convinced Cloud is something worth learning this year, anyway.)

You get through that list, you're operating outside of your comfort zone, and chances
are, your boss' comfort zone, which puts you into the enviable position of being somebody
who can advise him around those technologies. DO NOT TAKE THIS TO MEAN YOU MUST
KNOW THEM DEEPLY. Just having a passing familiarity with them can be enough. DO
NOT TAKE THIS TO MEAN YOU SHOULD PROPOSE USING THEM ON THE NEXT PROJECT. In fact,
sometimes the most compelling evidence that you really know where and when they should
be used is when you suggest stealing ideas from the thing, rather than trying to force-fit
the thing onto the project as a whole.

6: Practice, practice, practice

Speaking of the concert pianist, somebody once asked him how to get to Carnegie Hall.
HIs answer: "Practice, my boy, practice."

The same is true here. You're not going to get to be a better developer without practice.
Volunteer some time—even if it's just an hour a week—on an open-source project, or
start one of your own. Heck, it doesn't even have to be an "open source"
project—just create some requirements of your own, solve a problem that a family member
is having, or rewrite the project you're on as an interesting side-project. Do the
Nike thing and "Just do it". Write some Scala code. Write some F# code.
Once you're past "hello world", write the Scala code to use db4o as a persistent
storage. Wire it up behind Tapestry. Or write straight servlets in Scala. And so on.

5: Turn off the TV

Speaking of marketing slogans, if you're like most Americans, surveys have shown that
you watch about four hours of TV a day, or 28 hours of TV a week. In that same amount
of time (28 hours over 1 week), you could read the entire set of poems by Maya Angelou,
one F. Scott Fitzgerald novel, all poems by T.S.Eliot, 2 plays by Thornton Wilder,
or all 150 Psalms of the Bible. An average reader, reading just one hour a day, can
finish an "average-sized" book (let's assume about the size of a novel)
in a week, which translates to 52 books a year.

Let's assume a technical book is going to take slightly longer, since it's a bit deeper
in concept and requires you to spend some time experimenting and typing in code; let's
assume that reading and going through the exercises of an average technical book will
require 4 weeks (a month) instead of just one week. That's 12 new tools/languages/frameworks/ideas
you'd be learning per year.

All because you stopped watching David Caruso turn to the camera, whip his sunglasses
off and say something stupid. (I guess it's not his fault; CSI:Miami is a
crap show. The other two are actually not bad, but Miami just makes me retch.)

After all, when's the last time that David Caruso or the rest of that show did anything
that was even remotely realistic from a computer perspective? (I always laugh out
loud every time they run a database search against some national database on a completely
non-indexable criteria—like a partial license plate number—and it comes back in seconds.
What the hell database are THEY using? I want it!) Soon as you hear The Who break
into that riff, flip off the TV (or set it to mute) and pick up the book on the nightstand
and boost your career. (And hopefully sink Caruso's.)

Or, if you just can't give up your weekly dose of Caruso, then put the book in the
bathroom. Think about it—how much time do you spend in there a week?

And this gets even better when you get a Kindle or other e-reader that accepts PDFs,
or the book you're interested in is natively supported in the e-readers' format. Now
you have it with you for lunch, waiting at dinner for your food to arrive, or while
you're sitting guard on your 10-year-old so he doesn't sneak out of his room after
his bedtime to play more XBox.

4: Have a life

Speaking of XBox, don't slave your life to work. Pursue other things. Scientists have
repeatedly discovered that exercise helps keep the mind in shape, so take a couple
of hours a week (buh-bye, American Idol) and go get some exercise. Pick up
a new sport you've never played before, or just go work out at the gym. (This year
I'm doing Hopkido and fencing.) Read some nontechnical books. (I recommend anything
by Malcolm Gladwell as a starting point.) Spend time with your family, if you have
one—mine spends at least six or seven hours a week playing "family games"
like Settlers
of Catan, Dominion, To
Court The King, Munchkin,
and other non-traditional games, usually over lunch or dinner. I also belong to an
informal "Game Night club" in Redmond consisting of several Microsoft employees
and their families, as well as outsiders. And so on. Heck, go to a local bar and watch
the game, and you'll meet some really interesting people. And some boring people,
too, but you don't have to talk to them during the next game if you don't want.

This isn't just about maintaining a healthy work-life balance—it's also about having
interests that other people can latch on to, qualities that will make you more "human"
and more interesting as a person, and make you more attractive and "connectable"
and stand out better in their mind when they hear that somebody they know is looking
for a software developer. This will also help you connect better with your users,
because like it or not, they do not get your puns involving Klingon. (Besides,
the geek stereotype is SO 90's, and it's time we let the world know that.)

Besides, you never know when having some depth in other areas—philosophy, music, art,
physics, sports, whatever—will help you create an analogy that will explain some thorny
computer science concept to a non-technical person and get past a communication roadblock.

3: Practice on a cadaver

Long before they scrub up for their first surgery on a human, medical students practice
on dead bodies. It's grisly, it's not something we really want to think about, but
when you're the one going under the general anesthesia, would you rather see the surgeon
flipping through the "How-To" manual, "just to refresh himself"?

Diagnosing and debugging a software system can be a hugely puzzling trial, largely
because there are so many possible "moving parts" that are creating the
problem. Compound that with certain bugs that only appear when multiple users are
interacting at the same time, and you've got a recipe for disaster when a production
bug suddenly threatens to jeopardize the company's online revenue stream. Do you really
want to be sitting in the production center, flipping through "How-To"'s
and FAQs online while your boss looks on and your CEO is counting every minute by
the thousands of dollars?

Take a tip from the med student: long before the thing goes into production, introduce
a bug, deploy the code into a virtual machine, then hand it over to a buddy and let
him try to track it down. Have him do the same for you. Or if you can't find a buddy
to help you, do it to yourself (but try not to cheat or let your knowledge of where
the bug is color your reactions). How do you know the bug is there? Once you know
it's there, how do you determine what kind of bug it is? Where do you start looking
for it? How would you track it down without attaching a debugger or otherwise disrupting
the system's operations? (Remember, we can't always just attach an IDE and step through
the code on a production server.) How do you patch the running system? And so on.

Remember, you can either learn these things under controlled circumstances, learn
them while you're in the "hot seat", so to speak, or not learn them at all
and see how long the company keeps you around.

2: Administer the system

Take off your developer hat for a while—a week, a month, a quarter, whatever—and be
one of those thankless folks who have to keep the system running. Wear the pager that
goes off at 3AM when a server goes down. Stay all night doing one of those "server
upgrades" that have to be done in the middle of the night because the system
can't be upgraded while users are using it. Answer the phones or chat requests of
those hapless users who can't figure out why they can't find the record they just
entered into the system, and after a half-hour of thinking it must be a bug, ask them
if they remembered to check the "Save this record" checkbox on the UI (which
had to be there because the developers were told it had to be there) before submitting
the form. Try adding a user. Try removing a user. Try changing the user's password.
Learn what a real joy having seven different properties/XML/configuration files scattered
all over the system really is.

Once you've done that, particularly on a system that you built and tossed over the
fence into production and thought that was the end of it, you'll understand just why
it's so important to keep the system administrators in mind when you're building a
system for production. And why it's critical to be able to have a system that tells
you when it's down, instead of having to go hunting up the answer when a VP tells
you it is (usually because he's just gotten an outage message from a customer or client).

1: Cultivate a peer group

Yes, you can join an online forum, ask questions, answer questions, and learn that
way, but that's a poor substitute for physical human contact once in a while. Like
it or not, various sociological and psychological studies confirm that a "connection"
is really still best made when eyeballs meet flesh. (The "disassociative"
nature of email is what makes it so easy to be rude or flamboyant or downright violent
in email when we would never say such things in person.) Go to conferences, join a
user group, even start one of your own if you can't find one. Yes, the online avenues
are still open to you—read blogs, join mailing lists or newsgroups—but don't lose
sight of human-to-human contact.

While we're at it, don't create a peer group of people that all look to you for answers—as
flattering as that feels, and as much as we do learn by providing answers, frequently
we rise (or fall) to the level of our peers—have at least one peer group that's overwhelmingly
smarter than you, and as scary as it might be, venture to offer an answer or two to
that group when a question comes up. You don't have to be right—in fact, it's often
vastly more educational to be wrong. Just maintain an attitude that says "I have
no ego wrapped up in being right or wrong", and take the entire experience as
a learning opportunity.

---

Enterprise consulting, mentoring or instruction. Java, C++, .NET or XML services.
1-day or multi-day workshops available. Contact
me for details.