Joel Liu's Bookmarks tagged programmer →  View Popular

Usually the things that make or break a project are process and people issues. The way that you work on a day-to-day basis. Who your architects are, who your managers are, and who you are working with on the programming team. How you communicate, and most importantly how you solve process and people problems when they come up. The fastest way to get stuck is to think that it's all about the technology and to believe that you can ram your way through the other things. Those other things are the most likely ones to stop you cold.

In my first jobs, I saw lots of managers making stupid decisions, and so, logically, I came to the conclusion that managers and management was stupid. It's a commonly held belief in our profession: if you're not smart enough to deal with the technology, you go into management. Over time I very slowly learned that the task of management wasn't stupid, it's just very, very hard. That's why all those stupid decisions are still being made; management is much harder than technology because it involves virtually no deterministic factors. It's all guesswork, so if you don't have good intuition you'll probably make stupid decisions. Napoleon wanted lucky generals rather than smart ones.

This is where a programmer’s critical thinking skills will shine.

Granted, it’s difficult to determine the ramifications of question such as,
“What would the impact of using this non-standard syntax be if I made 300,000
library users adopt it?”. However, thinking on such a big scale can only help
you as a programmer, and the bigger you think, the more you help yourself.

Writing is also hard, and you’ll find plenty of instances where the authors
come up short. The burden is on you to prove beyond a shadow of a doubt that
you’re right and the author is wrong. If you’re not bending over backwards to
try to say “well, maybe the author was using it in the context of..”, you’re not
giving them much credit, and might not be putting enough thought into the
process. When you find yourself saying “this code is awful!”, try thinking of
how you would do it yourself. Sometimes you find that you come up with a better
way than the author. Sometimes you’re led right back to the same solution as the
author.