[rfrey]

I'm really surprised by the amount of smugness in the comments here. A bit of good-natured teasing, followed by a wheelbarrow full of "ruby-devs" this and "web-devs" that.

Take off your Hats of Superior Coding. Any one of us, regardless of honorific titles, could have made this mistake, and you know it. Being steeped in CS Fundamentals does not immunize you against bugs.

Congratulations to tenderlove for finding the bug. Remember the details - it'll be a great war story in a few years.

[agentultra]

Smugness: the dark-side of hubris. Hubris being one of the three virtues [0].

I like to remember the past of computer programming as though it was once friendly and receptive to people of all skill levels. I owe quite a lot to the geeks who came before me and answered my stupid questions, gave me powerful tools to learn with, and accepted my contributions; flawed as they were. Without making a few mistakes along the way I wouldn't be where I am today.

I don't know whether I would have given up if the people I met were more smug and mean-spirited but my progress might have been slowed by it. Life is too short to waste bothering with people who are miserly with their good fortunes. It doesn't cost you anything to be nice and share your knowledge and wisdom. It may pay off when the person you're sharing with rises to stand upon your shoulders one day and pay homage to you.

[0] http://threevirtues.com/

[duaneb]

You can be proud of your achievements without being smug.

Also, hubris being a virtue is crap. It may be decent for your self esteem but it makes you miserable to be around. Case in point: Larry Wall.

[bigtunacan]

Agreed, hubris is not a virtue.

Merriam-Webster - hubris - "a great or foolish amount of pride or confidence"

It's just a synonym used for arrogance and smugness. Humbleness is a virtue.

[wutbrodo]

From the way you phrased this, I think You may have missed the context link a couple comments above. Everyone is aware of what hubris means and that it's not a virtue per se. The point of the linked page is that it's (somewhat tongue-in-cheek) taking three vices and positioning them as virtues in a narrow context. It's just semantics; the saying could easily have used synonyms that have positive connotations, but using negative words instead is part of the joke.

[bigtunacan]

Yes; apparently I had. Thanks.

[ryanjshaw]

Is this even a bug or just a case of "in version 0.1 we'll do this quick & dirty", i.e. unaddressed technical debt?

I make a point to keep track of all technical debt in my projects so that I have an easy way to quickly identify opportunities for improvements when there is spare capacity, and also so that technical debt isn't left unaddressed.

[mkopinsky]

How do you keep track of the technical debt? Ticket system?

[kybernetyk]

    //TODO:

    //FIXME:

;)

[evincarofautumn]

Wink all you like, but I get a lot of value from greppable, well written fixmes directly in the source they pertain to. If I’m working on a feature and I discover some odd misbehaviour, there is often a comment right there in the source, explaining precisely what I need to do next.

[bigtunacan]

Agreed. A # TODO: or # FIXME: lives in the code for all to see. I use ticketing & project management tools as well (Pivotal, Trello, others), but these tools are more useful for "X needs implemented and has measurable priority or Y needs fixed ASAP".

Things that we know need to be addressed, but the priority level is "when we have time" are better served living in the code. They tend to get lost in project management and ticketing systems, whereas they live until the code dies if they are in the code.

[GoodIntentions]

If it is something expedient and thoroughly embarrassing I use

//kludge

[bglusman]

Shameless plug: https://github.com/bglusman/debt_ceiling

[varjag]

No need to track it, just default on the debt when it's too much to bear.

[tenderlove]

Thanks, I really appreciate the kind words! <3<3<3<3

[j_baker]

I think that Arrays are so ubiquitous and (usually) so fast that most devs reach to them by default unless there's a good reason not to. I can count on one hand the number of times a linked list has really truly been the correct solution to a programming problem I've faced.

[EpicEng]

Yet "most devs" aren't developing mainstream programming languages (nor should they). I can forgive e.g. a front-end dev for making that sort of mistake, but a language designer/implementer? No, sorry, you should know your data structures. You should be profiling this stuff and this many allocations should set off alarms. Modeling memory allocations and complexity in time and space should be second nature and, if not, should be understood before moving on.

[engendered]

Is this legitimately a bug, though? It could be tagged as a performance defect, but there is code like this through projects across the land.

I think the reason this rubs some people the wrong way is that implementations like this can be the result of the "no premature optimizations!" philosophy and its advocacy. I've encountered this firsthand at a number of organizations, and it apparently was somewhat endemic in the Ruby space.

Make something that works, and benchmark later to find that one magical hog that you can quickly change and then everything is optimal. Only it almost always ends up being a performance death by a thousand (million) cuts, performance and resource malaise so endemic that fixing it almost seems impossible.

[nirvdrum]

Not to get all philosophical, but "legitimately a bug" is a hard question to answer. Some people strictly consider correctness to be the definition of a bug. Others extend the definition to mean when things don't work the way they probably should (e.g., performance or usability). Performance is an especially interesting one to me because if it's not really a bug, then does a performance regression constitute a bug even if it's producing the same results? If someone is relying on that timing or it otherwise affects interaction with the code, its execution speed is a functional component.

In my experience, projects that adopt a slightly broader definition of "bug" have a better track record of improving on those fronts. Nobody like to have bugs around, after all.