Ask HN: What does fantastic programmers do differently than the average one? | Hacker News Reader

Ask HN: What does fantastic programmers do differently than the average one?

23 pointsdebanjan1610 comments

How do extraordinary programmers work? Have you worked with any of them? Or maybe you are one of them?

How do their minds work? What is their workflow that sets them aside from all the other programmers?

I have worked with a couple. A first in zoology who moved to code and wrote games in assembler, and also complete compiler systems for minified versions of the languages of interest: Algol, Fortran, C -He also tinkers in hardware at all levels and can re-frob a radio into a theramin from the principles of how circuits work, or can make a magnetometer based 3D action glove from bits in his toolbox. Another who coded C compilers for a living before GNU destroyed the marketplace. A third who uses FP (Haskell) to reason about systems as types, before even considering code to mutate those typed objects.

The first thing is, they all tended to have a really strong grounding in mathematics, around logic, statistics and related subjects. They had underlying conceptual models grounded in the formalisms of a maths discipline.

The second thing is that they had very high functioning reasoning skills. If <this> then <that> was very strong in their ability to see inherent linkages between specific and general, to take an abstraction and apply it, or to find a mapping to that concept in another domain, work in that domain, and map back into the field which applied in the first instance.

The third thing is that they seemed to go from solution hypothesis to code very naturally: they didn't hesitate to follow a code path, there was no sense of "suck it and see" -To me, this is the bit which makes me really wonder WTF was going on because my own code is littered with "this failed" attempts to get to the functional outcome.

So, there's a lot of maths, a bit of process in abstract reasoning and a giant ocean tanker of confidence.

I have watched these people sit for 6 hours exploring how to use assembler to shave two instruction cycles off a task. The focus required to model the behaviour of the system and do this in a pre-omptimising compiler world, in the tools of the machine, were amazing.

As a life long programmer who has also led teams of other programmers I would say lighten up on the expectation of formal math. While this example sounds a real good one, there are different kinds of programmers who excel and conventional maths aren’t consistently their strong suit (though logic and algorithmic thinking may be imperative.)

One thing which is curious, how many good programmers aren’t formally trained as programmers. I once worked for a guy who began as a finance geek who started his own million dollar company by teaching himself how to program. One thing that impressed me was his ability to sit down and power through things until he got them done. Unlike myself, who avoids doing work until the perfect solution emerges from the problems’ complexity (and then writes the minimum amount of code in the most abstract form to get the job done.)

Success takes many forms, so exclude nothing by expectation!

> They had underlying conceptual models

This is so important for every STEM subject. Ideally, having working mental models of [computers, processes, the nature] should be the goal of education.

Besides that, i observed really good natural language skills in people, who are good at programming. I guess, this ability (to write good code), complements conceptual understanding. In some papers you can observe, that the authors master the concepts, but their code looks like written by a novice.

”The third thing is that they seemed to go from solution hypothesis to code very naturally”

Functional thinking tends to do that, irrespective of the language. Once you have the ”pipeline” in your head, you can just write it out.

> Functional thinking tends to do that, irrespective of the language.

Can you expand on this a bit more?

And if possible, some books that teach this kind of thinking?

A good and practical first step is to learn to use map, filter and reduce to solve everyday problems, such as transforming an array of recursive definitions to an array of React component trees. Hint: define the function separately from where it is applied, and also apply it recursively.

Do you have any book recommendations?

Not really. References are enough.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

The characteristics that I think contribute are extreme attention to detail, patience, ability to extrapolate from examples encountered to fine-grained concepts, and lots of practice either on the job or via other transferrable field or hobby. Having a strong sense of how machines work, as in being able to guess which tradeoffs will pay could be a power-up. Typically, a person who wants to learn for its own sake and enjoys hard challenges like a game.

Being able to adapt and relate, draw analogies from different situations and subject areas can be a big boost in ability to come up with outside-the-box solutions. I think most of this sums up to thinking abstractly most of the time, rather than when necessary, or 'architect'ing. When something doesn't work, it didn't merely not work, it didn't work because... of some specific aspect or misconceptualization.

Subdividing a problem can be done many different ways. We want to separate concerns, but which ones, in what order and by what means. Keeping both higher-level and lower-level concerns in mind simultaneously speeds filtering of possibilities to something that has a good chance of working out.

Another good one is knowing what's fair game to modify when coming up with a solution is larger than one might think. Beyond the code, there's toolchains, data formats, even UX or documentation could be part of the answer.

Edit: I can't stress enough the importance of naming things. If you're bad at naming things, it could be you don't know or aren't even choosing the things consciously. Often, you start out needing a name for something but put in the time to think "what is it, why is it, is it more than one thing?" when you pick out names. I think practicing good naming probably gets you moving along the right path. Keep things as simple as you can, don't add to cognitive load by naming similar things with arbitrary differences in their names.

Extraordinary artists and technicians are not necessarily the most skilled with the tools. Sometimes they just filled a void and did something new.

Reply on news.ycombinator.com