27 Jan
2012
27 Jan
'12
7:15 p.m.
On Fri, Jan 27, 2012 at 11:27 AM, Richard <legalize at xmission.com> wrote:
It's one thing for a company to pay you to stop doing productive work
for a long period of time to retrain you in a new specialty.
It's an entirely differet thing to receive support to learn new
technologies.
No argument there. Perhaps the difference in viewpoint is around the
nature and length of "period of time".
?The statement was made:
In article <CAALmimmn7ZO96S=LfAaSYrknGq2Syk8mBLW8C2xS99COwtAp=g at
mail.gmail.com>,
? ?Ethan Dicks <ethan.dicks at gmail.com> writes:
And I have had a different experience - at _some_ places that was
true. At other places, no slack was given to allow time to absorb and
become more than a bumbling novice such things. Guess which places
were more fun to work at.
One place where it _did_ work, we had a team of experienced UNIX
developers... about 5-6 of us. The decision was made to shift to Perl
as a primary application development language (with a bit of C thrown
in for the parts where that still worked well). The dilemma was that
at the time (1998), Perl application (not web) developers weren't
exactly common, so it made conomic sense to invest in the people they
had since they would not be able to build a team of ready-made experts
in under 3-6 months. We spent an hour a day, first thing every day,
for *weeks*, with the team lead teaching a Perl fundamentals class to
us all. Most of us were contractors... the customer spent *thousands*
of dollars to do this. At the end of it, everyone was far, far
improved and the team went on to produce some pretty hairy stuff
because we had the chops to do it.
At CompuServe, before I joined a particular team, they did something
similar when they shifted from 36-bit and 32-bit hosts in the 1990s to
a foray into Windows NT... all the developers were signed up with
Developers' CD subscriptions and they took the existing team members
and brought in instructors and spun the team up on how to develop for
the new OS. Some years later, after AOL bought up CompuServe, the
same team, under many of the same (local) managers, right before I was
hired, shifted away from Windows and to UNIX (of all flavors and
vendors) for business application development. At that transition,
they laid off a number of folks (not all, but a good chunk), then
hired new folks (including me) who already knew C and Perl and UNIX
development.
I stand by my claim that if what you have experienced has been the
situation at every place you have worked, you are fortunate. Me...
I've been nimble over my career, picking certain techologies over
others and jumping in (and out) when the gates of change have opened.
Is that what was said, or perhaps was it that in
the professional
world (in the States for sure, and perhaps the UK now) you won't be
_given_ time to learn anything, nor are you likely to receive much
support to learn anything - [...]
Every place I have worked, there is always time to learn something new
and I have always received support for it. ?If by "time to learn
anything" you mean that the company should effectively put you on paid
6 month sabbatical, then yeah, *no* company is going to do that.
I meant nothing of the sort. I mean 3 to 5 to 10 workdays. Classes,
seminars, etc.
Learning new technologies, practices, techniques,
etc., is an ongoing
part of software engineering because the field moves too quickly.
I totally agree.
Usually all it takes is reading some books to stay up
to date and that
can easily be done for like 10 minutes a day during lunch.
I disagree here - to the extent that context switch overhead alone is
going to render "reading over lunch" largely an effort in reviewing
what you tried to read yesterday. It takes more of a time investment
than that.
?It really isn't that hard to keep learning new
stuff, but it's your responsibility
to manage your career and make it relevant to marketplace demands,
not your employer's responsibility. ?For people that aren't good
autodidacts, there are things like code camps, user group meetings and
so-on.
There are... I have presented at code camps and I have run user
groups. They are still no substutite for vendor or technology-based
instructional opportunities. They are an augment.
The only person looking out for your career is you.
That is at the crux of what I was trying to communicate - your
employer is no longer looking out for your long-term development.
Your employer is no longer sending you to week-long events like DECUS
Symposia or 3-5-day formal training sessions for new technologies,
etc. You are expected to be an expert on demand or you will be
replaced with someone who claims to be.
Now... to counter that... "never" is too strong, but "almost never"
may be about right.
From the tone of your responses, it seems to me that I
should make a
point explicitly clear - I have learned stuff constantly throughout
my
career. I took exactly *one* course involving programming while
pursuing a bachelor's degree, and I had been programming
professionally for three years at that point. I did not learn my
craft in school, I learned it on my own and on the job as needs
demanded and opportunities presented themselves. I have never stopped
learning, and as others have expressed, won't stop until I'm dead. I
have also found myself eminently employable at all times throughout
the past 30 years. I am not crying sour grapes that the world is
passing me by because of the state of the IT industry.
This particular thread started with the quote "the other week I was
told on this list that once you get into the commerical world there's
no time to learn anything." that I first asked clarification on the
scope of and then presented a hypothesis about what the scope of the
original thread behind the quote might have been. Specifically that
in the present IT envirionment, companies will not pay you to learn
your job, but that once upon a time, they _did_ formally retrain
employees with week-here, week-there formal re-education. The model
I've seen lately is much like you describe - steal time away from
"keeping things running" or "writing XYZ pounds of software" - i.e.,
day to day workload requirements - and spend that time reading
manuals, web pages, etc., while trying to keep skills current enough
to remain relevant. On your own time, not with the support or
blessing of your employer. Stay current or be replaced. That was my
point.
-ethan