[Cplusplus_and_furious]

I'll be perfectly honest, sometimes after finishing one module, one function etc. I take a break, sometimes I got stuck with a solution or library so all-encompassing, that I spend days reading documentations before actually code one line.

But from when I was still a teenager, I always get this idea that "true" programmers code non-stop like they are writing a bestseller followup.

None of my colleagues I worked with before I started my own business coded like that, there were some guys graduated in the 70s who pretty much don't do anything, one of such cases, so I've been told, make a ridiculous amount for maintaining a mainframe, which took me quite a while to realize what the hell a mainframe is. And they don't even use C, or assembly, both of which are low-end enough, they use COBOL. Luckily I haven't encountered anyone fossil enough to use punch cards.

But let's forget about them. They are not the "real deal". So, have you ever seen anyone code like this guy?



I sure haven't but I believe there is such a guy, or are such guys.

I feel so guilty sometimes for those breaks. I feel if I never had taken them I could have been much more productive.

[ndc85430]

It's important to take breaks. If you're not working productively, then I see no reason to force yourself to continue working. I take breaks every hour or so.

[depricated]

No one codes like that guy.

I mean, first thing - toss out any notion Hollywood has inspired about programming. I've seen two movies in my entire life that accurately portrayed it, and I only remember the title of one - "Trackdown" (or maybe Takedown, one is the book, one is the movie). That's a heavily embellished story about the hunt for and capture of Kevin Mitnick, based on the book written by the computer expert who helped the FBI capture him. That's a pretty accurate portrayal - days and weeks spent poring over code.

Breaks are important. Remember that writing code is mental labor. Just like your body needs rest from physical labor, your mind needs rest from mental labor. Taking a break from a problem lets you reassess it without trudging over the same pieces of it over and over again. There have been plenty of times where I just abandoned a problem for the rest of the day so I can tackle it fresh the next.

[Skydiver]

Before I started following the TDD approach, I used to be like a programmer Tracy Kidder described in Soul of the New Machine: Spend days or weeks seemingly slacking off and doing nothing, or poring over old code, and then go on coding binges overnight or through a weekend writing and debugging major pieces of code. Now with TDD, I tend to do more of a steady stream of writing tests, making the tests work -- lather, rinse, repeat.

Personally, I would rather much be doing TDD and peer programming, but my management chain doesn't consider peer programming as an "efficient" use of resources.

[ArtificialSoldier]

I'm known for writing code fast, but I can only do it at high speed when I know what I'm going to write, and that tends to not take very long to write. So I write code quickly, but in small bursts. If you know what you're going to write but it takes 1,000 lines to express it then it seems like you're using a very inefficient or verbose language. I don't know what my typing speed is, but I can write punctuation as quickly as any other character, so writing code goes fairly quickly. When I'm programming most of the time is spent sitting there thinking instead of actually writing.

[NeoTifa]

I only code like that for personal projects/hackathons, when I'm building something from scratch. To be fair, I've created so many Rails frameworks lately that it could look like that for a good solid hour before I break. In the real life, you just stare at the screen and scroll for like 45 mins, then you add 2-3 letters, maybe a copy and paste, then back to the scrolling.

[jon.kiparsky]

I know a lot of fiction writers, and they don't write fiction that way either. They put in a lot of time planning out how things are going to go, then they write a draft at high speed, then they look at the draft and think about it for a while, and then they revise it.

The actual time at the keyboard looks like they're going fast, but there might be a few hours or days of prep for those spurts.

As you can see, this is sort of how developers tend to work.

[modi123_1]

I am totally faster when pair programming on the same keyboard.

[NeoTifa]

I can't even with that vid right now.

[baavgai]

While I can get into a zone of banging away at a steady clip, it's not really a maintainable state. At some point you come up for air and are usually burnt enough that you aren't getting back to that state again any time soon. We actually need long pauses and sleep to be functional when we are working.

I find that getting up and walking around for a few minutes will result it more work done than the odd caffeine fueled fugue. Also, meditating before work, basically doing the opposite of thinking, seems to benefit thinking later on.

If I should look like I'm coding fast, then it's probably not actually creating but constructing. Moving code around, clean up, setting up the same sort of thing you've done a thousand times before, these all can look fast. However, the nuts and bolts of thinking about the problem and testing the solution tends to be unimpressively sedate.

[xclite]

Skydiver, on 31 October 2017 - 12:21 PM, said:

Before I started following the TDD approach, I used to be like a programmer Tracy Kidder described in Soul of the New Machine: Spend days or weeks seemingly slacking off and doing nothing, or poring over old code, and then go on coding binges overnight or through a weekend writing and debugging major pieces of code. Now with TDD, I tend to do more of a steady stream of writing tests, making the tests work -- lather, rinse, repeat.

Personally, I would rather much be doing TDD and peer programming, but my management chain doesn't consider peer programming as an "efficient" use of resources.

I would resign if forced into either, but I understand that people work differently.

And (not that you were trying to make this point) TDD, though rapid, isn't like Hollywood programming. You ever see those code ninjas write tests?

I agree quite a bit with baavgai:

Quote

If I should look like I'm coding fast, then it's probably not actually creating but constructing. Moving code around, clean up, setting up the same sort of thing you've done a thousand times before, these all can look fast. However, the nuts and bolts of thinking about the problem and testing the solution tends to be unimpressively sedate.

I generally work at the opposite end of TDD and peer programming for anything more complex than a single-line change. I get all the requirements I can on a problem, and then do pretty much no coding for some period of time. Just doing other stuff or sitting around thinking about the problem until I have A Plan. Then I go and do it, and then I write tests. I think one advantage of at least thinking about tests while coding is that it generally pushes you to abstract better. I find that I don't actually _need_ to do the test-driven part to get the benefit of that, so I just write the code first, usually.

I'm trying to change that habit as I write more Clojure, mostly as an experiment to see if I can glean some benefit from bottom-up REPL-drive development instead of my usual top-down approach.

All this to say: Maybe sometimes coders code that fast, but many don't, and there's no a commonly accepted approach that that the industry takes. Personally, I feel like I write my best code when I'm not actually coding, and most times when I'm coding it's just transcription.

(Check out Rich Hickey's talks on Hammock Driven Development for some fun insights on this from a languages/database guy)

[Skydiver]

xclite, on 01 November 2017 - 10:18 AM, said:

Personally, I feel like I write my best code when I'm not actually coding, and most times when I'm coding it's just transcription.

I know exactly what you mean by it feeling like transcription. Before I started doing TDD, after long runs of just letting ideas percolate in the back of my head for several days, it felt like I was just regurgitating code and/or designs that I had stuck in my head once I got into the code writing binge mode.

[no2pencil]

I recall an incident in my mid 20's, with enough caffeine & a mechanical keyboard, that a friend asked who I was chatting with. My reply was that I was coding. So sometimes, when in the zone, it can get nuts. But I'd say no more than like a 3 minute burst.

It really comes down to syntax. How much can you type before you have to stop & think. & with so many copy-&-paste solutions pulled from Source Forge, it's likely not many people are actually "coding" at all, let alone quickly & for any measurable length of time.

[jon.kiparsky]

I guess there's also a question of how deep your stack is. If you can keep the logic for the whole function in your head, then typing out the code is like taking dictation from your own brain. This suggests that good code style plays a role, particularly the rules of function length and simplicity. If your functions are limited to ten lines or less and they do just one thing, then you can usually type them out with a minimum of logic to think about, which will make your work quite fast. Now you can go up a level and think "okay, I need to do these four things, which means I need these four functions" and then you just blast out a few dozen lines to make those four functions, and people think you're some sort of genius.

[O'Niel]

The average lines of code a programmer (in a real business) writes each day is seven.
This includes documenting your code, commenting it, testing it,...

Taking loads of breaks is good, it keeps your brain fresh and so you'll write
more effective code that will be of higher quality.

Instead of writing lots of lines of crappy code.