This is the first of several interviews from fall of 2010 that I will document.
The Microsoft Software Development Engineer Interview is hard. While no interview process is perfect, they do a lot of things right in terms of setting a high bar, as well as showing off what the company has to offer. It is exactly what you’d expect from a world-class software company that has fairly high standards for engineers. Continue reading “The Microsoft SDE Interview”
The main purpose of oil is not to prevent food from sticking. I had long thought this. Oil acts as a flexible conductor for heat and allows food to cook more evenly. Continue reading “Things I Learned about Cooking”
“The great thing about managed code like Java and C# is that it can’t leak memory, because the garbage collector takes care of everything for you by reclaiming objects using a reference counting algorithm.”
The above statement of course, is completely false, although widely repeated. Continue reading “Memory Leaks in Managed Code”
Many programming languages contain the concept of a null “value,” which can mean “nothing,” or may be precisely equal to integer zero. When encountering this in a database, it would be natural to assume it means roughly “nothing.” This is a naive, although workable definition of null. As we’ve seen, simplified and even incorrect definitions can nonetheless sometimes be helpful. In this case, it is better to have absolute clarity. Continue reading “Databases: Null is not a value”
Agile is the hip new software development methodology. Everyone from Fortune 100 firms to doughnut shops are trying to implement it these days. When even a US Department of Defense contractor is trying to become agile, a serious paradigm shift away from the traditional waterfall approach to a better methodology must be happening because agile is better. Or is it?
Continue reading “You're Doing Agile Wrong”
I’m a firm believer that the things that destroy organizations are not the big problems, they’re the little ones. The “bikeshed problem” is the type of problem that everyone loves to squabble over: the completely trivial, stupid issue.
Continue reading “Bikeshed Problems”
UMass offers a software engineering course (CS320) that teaches the software design process — on real projects, with real teams. It is managed by select students who have successfully passed the course. Below are some rules I (tried to) live by while managing my 12-member team. Continue reading “How to Manage Software (at UMass)”
Because everyone and their grandma is coming out with a book on “usability for people who aren’t user interface designers,” I’ve decided that I too am qualified to say something on the matter. I’ve been writing some docs in preparation for my hiatus from Etna, and below I’ve included some snippets from those docs. This is high-level advice for programmers that have to make do with their own interfaces, and want a good starting point for designing UIs. Continue reading “User Interfaces for Engineers”
If there’s anything I’ve noticed that plagues many less-experienced programmers, it’s what I refer to as the fencepost problem (or fencepost error, if you will). The problem can be most succinctly summed up using this thought exercise: Imagine a fence that is 100 meters long. A fencepost is needed every 10 meters. How many fenceposts are needed?
Continue reading “The Fencepost Problem”
I’ve used CakePHP for a lot of projects now. Verdict: there’s no comparison to Ruby on Rails. Ruby on Rails is smartly integrated, well-designed, and sits on top of an elegant language. CakePHP is an admitted ripoff of Rails that sits on a popular but terrible language. It copies Rails – almost randomly – without copying any of the stuff that makes Rails great. PHP is a language plagued by indecision, delays, and paradigms from the last decade. Continue reading “Why I Don't like CakePHP”