Joe the office mate | Hacker News Reader

Joe the office mate

github.com

495 pointsabecedarius47 comments

> Joe wrote amazingly simple programs and he did so in a peculiar way. First he wrote down the program any old way just to get it out of his head. Then once it worked he would then immediately create a new directory program2 and write it again. He would repeat this process five or six times (program5, program6, ...) and each time he would understand the problem a little better and sense which parts of the program were essential enough to re-type. He thought this was the most natural thing in the world: of course you throw away the first few implementations, you didn't understand the problem when you wrote those!

I thought I was the only one who did that.

Good code isn't written, it's re-written.

It is scary when something "works the first time", because it probably doesn't.

There's different ways to re-write though. I tend to assume I couldn't come up with the right design if I tried. So I will leave my naive implementation in place until USE shows me a bug or a new feature and then that IMPLEMENTATION shows me where my architecture is clunky, and how to fix the original thing.

Over time, everything important gets a full rewrite or four, but only piece by piece.

Generally I assume in an implementation vacuum the long term spec isn't even well defined so I would never just rewrite something immediately.

Sometimes if a module proves difficult to amend I will start over from scratch. But usually by then I have tests and use cases I am confident in.

I love the idea of people doing these rewrite series though... not trying to be evangelical. Just describing a different kind of rewrite.

Back when rocks were young, one of my hobbies was writing assemblers because the ones available were generally terrible. My first few attempts were pretty bad. The fifth or sixth assembler that I wrote was commercial quality; it was fast, had macros, supported most of the different microprocessors that our platform had, and became widely used. It's been forked and is still in active development today, 35 years later. I'm still proud of it.

But those first efforts were indeed awful, and those were preceded by even more false starts; it took 2-3 years of iteration [not full time!] to get to something that was good.

(Simple assemblers are, well, simple. But if you're in an industry where it's common to write a ton of assembly -- like the early gaming industry was -- you start gauging assemblers by the creature comforts they provide, such as a decent macro capability, cross-reference and listing support, performance, and support for chip manufacturer assembly syntax).

I've been trying to build a web-based IDE for more than 10 years. The first one was a PHP script that had write access to change the files in its own directory.

I've started over completely, at least 6 times, trying entire new languages, entire new feature sets, entire new hosting paradigms.

Each time I try again, I get closer to something professional. Each time the hacks get a little too messy and realize I'm out of my depth.

But lately less and less changes with each rewrite. I am able to pull entire chunks of code in from a previous iteration and have them work well, with little modification.

The process of writing software that's beyond one's ability is fascinating.

> So I will leave my naive implementation in place until USE shows me a bug or a new feature and then that IMPLEMENTATION shows me where my architecture is clunky, and how to fix the original thing.

I do that too. And I generally avoid refactoring anything until the pressure it's putting on the rest of the code justifies it. And one of the things I think isn't appreciated is me in the future probably will know better how to rework the code than me now.

You get used to things working the first time when you use a strongly typed language like Haskell or ML. Still need to test for off-by-one errors and that sort of subtle bug, but it really is true that your program will mostly be error-free. Highly recommend investing some time in such a language if you are able to.

There's much more to errors than just types. The source of most of my errors are failures to account for corner cases in input data that I have no control over

Most common error in my and teammates code (Ruby, JS) while actively working on it is code being edited is not consistent with the other code in the system.

Thinking I’m dealing with an Object A when I have object B.

Not realizing that nil is a valid thing to be returned from code that at first glance shouldn’t return nil.

Plus, accidentally writing super slow n+1 queries. And accidentally loading too much data.

The comment was about code working when you first run it--not exactly where input outside your control comes in. Also, you'd be surprised how much types can catch, but feel free to completely ignore my opinion if that suits you ¯\_(ツ)_/¯

In my experience, a sufficiently rich type system is extremely similar to TDD in this regard.

Both give you super fast feedback and a lot of issues can be solved before you finally launch your software for the first time. But neither will save you from bad design or misunderstanding your requirements.

+1. I think that's exactly the right way to think about types. They're like integration tests you pay for with some upfront thought about your design (and fighting type system complaints).

I do something pretty close; if I'm working on a new feature, I typically create a branch off master, get an implementation working, then do another branch off master without having merged my original code. I repeat this until the code is acceptably un-awful.

It's kind of validating to hear that Joe had a similar workflow to me.

I do it as a way to deal with perfectionism. I write program0 (hey, this is computer science, we start at 0) and often never get around to program1, since program0 works, despite being a bunch of hacks. But I feel less bad about the hacks while I'm writing them, since it is version 0, after all...

Doing that made me feel insecure. Reading this helps with that.

Joe also happened to type with only two fingers. Made me realize how little a hyper optimized touch typing style really impacts work outout!

You only need two fingers to type ctrl+space!

I'm sure I use more than two fingers but even to increase APM I focused on getting more for my keystrokes rather than more keystrokes.

I have heard that J.P. Serre used the same method when writing his books.

This is how I've inadvertently been tackling my toy (for now) Erlang-based programming language (OTPCL). Wrote and rewrote and rewrote the parser, then wrote and rewrote the interpreter, then wrote a small standard library that I'm in the process of again rewriting and expanding (and I'm learning in the process that another rewrite or otherwise major change of the interpreter is likely in order; I'll probably also need to rewrite both yet again - and possibly even the core execution/evaluation model - if/when I decide to attempt to compile OTPCL to BEAM instead of it being strictly interpreted).

I figured my tendency to start and restart things is just because I'm a terrible programmer. Good to hear I ain't alone :)

I often do the same thing with more critical functionality. Though I'm not quite as thorough, usually calling it at iteration 2 or 3.

Not at all. There are others (me included) who also realized that code evolves with your understanding of a problem.

As someone who changed careers and now is coding as a career, it's comforting to see other folks doing this ;)

I feel like I get more "right" the first time now, but man I still see a better way once I'm done nearly every time.

I often do the same thing.

I feel like I do this too, but within a git repo.

A little selfish of me, but I'm very sad I never got to meet him. Programming is in a rather unique state where most of the foundational people are kept alive in living memory. There's people who can recount working with Dijkstra, or Dennis Richie or Joe Armstrong. Heck, there's probably some people who can remember Von Neumann (Peter Lax?). I really hope we can keep these memories alive. There's nothing really comparable for other fields. Nobody alive today can remember working with Gauss or Riemann.

This may be a gross exaggeration, but I believe we'll look back on programming during the mid to late 20th century like we do for physics in the early to mid 20th century. We'll marvel at the amount of talent alive at the same time.

TIL Dijkstra died in 2002. I don't know why, but I always thought he was much older than that!

Probably because he's cited with the frequency, authority, and timelessness of any major philosopher.

It's amusing to note that Dijkstra's most famous quote is something he never wrote.

Dijkstra submitted a letter to the editor of the Communications of the Association for Computing Machinery (CACM) that he titled "A Case Against the Goto Statement".

Niklaus Wirth was editor of CACM at the time, and he changed the title to the infamous "Go To Statement Considered Harmful".

https://en.wikipedia.org/wiki/Considered_harmful

Here's the story in Dijkstra's own hand (scroll to the last page of the PDF):

http://www.cs.utexas.edu/users/EWD/ewd13xx/EWD1308.PDF

This is a good reminder that when you read an article with a clickbaity title, don't blame the author, blame the editor.

Our field is a young one, the "founding generation" (those which actually got computing up and running in the 50s and 60s) only started really dying of age in the 90s (Hopper, Hamming) , though it's getting pretty relentless as the early generations are now reaching their 80s and 90s (McCarthy died in 2011, Engelbart in 2013, Minsky in 2016): Hoare and Wirth are 85, Hamilton is 82, Liskov is 79, Alan Kay and Leslie Lamport are 78, Vint Cerf is 75, …

One thing I've thought about a lot when people like Joe pass away is that it's somewhat sad that they never are able to receive all the appreciation people give after they are gone.

In a parallel culture timeline it is easy to imagine the announcement of someone soon to die (when possible of course), and all these kind words of appreciation from strangers being passed on to the one dying. On the other hand, I guess that the time is better spent with close family, but regardless, I hope that he somewhat understood his importance to so many people all over the world.

This seemed to happen with Gord Downie of the Canadian band The Tragically Hip. He was given a diagnosis of terminal brain cancer, but had the energy for a cross-Canada tour a few months later. He was much loved across the country, and though the band’s arena-sellout days were mostly behind them, they blew the doors off with sold out shows at the country’s top venues, culminating in a nationally-televised concert. I’ve always marveled that he got the chance to have this touching denouement to his career, and I’m glad he did. And I’m very thankful that I managed to see them in Vancouver.

Similar thing happened to Wilko Johnson, guitar player in Dr. Feelgood and actor in Game of Thrones. But in the end he surprisingly ended up surviving his terminal cancer, thanks to his doctors.

https://en.wikipedia.org/wiki/Wilko_Johnson#Cancer

I thought the same thing! Long time hip fan but grew up south of the boarder :)

This did happen with Pieter Hintjens, hacker, author and creator of 0MQ.

Brave and dignified to the end:

http://hintjens.com/blog:115

http://hintjens.com/blog:116

http://hintjens.com/blog:121

http://hintjens.com/blog:125

In academia, it is common to do conferences in honor of a major figure’s 60th/70th/80th birthday, and/or a festschrift (https://en.wikipedia.org/wiki/Festschrift). There’s typically serious work done there, but also a lot talk about they’ve influenced the field, as well as just general reminiscing. You might, for instance, mention the fact that the honored figure once reported his own car stolen because he couldn’t find it, then later found it and got pulled over for driving a stolen vehicle.

E.g. https://www.microsoft.com/en-us/research/event/lampsonfest/

I can’t say I’ve ever seen someone use an issue tracker as a blog before, but it does make sorting the posts dead easy.

I wish he would of called it an e-zine. Then "Issues" would match the use case... Bring e-zines back dang it! raises wrinkly millennial fist

A fun side effect of his approach is you can see people who forked off the idea, there's at least two people blogging using this format as well:

https://github.com/lukego/blog/network/members

I hope when I die I'll be worthy enough to ascend to whatever is the programmer Valhalla and I'll see Joe there, amongst the other greats.

I have never written a line of Enlang, but as I've seen the advantages of loading binaries at run-time as swappable components I get an inkling of the beauty of the idea. It's not near so easy in C# as it appears to be in Erlang.

Also, I nominate the name of programmer Valhalla to be called "Greenfield."

If anyone related to Joe has access to his home directory and knows someone managing his estate who could grant a copyright release, I'd be interested in adding it to the Internet Archive (out of respect). Email in profile.

I’d be very cautious as to what from my home directory I’d be ok with going online, even after I died. Much of the material might still have relevance to others, and they might not want it published…

> Joe's home directory was a treasure trove of new and old ideas…This was all openly shared over NFS and exciting to explore.

Agreed but I suspect that this home directory as exposed on the NFS might be appropriate.

https://twitter.com/mrsjoeerl

Sounds a lot like the stories I've heard about other software legends, or any kind of legends really. Sadly there aren't many places left with enough margin for creativity, it needs space and comes without guarantees.

I've only seen glimpses of this great man from his conference talks on YouTube, but he came across as a very intelligent, relatable and humble person.

It's a great loss.

I can't believe he died. What a loss.

Reply on news.ycombinator.com