| September 2004 | ||||||
| Sun | Mon | Tue | Wed | Thu | Fri | Sat |
| 1 | 2 | 3 | 4 | |||
| 5 | 6 | 7 | 8 | 9 | 10 | 11 |
| 12 | 13 | 14 | 15 | 16 | 17 | 18 |
| 19 | 20 | 21 | 22 | 23 | 24 | 25 |
| 26 | 27 | 28 | 29 | 30 | ||
| Aug Oct | ||||||
I've been thinking... it's actually pretty easy to say what it takes to be a good programmer. You just need to know everything at the low level and everything at the high level.
In other words, you need to know the system or product in and out. You need to know how everything talks to everything else, and how each piece actually does its work. Modern software engineering is predicated on abstractions, so you shouldn't have to know the details of how things work, but if you don't you'll end up with problems. If the abstraction is done right, you'll probably only have performance problems, but if you have enough performance problems, the system won't actually work for its audience. All abstractions leak. The more you know, the more you can avoid the pitfalls.
You also need to know everything about how the business uses, wants to use, or could benefit from using the system. Again, modern practices try to make this unnecessary by inserting a layer between the business and the developers whose sole purpose is to figure out what the business needs, but too often that layer has sufficient knowledge of neither the business nor the system.
The closer you come to the ideal of understanding the high and the low, the more value you'll be creating and the more your company or clients will fight to keep you. Remember that next time you think you shouldn't need to worry about something.