Thursday, July 31, 2008

There are some things a good developer is NOT required to know

Jeff Atwood and Peter Norvig seem to think you must have a deep understanding of how computer hardware works to be a good software developer:

Know how long it takes your computer to execute an instruction, fetch a word from memory (with and without a cache miss), read consecutive words from disk, and seek to a new location on disk

I did learn these things, but after reading Jeff's post I have been trying to remember a project I worked on during the past 10 years which required this type of knowledge - and I got nothing.

Let's put aside for a moment specialized area in software development in which this knowledge is important:

  • Real time applications
  • Embedded applications

Assuming you are developing using a modern, high level programming language like Java or C#. During development of applications in areas not mentioned above, did you ever encounter an actual need to know these things? why?

1 comment:

Anonymous said...

This may be more applicable to C++ than to C# or Java, but I have found a lot of times that knowing low-level execution time is a great way to combat other peoples' premature optimization. A few examples:

- virtual functions take longer because of an extra indirection and the inability to inline

- dynamic_cast is slower than any of the other casts, because it has to walk up the class hierarchy

- throwing exceptions hurts error-case performance by an order of magnitude on most implementations


There are very few cases where either of those three performance penalties will actually be a detriment to the application, so knowing those costs prevents a developer from being snowed by pessimistic guesses about performance.

Though about I/O seek time... it may not matter to know the specific latencies for most people, but it certainly does matter to know if a function call is blocking or not. Even Java or C# programmers should be able to appreciate the difference between blocking I/O calls and either asynchronous I/O or a dedicated I/O thread with a nonblocking queue.