Live data from Hacker News

The Productivity Mirage

frantic.im

41–50 of 164 posts

Re: The Productivity Mirage

#41

Earlier quoted context omitted.

This is just my opinion so maybe im describing something other than what you are observing. This was me, until I got AI. Now im building cool stuff that I never would have built (but also slowly destroying what little skill I had and not knowing much about the underlying code). Of the code I do know about well, I am fixing and improving my old code and being amazed (but probably not deeply learning) with new tricks a…

I think the downvotes are for saying positive things about AI. HN doesn't like that ;) And yes, messing about with skills is the new messing around with setup. It's a rabbit hole. I'm a massive, massive, believer in The Cult of Done [0] especially "the point of being done is not to finish but to get other things done". Allowing myself to finish something badly so that I can move on to the next thing was a game-change…

I'd say the downvotes are for: "No fuckin' shit we can just AI." This is clearly an article about the (and I can't believe I'm saying this) "classic" style of programming from, like, a few years ago. This is clear as day. There is not a single person here who doesn't realize this.

If you really must bring up AI here, a more relevant comment would be how you may over-complicate your AI workflow, over-focus on promots, or something along those lines.

Re: The Productivity Mirage

#42
Sure. That’s the theory of it. But when I wrote myself an app that helps me author blog posts I ended up writing more of them. Turns out that image uploading and then naming and description is slow but I kind of have the image and etc handy usually and can stay in flow state.

There are superstar product developers. Pieter Levels of the world. History has taught me that I don’t have that level of insight. But improving my flow gives me sufficient performance boost to be able to be useful to people who pay me for that.

Re: The Productivity Mirage

#43
post #33
post #29

Earlier quoted context omitted.

> 90% of our time should be spent thinking, and most of that reading I don’t know if that’s accurate for most of us, who are simply humble CRUD app developers.

90% of our time should be spent waiting for Claude to ask permission for something then!

Or waiting for your limits to reset ...

Re: The Productivity Mirage

#44
I think it's a false dichotomy. A good craftsman cares deeply about their tools. But the tools are a means to an end, not a toy.

I have a bunch of small productivity tools I made to match my workflows: tiny shell scripts and functions, custom Emacs functions and settings, small tools to control windows placement, etc. Cumulatively I spent many days building and adjusting it.

But when I need to jump into a task, things just work. Syntax highlighting is there, code navigation is there, code analysis is there, I can rearrange things in my area of attention the way I want with a couple of keystrokes, I can drive git the way I want with a couple of letters. I don't have to tweak anything. Nothing bothers me, nothing distracts me, nothing wastes my time and breaks my concentration by requiring legwork.

(Same applies to my mechanical and electrical tools. Mostly.)

Invest in your work environment. Adjust your chair. Adjust your shell prompt. Adjust your editor settings. Comfortable? Good. Now you can forget about them all, they are just there working for you. Concentrate on the real problem you have. Godspeed!

The skill of concentrating on a problem is much harder though. Endless tweaking of your tools that eats all your time can be a sign that you are just trying to avoid that daunting and uninspiring task. But this is not the tools' problem, not that simple.

Re: The Productivity Mirage

#45

This is so important. I've seen so many fellow technologists (and I've skated this myself) obsess about their setup to the point that they're spending more time on that than the actual thing they're building. The whole "90% of my time as a coder is spent typing, so I should optimise my ability to type fast" is so, well, wrong. 90% of our time should be spent thinking, and most of that reading.

Its kind of funny but non technical people imagine coders to only be productive when they are typing away like those typical "hacking into the mainframe" scenes. I actually made a satire art thing on this where it was a fake news release that companies are going to start making engineers dance when the ai agent is coding to "improve spirit" but meanwhile they use that data to create training datasets for their upcoming dancing bot

Re: The Productivity Mirage

#46
post #44

I think it's a false dichotomy. A good craftsman cares deeply about their tools. But the tools are a means to an end, not a toy. I have a bunch of small productivity tools I made to match my workflows: tiny shell scripts and functions, custom Emacs functions and settings, small tools to control windows placement, etc. Cumulatively I spent many days building and adjusting it. But when I need to jump into a task, thing…

[dead]

Re: The Productivity Mirage

#47
post #25

I bet you Bob was great at launching new concepts but that taking oncall responsibility for crusty old code that he didn't personally write wasn't for him...

More often than not, what matters is transforming a concept into working code that is good enough.

The easier part is maintaining and tweaking that code, but do not underestimate the value of the former.

Re: The Productivity Mirage

#48
post #36
post #25

I bet you Bob was great at launching new concepts but that taking oncall responsibility for crusty old code that he didn't personally write wasn't for him...

Do you even want your best and most prolific engineers wasting their energy on on-call duties?

This is something of a circular argument. Bob doesn't waste energy on on-call duties, so he implements more features, so he's a prolific engineer, so he doesn't have to waste energy on on-call duties.

Re: The Productivity Mirage

#49
post #44

I think it's a false dichotomy. A good craftsman cares deeply about their tools. But the tools are a means to an end, not a toy. I have a bunch of small productivity tools I made to match my workflows: tiny shell scripts and functions, custom Emacs functions and settings, small tools to control windows placement, etc. Cumulatively I spent many days building and adjusting it. But when I need to jump into a task, thing…

Exactly. It matters that you enjoy working with your tools. Even if they don't make you 10x more productive, focusing on what you're working on and enjoying the process is the most important part.

Especially in the age of LLMs I think a lot of us hate the current tools that force you to context switch between N agents and terminals. Constant context switching takes the joy out of work and prevents you from getting into a flow state. I hope someone figures out the solution.

Re: The Productivity Mirage

#50

This is so important. I've seen so many fellow technologists (and I've skated this myself) obsess about their setup to the point that they're spending more time on that than the actual thing they're building. The whole "90% of my time as a coder is spent typing, so I should optimise my ability to type fast" is so, well, wrong. 90% of our time should be spent thinking, and most of that reading.

> The whole "90% of my time as a coder is spent typing, so I should optimise my ability to type fast" is so, well, wrong. 90% of our time should be spent thinking, and most of that reading.

Any software engineer who proclaims "90% of my time is spent typing" does not understand two fundamental industry axioms:

  Software is the manifestation of a solution to a problem.  
  Define the problem which needs to be solved.
  
  When making software, remember that it is a snapshot of 
  your understanding of the problem.  It states to all, 
  including your future-self, your approach, clarity, and 
  appropriateness of the solution for the problem at hand.  
  Choose your statements wisely.
"Coding", when performed at the appropriate time, is little more than reifying a solution to a problem already understood. Also known as "a typing exercise."

All of this is to say; I agree with your position.

Post reply on HN