Hacker News new | ask | show | jobs
by lmilcin 2185 days ago
The gap between learning to code and producing usable software is...

... ability to perform complicated abstract reasoning, ability to reflect on own performance plus some experience.

Almost everybody is able to perform simple programming tasks in isolation. For example, follow a tutorial to build simple app using framework X or google solution to problem Y and ctrl-c/ctrl-v into your codebase.

Complicated abstract reasoning is necessary to be able to put together abstract concepts, flows, in new patterns that are required by the application.

Ability to reflect on own performance is necessary to learn from mistakes, look critically at the code, understand strengths weaknesses, evaluate solutions, etc. A person that lacks ability to reflect on own performance might be for example deaf to complaints of other people, might be blind to problems with the code they are producing (for example overcomplicated code), or trying to find faults anywhere else but themselves.

If you can't reflect on yourself you are cut off from being able to effectively learn and improve and this is critical to being able to produce usable software.

Regardless of how intelligent and self-reflective you are, some experience is needed.

3 comments

Quoting this because I would only fail to phrase it any better:

> Getting hooked on computers is easy — almost anybody can make a program work, just as almost anybody can nail two pieces of wood together in a few tries. The trouble is that the market for two pieces of wood nailed together — inexpertly — is fairly small outside of the "proud grandfather" segment, and getting from there to a decent set of chairs or fitted cupboards takes talent, practice, and education.

- Poul-Henning Kamp

[0]: https://queue.acm.org/detail.cfm?id=2349257

The thing is; there is actually a big market for nailing two pieces of wood together; there is just no market for someone whose only skill is nailing two pieces of wood together [0]. Consider a chair where one of the cross supports got unattached. You could by a new chair, or hire a carpenter to fix it. In most cases, unless you already have a maintenance staff, you would probably just fix it yourself.

Similar with programming. If you core product is software, you should probably have an expert. However, if the software is just ancillary; you can often get by with just the basic skills.

[0] Maybe assembly lines; but with modern manufacturing technology, I doubt that is the case anymore.

That is excellent quote. Thank you.
> ... ability to perform complicated abstract reasoning

This seems like it's kicking the can down the road. It is like saying that people need the ability to perform memory. It's tautologically true that these are both necessary for complex learning.

A lot of the challenge for learning systems is figuring out how to help people develop the mental schemas they'll be pumping abstract reasoning through. (Similar to the design of procedural pieces, which most coding lessons focus on!)

This is not my experience at all. I see the gap much more related to identifying and streamlining the real use cases, the things people really want out of the software, as opposed to whatever un-tethered flights of fancy originally drive the creator.
This is part where you learn to reflect on your own performance. As you build more and more software you learn from your mistakes to build what the clients want/need. And what kind of your fancy is helpful and what is not.

I know very intelligent people who, nevertheless, build shit software because they think they are right and everybody around them is wrong. You can't identify and streamline anything unless you are first open to opinion.