There are some things a good developer SHOULD know
Adi has posted a post that I am not in agreement with: there are some things a good developer is NOT required to know.
[Quoting Jeff Atwood and Peter Norvig] 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.
Well, I used knowledge about reading & seeking to / from disks the last two weeks. They are extremely important when you are thinking about high perf large I/O. Fetching words from memory, and the implications of ensuring good locality have huge affects on the type of performance that you are getting to get. As a simple example, a large part of the reason that thread switching is slow is that the CPU cache is mostly misses when you switch a thread.
You should know those things, and you should know how to apply them. No, they don't come often, and I can think of a lot more things that I would like a developer to know (OO, to start with) more than those low level details, but those are important to know.
Comments
Maybe they are important to know on demand. Maybe more important to know is how to find out such details when they come up, or good research skills, because the Jeff Atwood article was a bit silly - I would guess it is a fraction of a percent of even the most dedicated among us who has time to fill their brains proactively with such minutia just in case some day you may find yourself writing some bare metal piece of software. Much better I think to fill your brain proactively (which is, I think, what these guys are talking about) with scaffolding type knowledge, larger concepts and bigger pictures, and save the details for when you are ready to apply them. Unless of course you find that kind of thing fascinating, and you are simply satisfying your own rabid curiosity.
Yes and no.
You need to be aware of those issues.
I am not even sure what type of HD I have on this machine, for example.
But I know enough to understand what seek time and write latencies are all about, and I can find out the exact numbers if needed.
I don't know the numbers for the L1 cache either, but again, I understand the implications of its existence.
For me, these are all key concepts. The absolute numbers are irrelevant as they can be looked up, but you should know their respective orders of magnitude. This allows you to put upper/lower bounds on certain operations without spending a lot of time writing code or firing up a profiler. Some back-of-the-envelope calculations will point you in productive directions for profiling and optimizing as well as steer you away from fruitless attempts. Let's say you've got a web page that takes 5 seconds to render. A bit of digging reveals that it's executing a lot of SQL queries. Most of the time is spent waiting for the database. Some quick calculations reveal that most of the time is network latency, not query execution. Reducing or batching queries will pay off handsomely whereas tuning queries will likely not net you much improvement. Understanding physical limits of typical hardware is essential for highly performant applications.
I'm in agreement with the poster above. Knowing the characteristics of these kinds of operations has value but the specific numbers probably aren't a great deal of use because the story is always more complicated than a single operation in isolation.
Knowing how to use the tools in your toolbox, in this case profilers, and knowing where to point them is a must.
I think it comes back to what kind of developer you are. System (OS, compilers, high performance/transaction distributed systems) developers are expected to know this stuff.
The vast majority of developers in IT are writing and maintaining non-performance critical business apps, whereby application level profiling (a little concurrency and caching knowledge) and the ability to google proper platform API and pattern use are probably the more important skills.
I'm not questioning the veracity of the statement, but only pointing out a practical fact. I'm pretty confident that if I were to poll all of the developers that I come into contact with, which is not a small number, and I believe representative of general .NET developers, nine of of ten could not answer that question.
Oh, here's a good question. If you did not study CS, but grew up independently in this jungle world of software development, where can you go to learn the ways of men? I'm in the process of trying to fill the holes in my education (or lack thereof). I'm fat on OO/TDD/DDD sort of stuff, but lean in many other places. Anyone have a good curriculum to recommend?
I think for the most part we agree with each others. Some of it I know, some of it I don't, but I think it's imperative for any developer to at least have a vague idea of what they are and where to look them up. There are many thing that I don't deal with everyday that I wouldn't know them on top of my head but I can quickly pinpoint the necessary documentation and understanding them without much trouble.
These "must know" lists are really nothing more than ego-boosting tirades that amount to nothing more than "I know this - so should you."
So much of what "must" be known depends on the environment of the "problem". What someone deems a "must know" list on an clock-driven CPU architecture would not necessarily apply to an asynchronous CPU architecture.
Also, there are a ton of these "must know" lists out there, each of them quite different. If you took all of them, put them together, and made one "master" list, there would be no way any single "good" developer could know all of it; it's just too much information.
However, I do feel that there are a couple things all "good" developers should know how to do. Simply put, they should know how to find information and how to use that information. That's it. As long as you can determine what you need to know for a given problem, find what you need to know, and use what you learned, you are set.
Oren, as you wrote in a previous comment, developers should be AWARE of these things, but they are not required to KNOW them.
I agree with Michael - a developer should know how to search information and learn this stuff when it's required.
But to fail someone at a job interview (as Peter Norvig would have done) for not knowing this?
Christopher,
I don't have a CS degree.
A few books that have been very helpful are:
Operating System Concepts
Modern Operating Systems
Practical File system design
Operating Systems - Design & Implementation
That would give you a really good foundation in how things are working at the hardware level.
Read the c++ programming language and build a non trivial application in it.
In addition to just knowing these data points from a performance point of view, that knowledge also provides the developer with a more holistic view of how the system works. Without that knowledge, it is really easy to simply write code to the black box.
Those are just a few data points, but knowledge of low level concepts like Operating Systems (process scheduling), Compilers, Processor architecture (pipelining, etc.), can help to solve higher level problems through extension.
This article is a waste. They didn't say you should not know it, but they said it is not required. Were you just bored and wanted to write something or do you h8 MS?
James,
If you don't like this post, feel free to skip it.
Ok, random anecdote, but this reminds me of when I was first dating my now-wife who is a scientist. She asked me, "Do you know how a hard drive works?" And I was like, "I'm a programmer, of course I know how a hard drive works." She proceeded to talk about magnetic fields and the crystal structure of the material that makes up the driver. I then conceded, "No, I don't know how a hard drive works."
Comment preview