programming languages
Paul Graham’s essay, Revenge of the Nerds, is a nearly pornographic love letter to Lisp. If you can manage to read all the way to the end, there’s an interesting footnote buried at the bottom: Peter Norvig found that 16 of the 23 patterns in Design Patterns were
performance
Managed code may be fat and slow, but it fares surprisingly well in Rico’s C# port of Raymond Chen’s C++ Chinese/English dictionary reader: Sure, the C++ version eventually outperforms the managed code by a factor of 2x, but what’s interesting to me – and what this graph
software development concepts
Joel, on the merits of dogfooding: Eating your own dog food is the quaint name that we in the computer industry give to the process of actually using your own product. I had forgotten how well it worked, until a month ago, I took home a build of CityDesk (thinking
programming
In Extreme Programming Explained, Kent Beck notes that optimism is an occupational hazard of programming. Excess optimism, in the guise of enthusiasm, is a serious pitfall for game developers in particular: Rein in enthusiasm? Now why would we ever want to do that? Isn’t keeping the team motivated one
software development concepts
I was chatting on the phone with a friend of mine a few days ago, and he described a project he recently inherited. It was the work of a half-dozen different developers, who each built their parts of the project in a completely different way with little to no communication
programming languages
If you develop software long enough, you’ll eventually run into Universal Modeling Language. This happened to me last year when we started working with our offshore vendor. UML is a diagramming standard that allows you to model software in a universal way. This could be theoretically be helpful if
programming languages
A recent user-submitted CodeProject article took an interesting perspective on the VB.NET/C# divide by proposing that the culture of Visual Basic is not conducive to professional software development: We’ve seen that the cultures of VB and C# are very different. And we’ve seen that this is
programming languages
In Maciej Ceglowski’s cutting counterpoint to Paul Graham’s Hackers and Painters, he cites a key difference between software development and painting: writing software doesn’t get you laid. There’s nothing whatsoever distinctive about the analogy to painters, except that Paul Graham likes to paint, and would like
user experience
I had a great time at today’s Raleigh MSDN Code Camp. There’s nothing better than geeking out with a bunch of guys and gals who are as passionate about this stuff as you are! For anyone who couldn’t attend, here’s a a local copy of my
software development concepts
If anyone reading this is local to Raleigh-Durham and signed up for the 2005 Raleigh Code Camp at NC State, fair warning: I’ll be presenting there. The speaker schedule is packed with interesting sessions. Mine is on User Friendly Exception Handling Strategies at 10:15am. I haven’t had
presentations
Like most developers, I don’t get a lot of experience giving presentations. The golden rule is: practice, practice, and more practice. Then incorporate the feedback from those practice sessions into your presentation. Of course, it helps to perform practice sessions in front of people who have seen a lot
parsing
I’ve blogged ad nauseam about how much I love Regular Expressions, but even the mighty regular expression has limits. As noted in Daniel Cazzulini’s blog: A full-blown programming language cannot be parsed with regular expressions. But given the limited number of programming languages (successful ones, let’s say)