software development concepts

ruby

What Can You Build in 600 Lines of Code?

Joseph Cooney reminds us that, in January 2005, 37signals went live with a product they built in 579 lines of code [http://jcooney.net/archive/2007/08/16/54435.aspx]: > You read that right, not 60,000 or 600,000 but instead a commercial project written in less than

By Jeff Atwood ·
Comments

operating systems

Reinventing the Clipboard

Over time, I've become something of a desktop mimimalist. Sure, I'll change a few settings to my liking, but I no longer spend a lot of time customizing my desktop configuration. I've learned that if the defaults aren't reasonably close to correct

By Jeff Atwood ·
Comments

software development concepts

How Should We Teach Computer Science?

Greg Wilson recently emailed me the following question: I'm teaching a software engineering class to third-year students at the University of Toronto starting in January, and would like to include at least one hour on deployment --- [deployment] never came up in any of my classes, and it&

By Jeff Atwood ·
Comments

programming languages

The Enduring Art of Computer Programming

I saw on reddit that today, January 10th, is Donald Knuth's seventieth birthday. Knuth is arguably the most famous living computer scientist, author of the seminal Art of Computer Programming series. Here's how serious Mr. Knuth is – his books are dedicated, not to his wife or

By Jeff Atwood ·
Comments

perl

Nobody Cares What Your Code Looks Like

In The Problems of Perl: The Future of Bugzilla, Max Kanat-Alexander* laments the state of the Bugzilla codebase: Once upon a time, Bugzilla was an internal application at Netscape, written in TCL. When it was open-sourced in 1998, Terry (the original programmer), decided to re-write Bugzilla in Perl. My understanding

By Jeff Atwood ·
Comments

programming languages

On The Meaning of "Coding Horror"

In a recent web search, I found the following comment in a programming.reddit.com thread from eight months ago, completely by accident: I think prog.reddit will continue to move in phases... a couple of days ago, someone complained about a drop-off in Haskell articles, today there were 4

By Jeff Atwood ·
Comments

programming languages

Gifts for Geeks: 2007 Edition

In case you hadn't noticed, it's that time of year again: let the wholesale buying of crap begin! As a technology enthusiast with a bad impulse purchase habit, I get a lot of complaints that I am difficult to buy for. That's sort of

By Jeff Atwood ·
Comments

algorithms

The Danger of Naïveté

In my previous post on shuffling, I glossed over something very important. The very first thing that came to mind for a shuffle algorithm is this: for (int i = 0; i < cards.Length; i++) { int n = rand.Next(cards.Length); Swap(ref cards[i], ref cards[n]); } It'

By Jeff Atwood ·
Comments

user experience

Please Don't Steal My Focus

Has this ever happened to you? You're merrily typing away in some application, minding your own business, when-- suddenly-- a dialog pops up and steals the focus from you. At best, your flow is interrupted. You'll have to switch back to the window that you were

By Jeff Atwood ·
Comments

user experience

Presentation: Be Vain

Frets on Fire [http://fretsonfire.sourceforge.net/] is an open source clone of Guitar Hero [http://en.wikipedia.org/wiki/Guitar_Hero]. It's a great idea. Think of all the user-created songs we could play! My excitement quickly faded after I downloaded it and tried it out. I&

By Jeff Atwood ·
Comments

programming languages

Mort, Elvis, Einstein, and You

Earlier this week I wrote about The Two Types of Programmers. Based on the huge number of comments, it seemed to strike a nerve. Or two. This surprised me, because it was never meant to be the inflammatory, provocative diatribe that many people interpreted it as. It got so out

By Jeff Atwood ·
Comments

software development concepts

The Big Ball of Mud and Other Architectural Disasters

Mistakes are inevitable on any software project. But mistakes, if handled appropriately, are OK. Mistakes can be intercepted, adjusted, and ultimately addressed. The root of deep, fatal software project problems is not knowing when you're making a mistake. These types of mistakes tend to fester into massive, systemic

By Jeff Atwood ·
Comments