How to be an Excellent Programmer for Many Years
(Excellent==Successful. Money & fame are more difficult to control.)
Link: http://news.ycombinator.com/item?id=4626201
(Excellent==Successful. Money & fame are more difficult to control.)
- Choose a small subset of available technology, learn it intimately, and embrace it. Then evolve that subset.
- Understand the pros and cons of various data structures, both in memory and on disk.
- Understand the pros and cons of various algorithms.
- Understand your domain. Get away from your computer and do what your users do.
- Be ready, willing, & able to deep dive multiple levels at any time. You must know what's going on under the hood. There is a strong correlation between "number of levels of deepness understood" and "programming prowess".
- Use your imagination. Always be asking, "Is there a better way?" Think outside the quadralateral. The best solution may be one that's never been taken.
- Good programmer: I optimize code. Better programmer: I structure data. Best programmer: What's the difference?
- Structure your data properly. Any shortcomings there will cause endless techincal debt in your code.
- Name things properly. Use "Verb-Adjective-Noun" for routines and functions. Variables should be long enough, short enough, and meaningful. If another programmer cannot understand your code, you haven't made it clear enough. In most cases, coding for the next programmer is more important than coding for the environment.
- Decouple analysis from programming. They are not the same thing, require different personal resources, and should be done at different times and places. If you do both at the same time, you do neither well. (I like to conduct analysis without technology at the end of the day and start the next morning programming.)
- Never use early exits. Never deploy the same code twice. Never name a variable a subset of another variable. You may not understand these rules and you may even want to debate them. But once you start doing them, it will force you to properly structure your code. These things are all crutches whose use causes junior programmers to remain junior.
- Learn how to benchmark. Amazing what else you'll learn.
- Learn the difference between a detail (doesn't really make that much difference) and an issue (can end the world). Focus only on issues.
- Engage your user/customer/managers. Help them identify their "what". Their "how" is not nearly as important.
- Write a framework, whether you ever plan to use it or not. You'll learn things you'll never learn any other way.
- Teach others what you know, either in person or in writing. You'll accidently end up teaching yourself, too.
- Always tell your customer/user "yes", even if you're not sure. 90% of the time, you'll find a way to do it. 10% of the time, you'll go back and apologize. Small price to pay for major personal growth.
- Find someone else's code that does amazing things but is unintelligible. Refactor it. Then throw it away and promise yourself to never make the same mistakes they made. (You'll find plenty.)
- Data always > theory or opinions. Learn the data by building stuff.
- At some point, run your own business (service or product). You will learn things about programming that you'll never learn as an employee.
- If you don't love your job, find another one.
Link: http://news.ycombinator.com/item?id=4626201