Software Engineer at Clarivate Analytics (2017–present) · Upvoted by , Co-developer of Envelope, a visual engineering simulation systemAuthor has 560 answers and 2.6M answer views · 9y ·
- A bug is not a property of the code; a bug is a property of the programmer. If you have a bug, that means that the model of the problem in your head differs from either the actual state of the code or the actual state of the problem. Fix your mental model of both and then 'fixing' the bug becomes simple.
- Every language and programming paradigm is a tool. Every 'best practice' is a tool. Yes, even your favorite. Use tools when they are useful, and don't use them when they get in the way. Once you start a project, you are all but locked into the tools you chose -- so, choose the tools that, at the end of the project when the code is two maintenance cycles away from being thrown away and rewritten, you would have wanted to use in the first place. This means using object orientation only when the best way to represent what you're trying to do is objects, and using functional programming only when your code benefits from a functional style. Ideology only gets in the way.
- Temporary programs aren't. Particularly if you are in industry, assume that you will still be maintaining any piece of code that goes into revision control or becomes part of a process for the next ten years, unless you rewrite it first. Write code that you will still understand in ten years, and use technologies that you used ten years ago and that you expect you will still want to use in ten years.
- Every language you learn adds to your toolbox. Every concept you learn adds to your toolbox. Some tools are less widely applicable than others, but having exactly the right tool is what separates very skilled programmers from your average CS graduate (who has, over the course of the curriculum, been taught some large subset of what academics in 1993 thought were the most widely applicable tools).
- Don't neglect communication skills. The best design in the world is worthless if you can't explain it to your boss, and worse than worthless if you can't explain it to your replacement (when your boss inevitably fires you for putting a giant black box in the middle of a production system).
- If your predictions don't match the operation of the system, it's your predictions that are wrong. Don't say "this is impossible": it happened. Human memory and human cognition is incredibly crappy. The behavior of the system is the reality you need to deal with. Don't let your ego prevent you from being a competent programmer and a competent debugger by privileging your mental model of the world over the world itself.
11.9K views ·
View upvotes
· 1 of 221 answers
Something went wrong. Wait a moment and try again.