16 Ways to Become a Better Developer
Make a list of developers that you admire and study them. Learn things from them such as how they debug problems and what tools and technologies they’re using. Follow these developers on Twitter and subscribe to their blog’s RSS feed. Whenever they post something new, take the time to actually read and comprehend what they’re trying to convey.
While or after learning something new, share what you’ve learned. Don’t think you have anything to contribute? Wrong. Even if you’re a beginner web developer and only understand HTML, there is someone out there who is interested in learning that particular subject from someone who won’t throw a bunch of hard to understand, technical terms at them. Don’t present yourself as an expert, but rather as someone who is just trying to share your experiences and help other’s where you can.
If you can't explain it simply, you don't understand it well enough. - Albert Einstein
Spend 15 to 30 minutes per day learning something new about the tools that you use every day, whether it be your programming language of choice, shortcuts for your text editor, how to make your code more performant, or whatever you’re interested in. Keep a running list about topics that you want to research and spend a little bit of time each day conquering this list.
Development is more than just writing functional code. Experienced software developers know how to architect their code so that it’s maintainable, flexible, and easy to understand. Fortunately, you don’t have to reinvent the wheel. Software development design patterns are best practice solutions for architecting systems. As always, there are different tools for different jobs. Knowing when to use the right tool for the right job comes with practice and experience.
Imagine a carpenter who didn’t know how to use a hammer, a doctor who didn’t know how to use a stethoscope, or a truck driver who didn’t know how to drive a truck. A software developer who doesn’t know how to use their tools also fits into the same category. Take some time to learn your IDE, text editor, operating system, database, and libraries.
Sure, it’s easy to enter a few words into a search engine, click the top stack overflow result, and copy/paste the answer into your project. Doing this isn’t making you a better developer, it’s making you a better Googler. The next time you have an itch to search for something, try solving it by yourself first. Not only will you be practicing your troubleshooting skills, you’ll also be more likely to remember the answer when you figure it out. Of course, don’t waste too much time. The internet is a valuable resource, but remember to think for yourself, too!
Don’t be afraid of expressing your opinions, but also be ready to change your opinions if provided with sufficient evidence. To be a good developer, you have to take a stance on what you think is the right way to develop software. This, fundamentally, not only applies to software development, but in all aspects of life. Taking a stance that you can back with solid evidence and reasoning will gain you the respect and consideration of others. However, be prepared to change your opinion when presented with reasoning. Consider other people’s opinions and reasoning. If convinced, perhaps it’s time to adopt some new opinions.
As the old saying goes, practice makes perfect. A runner doesn’t get good at running by not running. A basketball player doesn’t get good by not playing. The only way to get good at solving problems is to practice solving problems. Study your craft. Take pride in becoming a better programmer and problem solver. Understand how to use various constructs in your programming language of choice to solve problems in different ways.
One of the most common characteristics amongst successful people is that they read. Your education doesn’t have to stop when you leave work. Keep a book by your bedside and pick it up a few times a week. I decided to make this a separate step from bullet point #3 because I consider this point to be a bit more in depth and beneficial to your life and career as a whole, where as I see #3 as reading a quick blog post about some cool tip, trick, library, or framework.
If you’re stuck on not knowing what to read, check out some of my personal recommendations
Lets face it, we’ve all seen THAT application. You know, the one that you’re assigned to maintain and makes you reconsider your career as a software developer. Just because you can write your entire application in one line, doesn’t mean that you should. Just because you can inject 20 parameters to one class’s constructor, doesn’t mean that you should.
Weigh the pro’s and con’s of some of the things that you’re currently doing. In some cases, we do things simply because that’s how we have been doing them for years. Check a list of some of the most common code smells and question some of the things that you’re currently doing. Perhaps there’s a better way of writing something than you currently are, or perhaps you have great reasoning behind why you’re case is unique.
One trap that developers sometimes fall into is thinking that if someone else, especially if that someone is popular, highly credible, or experienced, says that something is true, then it must be. Take everything that you read with a grain of salt and question what you’re reading. Try understanding why the author has the point of view that they do. This is a skill that grows over time. The more you practice your craft, the more confident you’ll be about your abilities.
There are a lot of people out there who will tell you that something can’t be done because of X, Y, and Z. There are other people out there who will tell you that something is simple, all you have to do is A, B, and C.
My point is, don’t gauge the difficult on a set of tasks simply based off of someone else’s quickly contrived assumptions. Think for yourself, lay out the steps necessary, do your research, find ways around your obstacles, and write the code.
Learning happens when we’re challenged. Take on new challenges and rise to the occasion. You may be presented with unique problems that you wouldn’t have encountered otherwise. Tackling unique challenges now will give you a new perspective when solving future problems, even if they may not seem similar at first.
Stop over-engineering! Not everything require 10 ajax calls, 5 database tables, 3 stored procedures, and 6 Microsoft acronyms. Lets face it, 9 times out of 10 it’s not going to get documented properly anyway, and even if it did, do you really want each new developer who works on the project to burn multiple hours just reading the documentation before they can even remotely comprehend how the system is supposed to work? Solve the simple case first. If additional features are needed in the future, handle them then. Don’t implement features just because there’s a chance that they’ll eventually be requested.
Putting ideas on a whiteboard and asking for other’s input is a great way to get feedback. From my experience, when whiteboarding, three possible things typically end up happening.
- The other person ends up teaching you something.
- You end up teaching the other person something, which requires an explanation on how components work, which in turn will reinforce that you do (or don’t) understand the topic.
- A debate (not argument) is started, which leads to possibly important factors that were not considered.
Whiteboards provide a great way to communicate ideas that are otherwise hard to explain with words alone.
Simply put, ask if you need help. Don’t spend too much time on a single topic if someone else can explain it better in a fractions time. There’s nothing wrong with saying “I don’t understand this, can you please help me out?”. No one is an expert at everything.