Ask HN: What habits make a programmer great?

I'm old fashioned so I make a distinction between programming and software engineering.

If you want to become a great programmer: read. Read anything and everything you can get your hands. Don't just read books but also read code. Study the great programs written by other great programmers. Then write. Put what you learn into practice. Write some more. It's been said a great programmer can solve pretty much any problem in two weeks and if it takes more than two weeks it's impossible. Not exactly the truth but you should be able to sketch out solutions to even the most sophisticated problems fairly quickly. The intuition comes from your own experience but also because at that point you've learned how to learn -- if somebody asks you to solve X you're at least passingly familiar with system Y and Z that are sort of like X.

A great engineer is something else. This involves careful analysis and deep understanding of the domain. This involves knowledge and contribution to specialized academic and corporate research. This involves the ability to communicate clearly and succinctly. But mostly it involves a highly developed sense of the problems that your clients are actually trying to solve. The big part of it is actually being able to work with and manage a team to evolve a solution that exceeds the client's expectations.

It's rare to be both. These are the mythical "10xers" that can not only deliver innovative solutions but also create systems that make those around them more productive.

Setting aside the fact that your question is loaded ("littered" with incorrect error handling--OK):

1. Return something meaningful, not the bare error you received above.

2. If you do nothing but decorate the error, ignore coverage. Having decorated the error helps debug the full system when the error occurs.

3. If your error handling is more complex (remove temporary files, close handler, etc.), you might want to factor the cleanup into its own function and test it there.

Finally, your code is not really "littered." If you had exceptions, there would be no trace of the possible errors that might occur on the production system. Your coverage will be higher, but when the software will blow up in production, it will not matter then least.

That's a communication problem, I think. You should outline that something working is a prototype, not an end-product. That means it's not maintainable, hard to extend etc...

To convert from a prototype to an end-product, you need to do the other steps.

I frankly do not believe that instinctive empathy is always necessary. Instead, like another suggestion, read good fiction- but also read people's real stories. There's a documentary on the families affected by the Sandy Hook shooting- this was useful to me. There's lots of people writing about their lives in situations you'll never be able to be in. Read them when you can, try to understand them, take people at their word when they say they're experiencing things. Chances are, they don't really have a reason to fake or blow it up nearly as much as it may first seem, even if it seems irrational or incomprehensible at first. Humans are rarely totally without some context or reason to their perspective.

Note: I don't have empathy for myself very well, but my own behavior can tread bizarrely enough that I am forced to examine my own behavior in a way that can be explained to others reasonably. If you can explain others' behavior in this way that isn't condescending towards them, that takes all aspects into their behavior into account, you will come off as compassionate and empathetic regardless of how you feel in the situation. At least this has been my experience.

Hard to say any definite habits that work for everyone, as each person is so different, but just for the fun of it, I'll try to list habits that work for me:

* Keep a diary. Write out problems and solution propositions first, if the solution is not trivial.

* Keep your mind clean, always finish what you started, so you can have completion and not clutter your thought process. This means not leaving code in a state of disarray, should compile when returned back to

* Let go. If the solution does not propose itself, take a break. Sleep over it. The solution will come, with time, not by bruteforcing of overdosing caffeine. Sometimes these work too, but as a habit, better to focus on long term goals than short term successes.

* KEEP IT SIMPLE. KISS! When solution starts to look too complex, it probably is. Break it down, simplify, line by line, so that the code is understandable and easy to read. Write for humans to read, not for machines to parse.

* There is no ready made solution. Accept the fact that to get results, work must be done and days and even weeks might go before getting there.

* It's ok to write code that is not "smart", that is not "perfect", that just freaking works right now as should and expected. It's just code, and in the end it all transforms into zeros and ones. Implement new features gradually towards more flexible and standardized solutions, first find a solution for the problem at hand and remember KISS again.

Some of the main points that come to mind. Especially the point of KISS, is so easy to go overboard with, starting to overthink all kinds of fancy structs, class inherintance models, whatever fancy code-beauty around a solution that could be solved with a simple function and evolved later if needed to something more flexible.

This KISS also applies to general software design, user interfaces etc also, probably the most useful habit is to remember when thinking about systems, keep it simple! It should also be fun to write at least in some level, if it feels like crap, don't do it for your own sake.