Yeah, I do like books a lot. I use web resources too, but it’s hard to replace a well written book. Books provide a greater depth and breadth on a topic than the typical web article can.

In most areas of knowledge, I think there is a list of seminal writings that experts should be familiar with. Certainly, there is a great deal to be learned by doing, but reading, particularly while applying what you read, can dramatically shorten the learning curve. It could have taken me decades to discover of all of the valuable lessons I’ve learned from Scott Meyers “Effective C++” and “More Effective C++”.

Really, as long as you are reading I think you’ve got it covered. The main point is to learn from others who have been there before you. Then you are in a position to knowledgeably invent your own patterns or chart or new course.

A few years back I even saw a posting for a Java position requiring more years of experience than Java had been around!

I too will perhaps like to include the url to this post in my Profile like Riccardo

@Scott
the only thing is you are emphasizing too much on Books.
I can’t remember when was the last time I touched a Book. I learn by either real life Problem Solving or by reading stuffs online…

I get frustrated when People ask me How much experience I’ve got.

Sometimes I will respond
“I am 28 years old and I think I’ve learned something everyday so I’ve got 28 years of Experience.”

Or if I am too pissed up at the moment I will simply say
“I don’t like to judge one’s capability or at least my capability in terms of years of experience…”

Haah…
The whole Industry is Confused I guess..

There are weeks I produce maybe 10 lines of code in a day (on average), other weeks I may produce hundreds or more a day on average (and that’s without code generators).
Yet my productivity doesn’t swing by orders of magnitude over the same period, it’s just that my activities are rather diverse.

On a similar tone there’s an old warstory I lived through about a decade ago.
Our project teams all had KLOC targets for each release.
On one maintenance release our job had included a major cleanup of our codebase as well as some minor new features and bugfixes. We also had to do a lot of documentation work to get rid of a backlog stretching several years by that time (don’t ask, review cycles took that long there).
As a result we ended that release with a KLOC count of -20.000 lines of code for the 4 of us, with a target of +50.000.
We got an official reprimand from the company for that, which took the personal intervention of the project manager to get rid of (he’d known and approved our plans).
We’d actually created 30.000 lines of code, plus several hundred pages of documentation, but as we scrapped another 50.000 lines the end result was negative.
Those 50.000 lines less code to maintain meant a lot less brittle code, and helped no small bit getting our stuff Y2K compliant and ready for the Euro.

As to years of experience and the ridiculous things you sometimes see:
Back in about May ’99 I saw a job ad listing a hard requirement for 10 years of Windows 2000 administration. Windows 2000 had been released the month before.

For example, there have been a number of times I’ve written 50 or 100 lines to do something. After having done so, the light dawns and I can reduce it down to an elegant 10 or 15 lines.

This illustrates a number of caveats. First is that, in some cases, the person who writes an order of magnitude less code, might be writing better, maintainable code.

This also indicates that someone writing more LOC per year is not necessarily better than someone writing fewer LOC per year.

How does one develop a metric for the thinking and puttering time? Time spent to come up with an elegant, easy, maintainable solution? Perhaps something like LOC/feature would be better. And, yes, I know, the question becomes one of defining quantifiable features,… etc… but is something to think about.

Marcus, don’t get wrapped around the axel on the LOC thing. My point isn’t that writing more code provides a better solution. It’s that the number of lines of code you’ve written is a far better metric for experience than time. Assuming an acceptly succinct programming style, you will learn more and have more opportunity for troubleshooting by writing more code–not more code to tackle a single problem but more code to tackle more problems.

And, yes, I do think LOC metrics matter. And apparently, so do you. Your point is that a solution is better if it involves fewer lines of code. Well how do you know that someone has achieved this if you don’t measure it? Just as cyclists measure heart rate, cadence, and wattage to analyze their performance, programmers should measure all sorts of values to analyze theirs. None of those values directly translate into victory, so you always have to interpret them. But they do give you insights into performance.

If you had two programmers and one consistently wrote twice as many LOCs every month, wouldn’t you be curious why? It doesn’t automatically mean the one with the higher LOC count is better, but it gives you a starting point to investigate. Perhaps he is writing more verbose code. Perhaps his tasks are simpler and he simply writes more of the same boilerplate code over and over. Or maybe he truly is more productive.

I guess that’s a topic for another blog, though. 8^)

And can we please get rid of the LOC metrics? I can’t believe you buy that. LOC are the tax we pay to have functional maintainable software, the less of them we create without harming the functionality and maintainability the better we are off.

That, and this blog post, are an excellent observations – having interviewed hundreds of developers in my time, I’m often sadly disapointed at how little they seem to know despite their time in the trade.

I truly believe that experience is good, but you have to continually push your knowledge during that time. For me a great indicator is what you’ve read. Although not entirely accurate, I find it’s a better indicator of skill than years of experience.

There are some classic books in software development such as The Mythical Man Month that should be read by all developers. Sure you may skip a few, or not even know about them all, but if I give you a list of the top 20-50 software development related books, you should have read at least a few. If you can identify any, well…

As an extreme example of this inflation, I once saw a position which asked for 1 year experience… for an _intern_.