Jonathan Danylko is a freelance web architect and programmer with over 20 years of programming experience in e-commerce, biotech, real estate, healthcare, insurance and utilities. As Jonathan said in the article, this article is suitable for fresh graduates and beginning programmers. If you are already a senior developer, you may see yourself in this article.
I've been programming since I was 11 and have always loved technology and programming. Over the years, I have accumulated some hard and easy experiences. As a programmer, you may not have these experiences, but I will dedicate them to my friends who want to learn more from them.
I'll keep updating these experiences, and I may have more thoughts, but in my 20 years, I don't think there's anything extra to add to the list below. Below is my most memorable experience to date.
1. Estimate the time required to resolve the problem. Fear not, admit it! I've seen some programmers sit in front of a monitor for 8 hours trying to solve a particular problem. Set yourself a time limit, 1 hour, 30 minutes or even 15 minutes. If you can't solve the problem in the meantime, ask for help, or look for answers online, instead of trying to be a "superstacker."
2. A programming language is a language, just a language. Over time, as long as you understand the principles of a language, you will find similarities between languages. The language of your choice, you should feel "comfortable" with and be able to write efficient (and concise) code. Most importantly, let the language adapt to the project and vice versa.
3. Don't focus too much on the "design patterns" of the program. Sometimes it's easier to write a simple algorithm than to introduce a pattern. In most cases, the program code should be simple and easy to understand, even a cleaner can understand it. 4. Back up your code frequently. When I was young, I had the experience of losing a lot of code due to a hard drive failure, and it was a horrible experience. As long as you don't have a backup once, there should be a strict deadline like the customer will need it tomorrow. This is where the source code/version control software comes into play. 5. Admit that I'm not the best programmer - I don't know enough. I often think that I know enough about programming, but there are always other people who are better than you. As the saying goes, "a mountain is always taller than a mountain". So, look up to them! 6. Learn and learn.
As mentioned in point 5, I often have a computer or programming related magazine or book in my hand (don't believe it, ask my friends). Granted, there's always a lot of technology you don't know that you can learn from to stay on track. If you have a dexterous way to acquire the new technology you need, you should keep learning every day.
7. Eternal change . You treat technical/programming knowledge the same way you treat stocks: diversification. Don't feel good about a particular technology. If that technology or language is no longer adequate, you might as well start updating your resume and start a new training program now. What are the main principles that keep me going? Know at least two or three languages, so if one language is outdated, you can rely on another as you learn new technologies.
8. Support new people. Assist and train beginner/entry developers to learn good programming methods and techniques. Maybe you don't know it yet, while helping them move to the next level, you are also moving to the next level, and you will be more confident.
9. Simplify the algorithm. Code is the devil, when you're done coding, you should go back and optimize it. In the long run, some improvements here or there will make things easier for later support staff.
10. Write documentation. Whether it's an API for a web service, or a simple class, you try to document it accordingly. Code comments that I used to be proud of, have been accused of over-commenting. It only takes a few seconds for you to add a comment to three lines of code. If that's a tricky technique to understand, don't worry about commenting too much. If you do your job well, most architects, backup programmers, support groups will appreciate you.
11. Test, test and test. I'm a fan of black box testing. When you're done coding, it starts when you're "approved". If your company has a QA department, if you have a bug in your code, you will get more comments than a project manager. If you don't thoroughly test your code, I'm afraid you're developing more than code and possibly notoriety.
12. Celebrate every success. I've seen many programmers shake hands, high-five, or even dance with their peers after solving technical programming challenges. Everyone has an "epiphany" in their life. If a programmer happily asks you to see his extraordinary code, maybe you've seen it 100 times, but you should also celebrate the 101st time for this guy. (Editor 's note: Nine Ways to Celebrate Success .)
13. Check the code frequently. In the company, your code should be checked frequently (both by yourself and by other colleagues). Don't see other people's inspections as strict code style. They should be viewed as constructive criticism. Personally, reviewing your code frequently and asking yourself, "How can I write better?" This will allow you to accelerate your growth and make you a better programmer.
14. Review your code. When looking at my old code, there are usually two ways: "Unbelievable, I wrote this code" and "Unbelievable, I wrote this code". The first is often a tone of disgust and thinking about how to improve it. You might be amazed that old code can be resurrected into a better program, or even a complete product. The second usually comes with a sense of wonder and accomplishment. Developers should have one or two self-finished project results, projects that can make people stand up and watch. Likewise, based on your superior programming skills, you can take past programs or projects and update them into better products or ideas.
15. Humor is essential. In my 20 years of development, I haven't met a programmer without a sense of humor. In fact, humor is a must in our business.
16. Beware of programmers who know everything, programmers who don't want to share, and programmers who are inexperienced. When you meet these kinds of programmers, be humble yourself. Omniscient programmers want to be a hero rather than a team member; conservative programmers are writing their own code; inexperienced programmers will ask you every ten minutes when When the code is done, the code is already yours, not theirs.
17. No project is easy. Friends, family and colleagues have asked me to rush things, rush a program or a website. For such a thing, it should be planned from both sides in order to make something that will satisfy both parties. If someone starts out with a 3-page website using Microsoft Access, it's likely to become a 15-page website with SQL Server, a forum, and a custom CMS (Content Management System).
18. Never take things for granted. If you take on a simple project, you might think that a certain part can be done easily. Don't think so! Unless you have a class, component, or piece of code that has been written and tested in an existing project. Don't think this will be easy.
19. There is no finished software. A programmer once told me that no software is done, it's just "temporarily done". This is wise advice. If the client is still using the program you wrote and it has stood the test of time. It's not a bad thing that you're still updating it if you get the chance, it keeps you going.
20. Patience is a virtue. When a client, friend, or family member uses a computer, they may get frustrated and want to smash the computer or leave in a huff. I keep telling them, "You control the computer, not the computer controls you." You have to be patient with the computer you use for programming.
Once the programmers know what the problem is, they look at the problem from the computer's point of view and say "Oh, that's why it
's doing this." Although this article does not have gorgeous rhetoric, the simple truth is not only applicable to programmers, but can also be extended to other industries. I remember when I used to practice calligraphy, I always felt that I was well written, but when I look back at it later, I also think, "This is actually written by me!"
Friends who are reading this article, I wonder if you have also seen yourself. ? You are welcome to share your feelings with everyone on Weibo or in the comments.
Source of this article: Bole Online - Workplace Blog
Link to this article: http://www.jobbole.com/entry.php/322
Via: Compiled by Jonathan Danylko : Bole Online Agile Translation Group - @guanguan