Comment by m4r1k 2 days ago
I once saw a talk from Brian Kernighan who made a joke about how in three weeks Ken Thompson wrote a text editor, the B compiler, and the skeleton for managing input/output files, which turned out to be UNIX. The joke was that nowadays we're a bit less efficient :-D
> low level projects that rely on as few external libraries
I think this is key. If you already have the architecture worked out in your head, then it's just smashing away at they keyboard. Once you have a 3rd party library, you can spend most of your time fighting with and learning about that.
Exactly. Both projects mentioned in this thread (UNIX, Git) have clean cuts visions of what the authors wanted to achieve from the beginning. Nowadays it is almost impossible to FIND such a project. I'm not saying that you can't write another Git or UNIX but most likely you won't even bother using it yourself, so what's the point? That's why I think "research projects" don't fit here -- you learn something and then you throw them away.
What I have in mind are embedded projects -- you are probably going to use it even when you are the only user. So that fixes the motivation issue. You probably have a clean cut objective so that clicks the other checkbox. You need to bring a dev board, a bunch of breadboards and electronics components to the cabin, but that doesn't take a lot of spaces. You need the specifications of the dev board and of the components used in the project, but those are just pdf files anyway. You need some C best practices? There must be a pdf for that. You can do a bit of experimental coding before you leave for the cabin, to make sure the idea is solid, feasible and the toolchain works. The preparations give you a wired up breadboard and maybe a few hundred lines of C code. That's all you need to complete the project in 3 weeks.
Game programming, modding and mapping come into my mind, too. They are fun, clean cut and well defined. The thing is you might need the Internet to check documents or algorithms from time to time. But it is a lot better to cut off Internet completely. I think they fit if you are well into them already -- and then you boost them up working 3 weeks in a cabin.
There must be other lower level projects that fit the bill. I'm NOT even a good, ordinary programmer, so the choices are few.
The interview is here: https://www.youtube.com/watch?v=EY6q5dv_B-o
One hour long, and Thompson tells a lot of entertaining stories. Kernighan does a good job of just letting Thompson speak.
I can assure that wasn't the case in our desktop software for Windows, and that already feels like trolling.
Not even Nokia NetAct took half as much, given its complexity of distributed CORBA services written in C++, nor the CERN TDAQ/HLT builds I was responsible for.
Back in my early career, the company I worked for needed an inventory system tailored to their unique process flow. Such system was already in development and was scheduled to launch "soon". A few months went by and I got fed up with the toil. Sat down one weekend and implemented the whole thing in Django. I'm no genius and I managed to have a solution that my team used for a few years until the company had theirs launched. In a weekend. Amazing what you can do when you want to Get Shit Done!
I worked at a place in love with their ERP system. Some there had been using it 30+ years, since it ran in DOS.
My Excel skills completely blow, and I hate Microsoft with a passion, but I created a shared spreadsheet one long Saturday afternoon that had more functionality than our $80K annual ERP system. Showed it to a few more open-minded employees, then moved it to my server, never to be shown again. Just wanted to prove when I said the ERP system was pointless, that I was right.
A big one is the lack of peer reviews and processes, including team meetings, that would slow them down. No PM, no UX, just yourself and the keyboard with some goals in mind. No OKRs or tickets to close.
It's a bit like any early industry, from cars to airplanes to trains. Earlier models were made by a select few people, and there was several versions until today where GM and Ford have thousands of people involved in designing a single car iteration.
IMHO the biggest thing is that they were their own customer. There was no requirements gathering, ui/ux consultation, third party bug reporting, just like you said. They were eating their own dogfood and loving it. No overhead meant they could focus entirely on the task at hand.
We aren't talking about a very large amount of code here. Mainly the process was implementing several similar systems over the previous 10 years. You'd be surprised how much faster it is to write a program the fifth time, now that you know all the stuff you can leave out.
A lot of the supposed "features" we have in Unix nowadays are the result of artifacts resulting from primitive limitations, like dotfiles.
If you're willing to let everything crash if you stray from the happy path you can be remarkably productive. Likewise if you make your code work on one machine, on a text interface, with no other requirements except to deliver the exact things you need.
I'd argue that ordinary programmers can perform the same *type* of exercises if they:
- Put away a few weeks and go into Hermit mode;
- Plan ahead what projects they have in mind, which books/documents to bring with them. Do enough research and a bit of experimental coding beforehand;
- Reduce distraction to minimum. No Internet. Dumb phone only. Bring a Garmin GPS if needed. No calls from family members;
I wouldn't be surprised if they could up-level skills and complete a tough project in three weeks. Surely they won't write a UNIX or Git, but a demanding project is feasible with researches allocated before they went into Hermit mode.
I also think people under estimate how much pondering one does before starting a project.
I think so. I don't think Ken had zero thought about UNIX and then suddenly came up with a minimum but complete solution in under 3 weeks. Previous experience also tells a lot too. Wozniak was able to quickly design some electronics, but he probably already bagged 10,000 hours (just to borrow the popular metaphor) before he joined HP.
> I’ve heard that Torvalds build Git in 5 days
And it shows.
I am joking of course, git is pretty great, well half-joking, what is it about linux that it attracts such terrible interfaces. git vs hg, iptables vs pf. there is a lot of technical excellence present, marred by a substandard interface.
"never trust a test you've never seen fail." has kept me honest on more than one occasion.
It is also the case that the first 80% of a projects functionality goes really quickly. Especially when you are interested and highly motivated about the project. That remaining 20% though. That is a long tail, it tends to be a huge slog that kills your motivation.
Ken is definitely a top-notch programmer. A top-notch programmer can do a LOT given 3 weeks of focus time. I remember his wife took the kids to England so he was free to do whatever he wanted. And he definitely had a lot of experience before writing what was first version UNIX.
Every programmer that has a project in mind should try this: Put away 3 weeks of focus time in a cabin, away from work and family, gather every book or document you need and cut off the Internet. Use a dumb phone if you can live with it. See how far you can go. Just make sure it is something that you already put a lot of thoughts and a bit of code into it.
After thinking more thoroughly about the idea, I believe low level projects that rely on as few external libraries as possible are the best ones to try the idea out. If your project relies on piles of 3rd party libraries, you are stuck if you have an issue but without the Internet to help you figure it out. Ken picked the right project too.