Domains, architecture, and design
1. A good programmer can take a complex problem, break it down into tiny pieces, solve each of those pieces one by one, and then put each piece back together to solve the actual problem.
2. Software is only a tool to solve domain problems. As it is required in almost every domains, get in to the one that interests you. If you have interest in a domain and are excited about it, you must be a quite better, much more motivated developer. You will also be comparitively way more valuable and much needed to companies hiring in your chosen domain.
3. Never allow a single domain pigeonhole you into one way of programming. For instance a developer is mainly good at linking together existing APIs but can not come up with a clear data representation. Do not be a single-trick man.
4. Always plan your design away from your system. It will assist you to create a clear mental model before you even begin. You should use the same way in hard form, because if you do not have the basic outline, your content will change into a messy stream of consciousness.
5. If you feel like you are stuck, copy your program to a paper. It’s literally magic. This is fundamental practice in coding competitions. It really works because when you do not have to think about syntax of the program you have more consumable brain power to solve the actual problem.
6. Attractive apps are mostly the ones that use data in non conventional ways or in ways that solve everyday problems. Learn all the things you can about data storage.
7. As a designer, one can not have blind spots in their understanding of their applications and their execution environments. They need to know how things work in the front-end (UI), the back-end, the data-store, the OS, any virtual layers, the network, the hardware, and the data center.
Languages, tools, and advancing from beginner to intermediate
8. Try to contribute to open-source projects in a way from beginner to intermediate. Discuss with the other developers of the project and get in meetings to collaborate with other developers in person.
9. Never let something get in the way of that starting motivation to learn programming and just create something. Sometimes you may actually block yourself by having too much emphasis on reading blogs or books first. And sometimes beginners might try to find the perfect first language. The choice of first language does not effect that much. What really matters is getting to program well. Just begin programming.
10. Starting any programming language is basically NOT learning how to program. Target coding techniques, solving problems, and strategic skills, not on getting grasp on as many languages as you can.
11. Acquire different programming paradigms such as object-oriented programming, functional programming, reflective programming, and more. You might not believe, but your programming in a single paradigm will get better after shifting to an alternative paradigm.
12. Whenever required, always choose the simpler programming language. The complex programming languages has more cognitive burden on your brain. The simpler programming languages do not give up anything if you talk about power or expressiveness.
13. In every language beginners only need to learn just enough of their tools to get by. To change into an intermediate or expert programmer, you need to know your tools deep. Gain the knowledge of all of the features, menus, and context menus. Acquire to use them without a mouse by memorizing all the keyboard shortcuts. look for every available “tips and tricks” article.
14. Get knowledge of your stack on the deepest levels before you have decided to reinvent the wheel. For instance, if you are a Ruby developer take time to learn the language’s vast range of techniques. Or you are a Node developer, take your time to understand the architecture, the strategies, and the code set of Node. If you are a developer in Angular go right up to the rock-face and gain the logic behind the amazing architecture the core team is keeping there right now.
15. Same is the case for the languages you work in. Acquire the most important libraries for your own use cases. As many libraries as you are aware of, it is less likely for you to try reinventing the wheel.
16. Whenever possible, try to use the programming languages that will remove entire classes of run-time errors. For that, search for languages with features like strong typing, static typing, managed memory, or immutable data.
17. Libraries, languages, or frameworks do not worry if you can’t understand what you see under the hood on your first try. You can put them aside always and come back to them later, just look into it that you can take them apart and try. All these rules you have to remember when you start learning were invented by someone, you can always change them into yours to reinvent with some commitment. Stay away from tools that put barriers in the way of this process, they make you dependent on them in a bad way.
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.
19. Try to build some of your own tools.
20. Start with making common programs that have already been made before. Don’t think of it as a production project, but as a chance to learn. If someone else can make a calculator, text editor, paint, Tetris, or Pong, then you can also make it. Learn from several examples of these apps written by more experienced developers and try to acquire their tricks.
21. You can always develop an aesthetic appreciation for the code. Study the source code of accomplished open-source tools and frameworks such as Ruby or Jenkins, and get to know them. Through time, you must train yourself to know what a good code looks like and what bad code “smells” like.
Code readability and maintainability
22. Do not wait for permission to refactor, test, document and all. This all is a part of ‘programming’. You don’t need permission to do your job.
23. Fix the things that are broken. You can go to your last project and go through your code. Read carefully and think about what each piece in this code does. You can go ahead and replace the hard-coded HTML with a templating system, take the database CRUD out of these business objects and re-write it to use proper parameterized queries instead of string concatenation, stop guessing how big an array should be and use a dynamic collection, delete orphaned code.
24. Almost all the developers have heard the saying that always write code as if the person who will be maintaining it will be a violent psychopath who knows where you live. What is actually means is that you should write readable code that could be easily comprehended even after a year by someone who is not interested and in a hurry. If you have ever had to dig through indecipherable code, you should know why this is important.
25. Always give a name to your variables so that other developers can understand your code easily. A very important skill you need to practice.
26. The use of inheritance often reduces testability and reusability of your object-oriented code in the longer run. Your priority should be using composition and interfaces.
27. Never use your design patterns in a way like a hammer looking for a nail. If you don’t see any a clear reason why you need it, you don’t have to use it.
28. You should always give priority to shallow code hierarchies to deep-nested code. Deep-nested code is more complex to maintain, hard to use again, and has more chance to create bugs.
29. Code that is reusable is very helpful and necessary, but trying to write overgeneralized, very flexible code is sometimes a waste of time. This type of code is normally harder to maintain and can cause bugs. It is fine for some thing to be hard-coded if your code is doing one task.
30. Make the art of debugging perfect using “print statements”. There are quite few scenarios in which a sophisticated debugger is not there with you, but you can never find a platform nor environment where you can not output textual information to a screen or file.
31. If you have great writing and communication skills, it directly translates into coding capability. One difference between an average programmer and a great programmer is not how many programming languages they know, and it’s also not if they prefer Python or Java. It’s as if they can portray their ideas by communicating.
32. Same as natural languages, you cannot master programming until you see and think in code.
Technical debt, code coverage, and process
33. Whenever you are in doubt, use brute force, and keep in mind that premature optimization is the root of all evil. When it’s said “use brute force,” it means that you should never let yourself get stuck trying to come up with a prematurely optimal algorithm. Just use the most simple, unsophisticated algorithm that should work and iterate from there.
34. You should know when to take on technical debt if needed and when is the time to pay it off so it doesn’t compound. When your are going through different features and pivoting frequently, borrow heavily on technical debt. When you think your position is stable and your direction is straight, optimize your remaining features and clean up bugs to pay off that technical debt before going to the next step.
35. In the reference of your projects, acquire what the right amount of testing should be. Less testing and your software is unreliable and everyone is not comfortable to deploy to production. Too much testing and you will end up giving too much time to resources writing and maintaining them, this will also make the development process slower.
36. Knowing to estimate you time can be tough. This is the reason why iterative development techniques such as Scrum are so well known. Force yourself and your team to have increasingly brief release cycles. Shockingly, shipping code more frequently decreases the risk instead of increasing it.
37. Commit the code in tiny, working pieces and write a detailed commit comment that will help developers find and understand bugs that may have occurred in that commit. Just discuss briefly what you did and why it’s done.
38. Mostly devs do not think about safety in every unit of code they design. Quite few think that frameworks will take care of that for them. Do not be like those developers.
39. Programmers can spend surprisingly greater amount of time hunting down the final 10% of bugs in a project than they would for the first 90%. If you are not working in a field that requires your software to work perfectly 99% of the time, then you need to spend less time debugging the final cases and features people probably won’t be needing.
Soft skills and productivity
40. You need to have big chunks of time set besides focused coding every day. The amount of time spent coding is of no use if it’s full of interruptions such as meetings, mails, and web surfing.
41. Convey your messages undoubtedly with your team about what you are doing every day. Discussing your architectural approaches will assist you to think about those approaches in new ways. It doesn’t have to do anything with proving to people that you’re doing impressive work. More importantly, your team will have new ideas you would have never got on your own, and you’ll solve problems a lot quicker.
42. Never be ashamed to accept when you don’t know something. As a programmer, you are always solving new problems, so someone cannot expect you to know all the solutions already. If you are trying to hide your lack of knowledge, it only slows the learning process.
43. You cannot hesitate to share your unfinished work with others time to time.
44. Don’t attach yourself emotionally to your code. Look for the code that you feel most proud of and delete it, then write it again from scratch in some other way. Use a pattern for design that confuses you or that you don’t like and figure out how to make it work. If needed, delete that as well once you have got it working and try again with a new pattern or language.
45. Using google is an important developer skill. Acquiring knowledge of how to do things you haven’t done before and finding best solutions from the collective intelligence of all the developer community is half the struggle in programming.
46. Average programmers always know what to write, but best ones know what to rewrite and reuse.
47. Even if you’re a novice at programming, you should teach as you’re knowledgeable about something. While Teaching it teaches the teacher as well. And if you can train other beginners, your lead should realize that you are way more valuable.
48. Don’t focus on growing exponentially and becoming a 10x programmer.
49. You can never become a better programmer through sheer force of programming only. You can just complement and enhance your present programming skills by branching out. know about your front-end users. Learn about the industry. Acquire knowledge about your business. The more stuff you are interested in, the more your work will be improved.
50. Don’t be afraid to make mistakes, ask questions, get frequent feedback, get out of the comfort zone, compare it to what you know, keep moving forward.
By: Mitch Pronschinske