My advice for improving your software development game
Domains, architecture, and design
1. The best programmers can take a complex problem, break it down into smaller pieces, solve each of those pieces, and then put everything back together to solve the initial problem.
2. Software is just a tool for solving domain problems. Since it’s needed in almost all domains, develop in one that interests you. If you understand a domain well and are passionate about it, you’ll be a much better, more motivated developer. You’ll also be exponentially more valuable and lucrative to companies hiring in your chosen domain.
3. Don’t let one domain pigeonhole you into one way of coding. An example would be a mobile developer who is mainly good at hooking together existing APIs but can’t come up with a sane data representation. Don’t be a one-trick pony.
4. Plan your code away from the computer. It will help you build a clear mental model before you start. You use the same strategy in writing, because if you don’t have an outline, your content becomes a messy stream of consciousness.
5. “When you’re stuck, write your program on paper. I’m serious. It’s magic. This is standard practice in programming competitions. (I think it works because when you don’t have to think about syntax you have more excess brainpower to solve the actual problem.)” (Source)
—Joseph Gentle
6. “Compelling web apps tend to be the ones that use data in unexpected ways or in ways that solve everyday problems. Learn everything you can about data storage.” (Source)
—Maggie Nelson
7. As an architect, you can’t have blind spots in your understanding of your applications and their execution environments. You need to know how things work in the front end (UI), the back end, the data store, the OS, any virtualization layers, the hardware, the network, and the data center.
Languages, tools, and advancing from beginner to intermediate
8. Contribute to open-source projects as a bridge from beginner to intermediate. Collaborate with the developers of the project and attend meetups to collaborate with other developers in person.
9. Don’t let anything get in the way of that initial motivation to learn programming and just build something. Sometimes you block yourself by having too much focus on reading books or resources first. Other times beginners will try to find the perfect first language. Your first language doesn’t matter. What matters is learning to program well. Just start coding.
10. “Learning programming languages is NOT learning how to program. Focus on programming techniques, problem solving, and analytical skills, not on learning as many languages as you can.”
—Richard Eng
11. Learn multiple programming paradigms such as object-oriented programming, functional programming, reflective programming, etc. Believe it or not, your programming in one paradigm will improve after studying an alternative paradigm.
12. “Wherever possible, always choose the simpler programming language. More complex languages increase the cognitive load on your brain. Simpler languages do not necessarily give up anything in terms of power or expressiveness.”
—Richard Eng
13. Beginners learn just enough of their tools to get by. To become an intermediate or expert developer, you need to know your tools cold. Learn all of the features, menus, and context menus. Learn to use them without a mouse by memorizing keyboard shortcuts. Find every “tips and tricks” article available.
14. Learn your stack on the deepest levels before you decide to reinvent the wheel. Peter Nixey gives a few good examples: “If you are a Ruby developer take time to learn the language’s incredible range of methods. If you are a Node developer, take time to understand the architecture, the methods, and the mindset of Node. If you are an Angular developer go right up to the rock-face and understand the logic behind the incredible architecture the core team is forging there right now. Ask before you invent.” (Source)
—Peter Nixey
15. The same goes for the languages you work in. Learn the most important libraries for your use cases. The more libraries you’re aware of, the less likely you are to try reinventing the wheel.
16. Whenever you can, use programming languages that will eliminate entire classes of run-time errors. To do that, look for languages with features like strong typing, static typing, managed memory, and/or immutable data.
17. “Frameworks, libraries, languages, never mind if you can’t understand what you find under the hood on your first attempt. You can always put them aside and return to them later, just see to it that you can take them apart and have a look. All the rules you have to follow when you first learn were invented by someone, you can make them yours to reinvent with some persistence. Steer clear of tools that put barriers in the way of this activity, those make you depend on them in the wrong way.” (Source)
—Jan Christian Meyer
18. “[When reading high-quality code], it might be tempting to look for main() and start from there, but you’re likely to spend a lot of time just reading set-up code and command-line parsing. I prefer to scan the filenames to look for some activity that interests me and then dig into those files. It’s not crucial to understand the whole project or the ins and outs of the entire design, you’ll wear yourself out doing this. Read the code. Look at the comments, see what the authors are doing, and how they went about it.” (Source)
—Andrew Binstock
19. Create some of your own tools. (But of course, if you’re going to use it in production, make sure it’s not another wheel reinvention.)
20. Make common programs that have been made before. Not for a production project (see “reinventing the wheel”), but as a learning project. If other developers can make a calculator, text editor, paint, Tetris, or Pong, then so can you. Look at several examples of these apps written by more experienced developers and try to learn their tricks.
21. Develop an aesthetic appreciation for code. Read the source code of famous open-source tools and frameworks such as Ruby on Rails or Jenkins, and get familiar with norvig.com. Over time, you need to train yourself to know what great code looks like and what bad code “smells” like.