Stack Overflow is an amazing resource for computer programmers. I've asked a lot of questions there, and answered a lot of questions there, and I've found the answers to lots and lots of questions that someone else has already asked. Participating in Stack Overflow has been great.

However, there have been a few cases where I've asked a question in this form:

I need some code that will [...]. Can someone point me to some existing code that does this?

And then I have received responses and comments like these:

We aren't here to do your homework for you.

You can't expect help without doing a little bit of work on your own.

You mean "Plez sir send me the codez?"

I don't understand why my questions provoke these responses. It is possible that I am asking the question in a way that the readers interpret as demanding or rude. But I also wonder if some people think that looking for existing code to solve a problem is a dishonorable thing to do, and Real Programmers write everything they need from scratch.

What if I had asked this:

I am new to C. I need to format some printed output in my C program. What's the easiest way to do this?

I hope someone would respond with

There is a standard function called "printf()" that will do what you want.

and not

Why can't you just figure out how to write your own formatting function It's the best way to learn C. Or are you just too lazy to spend time learning things?

Appropriate reuse of already written and debugged code is the mark of a professional, and time spent in research of existing implementations of algorithms you need is time well invested. If you want to write the millionth from-scratch implementation of Quicksort in your favorite programming language, go right ahead, but those of us who have real work to do are going to look for a library or a code snippet.

I often wonder how kids today get into programming. When I was a kid, and got my first computer, I spent a lot of time typing in the programs from David Ahl's BASIC Computer Games. After typing in the code for the games and playing them a bit, I'd start changing them. Eventually, I got into 6502 assembly language and higher-level programming languages, but that early exposure to a bunch of simple BASIC programs is what got me started as a coder.

Today, kids are surrounded by programmable computers, but few of them learn how to write code. Most kids are no more interested in programming a computer than they would be in rebuilding a car's engine. I don't see a lot of simple projects like those in Ahl's book that they can play with and start hacking on. How does a kid get started?

There are programming environments that are intended to teach kids programming (Scratch, Alice, etc.). But use of those is not widespread, and I question their usefulness. All the good programmers I know started with something primitive, like BASIC, Fortran, Perl, or command.com. I wonder if somebody can really learn how computers work by working with fancy 3D "authoring environments" like Alice and Squeak.

It's occurred to me that web applications might be one way to get into programming. Web browsers are as ubiquitous as BASIC was in the 80's. It's relatively easy for a kid to set up a web site with Drupal or some other off-the-shelf CMS, and then start customizing it. All they need is Notepad and an Internet connection. They learn a little CSS here, a little JavaScript there, and pretty soon they'd rather be coding than playing games.

Is there a web-app equivalent to BASIC Computer Games? If not, there should be.

Early in my career, I prided myself on my ability to absorb a lot of information and stay up-to-date on programming tools and techniques. I learned C++ before any of my colleagues did, and knew more about its intricacies than they did. I implemented ActiveX control containers before most people knew what "ActiveX" or "COM" was. I dug into CORBA. I played around with Java 1.0.

In short, I liked being an expert on new stuff. I enjoyed being on the bleeding edge. I liked being able to answer everyone's questions.

However, now I find myself on the other side of things. I'm bringing myself up to speed on some relatively "old" stuff: Java, JavaScript, and Cascading Style Sheets (CSS). It sometimes feels like I'm the only person who doesn't already know this stuff, and I'm not comfortable being the newbie.

There are benefits to jumping on the bandwagon late. For example, JavaScript actually works now, and most people have browsers with decent implementations of DOM and CSS. A lot of that J2EE silliness has quietly faded away. I can take advantage of lots of libraries written by experienced people, and there are plenty of people who can answer my questions.

Still, I'm nagged by the feeling that I'm behind, and won't ever be able to be one of the foremost experts or significant contributors to the communities. Maybe someday I'll be mature enough to accept that, but I'm not there yet.

There's a new programming language out there: Go. There are lots of ways to describe it, but basically it's got Python-esque syntax and C++-esque performance. It's statically typed, but is designed to feel more like a dynamic language. It has garbage collection.

Based on its pedigree, I expect this to be a lot more successful than the various other languages intended to be successors to C++. Play with it while it's still cool, before it starts to suck.

Sorry, Windows programmers, but only Linux and Mac OS X are supported for now. But I'm sure Windows programmers won't mind; to them, "new programming language" means "C# 4.0".

This is a quote I like:

The really good programmers spend a lot of time programming. I haven't seen very good programmers who don't spend a lot of time programming. If I don't program for two or three days, I need to do it. And you get better at it—you get quicker at it. The side effect of writing all this other stuff is that when you get to doing ordinary problems, you can do them very quickly.

That's from Joe Armstrong, creator of Erlang, in Peter Seibel's Coders at Work (which, by the way, every programmer should read).

This jibes with what I've seen over the years. Really good programmers don't treat coding as a nine-to-five job. It's something they want to do whether they are being paid for it or not.

A very easy way to weed out bad candidates when interviewing is to ask them about their personal programming projects. If they don't have any, then I'm pretty sure I don't want to work with them.

In this respect, programming is little different from other creative pursuits. You become a good writer by writing a lot; you become a good sculptor by sculpting a lot; you become a good musician by playing music a lot.

So go out there and write some code. That's what I'm about to do.

While working on an iPhone application, I decided I wanted to change the colors of the background and section headers of a UITableView with the UITableViewStyleGrouped style. It took a lot more work than I expected, so I'm sharing what I learned with anyone else who needs to do this.

My Menubar Countdown application uses an NSStatusItem to display itself in the menu bar. I recently had to add a custom view to that status item, and thought I'd share what I learned about the process here.

While learning about Core Animation, I was disappointed to find that it is plagued by the anti-pattern that I call the Overly Generic Interface.

Either I’m stupid, or Apple’s developer documentation sucks. Whenever I try to enter a new area of Cocoa development, I am presented with simplistic tutorials and detailed reference information, with little in between to bridge the gap between newbie and expert. Often, the only way to learn an API is to hack on the example programs until enlightenment occurs, or do a lot of Googling.

This is exactly what happened with Core Animation. Most OS X developers don't need to know much about Core Animation, as it is a relatively new feature of OS X, and Mac users don't expect fancy animations in every application's UI. However, on iPhone, users do expect things to bounce and zip around the screen, so an iPhone developer really needs to know this stuff.

I started reading Apple’s Core Animation Programming Guide several times, and each time, I got lost in Chapter 2. Skipping forward to subsequent chapters didn't get me anywhere. I was presented with architectural diagrams and abstract discussions of geometry and transforms and layers and timing and so forth, but there was nothing concrete that I could grasp.

Bill Dudney’s Core Animation for Mac OS X and the iPhone filled in the gaps perfectly. It doesn't contain much information that is not in Apple's docs, but it presents it in a way that makes sense to me. Dudney leads you by the hand through actual working code that does cool stuff. After reading this book, I now understand what Apple was trying to tell me in the Core Animation Programming Guide.

I read the PDF-formatted version. I also tried reading the epub-formatted version using Stanza on the iPhone, but that didn't work so well: the diagrams and code examples aren't readable. So I recommend sticking to the PDF or paper formats.

My only gripe is that I'd like to see more iPhone-specific information. The majority of the book covers Core Animation on OS X, and then there is a single chapter at the end about the iPhone. I would prefer to have an iPhone-centric book with an oh-by-the-way-this-works-on-OS-X-too chapter. But that's a minor quibble; I think I understand the material well enough now that I can learn the iPhone-specific aspects of Core Animation on my own.

Most programmers know that having functions with too many parameters can be confusing. However, fixing such problems requires some intelligence. A programmer once saw some code like this:

SetObjectParams(obj, foo, bar, baz, quux, xyzzy, abra, cadabra, hocus, pocus, presto, shazam);


Finding a stylistic rule somewhere that said a function should have no more than five parameters, the programmer “refactored” it to this:

SetObjectParams1(obj, foo, bar, baz, quux);
SetObjectParams2(obj, xyzzy, abra, cadabra, hocus);
SetObjectParams3(obj, pocus, presto, shazam);


No, that's not how one resolves this problem. You fix this problem by defining functions that each do something simple, give each function a name that describes what it does, and let them take however many parameters make sense.