How do you keep improving as a software engineer? Some pieces of advice are valid no matter your experience level, but often the advice will depend on where you are in your career.
If you’re a beginner, the best advice is to simply learn your language, frameworks, and tools top to bottom and gain more experience with a variety of different projects.
If you’re an experienced software developer, you should constantly try to find new ways to optimize your code for readability, performance, and maintainability, and then practice making well-reasoned decisions about where to focus time and resources in your code—whether it’s testing, performance optimization, or other technical debt.
Those are some of the themes you’ll find if you ask veteran software engineers to share their best advice for being a great programmer. There aren’t any well-kept secrets. The advice of many of the most successful developers is readily available to you on blogs and forums.
I’ve taken the most illustrative advice and recurring tips from blogs and forums and organized them into five categories that emerged as I compiled them. I’ve paraphrased and merged various similar tips into single snippets, and I’ve also left a few pieces of advice as untouched quotes from their authors.
Whether you have five, ten, or twenty years of experience programming—or if you have almost no experience—I think just about every developer will find some good ideas for self-improvement.A Developer’s Guide to the OWASP Top 10GET REPORT
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 brain power to solve the actual problem.)” (Source)
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.
[ Conference: ADM Summit 2019: Optimize Your Deployment Pipeline]
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.”
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.”
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 of the incredible architecture the core team is forging there right now. Ask before you invent.” (Source)
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.