I’ve always loved technology and programming. From Java at the beginning to Python now, I have accumulated some difficult and easy experience during these years of learning and working. As a programmer, you may have some development experience, you may not be new to Python, or you may not have any Python learning experience, but I will dedicate them to those who want to learn more.
I’ll keep updating these lessons, and I’ll probably have more to say about them, but as far as I’m concerned, I don’t think I need to add anything else to this list. Here are my most memorable experiences so far.
1. Estimate how long it will take to solve the problem. Don’t be afraid to admit it! I’ve seen programmers sit in front of a monitor for eight hours to solve a particular problem. Set a time limit for yourself. One hour, 30 minutes, or even 15 minutes. If you can’t solve the problem in the meantime, ask for help or go online for answers instead of trying to be a “super coder.”
2. A programming language is a language, just a language. Over time, once you understand how a language works, you will find similarities between languages. In the language you choose, you should feel “comfortable” and be able to write effective (and concise) code. Most importantly, adapt the language to the project and vice versa.
3. Don’t focus too much on “design patterns”. Sometimes it’s easier to write a simple algorithm than to introduce a pattern. In most cases, the code should be easy to understand, even for cleaners.
4. Back up your code often. When I was younger, I had the horrible experience of losing a lot of code to a hard drive failure. As long as you don’t have a backup once, it should be like having a strict deadline that the customer needs tomorrow. This is where the source/version control software comes in.
5. Admit you’re not the best programmer — not enough. I’ve always thought, I know enough about programming, but there’s always someone better than you. As the saying goes, “A mountain is always higher than a mountain.” So be like them!
Study and study. As mentioned in # 5, I often have a computer or programming magazine or book in my hand (ask a friend if you don’t believe me). Admittedly, there are always techniques you don’t know about that you can learn from to keep up. If you have a clever way of acquiring the new skills you need, you should learn them every day.
7. Perpetual change. Treat your tech/programming knowledge like you treat a stock: diversify. Don’t feel good about a particular skill. If that technology or language is no longer available, you might as well start updating your resume and starting new training programs now. What are the main principles that keep me going? At least two or three languages are understood, so if one language becomes obsolete, you can rely on another to learn new skills.
8. Bring in new people. Assist and train junior/entry-level developers to learn good programming methods and techniques. You may not know it, but by helping them move up to the next level, you’re moving up to the next level yourself, and you’ll feel more confident.
9. Simplify the algorithm. Code is evil, and after you’ve finished coding it, go back and optimize it. A few improvements here and there will make life easier for later support staff in the long run.
10. Document. Whether it’s a Web service API or a simple class, document as much as you can. Code comments, of which I was once proud, have been accused of being over-commented. It only takes you a few seconds to comment three lines of code. If it’s a difficult technique to understand, don’t worry about too many comments. Most architects, backup programmers, and support groups will thank you if you do your job well.
11. Test, test, test. I’m a fan of black box testing. When you’re done coding, you’re “approved.” If you have a QA department, if you have a bug in your code, you’ll get more reviews than the project manager. If you don’t thoroughly test your code, you’re probably not just developing code, you might get a bad reputation.
Celebrate every success. I’ve seen programmers shake hands, high-five, or even dance with their peers after solving technical programming problems. Everyone has an Epiphany in their life. If a programmer happily asks you to see his amazing code, you’ve probably seen it 100 times, but you should celebrate it for the 101st time.
Check your code often. In the company, your code should be reviewed frequently (both by yourself and by other colleagues). Don’t take someone else’s review as a criticism of code style. They should be seen as constructive criticism. As an individual, check your code regularly and ask yourself, “How can I write better?” This will accelerate your growth and make you a better programmer.
Review your code. There are two common ways to look at your old code: “Hard to believe, I wrote this code” and “hard to believe, I wrote this code.” The first is often a tone of disgust and wondering how to improve it. You may wonder how old code can be resurrected to become a better program, or even a complete product. The second is usually with a sense of wonder and completion. Developers should have one or two projects that they have completed that make people stand up and take notice. Also, based on your superior programming skills, you can take past programs or projects and update them into better products or ideas.
15. Humor is indispensable. In my development career over the years, I have met many humorous programmers, such as plaid shirt, rush clothes, wooden label attached to the programmer body, can only say that each person has a different personality. In fact, in our line of work, humor is a must as well as technology.
16. Beware of the know-it-all programmer, the one who won’t share, and the one who isn’t experienced enough. When you meet these types of programmers, be humble. The know-it-all programmer who wants to be a hero rather than a team player; Conservative programmers write their own code; Inexperienced programmers will ask you every ten minutes, and when the code is finished, it’s yours, not theirs.
17. No project is that easy. Friends, family and colleagues have asked me to rush something, rush an app or a website. In such a case, you should plan from both sides so that you can make something satisfactory to both sides. If someone starts out with a 3-page site using Microsoft Access, they’re more likely to end up with a 15-page site using SQL Server, a forum, and a custom CMS.
Don’t take anything for granted. If you take on a simple project, you may think that some parts will be easy to complete. Don’t think like that! Unless you have a class, component, or piece of code already written and tested in an existing project. Don’t think it’s going to be easy.
19. No completed software. A programmer once told me that no software is ever finished, it’s just “done for now.” This is wise advice. If the client is still using the program you wrote and has stood the test of time. If you’re still updating it, given the opportunity, that’s not a bad thing, it keeps you moving forward.
Patience is a virtue. When a client, friend or family member uses a computer, they may become frustrated and want to smash it or storm off. I keep telling them, “You run the computer, not the computer runs you.” You have to be patient with a computer that is used for programming. Once programmers know what the problem is, they look at it from the computer’s point of view and say, “Oh, that’s why it’s doing this way.”