Specialize in Something Relevant

generalist: a person competent in several different fields or activities

If you read my blog entry on Language Specialization you might have concluded that I prefer generalists. If, in our industry, generalists were what the definition describes, then I would prefer generalists. Unfortunately, business software developers seem to have created their own definition of generalist.

business software developing generalist: I know how to do the simplest tasks with many different languages/tools, but I can not be considered competent with any of them.

I blame Scott Ambler. To me anyway, it seems like the daft generalist movement started when Scott wrote Generalizing Specialists.

Our industry has always been saturated by bad programmers. I'm on record stating that at least 50% of the people writing business software should find a new profession. The problem with bad developers is that they take good ideas and turn them in to monstrosities.

I remember reading Generalizing Specialists and being inspired. I thought Scott gave fantastic and relevant advice. Unfortunately, many bad or junior developers heard: Don't bother to deeply understand anything, instead, you're agile if you know a little about everything. Suddenly, when I started interviewing developers I ran into situations like this.

• me: So, I see you have Erlang on your resume, how do you like the language?
• candidate: I like it's concurrency handling, but I'm a bit weary of it's syntax.
• me: (thinking - okay, do you have any original thoughts on Erlang?) I can understand those points of view, what problem were you trying to solve with Erlang and why did you think it was the right tool?
• candidate: Oh, I really only got through the 2 minute tutorial, you know, hello world basically. But if you guys have Erlang projects you want me to work on I'm happy to, I'm a generalist, I like all languages.
• me: Okay, so what language would you say you know the most about?
• candidate: I don't bother to specialize, I do a little bit with each language, you know, hello world or whatever, so I can use the right tool for the job. That's the best part of being a generalist.
• me: (thinking - this interview is already over) Okay, so tell me about the languages/tools you've had to use at your different jobs?

Inevitably, the candidate doesn't even have a deep understanding of the tools they've used at work, because they are too busy doing hello world in every language invented. They also love to say that they take the Pragmatic Programmers advice to extreme and 'learn' several languages a year.

The truth is, these generalists have little in the way of valuable knowledge. They provide their projects with little more knowledge than a Google search can bestow in 30 minutes. In short, they're worthless, if not destructive.

I don't actually blame Scott Ambler. In my opinion he was right then, and he's right now. Become a Generalizing Specialist is still the advice that I currently give developers.

Specializing in something makes you an asset to the team. If I'm building a Web 2.0 website, I want everyone to have an understanding of HTML, CSS, Javascript, Ruby, & SQL. However, I also want each team member to specialize in one of those areas. Knowing IE quirks is just as important as knowing how to optimize MySQL. And, I want to make sure I have team members that can get into the deep, dark corners of delivering highly effective software. That doesn't mean everyone needs to know what a straight join in MySQL does, but at least 1 person should. The rest of the team isn't entirely off the hook though, they better understand how to write basic SQL statements that are maintainable and at least semi-performant.

Becoming a Generalizing Specialist takes time, but the first step is becoming a Specialist. Once you deeply understand one language/tool, you can move on to the next relevant language/tool. How do you know when it's time to move on? When you start having answers to questions that people aren't asking. If you're constantly looking up answers to common questions, you aren't a specialist. However, if you start providing more (relevant) detail in your answers than people are looking for, you're on your way to possessing the deep understanding that a Specialist should have. At that point, it's probably time to start looking deeply into something else.

One painful mistake to look out for is specializing in something less relevant. If you work for a trading firm that writes only thick client applications, understanding why Chrome's Javascript VM is better than Firefox's Javascript VM is probably not the best use of your time. It's true that you may move on to a web application at some point, but by then your information will probably have become stale anyway. Stick to specializing in things that you work with day to day. Your language, your IDE, the Domain Specific Languages you use in your applications (regular expressions, SQL, LINQ, etc), or the frameworks you use (Spring, ASP.net, etc) are things you should specialize in to increase the value you provide to your team.

Eventually, you become competent with several different tools and languages. You've become a Generalizing Specialist and as such you are significantly more valuable to your team.

Language Specialization

Didn't you just totally sell out? -- Obie Fernandez @ Rails Summit Latin America

Obie and I are good friends. He wasn't trying to insult me. I was talking about how much I liked my new job (at DRW Trading), and the different aspects of the job. One aspect of my job is that I spend a fair amount of my time working with Java. I do some C# and some Ruby also, but these days it's more Java than anything else. I believe Obie was genuinely curious if I felt like I sold out since I'm not doing Ruby full-time anymore.

It's an interesting question, but it comes packed with all kinds of assumptions. For the question to be valid, I would have had to trade something I truly care about for the combination of something I did and did not like. Luckily, that wasn't the case.

Obie isn't the first person to be surprised that I'm no longer working full-time with Ruby. Truthfully, I find it a bit funny that people think I would base a career move on a language. Ruby is my favorite language, but it's not the correct choice for every problem that needs to be solved. And, languages have never been my primary concern when deciding what job to take.

My first job primarily used Cold Fusion. When I joined AOL Time Warner I gave up Cold Fusion for PHP. When I joined IAG I gave up PHP for C#. And so on. As you can see, I've never been too tied to a language. I've always been most interested in learning and growing. I love jobs that help me improve my skills.

Chad Fowler talks about something similar. In the section "Don’t Put All Your Eggs in Someone Else’s Basket" of My Job Went to India, Chad says the following:

While managing an application development group, I once asked one of my employees, “What do you want to do with your career? What do you want to be?” I was terribly disppointed by his answer: “I want to be a J2EE architect.” ...

This guy wanted to build his career around a specific technology created by a specific company of which he was not an employee. What if the company goes out of business? What if it let its now-sexy technology become obsolete? Why would you want to trust a technology company with your career?

I think Chad got it right, but it's not just companies you shouldn't trust. I wouldn't base my career on any technology, whether it was produced by a company or an open source community.

I prefer jobs that allow me to learn new things. Think of it as job security -- I shouldn't ever be out-of-date when it comes to technology experience. Think of it as an investment -- everything I learn creates a broader range of experience that I can leverage for future projects or jobs. Think of it as experimenting -- by trying many different solutions I may find ways to combine them and innovate.

I've turned down several jobs that paid more or offered comfort. I've never regretted it. Your career is long and (as Chad says) you should treat it as a business. When you look at it from that perspective it obviously makes sense to spend the early years learning and deciding which is the best direction to take.

The truth is, if you focus on one technology you'll never be as good as your teammates who have more experience mixing technologies to produce the best solution.

As I told Obie, I definitely don't feel like I sold out. In fact, one of the reasons I joined DRW was because they use Java. I've never worked with Java, messaging, or the financial domain. Having experience with those 3 things will make me better. And, diversifying your experience will make you better as well.

When To Retire Your Brand

Building a brand takes a lot of effort, but I think the payoff justifies the investment. Having a strong brand definitely helped me find a fun and very well paying job. So now that I have a dream job (@ DRW Trading), what should I do with my brand?

I have to confess, I didn't start writing because I wanted share information. I started writing because I wanted to build a big brand, find a great job, and enjoy life. Somewhere along the way I began to enjoy writing and the positive results that came from knowledge sharing. Someone once said to me "I write better tests because of your blog". Obviously I was happy to hear that kind of feedback. At the same time it wasn't the reason I got started down this path.

I love to program. I also love to be in shape (which I'm not) and learn other languages (which I haven't been doing lately).

Now that I have my dream job, I've been spending more time doing the other things I love. Unfortunately, I found that between learning an interesting domain, going to the gym, and learning Italian, there's not much time left for blogging. I also find that since I'm doing all the things I love, I don't really like to be away presenting at conferences.

I thought it might be time to declare success on the brand building project, and move on to new pursuits... But, I was wrong.

The largest reason I can't quit writing and presenting is that I enjoy giving back to the community. Seeing a blog entry get 8,000 hits in one day causes an amazing feeling. Giving a presentation and getting feedback that says "Probably the best presentation at the conference" definitely makes you feel good about what you are doing. Seeing an idea become committed as the way to do something will definitely make you smile. I truly enjoy spreading ideas (or at least attempting to spread ideas) that help the community evolve.

Blogging and presenting also help me personally improve. The easiest way to get feedback on something is to put it out there. I considered several of my testing ideas to be "the right way" for far too long. Putting them down as blog entries resulted in further evolution of the ideas as well as a greater understanding of how context determines the correct approach. Simply writing about my ideas improves them. One thing we aren't short of is people to tell you you're wrong.

Your brand is also valuable to your employer. Employing people with name recognition improves your organization's ability to recruit talented new hires. This also directly benefits you, since you'll be given the opportunity to work with more talented teammates. At the moment, DRW is looking to hire the absolute best people in the industry. I wish I had an even stronger brand, so I could help attract the top talent.

Ultimately I came to the conclusion that building a brand is a career long activity. You can stop at any time, but getting that free time back comes at cost to your profession.

Be Your Start-Up

It's impossible not to ponder striking it rich at a start up, but there's another alternative if you're looking to make some good money -- build your brand.

In January of 2005 I created a blog. I truly can't remember why I created it, but I do remember that I was making $60,000 a year. Then in February I joined ThoughtWorks and my blog became part of blogs.thoughtworks.com. I had instant readership, but not a lot to say.

Two and a half years and a lot of blog posts later I turned down an offer that was $174,000 a year. This wasn't $174,000 a year because the work sucks. It was a good job, but I wasn't ready to leave ThoughtWorks. It's been a year since then, and I know it was the right decision.

Now, I didn't make millions, but tripling your salary in two and a half years is still quite nice. There's no question that my brand was responsible for my ever increasing salary requirements. In fact, when I was interviewing two of the three interviewers started their interviews with "I read your material, you've got exactly what we need here. So why don't you ask me the questions instead". My brand had already gotten me the job.

Building a brand isn't as hard as you might think. There's really only 3 things you need to focus on.

• Writing
• Presenting
• Contributing

If you do all three of those, you'll have a brand in no time.

But, before you do those three things, you'll need to read two books that will give you the proper guidance.

• The Pragmatic Programmer
• My Job Went to India

note: both books are required reading whether you are building a brand or not.

Once you have the requisite reading covered it's time to make your mark.

Writing
Writing isn't hard. Writing well is hard, but you're a programmer, so you needn't worry about that. No one expects you to be a good writer, they're happy if you are, but they're forgiving if you're not. Don't use your poor writing skills as an excuse not to write.

Don't know what to write about? The answers are all around you. Anything you do that's interesting, there's 100 people searching Google for how to do it. Any question a colleague asks you, someone is searching Google for the same answer. Anything that's valuable to you... yes, someone is googling for it.

Take the time to write the answer in a blog entry. People will remember if your blog consistently shows up in their Google searches.

Create a blog. Blogger is free and definitely good enough. Here's a few thoughts on blogging.

• Don't roll your own, you don't need the maintenance headache.
• Name it something simple, but be sure to include your name. Disco Stu's Ramblings is funny, but you want to build your brand, not Disco Stu's.
• Buy your name as a domain and put the blog as a directory (I didn't do this correctly). If I had it to do over my blog would be at http://jayfields.com/blog. This is important for Google Page Rank. If you do it the way I did you'll have different page rank for your homepage and your blog. Not the end of the world, but not ideal.
• Keep it focused. If you want to write about programming and gambling, create two different blogs. Also, avoid "Sorry I haven't written in awhile" posts. People aren't dying for your next post. They're subscribed because they want technical content, not stories about how you've been busy remodeling your home.
• Keep blog posts short if possible. Anything over 1500 words is article material. If you can't find somewhere to publish the article, then your blog is fine. But, remember that people don't like reading long blog entries (like this one)

At first, stick to writing blog entries. They're not too hard and don't require as much polish. They also let you start building a catalog of material. Once you have enough similar posts, start rolling them into articles to post on InfoQ or other similar sites. Eventually, if you write enough articles, you can roll them up into a book. It will take years, but so does writing a book from scratch and doing it this way allows you to get constant feedback without any deadline pressure.

Presenting
Of the 3 things you need to do, I think presenting is the hardest to get going with. You aren't likely to pick up a speaking spot at a good conference if no one has heard of you. So, you'll need to rely on your writing to build your brand a bit, then you can present on the topics that you write about. Alternatively, if you create some open source software that generates buzz you can also pick up a few speaking engagements. Getting started is the hardest part, but once you give a few good talks you'll quickly be turning things down because you just can't fit it in your schedule.

If you're serious about speaking I also highly recommend SpeakEasy. I spent two and a half miserable days at SpeakEasy learning how bad I was at public speaking. The experience was priceless. I can't say enough good things about what I learned in those two and a half days.

Contributing
The last suggestion is the easiest. Contribute some open source software. There's so many ways to contribute.

• Pick an existing project that you use and create a patch for an outstanding bug.
• Extract something interesting from your codebase and release it as open source. You don't need millions of adopters. If you create something valuable to 20 people you'll gain 20 people advocating your brand.
• Be the documentation guy. Almost all open source software suffers from poor documentation. Make it your speciality. You'll quickly make friends if you do the work others don't feel like doing.
• Join a mailing list for your favorite open source project and be active. Be the guy that's always willing to help the recent adopters.

I'm sure there's other ways as well. It doesn't matter how you contribute, just get out and start contributing.

Oh, and don't submit patches as disco_stus_brother. You're name is your brand, use it.

Elitist or Optimist

The last few entries have focused more on the industry and leadership than usual. You might find that odd, but the reality is, I write about what I'm doing. When I'm coding in Ruby, you get Ruby entries. When I'm coding in Flex, you get Flex entries. Lately, I've spent more time shaping teams, processes, and individuals -- thus the posts of that nature.

A Scotch Drinker feels I've become Elitist.

I like scotch and scotch drinkers in general, so I gave his/hers entry some thought. You should read the entry if you care, I'm not going to summarize it. But, here's a few quick responses.

• There's no question that I wouldn't have reached my position so quickly if the competition wasn't so weak. That's not a good thing.
• I dropped out of college, to say that I'm implying formal education is required is amusing. In fact, no where in my list of things I look for in a colleague do I mention education. I want talented colleagues, nothing more, nothing less.
• There are plenty of crappy jobs. You know what happens to them when you give them to good developers, they get automated or removed. Giving crappy jobs to crappy programmers is an answer, but not the best one.

While I don't agree with the content of the post, the premise might still be correct.

Elitism is the belief or attitude that those individuals who are considered members of the elite — a select group of people with outstanding personal abilities, intellect, wealth, specialized training or experience, or other distinctive attributes — are those whose views on a matter are to be taken the most seriously or carry the most weight... -- Wikipedia

I can see where the scotch drinker is coming from. My minimum set of requirements might seem like I'm describing the elite. On the other hand, they might just be a good set of minimum requirements.

I think the difference is, I'm not saying we should fire all but a select group or that a select group should run the show. I'm suggesting that the current minimum requirements for being a programmer are disappointingly low and the products that those programmers produce are often terrible.

If you prefer, here's a more politically correct assertion: Any Net Negative Producing Programmer (NNPP) should find a new profession.

Removing the NNPPs doesn't mean that 50% of your colleagues should move on. My last client, TrafficBroker, didn't employ a single programmer that couldn't pass my requirements. They have no need to get rid of anyone. Conversely, my last full time job before ThoughtWorks was staffed with about 80% NNPPs. You're ratio will probably vary, 50% is based on working for ~10 different companies in the last 5 years and discussing my experiences with many friends from ThougthWorks.

As Josh Graham already pointed out, I'm not the first to say this. Yet, I still feel like it's worth brining up. I knew it would generate responses such as the one from scotch drinker, but it's worth taking some criticism. I hope my entry inspires a few more people to be more vocal with the unacceptable state of certain things in our industry.

As an industry we can do better. Every NNPP that finds a new profession helps our industry improve. I'm not looking for a software development elite community. I'm looking for a productive community. That's why my blog posts and presentations range drastically from very beginner to very advanced. I'll write anything that I think is helpful. But, NNPPs are uninterested or unable to improve, and I can't help them.

I'm not elitist, I'm a silly optimist that thinks a simple blog entry can help change an industry.

Civics not Cadillacs

Back when I made $20,000 a year I bought a used Honda Civic. I needed something to get me from point A to point B fairly reliably. I was looking for the best deal given my requirements and I found a Civic that seemed to fit the bill. I had a good advantage as a buyer, I knew what I wanted and I knew approximately what it should cost. The car lasted for several years, and I was always happy with the purchase.

The story could be much different. If I knew less about what I was buying I would have had to rely on someone else. If I ended up relying on someone unqualified I might have ended up with a Cadillac. Cadillacs are fine cars, but on a $20,000 annual salary I did not need the beauty and luxury features of a Cadillac.

The analogy probably breaks down quickly, but the same basic idea applies to business software. Time after time I see developers delivering Cadillacs when Civics would have been acceptable. The business has no idea what the difference in cost is between a Civic and a Cadillac so, as any ignorant customer does, they smile, thank you, and walk away worrying that they got screwed.

Imagine walking 5 miles to work every day while someone is building you a car. You want a Civic, which you think can be built in 2 weeks. Instead, you get a Cadillac in 4 weeks -- at a much higher cost. You'd be upset, and yet this happens in software all the time. Even worse, you might get a Civic in 4 weeks, but it comes with assurances that if you ever want to change the engine or make it a convertible it can be done in 15 minutes. You'd be asking yourself: when did I ever say I wanted a new engine or a convertible? You had to walk 10 miles a day for 2 extra weeks to get your "ultra configurable" Civic.

It's time to fire your mechanic.

This happens a lot with hackers, which is why businesses should employ developers, not hackers. But, this behavior isn't exclusive to hackers. I've seen plenty of developers who prefer to deliver Cadillacs. I know I always appreciate Cadillac software solutions, but I always find myself asking if the business knows the cost of the Cadillac.

The solution is simple: increase collaboration and change the definition of success. Developers should constantly be talking to the business, but they also need to think in terms of business value instead of solution beauty. Successfully delivered applications can be used by the business to make or save money. The amount of money made or saved is often determined by how much collaboration occurred between the developers and the business. High collaboration ensures the business gets the application they expect. The collaboration also ensures the developers understand their impact to the business. If they make or save the company money with their applications, they've succeeded.

Making or saving money, that's why a business employes you -- and that's how you earn your salary.