Hacker News new | past | comments | ask | show | jobs | submit login

I have a similar story. After taking a not-unusual academic path from Math through Linguistics to Cognitive Science, I eventually got started in programming to support my research. I had previously avoided programming largely out of fear. When I thought of the effort it took me to produce a half page of correct mathematics, I blanched at the thought of trying to write thousands of lines of working code.

When I finally delved into Perl, Python, C, etc. and reading open source code (mostly C, mostly greenfield projects), I was flabbergasted to discover how much coding is by guess and by golly. I am genuinely unable to grasp how a person with the intelligence to master the technical details that programming requires could be so lacking in ability to elegantly conceptualize a problem domain and produce suitably organized code. I have come to wonder if it isn't a psychological inhibition. Like some people keep their desk obsessively neat but others work amid a filthy messs, not because they're too lazy to clean but because they're more comfortable that way.

Once in a while, I see a programmer demonstrating the clarity of analysis I'm accustomed to seeing in science (and even the humanities). This is the kind of programmer who will produce a shorter and clearer solution in C than the average programmer will produce in Python. It's rare, though, so I'm constantly amused/irritated by the frequently stated assumption on HN and elsewhere that programmers have superior analytical skills.




For any non-trivial (code size, complexity etc) programming-problem

there are programmers with little analytical skills but given enough time they will end up with code doing mostly the right things... unfortunately from the out side there is no way to tell to what degree the code evolved from try and error or from true analysis...

Then there are skillful and analytical programmers who over the course of the dev cycle for a problem burn out their "analytical mana" due to simple exhaustion, external pressure or both or simply because the problem grows conceptually over their 'head-room' during the work on it... backtracking and reworking already written down code is still cumbersome, always a risk and unpleasant ('trashing something already done')

Then there often is time eroding the most clean, analytical code with every little update into a mass, unless ofc energy is spent to re-analyse and rewrite.

Then there are ofc some differences between areas in which programming is used.

'how much coding is by guess and by golly'

I hear this quite often from ppl with math, physics background etc. who are often accustomed to read expositions of ideas in math papers: presenting the final versions of the formulas.

Code quite often is more equivalent to the notes a mathematician would make and use before summarizing them into the published paper.

Those Math-Whitepapers are executed in the heads of the humans so they tend to try to keep it clean and minimal and analytical sound.

Those Code-Artefacts are executed by machines which don't care at all about such things, thus as long as the humans are satisfied with the end-results the 'inner-structure' tends to erode. Code is read more often than written but it is often only read later and by other people, so ... first things first: it has to work, right? ;)

But yea, I mostly agree that many programmers slide down into a habit of very special kind of

"reactive programming" ;)

where they try to hit the target by incrementally zeroing down on a solution reacting only on the results of the previous version of the code. Due to the action - reaction structure this tends to be quite flow-inducing and satisfactory... but the results are seldom analytically pleasing or sound.


I think that code is often written in much the same way that metal forgers hammer metal into shape. It takes a while, there is a lot of frustration involved, lot of mistakes made in the process of getting the end-result, and often times when deep skill is not present, bulldozer approach to solving the problem become the norm. Clever code is used, and overlooked like small landmines. Modify the clever code and the landmine blows up in your face w/ 12 broken features & the whole application turned out to rely on some clever piece of logic that befuddles most people from a single glance.

Writing code is mostly a creative process. When you used standardized tools, the creative process eventually starts to look common, but when you learn how to use the general tool set which might be analogous to a carpenter's tool belt, then you end up with a more custom tailored product which is very specialized for a specific task. Since there are too many ways to solve any specific problem when the tools you are using are equivalent to screws, nuts, hammers, screwdrivers, anything can be fabricated to make the process work.

The real key here is that when creative-problem-solving meets design-pattern-nirvana, then you can start refactoring into the standard patterns that everyone is accustomed to seeing, and then things start to make more sense.

It's like the PubSub pattern is beaten to death in so many different workflows, but ultimately it's the same shit. Event-based programming is PubSub. Clicking causes a publish/emit, and every entity subscribes to these events/emits on a particular address of a specific pattern.

When we are all starting to speak the same language, I think writing code will become more a practice in writing in our general idioms. Lot of programmers are not formally trained, and nobody does apprenticeships before they write code, they just start.




Applications are open for YC Winter 2020

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: