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.
Here is the most illustrative advice and recurring tips from blogs and forums, organized into five categories.
Whether you have five, ten, or twenty years of experience programming—or if you have almost no experience— just about every developer will find some good ideas for self-improvement.
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)
—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 of 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.
Code readability and maintainability
22. “Don’t ask permission to refactor, test, document etc. It’s all part of ‘programming’. Don’t ask permission to do your job.” (Source)
—Jerome Terry
23. “Fix what isn’t broken. You should go to your last project and read through the code. Think about what each piece does. There’s a loop here, some sorting there, a bit of number crunching, screen updates, HTML generation, database CRUD, that sort of thing. Now replace the hard-coded HTML with a templating system, get the database CRUD out of your business objects and re-write it to use proper parameterized queries instead of string concatenation, replace all the “writelns” and “MessageBoxes” in your error handlers with a logging framework, refactor code that’s trying to borrow methods from other classes, use locale-aware string formatting, stop guessing how big an array should be and use a dynamic collection, delete orphaned code.” (Source)
—Chris Wenham
24. Most developers have heard the saying, “Always write code as if the person who ends up maintaining it will be a violent psychopath who knows where you live.” What that means realistically is that you should write readable code that could be easily comprehended a year later by someone who’s disinterested and in a hurry. If you’ve ever had to dig through indecipherable code, you know why this is so important. Have some empathy for the developers who will read your code.
25. Name variables so that other developers can understand your code better. This is a skill you need to nurture.
26. Using inheritance often reduces testability and reusability of your object-oriented code in the long run. Your first choice should be using composition and interfaces.
27. Don’t use design patterns like a hammer looking for a nail. If you don’t have a clear reason you need it, don’t use it.
28. Always favor shallow code hierarchies to deep-nested code (whether it’s inside or outside a function). Deep-nested code is harder to maintain, harder to reuse, and more likely to create bugs.
29. Reusable code is helpful and important, but trying to write overgeneralized, super flexible code is often a waste of time. This kind of code is usually harder to maintain and causes bugs. It’s okay to hardcode some things if your code is doing one task.
30. Master the art of debugging using “print statements.” There are many scenarios where a sophisticated debugger is not available to you, but I’ve never found a platform nor environment where you couldn’t output textual information to a screen or file.
—Richard Eng
31. Having great writing and communication skills directly translates into programming capability. Joel Spolsky can elaborate on why this is:
“The difference between a tolerable programmer and a great programmer is not how many programming languages they know, and it’s not whether they prefer Python or Java. It’s whether they can communicate their ideas. By persuading other people, they get leverage. By writing clear comments and technical specs, they let other programmers understand their code, which means other programmers can use and work with their code instead of rewriting it. Absent this, their code is worthless.”
32. Just like natural languages, you haven’t mastered programming until you see and think in code. A popular book, Structure and Interpretation of Computer Programs, by Abelson, Sussman, is one of the best resources to help you do this. Don’t worry that its examples are in Scheme; it’s an optimal language for learning to think in code.
Technical debt, code coverage, and process
33. Donald Knuth, is known for his maxims “When in doubt, use brute force” and “Premature optimization is the root of all evil.” When he says “use brute force,” he means that you shouldn’t let yourself get stuck trying to come up with a prematurely optimal algorithm. Just use the simplest, unsophisticated algorithm that will work and iterate from there. Using the simplest formula will also help you better understand how your software should work so that you can start forming a mental model with which to think of better, more efficient algorithms.
34. Know when to take on technical debt and when to pay it off so it doesn’t compound. When exploring (and discarding) different features and pivoting frequently, borrow heavily on technical debt. When your position is stable and your direction is clearer, optimize your remaining features and clean up bugs to pay off that technical debt before moving on to the next stage.
35. Within the context of your projects, learn what the right amount of testing is. Too little and your software becomes unreliable and everyone is afraid to deploy to production. Too much and you’ll end up wasting too much time and resources writing and maintaining them, while also making the development process slower.
36. Estimating time is hard. This is why iterative development methods such as Scrum are so popular. Push yourself and your team to have increasingly shorter release cycles. Surprisingly, shipping code more frequently reduces risk instead of increasing it. It forces you to have better organizational practices and make a better product for the customer with faster feedback.
37. Commit your code in small, working chunks and write a detailed commit messages that will help developers find and understand bugs that may have been introduced in that commit. Just summarize what you did and why you did it.
38. Most developers don’t think about security in every unit of code they write. Many think that frameworks will handle that for them. Don’t be like most developers.
39. You can spend an exponentially greater amount of time hunting down the last 1% of bugs in a project than you would for the first 90%. If you’re not working in a domain that requires your software to work perfectly 99.999% of the time, then you should spend less time debugging the edge cases and features people probably won’t use.
Soft skills and productivity
40. Have large chunks of time set aside for focused coding each day. The quantity of time spent coding is meaningless if it’s full of interruptions such as meetings, emails, and web browsing.
41. Communicate clearly with your team about what you’re doing each day. Talking about your architectural approaches will help you think about those approaches in new ways. It has nothing to do with proving to people that you’re doing good work. More likely, your team will have some ideas you would have never thought of on your own, and you’ll solve problems a lot faster. Your team should also document solutions and share them on a wiki to save valuable time for everyone.
42. Don’t be ashamed to admit when you don’t know something. As a developer, you’re often solving new problems, so you can’t be expected to know all the solutions immediately. Trying to hide your lack of knowledge only slows the learning process.
43. Don’t be afraid to share your unfinished work with others frequently.
44. “Emotionally detach from your code. Find the code that you’re the most proud of and delete it, then rewrite it from scratch in a different way. Use a “design pattern” that confuses you or that you hate (e.g., the Singleton) and figure out how to make it work. If necessary, delete that after you’ve got it working and try again with a new pattern or language. Not only will you learn that there’s More Than One Way To Do It, but you’ll learn that your code is transitory. Code, by its nature, is not just inextricably glued to its language, platform, and the APIs it consumes, but written in the form of ephemeral static charges, orientations of magnetic particles, subject to the whims of the market, Moore’s Law, and your employer. … Remember that emotional detachment from code is a virtue, but this doesn’t mean emotional detachment from your work is, too. In fact, another way to become emotionally detached from code is to put your interest into the outcome instead.” (Source)
—Chris Wenham
45. Googling is a crucial developer skill. Learning how to do something you haven’t done before and finding optimal solutions from the collective intelligence of the developer community is half the battle in programming.
46. “Good programmers know what to write, but great ones know what to rewrite (and reuse).” (Source)
—Eric S. Raymond
47. Teach. Even if you’re a novice at programming, you’re knowledgeable about something. Teaching teaches the teacher. And if you can train other workers, your manager should realize that you’re exponentially more valuable.
48. Don’t focus on becoming a “10x” programmer. Read these articles by Matt Asay and Scott Hanselman to see why.
49. “You won’t—you cannot—become a better programmer through sheer force of programming alone. You can only complement and enhance your existing programming skills by branching out. Learn about your users. Learn about the industry. Learn about your business. The more things you are interested in, the better your work will be.” (Source)
—Jeff Atwood
50. Make mistakes, ask questions, get rapid feedback, get uncomfortable, compare it to what you know, keep going. More on that here.
Additional resources and comments
Here are some books and other resources that were referenced multiple times by programmers giving advice for how to get better:
- Rich Hickey’s talk Simple Made Easy
- Kent Beck’s article XP Simplicity Rules
- Jim McCarthy’s book Dynamics of Software Development
- Andy Hunt and Dave Thomas’ book The Pragmatic Programmer
Take a look at some of these and then maybe pick some of your favorite pieces of advice from this article to create a tentative checklist for your personal growth.
Share some of your own advice in the comments below or tell us about some advice here that you really liked or disliked.
source: https://techbeacon.com/app-dev-testing/50-tips-improving-your-software-development-game
