Recently in Programming Category

These links are collected from The Working Geek's Twitter feed. If you have suggestions for news bits, please mail me at andy@theworkinggeek.com.

• Five ways companies mistreat job seekers (usnews.com)
• Video of @seiden on TV this morning talking about job hunting (jasonseiden.com)
• I'm a guest expert at JavaRanch this week in their jobs discussion forum! (coderanch.com)
• Resume tactics from the grocery checkout lane (theworkinggeek.com)
• I Just Want a Job; Words That Will Crush Any Interview (resumewonders.com)
• Todd Nilson on email openings and closings (talentline411.com)
• "I consider it part of the benefits package for other employees not to have to work with asses." (evilhrlady.blogspot.com)
• Four biggest myths about job references (usnews.com)
• How to boost your career by contributing to open source projects (theworkinggeek.com)
• Today's absurd interview tactic: Intentionally showing up late (askamanager.blogspot.com)
• Two projects for civic-minded student programmers (blog.jonudell.net)
• Gushing review of "Beautiful Teams" (speedofmeme.blogspot.com)
• Max Kanat-Alexander on the Engineer Attitude: "I can solve this problem the right way" (codesimplicity.com)
• If I call to set up an interview, don't ask "Why has it taken you so long to call me" (askamanager.blogspot.com)
• A software project is code delivered at a specific point in time (theworkinggeek.com)

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.

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 TWG readers have suggestions, I'd love to hear them in the comments below. Good luck!

Steve Yegge has posted this rant called "Good Agile, Bad Agile" that I've seen posted a couple of places, and there's over 100 comments on it, and it's just a steaming pile.

It's hard to discuss the article, because Yegge's just painting broad strokes to be outrageous. His saying "Take Pair Programming, for instance. It's one of the more spectacular failures of XP. None of the Agileytes likes to talk about it much, but let's face it: nobody does it." is no different than a bad standup comedian saying "And what is the deal with these bad women drivers?"

The key to his "good agile" is removing the ability to know when a project will be complete as in:

You don't need "war team meetings," and you don't need status reports. You don't need them because people are already incented to do the right things and to work together well.

So the project gets done as fast as it can, but the customer for the project has no idea when that will be.

He calls this the "tyranny of the calendar", and how open source projects don't have them, as if that's an endorsement. That's true that most open source projects don't give dates, and in at least one case, it can be damaging to the project to not be able to have dates. I'm thinking specifically of Perl 6. I regularly get email to the Perl Foundation email address asking when Perl 6 will be done. I don't have an answer. I have customers for Perl 6, publishers wanting to write about Perl 6, etc, and I can tell them nothing more than "I dunno." Those are lost customers.

But Google doesn't need dates, because "Google isn't foolish enough or presumptuous enough to claim to know how long stuff should take." That's because they are big enough that they have that luxury. A late project won't hurt them. How many of us elsewhere can afford to tell a customer that "we'll be done with it when we're done with it?" I count maybe Microsoft, and probably not even them entirely.

For us in the real world, a project is not about a chunk of source code, but a chunk of source code delivered at a specific point in time.