Just a quick note to let you know about the launch of Programmer Puzzlers, a new site with logic, coding and math puzzles designed for programmers.  Stretch your mind, have fun, challenge your friends or gear up for an interview.

The first puzzle, Burning Ropes, is already up, but a new puzzle is published every week.  So if you’re interested in solving puzzles, be sure to subscribe to Programmer Puzzlers via RSS or email.

You can also submit your own puzzler here.

One day a developer started at a company and on his first day, while setting up his development environment, pulled out a memory stick.  It contained all the old code he had written at previous companies, so he could write code more quickly, he proudly proclaimed.

Aside from the fact that it’s illegal and unethical, it’s also stupid.

Code that is not being actively maintained and refactored degenerates quickly.  So instead of his output improving and learning new and better ways of doing things, it actually is getting worse over time.

Short-cut thinking sabotages software projects.

More and more developers are content to write bad code and build crappy software products.  We’d like to blame it on the managers and the companies that push us to produce more on shorter schedules.

“I’d love to do automated testing or TDD, but they just don’t give us time to do that.”

Automated testing and TDD are part of coding, not a separate activity.  When you deliver a software product, or even just a snippet of code, you’re putting your signature on it that it works.  Automated testing and TDD are not optional to the company, they are optional for you.

If you are truly confident that you are shipping quality code without them, then maybe they’re not needed.  But don’t push the decision off to the (usually non-technical) manager.  He may not explicitly give you time to do “automated testing” but he sure as hell expects the thing to work properly.

“I know this is a hack, but they said we just need to get it working right now, and we can come back to it later.”

If this is the mentality at your company, how many times do you actually get downtime to go refactor and improve your code?  Rushing and hacking and crunch-time just begets more rushing and hacking and crunch-time.  The more you rush, and skip good design and quality practices, the worse your code will be.  You’ll introduce more bugs and more unnecessary complexity.  That will delay your schedule even more, resulting in … more crunch-time.

It’s a vicious cycle that we as developers are not only complicit in, but actually cause by producing poor quality code.

“This code isn’t very important so it doesn’t need to have a good design”

What would happen if this code doesn’t work correctly?  If the answer is “not much”, they you should probably go work on something else.  If the answer is “a whole lot” (it probably is) then do it right.

Writing bad code is viral.

• If you write bad code on certain parts of the codebase, it will become a habit and it’ll start to bleed over into all of your coding.
• It’s the broken window syndrome: if some parts of the code are written poorly, there is less impetus to write better code in the other parts.
• Your code base is the primary training manual for new developers on your team.  If they’re learning from crappy code, that’s how they will write code too.
• Letting bad programmers onto your team can actually have a negative productivity impact.  More diligent team members will spend time fixing their crappy code, and other programmers will fall into the crappy code slump alongside them.

If the code is important enough to be written, then it’s important enough to be written correctly.

How has the bad code virus spread in your software team?  Have you been infected?  Got any natural remedies to suggest?

I have a guest post up at Remarkablogger today about the great response to the Code Anthem blog in our first month from you fine folks.  It’s a good read for anyone interested in blogging, start-ups or general movement-starting activities.  Or if you just want a meta-post about what’s going on behind-the-scenes here at Code Anthem (on the blog/marketing side, at least).

“I am in the process of launching my startup, Code Anthem, for great programmers and the companies that hire them. I was thinking over some of the logistics of running a private beta program and realized that I needed a group of people who could be my beta testers, early adopters and even evangelists when we launched.

I decided to start a blog and open a twitter account. That was 1 month ago, and since then I’ve had over 50K visitors to the blog, over 500 subscribers via RSS and email, 221 comments and over 150 Twitter followers. I didn’t have an existing audience of any kind to pull from, so this was all starting from zero.”

Read more >