On breadth vs. depth of technical knowledge

May 10, 2009 Career 4 comments

Friday’s posting about balancing the value of learning specific technologies and following technologies you enjoy got Jeffrey Thalhammer thinking about depth vs. breadth of knowledge.

Whenever my colleagues and I discuss our career plans and the job
market, someone always asks me whether to learn programming language
X, or operating system Y, or framework Z. But I like to point out
that time spent learning some new skill is also time not spent
honing the skills you already have. And in my opinion, it is both
more lucrative and more enjoyable to be a master of one craft, than
to be mediocre at several of them.

This is because I’ve noticed that those who are the best in their
chosen fields are always fully employed and highly compensated.
Especially during an economic downturn, employers become more
selective about who they hire. So when they go looking for a
candidate with a particular set of skills, they want to choose the
person who is strongest with those skills — not the person who has
the most different skills. And employers are usually willing to
pay a premium for top-notch talent, if they can find it.

I’ve been on the hiring side of the interview table enough times
to know this. When a job candidate shows me they have mastered one
technology, it also demonstrates to me that they have the potential
to master others. But having partial expertise in many technologies
may only prove that they own a lot of O’Reilly books.
Truly mastering any technology requires a great deal of patience
and dedication, and those traits are far more valuable to the team
than being able to write code in 16 different languages.

Having said all that, I do acknowledge there is a real tradeoff
between the depth and breadth of one’s technical skills. Not all
job candidates are created equal, and it just isn’t possible for
everyone to be the “best” in something. I’m sure there is a
sweet spot where you can optimize your employability, and this
doesn’t mean that you should completely ignore other technologies.
The industry is constantly evolving so you must stay up-to-date,
and learning a little bit about other technologies can give you a
fantastic new perspective on the those you already know well. And
of course, this all assumes that you actually enjoy the technologies
you’re working with. If you don’t enjoy them, then by all means,
go learn some new skills.

But if you do enjoy the technologies you work with, then I urge you
to consider mastering those technologies before going off to learn
some new bag-of-tricks. To be sure, the road to mastery is long
and difficult. It is fraught with frustration and can be boring
at times. But it is also challenging, exciting, and deeply rewarding.
In the end, I believe it will lead you to a much happier and more
prosperous career.

I’d rather be the first-pick candidate for just one position than
the second-pick for several.

Jeff Thalhammer has been specializing in Perl software
development for over 10 years. He is the senior engineer and chief
janitor at Imaginative Software Systems, a small software consultancy
based in San Francisco. Jeff is also the creator of Perl-Critic,
the leading static analysis tool for Perl.

Do I need to learn Microsoft technologies?

May 8, 2009 Ask Andy, Career, Programming 17 comments

In a thread on Stack Overflow, a reader named Andrew finishing his undergrad degree asked:

I notice that the vast majority of companies I’m looking at are strictly Microsoft users, from windows to visual studio. Am I going to be at a disadvantage as most of my experience is unix/linux
development based?

My response included:

Whether or not “most jobs” are using MS technologies, would you WANT to work with MS technologies? If you went and boned up on your .NET and Visual C++ and had to use Windows all day, would that be the kind of job you wanted? If not, then it doesn’t matter if that’s what “most jobs” call for, because those aren’t the jobs for you.

I was taken to task by a reader named Ben Collins (not Ben Collins-Sussman of Google) who said:

I think this is stupendously bad advice. Of course you should bone up on Microsoft technologies. The chances of you making it through a 40-year career in technology without having to work with MS stuff is slim to none.

Ben’s right, you’re likely to have to use Microsoft technologies, if that’s how you want your career to take you. What I think we’re seeing here is the difference in viewpoints between someone like Ben who seems to think primarily in terms of maximum salary and maximum employability, and someone who thinks about the importance of loving what it is that you do for a job.
There’s nothing wrong with wanting to be employable. Nobody who knows Visual Studio or Java is going to have too much of a hard time finding jobs that need those skills. Then again, I flipped burgers at McDonald’s for three years, and McDonald’s is always looking for people, so I’m pretty employable there, too.
To those of us who look at our jobs as more than just a way to make money, it makes little sense to ask about what “most companies” do. We’re more concerned with the joy of working in our chosen part of the tech industry. I’d learn Visual C++ and try to find some joy in working in Windows if it was the only way to support my family, but that’s not the case.
To the fresh college graduates out there, I ask you to not put yourself in the situation where you’re concerned with what is going to give you the maximum salary, or the maximum number of potential job openings. Instead, look at what you want to do, what sparks the excitement in your heart. Optimize for the maximum amount of love for your job, especially as you’re just starting out.
For those grizzled veterans out there who slog through the trenches, working on projects that don’t bring them joy, I ask you to reconsider your career choices. Imagine you’re fresh out of school. What would you love to be doing? Figure out what that is, and work toward it, if only in small steps.
You spend more waking hours on your job than with your spouse. Optimize your career to bring you as much happiness as possible. Life is too short to work in a job you don’t love.

Should I switch jobs to learn better development processes?

April 30, 2009 Ask Andy, Programming, Work life 2 comments

A reader who wishes to remain anonymous wrote to ask:

I’m a programmer from the Philippines. I’m kind of a latebloomer since I didn’t take up Computer Science or a similar course in college, but I learned programming on my own. I tried to save money so I can buy a couple of books (although I would love to read more), so I can continuously learn software design and development. For almost two years now, I’ve been landing jobs in companies that really don’t have good processes for developing quality software. I have recently started a job. I’m not an expert, but I know when legacy applications have been built by engineers that also aim to produce quality software. The applications uses an object-oriented programming language, but all of them looks procedural. I still want to continuously learn and be a good software craftsman someday. Should I leave and apply for another job in which I think there is more potential to learn great software development processes?

Thanks for writing. Let me preface my suggestions with the caveat that they’re from the perspective of a programmer in the United States. I don’t know how applicable they are to business life in the Philippines. You’ll have to look at them through the lens of your own culture and understanding.

First, that you are wanting to improve yourself, to improve your skills, to improve your job prospects, means that you have the drive that will make you a better employee and programmer. Being able to write good software is only half of what it takes. The other half is having the drive to apply those skills day in and day out. (The third half is being able to be part of a team.)

It’s good you have that drive, because it sounds like you’re going to have to do much of the learning you want on your own. I would not rely on an employer to teach those skills to you. If your only reason to leave your current job for another is to learn better software development techniques, think twice. Chances are, the company you go to will have the same problems, perhaps with a different flavor, as your current company.

Instead, keep reading constantly. Read books like The Pragmatic Programmer by Hunt and Thomas, and Code Complete, 2nd ed. by McConnell. Read websites like StackOverflow for comments and ideas on how to be a better programmer. There will be much to sift through, but that’s how it goes.

Apply those skills by working on projects outside of work, preferably open source projects. Working on open source lets you work with other programmers around the world who have the same drive you do. You’ll learn and practice, while creating code that you can bring to your next interview to show as an example of your programming skills.

You may also want to try to bring some of these ideas to work with you. As you learn how to write great documentation, apply it to your daily life at work, even if nobody else in the company does. When you learn about test-first development, use it as your software methodology, even when you’re the only one who does. You’ll have better code, better projects, and people will notice. You’ll be leading by example.

Finally, don’t let the bad code get you down. The world is filled with it, especially at work, and it’s just part of life as a programmer. Consider it a test bed for your refactoring skills.

If other TWL readers have suggestions, I’d love to hear them in the comments below. Good luck!

What can go in a sysadmin’s work portfolio?

April 20, 2009 Ask Andy, Job hunting No comments ,

A portfolio of your work is a great way to show at the job interview that you are able to produce work that the hiring manager wants. Anyone can make claims as to his skills and abilities, but producing tangible evidence of those skills makes it clear, and reduces the risk for the interviewer. Bringing a portfolio also puts you above other candidates who don’t.

For programmers, code samples are the most obvious work product to bring, but what about sysadmins? Jeffery Land writes:

I was curious about what you suggest for a systems administrator to bring in a portfolio? Most of the work revolves around resource management and troubleshooting issues. At the end of the day this pretty much just leaves you with the experience and nothing you can really point to. I’ve been putting together a blog with my experience that I point out to potential employers but that’s pretty much that best I’ve been able to come up with for a sample.

There’s plenty you do that has a trail. I’d start with just about anything you’ve created that gets put on paper:

  • Network diagrams
  • Policy manuals
  • Documentation
  • Checklists
  • Project schedules
  • Training materials
  • Budgets

You can also include electronic files and code:

  • Significant shell scripts
  • Configuration files

Before you snicker at how silly a config file might be, consider the research and care and feeding that goes into it. For example, tuning PostgreSQL’s memory and disk usage can be a huge challenge. My postgresql.conf files at work have been tweaked and tuned and comments explain why different settings are set as they are. Some places have links to pages that give the reasons for each parameter’s value. It shows the history and reasoning behind it all.

One caution, though, is that while these documents and files are great evidence of your skills, they may well be considered confidential by your company. You certainly don’t want to include any proprietary information or passwords in your portfolio. You should plan on leaving your portfolio at the interview, and don’t want to say “I can only leave certain documents.”

Whether or not you can get existing work products, Jeffery’s blog idea is a great one. It allows him an easy way to show that he has experience and know-how, even without a final work product to show. Take a look at his blog entry called “Configuring DNS Zones in Core”, where Jeffrey explains configuration details for DNS under Windows. He’s created a helpful resource out on the net that will likely improve his blog’s Google page rank, and anyone checking him out online can get an idea of his sysadmin skills.

Your portfolio is a powerful selling tool at the interview, and every techie can create one, no matter the type of work she does.

JobCamp wrap-up and 23 Rules For Job Seekers

March 27, 2009 Job hunting 1 comment

Milwaukee JobCamp today was a great success. Over 500 people showed up at Bucketworks, one of my favorite places ever, to meet other job seekers and get advice. Jim Trainor gave a great presentation on job hunting that had standing-room only.

My talk picked a few of the high points out of my upcoming book, which I condensed into my presentation 23 Rules for Job Hunters.

Response was even better than I had hoped for, with at least a dozen people coming to talk to me after my presentation. I met a couple more great people like Angela Harris, trading stories and talking shop until the place closed at 9:00.

If you were at JobCamp today, thanks for stopping by my blog, and I hope you’ll follow my news feed. You can also follow me on Twitter @theworkinggeek.

Beautiful Teams

March 8, 2009 People, Work life No comments

beautiful-teams.gifBeautiful Teams from O’Reilly is going to the printer next week, and I’ve been reading the draft. It’s chock full of interviews and stories and opinions about development teams and what makes them work. If you’re a reader of this blog, then it should be on your list to pick up.

How to get laid off properly

March 7, 2009 Job hunting No comments ,

My friend Casey West got laid off the other day, and he wrote a great blog post about it. Casey’s post tells about how he handled it, and his advice for others in his unfortunate situation. I especially like how he discusses that after a layoff, you are effectively a security risk, so understand the company’s handling of you.

However, I’d like to point out a few things he did right that he didn’t mention.

Don’t argue

When you’re being fired, either as a layoff or for cause, there’s nothing to argue about. Nothing you can say will save your job. There is nothing a manager likes less than having to fire someone. You’re being called into the office as the final step in a long progression. The topic of the conversation is the termination of your employment, not to discuss whether you should be fired or not.

Tell people you’re available

Casey immediately started to let people know he was available for work. Online, that means blogging about it and mentioning it in some online fora. It also means telling family and friends. He didn’t say “Please give me a job,” but he did let people know. Getting the word out is the first step in working your social network for potential leads.

I wish Casey all the best in his hunt for his next job. I’ve worked with him both at a previous company, and on open source projects. He’s a great programmer, and he’s great to work with. His resume is at http://caseywest.com/hire-me/.

Sing from your toes

November 24, 2008 Job hunting No comments

Jason Seiden’s been posting a lot of interview thoughts on his Twitter. Here’s a little video clip on how to interview with emotional impact, also in his blog.



Do your due diligence when researching a company

November 9, 2008 Job hunting 1 comment

Random Manager posts about uncovering disturbing background about a company when researching before pursuing an opportunity:

It may not bother some candidates that a company’s executives are members of a cult that is popular with certain Hollywood celebrities. However, when there is evidence that principles from the cult are being used as management tools within the company, that’s a clear sign to run, not walk, from that opportunity.

While finding out that the company may be run by Operating Thetans makes for a good horror story, the reality doesn’t have to be that creepy to make the research worth your while. When you go researching your potential future employer, I suggest looking for people who are part of the company, and find what they have to say.

Maybe you’ll find a former sysadmin who blogs openly about how things go at the company. What if the IT department is in the middle of political upheaval over whether to move to Oracle or stick with PostgreSQL? Perhaps the company has had trouble hiring developers, and you’ll want to ask about that at the interview.

No matter what you find, or don’t, the potential goldmine of information available about your prospective employer makes some online research well worth the investment of time.

Laurie Ruettimann’s four simple rules

November 9, 2008 Work life No comments

Laurie Ruettimann over at Punk Rock HR has four simple rules to live by:

  1. Don’t be an asshole.
  2. Don’t divert attention away from the mission and vision of the organization.
  3. Don’t cause problems that are bigger than the problem we’re trying to solve.
  4. If you don’t like it, leave.

Beautiful, every single one of them. I’d like to club everyone who posts at anonymous whining sites like jobvent.com with these rules, starting with #2 and #4.