Enterprise Integration Zone is brought to you in partnership with:

Senior Java developer, one of the top stackoverflow users, fluent with Java and Java technology stacks - Spring, JPA, JavaEE. Founder and creator of http://computoser.com and http://welshare.com . Worked on Ericsson projects, Bulgarian e-government projects and large scale recruitment platforms. Member of the jury of the International Olympiad in Linguistics and the Program committee of the North American Computational Linguistics Olympiad. Bozhidar is a DZone MVB and is not an employee of DZone and has posted 87 posts at DZone. You can read more from them at their website. View Full User Profile

You're Not an Expert in All Levels of Abstraction

06.24.2013
| 10230 views |
  • submit to reddit

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.

Published at DZone with permission of Bozhidar Bozhanov, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Gaurav Abbi replied on Sun, 2013/07/14 - 8:48am

Well said, 

With experience, you might not get expertise in all levels which is fair and true.

But what one gains, when he/she is doing well within his/her domain, is to get better at attacking a business problem. We start think better and taking into account more variables and aspects when designing a software as compared to early phases of our carrier :).

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.