Hacker News new | ask | show | jobs
by rectang 87 days ago
I ran reading groups over several years a medium-sized startup I worked for and for an open source community I was a part of. The groups were targeted not only at engineering staff but also semi-technical positions such as product management and low-skilled data pipeline specialists, with the aim of building bridges between departments and internal recruitment.

Running those reading groups was basically how I acquired a lot of knowledge I didn't get because I didn't major in Comp Sci as an undergrad.

Books/MOOCs we went through:

* Pro Git (Chacon) [three times]

* Programming Language Pragmatics (Scott)

* Calculus first semester (Coursera/OSU/Fowler)

* Eloquent JavaScript (Haverbeke)

* Learning Perl (Schwartz/Foy) [two or three times]

* Coding the Matrix (Coursera/Brown/Klein) [didn't finish]

* Object-Oriented Programming: An Evolutionary Approach (Cox)

* Learning Core Audio (Adamson/Avila)

The level of commitment from the participants was mixed. Nobody came for the free lunch (although arranging free lunch was essential in getting people to show up). Many people had ambitions that outstripped their commitment. But there were plenty of people who took advantage and learned tons.

One fellow, who I feel immensely fortunate to have known, went from zero experience to arguably our most productive IC within 2 years, and eventually landed at a FAANG. He also took a turn leading the discussion group.

Another participant was a Product Manager who became much better able to communicate with Engineering after improving her understanding of programming fundamentals.

The sessions were generally organized around questions that people would bring about the material — my motto was "we'll struggle through together". I preferred questions posed by others but always had enough of my own to fill space.

The tips I would have for people running such groups:

First you need a discussion leader. You need someone who can get the group unstuck and who knows the material. It's the same dynamic as having a good TA for a college discussion section.

Second, remove all friction. Corporate won't buy books? Screw it, I bought 'em myself. Corporate won't arrange for lunch? Screw it, I bought it for everybody. (Our CTO was highly supportive but once the company got acquired we couldn't get budget approved anymore). The total outlay I made leading the group was a few thousand dollars — far less than I would have paid for formal courses where I would have learned less.

1 comments

Wow, Cox's original Objective-C book? Interesting historically, but it's hard to imagine it was of much pragmatic use, even if you're working in Obj-C as your day-to-day. Still, it's an interesting artifact of the early OO age, and the metaphor of libraries of objects as integrated circuits was interesting.
Yes! And I wouldn't have picked it, but I went along with it when someone else wanted to read it.

The "software IC" metaphor may not have caught on, but these artifacts of early experimentation, competitors against what evolved into mainstream OOP, are many times more interesting to read than the Nth "OOP sux" article.

EDIT: I just went back over some of my notes... Cox predicted that companies would compete to provide different implementations of common interfaces ("software ICs"). In restrospect, that didn't happen but Cox's prediction was wrong in such an interesting way: software orgs rather than customers assumed control over interfaces.