Programming is not just writing code – it is working with a huge pile of abstractions. Starting from zeroes and ones, through processor instructions, memory addresses, low-level network protocols, data structures, up to web services, component frameworks and user interface. From low-level, often tedious stuff, to more pleasant to use and maintain stuff.
We are categorized as “senior developers”. Which, to some people, automatically means that we are experts in all these level of abstraction. And if we aren’t, then we are not good. I tend to disagree with this opinion. And not only to justify my lack of expertise in all levels of abstraction.
It’s basically a tradeoff – you either focus on some of the layers, and become really good there, or you do a little bit of this and that and become no expert anyway. You can argue that at some point you should reach an expert level in most levels, one after another, but this expertise becomes redundant and obsolete with time. If today I put my application design and framework knowledge aside, and plunge into algorithms or TCP programming, in 3 years I may no longer be expert in the former, due to the advancements of technology.
Abstractions are there for a reason – to shield you from knowing a huge amount of caveats down the whole stack. If it weren’t for the abstractions, we wouldn’t be able to write decent software at all. And focusing on higher levels is what we are supposed to do, because the lower levels are already handled. This turns low-level programming into some arcane art that is only for the enlightened, but that’s not the case. It is just that demand for it is lower.
This, of course, does not mean that by learning jQuery, rails or spring, you are the best out there and there’s no need to know anything else. By all means, you must be familiar how things work below your expert level, and also – above it. Mainly because all abstractions are leaky. You can’t ignore the fact that your application consumes memory, that you’d better use a hashtable when fast access is needed, and that a TCP connection may be firewalled, even though you don’t have to write destructors, implement the hashtable or know TCP. But knowing how things work in principle in other levels of abstraction doesn’t mean you are expert there. And you don’t have to be.
Why am I writing about this at all? Because people in many companies (including big ones) tend to think it’s a must to be an expert in all levels, and especially in the lower levels. Asking all these trivia questions on interviews, assuming you have worked with data structures and network programming all your life. Of course you haven’t, and this doesn’t mean you are not an expert.
Not being an expert in all these levels is fine. Be an expert in a couple. And be sure to know how the others below and above work in principle, so that you can become an expert when there’s a need for that.
Filed under: Opinions by Bozho
