|
I think about this from time to time. How did I get there? How do I get further? I started off really bad. I've progressed to "good", and hoping to get to "great" someday. I've picked up this wisdom: 1. Learn an IDE and an editor. The IDE is useful for refactoring, for project management, for code completion, and other niceties. Your editor is there to lean on when you have to do some down and dirty editing. For example, today I took a GORM class, copied the contents into vim, and within a few macros and regular expressions I had transformed it into the bones I needed for an HTML table in five minutes, as opposed to a half hour of copying, pasting, adusting, and making sure I didn't make some stupid error. Now, to be fair, for many years I was more comfortable staying in just Vim and can see why someone could just stay there, I think both are necessary. (Now, editors like Sublime in languages like Ruby may be close enough to an IDE that it doesn't matter, but I'll swear up and down that having a tool that contains the kitchen sink makes the 80% much more comfortable to me. But by learning it, I mean really digging down and memorizing the keystrokes and being able to use without thinking. If it takes flash cards and repetition, so be it. 2. Great programmers don't have to worry about learning libraries -- they just figure them out. I am not a great programmer. I work to understand an API so that I don't have to think about it when I'm using it. 3. Most of our work is fairly repetitive in terms of the patterns we use, so figure out the patterns that work ahead of time and look for ways that you can avoid making decisions. Every time you have to think about something simple because there are two equally-okay ways to do that, you're slowing down. 4. In a similar vein, look for ways to write programs to simplify what you do, especially in terms of generating code. In any given project, many of our screens can be the same, especially in enterprise software. Instead of copy-and-modify, write a script that is repeatable. Even with the Don't Repeat Yourself maxim, there are far too many ways in which we may not be repeating the same code, but we're certainly repeating 90% of the same process of getting to a similar end result. If you see an elegant way to abstract that out, all the better, but code generation can be a useful tool. 5. Pair program with better programmers. See what kinds of patterns they use. Steal as you can. I had my greatest growth when I was on a project with a programmer I really respected and we paired. I got insight in to how he approached problems that I was able to take with me. |
I would love to be able to do this. The amount of time I'll ponder on a library thinking "what are the internal mechanics of this?" can be quite frustrating. For OpenGL, for example, I have such a hard time processing a mental image of the system that I can't really figure out how to use it well.
Every library should have their first page be an explanation of how everything goes together, in layman's terms. The fact that the X server books had a huge introduction explaining everything really helped me understand the otherwise ungrokable code.