Interesting blog post about programming

It's a pretty interesting little blog post. I've heard some of them before.

The 10-12 lines per day average must be for some other kind of programming. In game development I am easily doing 10 times that per day on average. Interestingly, the more my skills have grown, the more code I produce daily, not less.

I also noticed that the post seems to suggest that the great programmers sit back and research and think things through more than they program. That certainly is not the case with all great programmers. Carmack, for instance, says he doesn't waste much time creating grand plans and prefers to start tackling the problems programming right away to better understand them.

I prefer Carmack's approach personally. I do find that I have to spend sometimes a couple days to research and understand a problem before beginning to tackle it. For instance, recently I needed to add a hash table to a core feature I was planning. I had found some existing solutions to hash tables in C, but I needed to be able to serialize the hash table and I wasn't able to find one that could do that, so I decided to roll my own (plus some of their code was buggy or incomplete!). Unfortunately, I wasn't a CS major in college and had no formal training in that so I had to sit down and read some web pages and watch some MIT videos on the subject. Actually it turns out to be real easy to do, but it took me a while to weed through all the information out there.

Also, I disagree with the post's assertion that programming your own solutions instead of using an existing one is always ignorant. Rolling your own can be one of the most effective ways in getting rid of ignorance. I could give a lot of examples about this, but one great one I learned like last year was when I was learning how to do 3D physics myself. The number one thing I learned was: don't do your own 3D physics engine. But had I not tried, I would have never known the exact reason why. While the physics itself is very easy to do, the collision detection and response get insanely complicated to deal with for anything other than spheres and boxes. I also learned enough from that adventure to figure out how to use Bullet, even with their lack of documentation. So in that case my "ignorance" that the blog post would claim, actually turned out to work greatly in my favor in the end.

That said, yes, any good programmer will know how to use the right tool for the job, and if there's something that can help you out, then you'd be well advised to use that instead of your own concoction.

10-12 lines a day is lower than I've heard, but I don't see this as being in any sense contradictory to "Carmack's approach". Heck, it outright says as much in TFA.

My own experience agrees -- one of my most productive times was designing a little application framework at a previous job. The final framework was about 3000 lines of Java, and it was developed in about 6 weeks (30 working days). Each of those days I rewrote somewhere around 1500-2000 lines of code, as I converged on the final design.

Looked at in total, that's 3000/30 = 100 lines a day of code into the final product, which is on the order of what I've heard before. That doesn't mean I only wrote 100 lines of code each day, though.

Oh, I wasn't saying the 10-12 lines per day was related to Carmack's approach. I was referring to stuff later in the article about thinking things through 90% of the time. I might have misinterpreted the meaning of TFA.

Yah, the 100-120 lines per day thing is normal for me, and I mean into the final product. The two latest games were roughly 20 to 30 kloc and took roughly three months a piece (and I don't waste much space with fluff or comments). That is over 200 lines per day into production.

(Aug 20, 2010 07:16 PM)OneSadCookie Wrote: Each of those days I rewrote somewhere around 1500-2000 lines of code, as I converged on the final design.

Wow, that's a LOT of work! I've had rare days where I've cranked out 1000 lines of code, but I've never re-written that much within maybe a month's span. That's ridiculous/heroic/insane amounts of effort on a daily basis. I'd estimate 75% of my code sticks on first try and makes it to release nowadays... although, of course, I'm self-employed, which means I do the code reviews myself, dictator-style

10-20 lines of code a day are pretty standard by a large studio later in the development cycle when fixing bugs vs implementing features. You could easily work over an entire problem for a day, understanding the system, and in the end, only end up making 2 or 3 changes across a few lines. Yes, easily spending hours to write a few characters. That's how debugging works sometimes. Lots of investigation to make the proper change.

Not all programming is feature implementation or working from scratch to a final product.

Then again, nothing makes me happier than cranking out some 100 line perl scripts that I can run with minor modifications to answer people's most complicated questions ^_^

(Aug 20, 2010 10:16 PM)skyhawk Wrote: 10-20 lines of code a day are pretty standard by a large studio later in the development cycle when fixing bugs vs implementing features. You could easily work over an entire problem for a day, understanding the system, and in the end, only end up making 2 or 3 changes across a few lines. Yes, easily spending hours to write a few characters. That's how debugging works sometimes. Lots of investigation to make the proper change.

Not all programming is feature implementation or working from scratch to a final product.

That's an interesting take on it which I hadn't considered. I'm like 75% always "implementing features" as an indie. I've never worked in that environment, so I am completely unfamiliar with it.

Some days I will write little code, and other days I may write thousands of lines of code. Often I will re-write code that I had written earlier if I discover a better way or re-arrange code to increase generality or pull out common functionality, so that definitely lowers the amount that is in the final product.

I would say that I write significantly more than 10-12 lines a day that make it into the final product, but part of that is because I work for a small company with a game background, so we're given a lot of freedom. Another thing you have to look at is a lot of code will be in one "final" release, but not another one. We are currently going through a major re-factoring of our code, everything from UI down to creation of viewable and exportable geometry. (our main product is a real time 3D terrain and city editor) Though some of the basic math and algorithms will remain, a lot of code is being replaced. Before we were more focused on short term progress, getting the core functionality in place. Now that we have a product out and are making money off of it, we are going back and creating frameworks that we can base everything on for long term progress, which we can actually maintain and add features without re-implementing the same functionality across multiple systems. Though a lot of our previous code was a pile of crap and I am glad we are getting rid of it, we probably wouldn't be in business right now if we tried to start off designing everything properly up front, since it would have taken too long.

As for "reinventing the wheel", this is something that has come up a lot at work. The leaders of our company worked as game programmers, where they pretty much avoided standard libraries, especially the STL. There is certainly some reason for that on older consoles, since the STL would have various issues and overhead that would cut into performance, so they would write their own slimmed down (and less full featured) data structures. (EASTL documents a lot of drawbacks with the STL) Unfortunately, even though we aren't making a game (though we've always had that in mind), that still permeates their line of thinking. When I started, we had an array class which by grew linearly (by 8 elements at a time by default) and a hash table which was unsuitable for storing elements by value due to its interface. That's it. After myself and other coworkers unsuccessfully petitioned to use the STL, I ended up implementing most of the data structures already available in the STL with similar interfaces. Though they have some features that would make those structures a little nicer for games with stringent memory requirements and a few tweaks to the interface, the benefits for our product were probably negligible, especially for the time to implement them, test, and replace the usage of our previous data structures.

That said, there are a number of things that we have no choice but to implement ourselves. Except for the core basics, such as data structures and math (vector, geometry etc.), we can't just pull everything from existing libraries. We are trying to build up our internal frameworks so we can have more re-use of code, but even when that's complete there is still a lot of custom code that's required for various systems, just due to the complexity of what we are doing.

High performance software, such as intensive 3D games, require even more custom code and reinvention of the wheel. In order to get the desired performance, design is often sacrificed. Even when pre-made engines are used, such as Unreal, significant changes are made to tailor it to a specific game.

(Aug 20, 2010 10:41 PM)akb825 Wrote: ... and a hash table which was unsuitable for storing elements by value due to its interface.

What do you mean by storing by "value"? Do you mean storing by an arbitrary key, i.e. something other than a string for the key?

This is in C++, so "by value" means embedding the value in the node through templates instead of storing a pointer to the value. The reason why we couldn't store anything by value efficiently is because in order to get a value, you would call the "GetValue()" function, which takes a reference to the value type as an output parameter. In other words, if the value was embedded in the node and you requested it, you had no choice but to have it copy the value into the output container. That's fine for things like ints and pointers, but that is inefficient for large objects, especially if they make a deep copy of member variables. That forced us to instead store objects by pointer, which required extra memory management. There were numerous other deficiencies with that class, but that one was especially annoying for me.

"They write their most important code in the shower and in their dreams."

I mostly blew this article off as bullshit until I saw this line - their definition of "writing code" involves planning, typing, debugging and refactoring. I dig that, I do my best conceptual planning away from the computer.

I still think this article is nonsense. So is the lines of code metric. Some tasks just take more lines of code than others, there is no correlation between the complexity of the problem and the number of lines of code it takes to write - the language and API you have to work with are also a factor. Besides, sometimes an implementation is better self-documented by more lines of code and sometimes an implementation is better self-documented by less lines of code.

The number of stable applications you can ship in a year is a better metric. Or, better yet, the happiness level of the people that pay you to do your work. That's probably the only one that matters.