This pattern is common to all great programmers I know: they’re not experts in something as much as experts in becoming experts in something.
The best programming advice I ever got was to spend my entire career becoming educable. And I suggest you do the same.
Laziness can be a virtue. There are two types of laziness in this world. Good laziness and bad laziness. Every developer should strive towards being a good lazy developer. Normally laziness has a stigma attached to it, and rightfully so, but in the programming world, laziness can be a real asset.
Write less code.
Steve Jobs famously observed, “The line of code that is the fastest to write, that never breaks, that doesn’t need maintenance, is the line that you never have to write.”
The following advice may seem bloody obvious, but too often I must remind myself and others of it: “Take a moment to understand the error message at the top of an exception/stack trace before making additional changes to your code.”
[R]ead much more than you write, and stick to high quality material. Say goodbye to books that insult your intelligence. Instead, aim higher at professional, up-to-date material. That’s the ticket.
The best programming advice that I ever received can be summarized by the acronym YAGNI, or “You Aren’t Gonna Need It.” This is a very tough principle for many developers to follow because it is easy to get caught up in the excitement of building a rich architecture and providing clever solutions to problems. […]
Simplicity is key to building great software and I believe many developers create solutions that are overly complex. It’s easy get away with when you are running a small team, but when the development team (and typically the product itself) get larger, simplicity becomes more important. It’s not just about a clever solution, but one that is easy to read, learn, and understand.
My manager advised me to pick a relatively narrow area, say, JScript language semantics, and then find questions on the internet and within Microsoft that other people had on that topic. If I could answer the question, I’d answer it. If I couldn’t, then I’d research the question until I could definitively answer it. This paid off in more than just my increased expertise.
In later years, as I found myself building and managing software teams, I’ve realized that there were probably a dozen programmers on that ancient project who knew why the system was so slow and how to fix it. They knew, but they kept it to themselves because in that organization, there were some things that were more important than making the system better. “In the future, stay the hell out of other people’s code,” assumes there will be a future. But the best way to have a future is to be part of a team that values progress over politics, ideas over territory, and initiative over decorum.
I recognize this is largely a matter of style. Some people insist on line-by-line tool-driven debugging for everything. But I now believe that thinking—without looking at the code—is the best debugging tool of all, because it leads to better software.
The first idea is refactoring. This means taking a function or method and making sure that it does just one specific thing. This often involves creating helper functions or methods to take over part of the work the original one did. Each helper should also be refactored so that it too does one specific thing. One advantage of doing this is that refactored functions and methods are smaller and easier to understand. […]
The second idea is “TDD” (Test Driven Design/Test Driven Development).
This involves writing tests before writing an application (or before adding a new feature or doing a change). These tests will naturally fail since what they test hasn’t been done yet. Then the implementation is done and is complete once the tests pass. This sounds like a lot of work if you’re not used to it—but in fact it can save huge amounts of time.
One of the leaders on my earliest projects told me, “Make code usable before you make it reusable.” It’s so easy to get caught up in making something perfect and extensible that sometimes we don’t even make code usable in the first place. Once you’ve got something that satisfies its original purpose, you can see how it may be extended. Until it’s actually used, you can’t know where it could be extended or reused.