I’ve been writing code for almost 11 years now. One thing I am completely sure of is that for being a really good programmer, you have to do a lot ...
For further actions, you may consider blocking this person and/or reporting abuse
Excellent summary! I make many of the same points in my other articles, but I love how you boiled it all down.
I would say, however, that "best practice" does not exist. Good practice is important, but there are three important things about it:
Know it and follow it strictly until you have a good reason to depart.
Don't let it become dogma. Adjust it as you learn more. Practices, standards, and methodologies exist for people, not the other way around.
Good Practice for one project may be Bad Practice for another project, sometimes even in the same language or stack! Be ready to defend your practice in the scope of your own project, but don't assume it's the Answer To Everyone's Problems.
As I've said before, Best Practice cannot exist, because if it did, it would mean that there was One Great Solution To Every Problem Ever™, and the entire history of computer programming proves that premise ridiculous.
Solid tips, Aman.
Based on the title I was expecting you to take things in another direction: project management, leadership, human communication, marketing, domain knowledge, estimating, time management, teamwork, etc.
Despite my surprise, I like your tips very much.
Nice summary. The first part about human communication is essential.
Curiosity is a good point but not only with new programming language, sometimes another domain (architecture, design ...) could be very usefull to lean new practices and process. I'ld like to write something about that one day.
Moreover when you create a software go to see how user use it (UX design) it's very very instructive.
Disagree with learning a new language everyear. I’ve found it’s far more marketable in a profession where new technologies arise and die rapidly to learn and build deep proficiency in a fewer languages that meet the demands of the market. Plus, languages share traits with one another—making it likely that if you know one language deeply, you’ll be able to work in another without much difficulty—Ruby vs Python for instance. By mastering the language you work in, you’re learning to use other similar languages as well. There’s also a bunch of trendy crap in the tech world that is a waste of time to learn. In the end, we’re all in this field for the money—that’s what careers are all about. Use your time wisely and maximize your value.
Some are, others aren't, human motives are not this simple.
Awesome post. I follow most of what is mentioned in "Write for other people", except the 2nd point about comments. I just realized that I've done exactly what you said in my comments - I've explained the 'what?' but not the 'why?'. Thank you.
I have drummed into every one that has worked with me a few key concpets around code:
I could do better at writing better commit messages!
I think I am past learning new languages at this stage of my career, but perhaps not, always fancied having another go at Ruby as the first time I looked at it the documentation was in Japanese!
I used to use UltraEdit, but moved across to PHPStorm a couple of years ago, for most of the web scripting I do. Worst decision made, using netbeans ...
Someone (I think on this site) once said we should call these professional skills. I agree with them, b/c I think it's useful to be able to use "hard" and "soft" skills to mean "skill based tasks" and "intuition based tasks". Eg the sequence of keys you press to rename a variable a hard skill, choosing the right variable name is a soft skill, caring about variable names (readability) is a professional skill.
Anyway, other than that nitpick, I agree.
Oh, maybe worth saying that I agree within the common context that we typically write code in. In general, they can change as goals and constraints change. Eg I enjoy tweeting programs (example), and to meet the constraint of tweetable, descriptive variable names and proper indentation are counterproductive. Thus, the most important professional skill is to know the goal.
The fact that you need to write comments is an indication that your code itself is not clear enough.
Remember that comments need to be maintained and refactored with the code. An out of date comment is worse than no comment at all.
I prefer restructuring/renaming code until it is clear what it does instead of commenting difficult parts.
Great post, I like to add one more skill (not too soft then other).
Try tô teach the juniors of the team is a great skill, you develop the teach skills (obvious) and social skills