Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Coding is when we're least productive

codemanship.wordpress.com

Post reply on HN
Print view View original

51–59 of 59 posts

Re: Coding is when we're least productive

#51

Post by assaddayinh »

bluGill wrote: post #32
michaelsalim wrote: post #24

Earlier quoted context omitted.

I see where you're coming at. But don't underestimate the amount of design work that goes into making a good chair. It probably took more time than your think, which transforms them into the person who can craft the chair

Chair makers do not make one chair - they make one for the whole family. Then they make more in a very similar style for the next family. There is very little new design in a chair - it has all been done.

Reference to https://en.wikipedia.org/wiki/Use_of_Weapons ?

Re: Coding is when we're least productive

#52

Post by gjadi »

emil-lp wrote: post #29
BrenBarn wrote: post #6

This is one reason I always roll my eyes when people talk about how vim keyboard bindings are so great because you don't have to move your fingers from the home row. The actual action of typing text is a small part of the process of coding.

Roll your eyes if you want. A professional takes tools seriously, that includes key bindings and shortcuts. Yes, it's not the time it takes to type that's the matter, but once you're in the zone you need to stay there without any resistance.

This.

For me, navigating with shortcuts feels like I can keep my inner monologue, it is part of it, maybe because I can spell it?

Dunno, but reaching for the mouse and navigating around breaks that, even if it can be more convenient for some actions.

Re: Coding is when we're least productive

#53

Post by sublinear »

BrenBarn wrote: post #6

This is one reason I always roll my eyes when people talk about how vim keyboard bindings are so great because you don't have to move your fingers from the home row. The actual action of typing text is a small part of the process of coding.

I agree. Vim is my default text editor, but it's not great as an IDE. Don't have much of a choice there either, and have to use the right tool for the job.

Re: Coding is when we're least productive

#54

Post by mathgeek »

shalmanese wrote: post #34
mathgeek wrote: post #30

Earlier quoted context omitted.

Yes, but that is part of the point: a chair being built is mostly distinct from a chair being designed (there is of course a small amount of design that is done while building). Software is designed at a much higher percentage while being created (or if you prefer, there is a cycle between the two states). You also don’t often learn why you don’t need a chair while building one.

> or if you prefer, there is a cycle between the two states Yes, what I mostly emphasize with this mode of thinking is that the act of building software is primarily there to transform people (you try a thing, it doesn't work like you think it would, that inspires you to try another thing) and the software at the end of it is largely a byproduct. If you have the right people-state, producing the software is trivial,…

Perhaps sometimes and in an ideal state, but most folks who code learn a lot and make a lot of design decisions while producing software.

Re: Coding is when we're least productive

#55

Post by perrygeo »

shalmanese wrote: post #22

At the end of the week, if you suffered a hard drive crash and all of your recent code got erased, how quickly could you recreate it? That's how much of your week was spent coding . The rest of the week was spent transforming you into the person who could code the thing you coded. Contrast this with a chair maker. If at the end of the week, their chair got thrown in a woodchipper, some significant fraction of the nex…

Having been in this situation more than once, recreating a concept from scratch when you've already coded it once takes ~20% of the time. This also tracks with my long term empirical observation that roughly 80% of a software project is maintenance, testing, debugging, monitoring, fixing bugs, planning, refactoring, etc.

Sitting down to an editor and typing out ascii charachters is the smallest and least consequential part of software development. And that was _before_ LLMs enter the equation - now it's not even strictly necessary. The software industry needs to get over its obsession with coding as an activity, and with code as an asset. Code is at best a necessary liability. Software systems are what we should be focused on.

Re: Coding is when we're least productive

#56

Post by danielbln »

beej71 wrote: post #46
Nevermark wrote: post #2

Coding is when we carefully write down our solution to a problem. (Manager pushes paper, pen and a list of problems in front of you and demands, “Now write, just write! And fast!”)

This is what I tell my students. The hard part of programming is the understand and plan phases and barely any of that takes place at the keyboard. The rest is just typing in your completed plan. And if you find yourself going in circles while you're typing in code, you probably didn't complete the plan phase.

So where do you iterate? Most plans don't survive contact with reality, and all that.

Re: Coding is when we're least productive

#57

Post by [deleted] »

danielbln wrote: post #56
beej71 wrote: post #46

Earlier quoted context omitted.

This is what I tell my students. The hard part of programming is the understand and plan phases and barely any of that takes place at the keyboard. The rest is just typing in your completed plan. And if you find yourself going in circles while you're typing in code, you probably didn't complete the plan phase.

So where do you iterate? Most plans don't survive contact with reality, and all that.

[deleted]

Re: Coding is when we're least productive

#58

Post by beej71 »

danielbln wrote: post #56
beej71 wrote: post #46

Earlier quoted context omitted.

This is what I tell my students. The hard part of programming is the understand and plan phases and barely any of that takes place at the keyboard. The rest is just typing in your completed plan. And if you find yourself going in circles while you're typing in code, you probably didn't complete the plan phase.

So where do you iterate? Most plans don't survive contact with reality, and all that.

To elaborate a little, I told them that usually during this process you'll bounce back and forth a little bit. You'll notice while your coding something up there was something you didn't understand and so you drop back, understand, and then move forward again. So there's some back and forth, but hopefully general progress is forward.

As for iteration, there's a little bit of iteration in every phase. But there's also iteration over the entire process. Once you've understood the problem, come up with a plan, coded it up, and look back to see what could have been done better, it might be time to re-understand the problem.

Post reply on HN