To each their own.

Committed sitting in a chair works well. But it's not the only option. When my kid was born it completely destroyed the routine of long uninterrupted coding sessions. However it also made me realize that you can prototype and refactor in your head while pushing a stroller. Then you get back to the computer and just flush it all in its final form. The cherry on top is that, end to end, this takes less time than sitting in front of a machine and coding and re-coding.

But, again, this worked for me because of how I code. Sitting in chair worked for Blow because of how he codes. So YMMV.

The chair is also a metaphor. Planning a project in a hammock is as much work as typing on Emacs.

But googling productivity advice, asking people what should they work on, and faffing about on HN is NOT work. Jumping on another project instead of taking one to completion as soon as it starts to get unfun is NOT work (which is OK for a hobby, but work gets harder the closer you are to completion)

In any case, you can do a lot of work away from the keyboard, but until you type it in in your editor, it's just an idea that exists in your head, and those are worthless.

It has got to be more than that. I almost always have an editor open, working on some ambitious project. Without bashing myself too much, I have have 96 original Github projects, 90% of which unfinished.

All the finished ones are either tiny, or in such a small niche no one would ever use them or pay attention to them. Of the unfinished ones, they're all so unfinished that even if there would be something worthy of note in there, it would not be in a state that's marketable to anyone.

Of course I finished everything I worked on professionally, and there's some cool products amongst those, but no one ever paid me to work on something with global/cultural impact.

I'm not complaining at all by the way. I'm always having fun when I'm coding. But there's a definite difference between what I do, and what someone like Ludwig, or mitchellh, or Linus Torvalds, or Bellard, etc is doing.

At the very least, there's some focus and speed. I was pretty close to finishing my non standard conforming C compiler, and then Rust came out and it did everything I wanted to do in my C compiler and more. And then a couple years later I was pretty close to finishing my ECS system in Rust, and then my day job became super stressful for a couple months, making me too tired to code at night, and then SPECS was released which basically did what I was trying to do.

My favourite OSS project I ever finished was a Ruby framework for writing an AI for the Starcraft: Broodwar game. The amount of active people in the BWAPI community at that point was definitely less than 50. Most of them either did it in Java, or just in C++ directly, I'm pretty sure everyone raised their eyebrows at someone going through the effort of making Ruby bindings.

>It has got to be more than that. I almost always have an editor open, working on some ambitious project. Without bashing myself too much, I have have 96 original Github projects, 90% of which unfinished. All the finished ones are either tiny, or which such a small niche no one would ever use them or pay attention to them. Of the unfinished ones, they're all so unfinished that even if there would be something worthy of note in there, it would not be in a state that's marketable to anyone.

I'll bring up a remark John Carmack made (paraphrasing): "All the small games we made for Softdisk were not worth remembering, but I'd like to think that the work that we've put during that time was what ultimately allowed us to build better games".

With that I mean, we romanticize programmers to the point where we forget what they made them great. They worked and made stuff no one will ever remember or know, but it was NECESSARY work that led them to build the stuff worth remembering.

There is a little bit more. Look up the concepts of social proof and compound interest.

Here's a helpful piece on compound interest: https://tynan.com/thekey/

As for social proof, here's the concept: your reputation consists of your greatest achievements, not your greatest failures. I'll use Jonathan Blow as an example. He's the creator of Braid. He will always be known as the creator of Braid. One huge massively loved breakout hit is all you need to cement your reputation as an outstanding programmer. You could work on a dozen things nobody's ever heard of before and after that breakout hit and it doesn't matter.

The tricky thing is you never know what's going to be big and successful and what's going to be forgotten. That's why most outstanding programmers swing for the fences. They make things that are BIG. They're ambitious. You're not going to become recognized for outstanding work by making yet another ECS system in Rust. It has to be a step above in some way.

That said, to make a big, ambitious, impressive ECS system in Rust, you need to understand the problem extremely well. You do that by making unimpressive ECS systems in Rust. See previous point about compound interest.

I remember he made Braid, but I'm more interested in Jai.

I also don't think they make it for the fame, they make it because they can see that it could be made, or at least should be attempted, as it's better and hasn't been done.

The Unreasonable Effectiveness of Just Showing Up

https://news.ycombinator.com/item?id=27833064

What you say is true, but not enough. It is also essential to have a clear idea of what you are trying to build and how you are going to build it. Without those, time in the chair is not going to be used well.

Agreed. I've showed up nearly every saturday and sunday morning for the past decade, and I'm still working on the same stupid side project because I keep rethinking the fundamentals and going back to the drawing board. I'm finally nearing completion, but looking back, some time management and a clearer vision would have radically improved the outcome of my life thus far.

Absolutely correct. At a minimum you need:

- the vision of what you want to achieve

- the skill to achieve it

- the time to build it

I find that time is the most difficult problem to solve, especially since I had a family.

Apply that to a larger scope than writing a program.

Your family is something that you're trying to build. Put into that the time needed. If you wind up with not enough time for writing a program, that's fine. In the battle for time between your family and your program, the program should lose.

One of my biggest failures was focusing too much on my pet projects when I had small children.

It is always difficult to balance our internal drives with the needs of those around us; both spending too much time on ourselves, and denying ourselves an outlet for creativity, can lead to resentment one way or the other.

I would say that I have been “lucky” that my childhood was a bit more difficult than some, so I had a clear vision of who I didn’t want to be, and that meant some personal sacrifices, especially around hobby projects.

I hope you’ve managed to rebalance now your kids are presumably a bit older.

Why not? You just have to use the time in the chair to sketch out a clear idea of how/what you are trying to build first.

I don't completely disagree with that, it's just that the ones who are really familiar with their tools will also iterate on half -baked ideas faster, because there are many things that come come up while on the chair.

And this is something that I actually intended to bring this point up in a thread I saw yesterday regarding thinking time and typing time but I procrastinated on it until today.

I follow the same principle whenever I type a reply. I'm not gonna pretend that the text I'm currently typing is a draft, but thinking about the things that are worth mentioning is something that I can afford after I started typing a response to your comment, if that makes sense.

Yeah, that's definitely true. I find that I'll often be excited about an idea and immediately start putting in the time to build a rough prototype. Once I realize the true scale of the effort involved I second-guess my commitment to the idea - is this really something I want to spend the next year+ working on? I think having that clear vision and enough conviction that the results will be worthwhile is very important and definitely something I struggle with.

Focus is incredibly underrated and probably why a bunch of us are on ADHD medication, but I'll also highlight the importance of _environment_ that allows focus.

Disruption-based workflows, lack of direction, applied pressure on developers that leads to stress can all kill even the most productive dev. I've worked places (most of my career) where that space to fail and space to take a bit longer on things that have value not immediately visible and produced a lot and a couple places where negative attributes have killed the momentum that can come from the general joy & excitement of development.

A lot of these 'outstanding' people work within an environment where development is mostly joy. Where spending 3 days on a small problem incites a drive to tackle more. They're either established and trusted, wealthy enough to not be affected by these things, or just work within another flexible space.

It makes development pleasurable and as a result the output maximizes over time.

^ this but it’s very hard to keep that editor open all the time if you’re not “obsessed” with what you are doing.

Agreed. Also, caring is another high order bit in your output and growth. Butt-in-seat time can be extremely wasteful if you are not engaged with or invested in your work. If you are passionate about what you're working on, it can be a huge productivity multiplier.

I agree with the general ethos - good code doesn't get written by attending meetings all day, or fiddling with org mode. But like all advice, it needs caveats. If you're on a brownfield project where you have very little knowledge of the domain or legacy code, just jumping straight in and spending lots of time in your editor is probably going to result in a lot of frustration and wasted effort.

Yep, I'm not sure Blow is the person I would take productivity advice from, to put it mildly.

I don't know about you, but he's shipped more than most people on here have done. I guess two award winning games and a programming language is not good enough for some of you.

Or are you trying to say he is too successful to take any advice on success from?

And Chris Roberts shipped 4-5 successful games. Would you take productivity or project management advice from him, now?

Background: He is wheelchair-bound.

That’s not true. He lives in SF and enjoys going out dancing.

I apologize if that was wrong, but this article on wired.com mentions that he is “confined to a wheelchair by a rare muscular disease”. https://www.wired.com/2010/12/mf-spotify/

There is no mention of the word Blow in your link. Are you an LLM that is hallucinating?

EDIT: "Ludvig Strigeus is wheelchair bound." Did you miss that the quote you were replying to is from Jonathan Blow, not Strigeus? FWIW, you still have not passed the Turing test, as you got confused by tangentially related inputs ;)

I accidentially hit the reply button on a reply of the post I was actually referring to. Parent was about Strigeus. Besides: Since every mid-sized LLM appears to pass the test I’m not even trying anymore.

> Effort and consistency trumps all. Being a 10x developer has no effect whatsoever on what you can accomplish in work or in life.

Ehhh. There may be issues with the term 10x developer, but if you're using it then it literally means developers that are more productive than most other developers.