[clifanatic]

There's a great, fun, programmer-centric website called thedailywtf.com (sorry, I just scheduled the rest of your afternoon for you). Developers can submit WTF's that they've found in other's code - as the site admin says, "curious perversions in information technology".

One thing that strikes me about the majority of the submissions, as funny as they are, is that they mostly boil down to "so-and-so didn't know that such-and-such feature existed, so wrote reams of code to implement that feature in a complex way". It also strikes me that just this article's sort of analysis of "prolific" (aka "good") engineers/programmers drives this same sort of behavior. If every developer is supposed to be committing code all day, every day, there's no time left over to read the product documentation, try out a new feature, review a reference implementation, read a blog post: to be "good", you must be spending as much time as possible _typing_, because that's what you're paid to do. This (ubiquitous) management mentality is how we end up with roll-your-own crypto, or five competing Javascript frameworks, parsing using regular expressions... it's not so much that what they did was wrong - and trust me, if it works, it won't be removed - it's that it's pointless.

[darkerside]

It can also work the opposite way. You can think you understand the requirements and go hole yourself away for a couple of days pumping out code. When you finally merge your work, another developer tells you, "Why didn't you just use function X or package Y?".

If you're doing your work in small, sharp bursts, you actually end up with more time in between work for talking with other devs, reading up on technology, etc.

[Bartweiss]

I think this is the better insight.

A lot of DailyWTF posts are about people not knowing a function existed and then reimplementing it horribly. Many of them include a note like "the other 10,000 lines were similar".

Ignorance is not embarrassing, it's the default state when all of our tools grow and change daily. But a lot of the worst wtf moments are clearly cases where something wasn't sanity checked by anyone until it was presented as a finished product - sometimes too late to keep out of production. That's the benefit of frequent commits, reviews, and research breaks; they might not prevent our ignorance, but they keep it under control.

[RangerScience]

I think you missed what this article was on about. They're comparing against "impact", not LOC. From what I understood, "impact" is actually LESS from high LOC; it's highest for a few lines in many files.

But, the overall conclusion - small bites, many times - definitely fits both my experience and my intuition.

You either have to a) create a library/module or b) use a library/module. "A" is rare, and it's easier to see the impact of it - "you're the person that made that thing". "B" is the most common, and it usually involves many small bites. It's also harder to notice who's accomplishing what this way, since you have to point at the whole team to say "you made that thing".

Impact sounds like a decent way to see who's meaningfully contributing to a group project, although it definitely (sounds like) it has major blind spots. They could do with more detail as to how "churn" relates.

[paulryanrogers]

Some rolled-their-own solutions may have been done before feature/library X emerged. Ironically because those which came later were initially excluded to follow a "take small bites" approach.

[mempko]

You write the product, you influence 1000 users. You write the library, you influence 1000 users with each a 1000 users.

[djedipus]

Assuming equal likelihood of success for product and library. It may feel that way to us but there is a survivability bias embedded in that assumption. I'd hazard a guess and say incremental value add per unit of effort is greater for product development due to the inherent bias developers have for building libraries under the false assumption that a domain can be conquered for good.

[riazrizvi]

But, there are only so many documents and so many relevant API's to read. At some point, the ratio of research-to-writing flips.

[asolove]

Are you joking? I've worked as a programmer for 13 years, mostly in the same two languages. But my reading list is longer than ever and my thinking-to-coding ratio is higher than ever. Unless my employers are regularly lying to my face, they are pretty happy with the outcome.

[riazrizvi]

No, I'm not. Most of the time I spend writing code, not checking documentation, or APIs. I've been a programmer for 27 years.

[buzzybee]

This is going to be domain-dependent. The lower in the stack you go, the slower things move and the less likely it is you're going through wholly unfamiliar territory. Top-of-stack, user-facing code(of which web browser stuff is the poster child) churns endlessly; UI code you write today is likely to have a lifespan of a few years at best, if the system continues adding features and staying up to date with new platforms.

This is true, at least, until you hit code that touches hardware directly, and then you still get to encounter lots of new problems because the hardware is doing things that break your code.

[riazrizvi]

I think that if you are reading > 50% of the time, vs coding, then you are still learning your trade. I write for MacOS and iOS, lots of new material each year, it doesn't take that long to get through the relevant updates, though.

The times I've spent most time reading, are when I've transferred across industries, to capital markets trading systems, to web media, to web apps, to mobile apps, to big data, to VR/graphics apps. Each transfer involves an initial period of furious research, but even though the ratio of reading to coding stays high initially, I am generally able to start writing more than reading within the first few weeks.

I did spend more time reading the first years of programming. But I think you hit a watershed, where it becomes harder to find a treasure trove of ideas about software architecture, for example, in a new book, and instead it becomes more helpful to advance your art by experimenting, and developing, and analyzing your own output.

For what it's worth my main point was about the ratio of coding to research, and although the previous commenter disagreed, I think he also introduced a new point about the ratio of thinking to writing. I remember I used to spend more time staring at walls of code, or paper notes. Not anymore. If before my work was more chunky, now it is more consistent and smooth. That is a skill/discipline I developed. The article resonates with me because my commit frequency has increased since I have been able to improve my analytical process in this way.