←back to thread

414 points henry_flower | 10 comments | | HN request time: 0.436s | source | bottom
Show context
m4r1k ◴[] No.43112034[source]
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
replies(7): >>43112150 #>>43112344 #>>43112772 #>>43114120 #>>43117365 #>>43118374 #>>43118624 #
1. xattt ◴[] No.43114120[source]
I’m wondering what the process was for the early UNIX developers to attain this level of productivity.

Did they treat this as a 9-5 effort, or did they go into a “goblin mode” just to get it done while neglecting other aspects of their lives?

replies(5): >>43114283 #>>43115981 #>>43118732 #>>43118755 #>>43126073 #
2. noisy_boy ◴[] No.43114283[source]
Genius level mind minus scrum/agile nonsense can help.
replies(1): >>43120069 #
3. ironmanszombie ◴[] No.43115981[source]
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!
replies(2): >>43117965 #>>43120528 #
4. deaddodo ◴[] No.43117965[source]
That's fine when it's self-motivated, but it sets a terrible precedent for expectations. Doing things like this can put in management's mind unrealistic expectations for you to always work at that pace. Which can be unhealthy and burnout-inducing.
5. Daishiman ◴[] No.43118732[source]
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.

6. masom ◴[] No.43118755[source]
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.

replies(1): >>43120964 #
7. hylaride ◴[] No.43120069[source]
Impossible! How can the product managers maintain control without the bureaucracy? /s
8. smm11 ◴[] No.43120528[source]
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.

9. jandrese ◴[] No.43120964[source]
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.
10. kragen ◴[] No.43126073[source]
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.