If you want to be a better programmer, a good first step would be to choose an area of software development to take additional responsibility for. Now, when we say “responsibility,” we don’t mean the sort of “you’re to blame and you accept it” responsibility that is so commonly thought of. Instead, we mean the willingness to take charge or the willingness to do something about an area.
So select out some area of software development, and decide to be a bit more responsible for it than one was before. The “area” could be simply some additional part of the current project you work on, the whole project itself, some type of software development that you haven’t done before, some aspect of software development you’d like to know more about, etc. If you’re feeling adventurous, try deciding that you’re personally responsible for the quality of the entire software project you’re working on. If you do, you may be surprised at how much easier this makes your life. When you’re trying to maintain the quality of only a piece of a software project, it’s very difficult. You’re surrounded by complexity or confusion, and you have to fend it off at every turn. But when you look at the project as a whole instead and try to decide what should be done with it as a whole, the solution presents itself much more readily. Now, it may seem like quite a bit more work to resolve the problems of the whole project, and it is. But it’s considerably more satisfying, tremendously more effective, and will bring you up to seniority as a software developer much more quickly than just trying to solve the problems of your one particular area.
It may be the case that you have to work your way up to broader responsibility in smaller steps. In fact, this is very common and is possibly a good idea for everyone who finds themselves wanting to expand their range on a project. After all, if you weren’t initially responsible for the entire project, you may not yet know enough about it to truly take responsibility for the whole thing right now. So perhaps you should take smaller pieces, learn about those, and then decide to be responsible for them. In that fashion, you can eventually work your way up to being truly effective at improving the quality of your entire system, because you actually understand
how it works.
Another way of taking responsibility is to always improve the quality of every piece of code that you touch, even if you’re not normally “in charge” of that area of the project. For example, you’re asked to add a feature to a particular class, and you first refactor that class to be simpler and more readable before you begin adding your feature. It takes a little bit of extra work, but in addition to improving your skills as a programmer, this also eases the future maintenance and development work for you and any other who may touch this piece of code again. If you do enough of this work, it eventually becomes a time savings instead of a “waste.” (Though note that refactoring is rarely ever actually a waste, because improving simplicity, reliability, and readability inherently adds value to the system as a whole.)
Some people are worried about taking more responsibility for the system because they worry that somebody will stop them. Perhaps somebody will say that they should be focusing on their “real” work, or that this simply isn’t allowed. This has never actually happened to me, despite doing extreme amounts of refactoring on almost every project I’ve ever been on. Most of the time, every developer on a project is actually happy when they see improved code quality. Managers want deadlines met and features released, but once you explain to them that code quality leads to this, they are also very supportive. (If they need convincing, you should encourage them to read my book, which was written partly with them in mind.)
At the very worst, you can simply skip asking for permission, and just refactor as part of adding whatever feature you’re working on. One should still coordinate and communicate with the rest of one’s team, but honestly, one doesn’t usually need permission to write quality code or to improve the quality of existing code. Once in a while, people do have valid objections, like it being very close to a release so you should wait until afterward to do the refactoring. If the release is days or weeks away, this is a reasonable attitude. If the release is months away and people have this attitude, then you’re on a project that’s going to miss its deadlines anyway, because they’ve thrown code quality out the window. You’re more likely to make your deadlines by starting to refactor now than you are “sprinting” for three months.
But even if nobody stops you, one question may be where to begin. What’s the first thing one should start taking more responsibility for? What’s the first thing one should come to understand about the project to improve one’s skills? Well, this is a trick question, because the first thing one should learn isn’t about the project at all, but it’s about software development itself. Step back from the project and think about general design principles. Can you list off all the most important facts about design, development, and testing right now? Do you know which pieces of your knowledge are actually the most fundamental building blocks upon which all other truths about software development are based? If you can’t do this, I’ve written a book to help you out, which contains all the fundamental laws of software design written out in sequence with numerous real-world examples to show you how to apply the ideas. I’m telling you this not to sell you a book–I make my living writing software–but because I wrote the book explicitly for the purpose of making this step of growing your knowledge really easy, and also very complete. I don’t know of any other book that contains this information summarized so succinctly and simply. If you’d like to get a sneak preview of what’s in the book, here is an archive of a webcast I presented on November 29, 2012 that gives a rapid-fire overview of all the fundamental ideas
in the text.
Once you have a solid understanding of broader principles, you can start to look at your project from a viewpoint of greater certainty. You can actually see specifically which parts need improvement and generally how to accomplish that. You can start to explain to others not just how the system should be improved, but also why. In general, the more you improve your knowledge of software development as a whole, the easier your day-to-day programming tasks will become.
But no matter how you accomplish it, the first step is simply the decision to increase your responsibility for some part of the world of software development. I say this not because it’s going to help me or because I’m trying to sell you something, but because it’s going to help you, help your software, and help make the software industry as a whole a better place to be.