Ask HN: What habits make a programmer great?

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 "you got it"

2) Write some theoretical test scenarios in another blank file (given state, steps, outcome) to verify that it's actually "solved". Discuss with a team member if possible.

3) then write out those functions from 1) inside the existing codebase

4) verify stuff is working

5) only then do abstractions / splitting up into multiple files

For a problem where the solution is already existing, but the implementation lacking (e.g. a refactoring)

1) design the new code (data structures, interfaces)

2) always propose to the team - no ninja-architecture/refactors

3) ensure the solution can be tested, document what should be tested

4) execute on the implementation

YMMV

But:

If you know multiple programming languages. Sometimes adjust for the toolset. Eg. Python or NodeJS for crawling websites. I always abstract it with an api. For eg. Try take a screenshot of a website in c# ( my most proficient language).

SOME tools do get you much faster to the end result with more options. Just make sure you tackle that problem with that programming language and try to abstract it away.

Edit: My solution for website as a screenshot, a c# wrapper for a nodejs api

The API in Nuget ( dot nets package manager): https://www.nuget.org/packages/WebsiteAsImageWebService.Api/

Proper understanding of the problem is extremely important. Great advice.

There is a lot to be gained by going along with the dominant groupthink on a topic, and there is a lot of risk involved in declining to do so. This is especially true as the groupthought picks up steam and gains powerful backers, who will be offended that little-old-you would dare to contradict someone of their high status.

The likelihood that your successes over the conventional/trendy method will be undeniably obvious is very low, especially when you consider that as larger interests and personalities invest in the groupthought, their PR machines will be working to discredit/counteract those who stand to imperil their investment. You will probably not get the punchy ending that you'd need to justify the burn you initiated by going your own way.

You could try to argue that the rest of the team is just trying to follow the zeitgeist instead of thinking about how to generate objective value, but this will hurt much more than just smiling and using the "Tech Flavor of the Week" on the project.

Team cohesion is more important for large-scale productivity than technical implementation details. It's easier to work around a buggy framework than it is to get people to cooperate and release their grudges.

If you want to be a "great programmer" in the sense that you have maximal self-satisfaction, then yeah, you should use whatever you think is best.

If you want to be a "great programmer" in the sense that you're a hot commodity on the market with a strong network full of people who want to give you money, you must recognize that your field of operation is not really computer code, but the delicate egos of the humans around you.

---

Along a less social track: the bigger the technology gets, the more likely that its kinks will get worked out and that it or something based on it will become a driving force in something that is objectively useful/valuable down the road, at which time having the investment in the platform makes it easier to adopt the better tech from both a technical (increased familiarity with tech-specific syntax and concepts) and personal perspective (don't have years of resistance that you've brainwashed into yourself, + accompanying reputation).

JavaScript is a good example of a technology that has been difficult to justify at a technical level in any case where it wasn't mandatory up until very recently. However, its widespread faddiness is now starting to cause actually useful new things to be JavaScript-first or JavaScript-based, even if they're doing that just so they can ride the hype wave themselves.

My experience has taught me the exact opposite: no amount of Google Docs or whiteboarding meetings will tell you what the real problems are, you're only going to find them when you start implementing.

I got burned on my last project: we spent several weeks mostly talking and writing (English) about problems that turned out to be trivial, and got totally blindsided by problems that were not detectable until we actually connected to the firehose of incoming data (it's a streaming/analytical system) and then verified our work. There were lots of subtleties in the way a small portion of messages could be related over days and weeks. Nothing we would have been able to forsee with unit tests or manual inspection. We had to actually write the program to find out what would be hard about it.

To give "urge" more meaning: These days I get a noticeable weird feeling in my gut if I'm working in a environment where there are too many unknowns.

further, try to create an environment where others (particularly others who are less powerful) feel comfortable voicing their concerns and are secure enough to state when they don't know or don't understand something.

e.g. if people are worried they are going to be fired or ridiculed in a group setting for not knowing a thing then it would be unreasonable to expect them to say "i don't know".

That attitude hurts everyone who has to support what you write.

edit: Reformatted as a habit "Make sure whatever you write can be supported without unnecessary headaches."

1. Re-structure your logic so the error cannot happen

2. If you can't do 1, recover from the error silently and continue on with the program

3. If you can't do 2, handle the error gracefully and notify the user of what state is changed, letting them choose whether or not to continue

4. If you can't do 3, inform the user of what happened and ideally provide the user corrective action they can take, then exit cleanly with an error code

5. If you can't do 4, exit cleanly with as descriptive of an error code as you can

6. If you can't do 5, you're probably faced with crashing or exiting with some unhandled exception. This is a bug that should never go into production.

Always be looking for opportunities to move your code up that hierarchy. Moving every 6 to 5 is my personal bar for barely acceptable quality. 4->3 is usually a big win (basically anything that prevents the program from exiting).

1. If at all possible start from something existing. It is entirely possible by the time you are done nothing remains of the existing. That's fine. To me, it's easier to tweak existing code than fill in an empty editor window. To some, an empty editor window is all opportunity, to me, it's analysis paralysis.

2. Always be ready to throw everything away. You perhaps will save a few choice lines but be ready for your first, sometimes even the second solution to suck badly. This is fine. Putting in more time to have an easier to maintain solution is always useful.

3. To continue from there, easier to maintain code is king. Unless you are writing something extremely time critical do not try to be clever. A little slower is okay (and yes, I am in the performance consultancy business) if it significantly decreases the maintenance burden. Clever hacks belong to toy projects and blog posts. The next person who maintains it will be stupid to the code -- even if it's yourself. That clever hack is now a nightmare to untangle. In short: always code under the assumption that you will need to understand this when the emergency phone kicks you out of bed after two hours of sleep in the middle of the night. The CTO of Cloudflare was woken to the news of Cloudbleed at 1:26am.

What if you write a function in Go that's littered with the usual

  if err != nil {
    return err
  }

Any tips on how to do this? I don't often feel things for myself and it's even rarer to experience empathy at a level I can detect. I meditate to try to better understand and learn to detect my feelings, but haven't made much progress yet (I use Headspace).

Especially seems that a lot of devs forget about the first point.

In my experience, when I've started doing gym & swimming I became to feel less "burned out" as well as my self-esteem improved :-)

If you try to work on a complex algorithm with little sleep, you tend to throw a wrench into it.

Seems to be Gall's law:

https://en.wikipedia.org/wiki/John_Gall_(author)#Gall.27s_la...

(...Don't polarize on one end of the Specialist vs Generalist debate.)

Since improvement of experience and quality of output is roughly logarithmic, it is (depending on the specialisation of the task at hand) better to have a person that has worked ten years to be 7/10 in 5 displines than 10/10 in one and 2/10 in the remaining 4.

Of course, if you only care about the one discipline, get the 10/10 guy. But in real use cases, things are only occasionally atomic, and lack of understanding of adjacent processes and disciplines can prove fatal.

> Don't ignore constant factors. Sometimes an algorithm with asymptotically worse performance will perform better in practice because it has much better cache locality.

Forget the cache, sometimes they're just plain faster (edit in response to comment: I mean faster for your use case). I've e.g. found that convolutions can be much faster with the naive algorithm than with an FFT in a pretty decent set of cases. (Edit: To be specific, these cases necessarily only occur for "sufficiently small" vectors, but it turned out that was a larger size than I expected.) Caching doesn't necessarily explain it I think, it can just simply be extra computation that doesn't end up paying off.

This is my #1 pet peeve with GitHub. When I first look at an unfamiliar repo, I want to get a sense of what the code is about and what it looks like. The way I do that with a local project is by looking at the largest files first. But GitHub loves their clean uncluttered interface so much, they won't show me the file sizes!

This is true not just for data science but when trying to solve any numerical problem. Using a spreadsheet (or a R / Python notebook) to implement the algorithm and getting some results has helped me in the past to really understand the problem and avoid dead ends.

For example, when building a FX pricing system, I was able to use a spreadsheet to describe how the pricing algorithm would work and explain it to the traders (the end users). We could tweak the calculations and make sure things were clear to all before implementing and deploying the algorithm.

Great advice!

I work with a lot of traders. One antipattern I noticed is that when there's a problem with the data, they'll do all sorts of permutations and aggregations and then scratch their chins and ponder about it for hours.

Go to the fucking source and find an example of the problem! Read it line by line, usually it will be obvious what happened.

Corollary: Don't assume your data is correct, most outliers ina large data set are problems with the data itself. Build a few columns that serve as sanity checks. One good example is a column that shows the distance between this sequence number and the last, anything >1 is a dropped message.

6. Use assertions for defining your expectations at each stage of the algorithm - they will make the debugging much more easier

I reformatted this in a Google Doc, if anybody wants: https://docs.google.com/document/d/1Pix3-l3Qz1aLOuxoiiP1PTV6...