The 100 hours re-tooling rule

[Peter Gibbons]

I don't get it why there is such resistence to learning new languages and in general re-tooling by some developers.

If somebody has spent already 10000 hours to become a master in software development - why not spend another 100 from time to time to keep their skills marketable?

If somebody has spent 10000 hours mastering C/C++ then 100 hours should be more than enough to become really good with Objective C - one of the hottest 'new' languages.

Javascript could be learned just as quickly - no matter what is one's language background.

Usually people will say - "Yes the language could be learned, but what about the APIs and frameworks? They are huge!".

I always thought about APIs and frameworks as learn as you go thing.

I have close to 15 years using Java and I certainly don't remember more than 5% of all APIs. If I need something - I just look it up.

I know one of the objections is that new languages do not bring any new advantages to the table. That is debatable but the fact is that Apple could decide to use any language they want and the didn't go with C++ - they went with Objective C. We could complain that Objective C is too verbose and requires semi-manual GC or we could just grab the bull by the horns and learn it.

[Slinky]

I have close to 15 years using Java and I certainly don't remember more than 5% of all APIs. If I need something - I just look it up.

Unfortunately, the number of shops in my commute area want you to have these APIs memorized, and be able to regurgitate them on demand.  That's the #1 reason that the people I know, have a resistance to learning new stuff. I agree with you that these can be looked up easily, but if the people giving you money want them memorized, then the issue is DOA for most older developers. You will not get past the interview for X skill. My memory is not what it used to be, and my brain "leaks" a lot of trivial facts like these.

This only seems to work if you work for yourself.

[David Randolph]

It isn't just API's that have to be learned. There are also ways of doing things that need to be learned periodically.

For example, look at the difference between how one would program a solution in Fortran and programming using generics and dependency injection in C#. (And I just looked up templates for C#. There are a couple of packages that do that.) Having worked in wierd assembly such as the Forth run time, many of the Object Oriented patterns seem to be ways to convince the compiler to let you do stuff like I used to do back then. The compilers don't want you to do things like setting pointers to routines to call, but that is often the most efficient way to do something. So, someone works up a "pattern" of how to program to get around the compiler. Then, they teach that to the kids as something totally new.

But, we have to learn these new ways in order to deal with the latest tools (with their restrictions).

[The Gorn]

I don't get it why there is such resistence to learning new languages and in general re-tooling by some developers.

In my own case it is due to burnout plain and simple. In the past I have jumped through new language hoops like a dumb little circus stunt animal several times, and then been disrespected for "not having enough X to bring to the table."

[I D Shukhov]

I have to have a motivation to learn a language.  To be "more marketable" absolutely does not do it for me any more.   I need to have a project I care about and the language must be the right tool for the project. 

Pure interest is also not a good enough motivator for me, because I don't have an infinite amount of time and have to make choices.  For some  people pure interest is perfectly okay, though.  I'm sure Erlang, for example, is interesting, but I don't currently have a need to learn it.

[Peter Gibbons]

To be "more marketable" absolutely does not do it for me any more.

Good point. I should have phrased it: "Being ready to take advantage of new opportunities."

Being interested is a key point. I never was able to push myself to learn some enterprise frameworks like Struts, Spring, Hibernate ...
I knew "I should" but never was able to sit down and do something with them. Just reading the docs a little bit gave me a big headache.
So I left those opportunities for other developers to take advantage of.
 

[Walter Mitty]

David,

My take on assembler is different from yours.  I did a lot of my early professional work in assembler,  before "goto" was considered harmful.  Assembler certainly permitted the clever and knowledgeable programmer to build things along the lines of millions of intelligent patterns.  And also along the lines of billions of stupid patterns.  It just didn't coontrol the programmer very much.

If generic programming reminds you of things you used to do in assembler,  I don't doubt it.  But the higher level languages might have been doing a favor to people who did stupid things with assembler.  I don't think of myself as stupid, but there are certainly a large number of stupid mistakes I made in assembler.  The right high level language might have saved me from a few of those blunders. 



I know that, when java programmers cut over to SQL,  one of their consistent reactions is that they feel that thev'e gone back to assembler.  I also know that that's how I feel when moving form SQL to Java. 

[unix]

I tried to learn Java but just gave up. No sense in re-tooling for an uncertain future with no obvious benefits. Instead, focusing on something shallow and stupid, Perl.  In the sysadmin teams I have been in, I was ususally the only one who did any development / scripting / automation.
I always wondered what my career would have been like had I pursued development. 

[The Gorn]

I tried to learn Java but just gave up. ...  In the sysadmin teams I have been in, I was ususally the only one who did any development / scripting / automation.
I always wondered what my career would have been like had I pursued development.

Retooling for an administrator ought to be somewhat different than it is for a programmer. No, it doesn't even make any sense for you to embrace Java. You aren't a developer and system admins work with quick and dirty solutions, which epitomizes scripted languages. The words "quick and dirty" don't even belong in the same paragraph with "Java."

What are the trends in system administration? You should be learning tools and techniques associated with those, assuming that you want to stay in that field.

[David Randolph]

Assembler certainly permitted the clever and knowledgeable programmer to build things along the lines of millions of intelligent patterns.

Even back in College, I was asking the questions of "how to organize programmer work better". The Masters I almost got was in Industrial Engineering which asks that question of a lot of fields. My first year as a full time professional, I read the book on data flow diagrams and some on object oriented programming. Thus, I was using the concepts as early as I could and the only tool that let me do that was assembler.

Almost none of that effort paid off in terms of a career.
Lesson: Learning how to do the programming better doesn't help the career. People skills paid off better for others.

[Walter Mitty]

When I think of how to organize programming work better or industrial engineering,  I think in terms of The Psychology of Computer Programming by Gerald Weinberg.  But I think I'm probably misconstruing your use of those terms.

As for me,  I learned programing as a sideline during college.  My first course in programming was a "freshman elective", the only course that didn't have to be related to the rest of the curriculum.  I soon as I saw my first computer, behind the glass, I realized that I wasn't going to get anywhere in science without mastering that tool.

The first course taught assembler and FORTRAN,  but not structured programming,  let alone object oriented programming.  Smalltalk was still a decade in the future.    I don't recall exactly why I latched onto assembler rather than FORTRAN.  I think it had to do with control over the machine.  I certainly did use FORTRAN wherever number crunching was called for and FORTRAN was available. 

Then I got my hands on a computer, and I was pretty much hooked.  That machine was a PDP-1  (yes, one)  and it had only assembler on it.  Plus DDT, an interactive debugger.  That pretty much deifned my  technical trajectory for the next ten years.  But I still didn't think in terms of earning a living with computers.  When one of my Physics professors heard that I was learning programming, his comment was "a waste of a good mind."

[Walter Mitty]

I never, ever got a job in computing except through people that knew me, with one exception.  The people who knew me back then thought I was pretty good at what I did,  and so did I.  But selling myself to a stranger just wasn't my line. 

Later on, when I switched to contracting, I mostly got contracts through people that knew me. 

If you're good, and nobody knows it,  you're screwed.  That was true forty years ago, and it's still true today.  However, if you direct your major effort towards making sure people know how good you are, you're screwed, unless sales is your thing.  If you're good at technology, you have to realize that the half life of technical know how is about 18 months.  You have to keep learning.

Every now and then, you run into fundamentals that you can use for about ten years.  For me, the last such thing was the relational model of data.  That changes, but real slowly.  And it's real powerful.

[The Gorn]

If you're good, and nobody knows it,  you're screwed.  That was true forty years ago, and it's still true today. 

You are slightly better off than if you are not "good". At least you have raw materials in your possession.

A lot of people don't even have that.

However, if you direct your major effort towards making sure people know how good you are, you're screwed, unless sales is your thing.

If you direct your major effort toward making sure that people know how good you are, sales will eventually become your thing. (Consider it learning on the job, in a way.)

If you're good at technology, you have to realize that the half life of technical know how is about 18 months.  You have to keep learning.

Every now and then, you run into fundamentals that you can use for about ten years.  For me, the last such thing was the relational model of data.  That changes, but real slowly.  And it's real powerful.

I milked C++, Windows, and the object oriented paradigm of software development from 1992 through 2010. What's that, 18 years? Not too bad by your time line. I consider myself fortunate that it lasted that long.

There are still a lot of commercial projects in C++. And there are still a lot of Windows applications being written, even in C++. But the market for technology services and software development has changed for the worse in that time frame. Which is where my involvement with it pinched off, in 2010.

Today even the smallest, most bush league companies with almost no management expertise attempt to run software development like a factory effort. In particular they don't wish to deal with individuals who can carry a large part of the project themselves.

They see immense risk in this model and they really don't want to have powerful programmers working for them. Even when it is really the only feasible way of getting something done on their financial terms.

This is the era of the weakling, cowed software developer and the play-pretend team effort where everyone regardless of merit is "equal". The push-around milquetoast who works within a strict methodology and bows to his masters is the desired model of candidate.