My Code or Someone Else's Code? | Hacker News Reader

My Code or Someone Else's Code?

lookatsoftware.blogspot.com

15 pointsjeffspost8 comments

I really enjoy looking at other people's code. I also enjoy them working on mine. I tend to approach the situation as "I can make it better". Sometimes I'm just blown away by what is there. Most of the time however fresh eyes are good, and I can refactor it prettier, or add edge case handling or whatnot.

I also find maintaining my own code boring. In my head, I've already done all the interesting bits. Letting someone else work on it, then bring it back to me makes it interesting again, because it turns on all sorts of new ideas based on what the other person discovered (and I missed).

In general the best code I've ever been part of has included passing code around the group. Ownership of modules was shared by at least 2 people, and everyone had input on it. Unfortunately this gets ruined frequently by the type of dev that thinks my changes to his code are an insult ("it was working just fine before, now its all weird, I don't know what you did" where before means before the spec changed).

I think that your ability to keep the ego out of the picture can convert (potentially fractious) collaboration into the best kind of continuing ed. Bravo!

Yeah, that's hard for me: not to be defensive; always to remember i am a continuing student (and that that's a good thing).

Ditto.

Sometimes I take a look at other people's code just to see how they implemented something, even if I've already implemented that something in my own code.

Diving into a huge codebase is daunting, but I love reading snippets or small scripts written by other people.

I find reading other code is a great way to learn. I'm working through both Quantlib and GNU Scientific Library to learn numerical methods that can be used in finance. Theory is one thing, but when you see an actual implementation of it, then it becomes much more clear.

Sometimes it's good, and sometimes it's not. I find that the language has a lot to do with it.

At some point I was doing some modifications to Rails 2.0 internals (the public APIs to these sorts of things never expose the needed functionality) and I found it pretty much impossible to predict when something would get executed (if at all).

Figuring out how Rails is wired demands serious spelunking. Forget reading. You invariably need to get out the profiler and browse call graphs, and then shotgun-pepper the code with thrown exceptions to see where in the stack they come up - and this is just to figure out how it's put together. (Hint: a template handler in Rails 2.3 gets called 32 stack levels deep, at least two of which are a benchmarker).

I think this has much to do with all the "magical" stuff, so it might be particular to Rails - but I also think that the easy power of the language gives programmers a lot of rope to hang their readers with.

I wonder if an easier, "fun" like Ruby language makes people cavalier about setting up crazy structures, whereas "difficult" languages like C++ make people a bit conservative - the language is complicated enough, so why make it worse with crazy design?

This 200 word blog post made it to page 1?

Concision is good.

Reply on news.ycombinator.com