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 developer or working in a software development company UK or anywhere around the globe, than 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.
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. 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
6. 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.
7. 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.
8. 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.
9. 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.
10. 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.
Code readability and maintainability
11. Name variables so that other developers can understand your code better. This is a skill you need to nurture.
12. 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.
13. 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.
14. 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.
15. 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.
Technical debt, code coverage, and process
16. 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.
17. 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.
18. 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.
19. 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.
20. 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
21. 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.
22. 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.
23. Don’t be afraid to share your unfinished work with others frequently.
24. 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.
25. 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.
Finally
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. Hopefully we'll all get the jobs we want with this advice.
No comments:
Post a Comment