2024-06-06 Learning to be a programmer
======================================

I was talking with @akkartik@merveilles.town and @TodePond@mas.to
about programming.

@TodePond@mas.to got me thinking about communities around programming
when they wrote:

> the problem i see is that no one is talking to each other. everyone
> is trying to build their solutions in isolation - as island
> communities. in my opinion we shouldnt build anything new, we should
> try to make compatible the mindsets and tools that we already have.
> its an extreme viewpoint but i see no one else taking it, so im
> taking it.

I can definitely see many people writing their own software and many
more people using existing software and never adapting it. I do it,
too!

To put a really hurtful spin onto it: we rarely sit next to a newbie
using our software. I never do. Never. We should listen to them
muttering to themselves for the first four hours. The bugs they
attribute to their own incompetence; the confusing usability issues
they never report… and now imagine sitting next to a newbie looking at
our code, trying to find their way. No comments. No helpful guides.
The code is the best documentation, some people say. I guess they
haven't seen my code. All those readability refactors I didn’t do. All
these questions nobody ever asked me. People look at the code and
don’t come back.

Those are my free software nightmares when I look at all the things
I’ve written with a community of one. 😳

Anyway, I guess what I want to say: if you feel like you write free
software for others but nobody joins your community, you are not
alone. We are all together in this, alone. 😥

I think the reason for this has to do with how hard it is to
understand code by just reading it instead of writing. It’s super hard
to get into another code base. And it is hard to write code such that
it is a welcoming ramp up. I’d say Emacs is one of the examples where
it worked but we don’t actually know whether the approach is “good”. I
certainly used Emacs for a year or two before writing my own init file
way back when.

I'm not sure which parts enable it and I'm not sure if having more of
the same would result in more programmers modifying the code and
sharing their modifications.

* Good documentation of the programming language, Emacs Lisp

* Good documentation of the software itself, Emacs

* Good documentation of the code, with documentation strings and
  comments throughout the code base

Nearly every function is documented, nearly every global variable is
documented, the concepts are documented in the manual, the language is
documented in the manual – it's a gigantic group effort to build that
ramp.

I think this is how you get started modifying Emacs: with an init file
that customizes some part of it.

That reminds me of the post by Peter Seibel (2014) that I recently saw
linked in my feed:

> It was sometime after that presentation that I finally realized the
> obvious: code is not literature. We don’t read code, we decode it.
> We examine it. A piece of code is not literature; it is a specimen.
> Knuth said something that should have pointed me down this track
> when I asked him about his own code reading: … He’s not describing
> reading literature; he’s describing a scientific investigation." –
> Code is not literature

I feel this is how I approach new code: find a tiny task and see
whether I can make that change. Usually this requires building the
code, searching the best location, learning about the code style,
investigating the libraries used, and so on. There are many strings
attached.

I don't know how else to do it.

The same is true at the office. Our code base is about four million
lines of code. Newbies get assigned small issues to fix and need to
ask a gazillion questions and that's how they learn.

If only there were a better way. If there is, I don't know it.

@akkartik@merveilles.town linked a guest post on their blog (2018):

> We all read code already; it’s just that we usually read when we
> want to edit. And the comprehension that questions about reading
> are really concerned with—it comes from both reading and writing,
> interleaved in complex ways. That hacking produces better
> comprehension than passive, linear reading fits with what we know
> about learning. – Nobody's just reading your code, by Stephen
> Malina

@akkartik@merveilles.town summary of our little interchange gives me
pause:

> We live in a world where everybody is illiterate, unable to read
> computer programs. Everybody. A tiny minority can write programs,
> but even they can't read programs written by others without 1000x
> effort. They/we oppress the rest.

Indeed, how not to be part of this, I wonder.

​#Programming

2024-06-07. @Sandra@idiomdrottning.org says:

> I think “programming for the household” is actually awesome.
> Automating our own lives, autonomously, not squeezing our lives
> into someone else’s automation. – There’s no shame in programming
> for yourself