
Education of a Programmer - jasim
https://medium.com/@terrycrowley/education-of-a-programmer-aaecf2d35312
======
euske
One thing I'd add to these principles: I always emphasize when I teach
programming that there's no magic. There's always a reason behind everything
and regular folks like you can understand it. There are people (even among
tech community) who like to say something is "magic" or "beyond one's
comprehension", but don't take their words seriously. Mysticism is just
intellectual laziness. Don't indulge in it.

~~~
adrianratnapala
I'm pretty sure this is not going to help "ordinary" people. Unless they
already think like you and me.

When I was a kid, I wanted to know how all the black boxes worked -- one of my
greatest days was when my father explained the internal combustion engine well
enough that cars no longer seemed like magic.

Later I noticed that many people -- especially when talking about electronics
-- would ask "How does it work?", when they actually meant "How do you use
it?" I thought this was just a quirk of the Australian dialect, but as I
gained more experience with people, I realised it was really an aspect of
human thought.

To most people, knowing "how it works" is no more than being familiar enough
with the magic spells that you can use them with confidence.

~~~
jomkr
Isn't "the magic spells that you can use", exactly how we (programmers) use
interfaces.

I trust that the interface, be it the C++ standard, or boost::whatever, is
well enough tested that I don't need to know "how it works".

It would be nice to know how everything works but there is only finite time in
the working day.

~~~
Berobero
Is it truly possible to have a solid understanding of the interface and its
use, though, without having a reasonable insight into, at least, the likely
implementation of something?

~~~
aynsof
I'm sure this isn't what you meant, but how about something like movement?
I've met doctors who know anatomy like the (ahem) back of their hand, but they
couldn't perform coordinated physical tasks to save their life.

------
Animats
The "end to end argument" in that paper reflects the issue of how dumb the
network should be. This goes back and forth. With telephone switches and Plan
55-A message switching, all the intelligence was in the network. With the
ARPANET, the network did reliable delivery, but the work was distributed among
the dedicated network machines. IP was pure dumb datagram, which was
controversial at the time. It still is; the last few years have seen the
proliferation of non-transparent middle boxes, from the Great Firewall of
China to Comcast to Cloudflare to Google.

~~~
loup-vaillant
One day we'll have 2 available outgoing ports: 80 and 443 —the web. IPv6 won't
be needed because nobody will have servers, and can all be served behind a
NAT. Email will go through webmail interfaces, and there will be a couple
dozen providers in the whole world. Anything else will instantly be rejected
as spam —only spammers use small providers anyway.

We will see conspicuously interesting ads, thanks to ever more accurate,
automated analysis of our communications and browsing patterns. Sometimes,
such analysis will be performed to stop criminals (mainly terrorists,
paedophiles, and intellectual thieves).

How about getting our shit together and starting to fight this nightmare?

------
iliketosleep
I love how he says “revel in the asynchrony” when discussing distributed
systems.

In a more general sense, taking the bull by the horns and dealing with the
underlying, sometimes unwanted, realities of the system rather than burying
one’s head in the sand and pretending the problems do not exist (only to be
forced to deal with them later and apply band-aid solutions that are not
robust).

As he goes on to say _Rather than trying to hide it, you accept it and design
for it._

~~~
joatmon-snoo
There was a PhD thesis that appeared on HN a few weeks ago - Algebraic
Subtyping (which I still have open in another tab because I've been making my
way through it at a dreadfully slow pace) and its core claim is that
traditional type systems start from a simple interface, which results in a
needlessly complex model, whereas starting from a simple model enables the
development of a slightly more complicated, yet still elegant and simple
interface.

The similarities between that claim and this one are striking.

------
jandrewrogers
This article really resonates with my experience.

The section on "performance" is so spot on. It is remarkable how rare it is
that programmers think in these terms. There is no absolute truth to any
particular performance optimization; optimizations only exist within the
context of a complex topology of resource constraints that vary with time and
application. It seems like a lot of work but this type of analysis becomes
routine and automatic with experience. You really do have to evaluate your
optimizations from first principles each time.

Props also for "Einsteinian" (I use the terms relativistic/Newtonian). I
frequently say "all software systems are distributed systems". Programmers
often resist the idea but it actually makes the design of systems much easier
once you fully embrace the implications.

------
MrBuddyCasino
"If someone tries to explain a system by describing the code structure and
does not understand the rate and volume of data flow, they do not understand
the system."

This is something that becomes evident when you stop using OOP languages, and
then you cannot unsee it anymore.

~~~
amackera
Could you elaborate a bit? I'm super curious but I have little experience with
non-OOP languages.

~~~
MrBuddyCasino
You could go and learn Clojure, or Haskell if you're particularly masochistic,
but even C will do the trick. Be warned that it will be frustrating at first,
it definitely takes some brain rewiring.

------
contingencies
Some great quotes in here, though quite a few are effective restatements.

As usual, added to
[https://github.com/globalcitizen/taoup](https://github.com/globalcitizen/taoup)

I particularly liked the _light speed analysis_ technique, the bold statement
that a clean start is a fundamental technique in managing complexity, and the
expression of effective technical management as the design of transparent,
self-coordinating feedback loops.

------
signa11
honestly, i am an ardent believer of the ancient simian proverb (as
popularized by silvanus p. thompson, in calculus made easy): 'what one fool
can do, so can another' (given sufficient motivation, that is).

edit-001: feynman's infamous algorithm contains more detail:
[http://wiki.c2.com/?FeynmanAlgorithm](http://wiki.c2.com/?FeynmanAlgorithm)

~~~
henrik_w
I also like this quote:

"What one programmer can do in one month, two programmers can do in two
months." \- Fred Brooks

------
gavinpc
> I had been designing asynchronous distributed systems for decades but was
> struck by this quote from Pat Helland, a SQL architect, at an internal
> Microsoft talk. “We live in an Einsteinian universe — there is no such thing
> as simultaneity."

Had the author really not heard this idea from Lamport already?

~~~
firethief
Surely, but that's beside the point. After decades of experience working in
its cognitive neighborhood, the author finally got to know that idea well
enough that Helland's point resonated with him. It's no simple matter to go
from being aware of a concept to weaving the concept and all its implications
fluently into ones thoughts. I'm familiar with all the main ideas presented in
this piece, but I still found a lot to think about and took a lot of notes
while reading it.

------
debt
he uses the phrase "anti-fragile" which as far as i know was coined by nassim
taleb in his book "anti fragile" kind of an economist or chaos theorist idk
good book regardless

------
tedmiston
Attempting to read or even skim an article of this length on mobile makes me
wish my browser had a minimap scroll bar. I wonder if that could be feasibly
implemented as a bookmarklet.

