Ask HN: What habits make a programmer great?

Post by mustardo » Thu, Jul 06, 2017, 10:05 AM UTC

majewsky wrote: post #46

henrik_w wrote: post #16

A few habits I've found that work well for me: 1. Start small, then extend. 2. Change one thing at a time. 3. Add logging and error handling early. 4. All new lines must be executed at least once. 5. Test the parts before the whole. 6. Fix the known errors, then see what’s left. Taken from here: https://henrikwarne.com/2015/04/16/lessons-learned-in-softwa...

> All new lines must be executed at leaat once. What if you write a function in Go that's littered with the usual if err != nil { return err } and the error that's being propagated is hard to reproduce, e.g. a filesystem error? I never cover those "return err" in actual programs.

Post by pricechild » Thu, Jul 06, 2017, 10:16 AM UTC

mdular wrote: post #6

ankurdhama wrote: post #2

Focus on the problem and not the tools ceremony around it. Don't follow the herd and the hype. When given a problem, keep drilling the problem until it is absolutely clear to you and then only work on solution.

This. I often encounter situations where a day or two were spent creating a mess of classes and abstractions, yet the actual logic to solve the problem still hasn't materialised. A defense about "code quality" or "not wanting to write spaghetti code" is often made. My recommendations for a problem you don't have a clear solution in mind for: 1) Hack some pseudo-code spaghetti together in a blank file until you think…

Post by sgift » Thu, Jul 06, 2017, 10:18 AM UTC

nostrademons wrote: post #31

sgift wrote: post #17

Earlier quoted context omitted.

Please, everyone who thinks, "I just expect correct inputs" take note of part two. I've had so many discussions with colleagues about that "Why don't you check for null pointers and give an error message?" "I think it's perfectly fine to just crash with a null pointer, I don't expect null pointers." That attitude hurts everyone who has to support what you write. edit: Reformatted as a habit "Make sure whatever you wr…

Only if a.) you can do something to recover from the null pointer or b.) you can provide more information about its cause than you could recover from an ordinary stack trace. Otherwise you're just adding code without changing the ultimate result of the NPE: a debugging session. Assertions, however, are great. If you can force the program to throw that NPE closer to the point where it actually illegitimately became nu…

Post by SwellJoe » Thu, Jul 06, 2017, 10:35 AM UTC

mustardo wrote: post #61

majewsky wrote: post #46

Earlier quoted context omitted.

> All new lines must be executed at leaat once. What if you write a function in Go that's littered with the usual if err != nil { return err } and the error that's being propagated is hard to reproduce, e.g. a filesystem error? I never cover those "return err" in actual programs.

Consider using a language that has exceptions instead of 1980's error codes

Post by psynapse » Thu, Jul 06, 2017, 10:40 AM UTC

photonios wrote: post #55

- Add value. Train yourself to only do things that add value. Value is loosely defined. It can be going the extra mile smashing that bug that everybody is complaining about. It can be whipping up a mind blowing demo to pull in that big customer. Nobody cares if you work 80 hours a week, but it's not adding any value. Get in the habit of working on things that bring value to others. - More communicating, less coding.…