

Ask HN: How do you keep up with changing technologies? - WesleyJohnson

I was late to the game and have roughly 5 years of experience with SQL Server and around 2 to 3 years of experience with ASP.NET and OOP concepts. I'm still learning new things on regular basis and only recently truly discovered the wonders of interfaces, after nearly 3 years of working in ASP.NET and C#. I still write all of my object &#60;-&#62; database mapping code manually (and kind of enjoy it), but I know the way of the future is Linq to SQL, Linq to Entities or NHibernate and 2 of those technologies have been around for at least a couple of years now. I just took a new job and while I think I've upgraded in terms of the caliber of people I'll be working with, it's an established shop so I'm still looking at interacting with veteran technologies on a daily basis - with no real hope of integrating the newer that's out.<p>I suppose if you're building products and apps that work and the end result doesn't become obsolete, then it doesn't really matter if the tech you built it with is older, but I can't help but feel like I'm falling behind. How do keep with up all changing technology and how do you force yourself to step outside your comfort zone of doing things the way you know how and trying something new? I just don't want to put in another 4 years at a job and find myself unemployed and 7 or 8 years behind the field.
======
patio11
There are two facets to this question: what you can do as WesleyJohnson and
what you can do within your organization. Your motivation is making sure
WesleyJohnson has a job four years from now. Your organization's motivation is
selling more $FOO at lower costs. You need to start identifying or creating
happy synergies which align your organization's motivations with your personal
motivations in terms of career growth.

I do Big Freaking Enterprise Web Apps at the day job. I do not want to be
doing BFEWA in a few years, so I convince my day job that I can deliver
projects on schedule and under budget if they give me more latitude with
respect to the technologies I'm allowed to use.

This started with the kind of one-off "We don't really care what you do to
accomplish this as long as you get the job done" projects and snowballed from
there.

A key component of my process was, after saving them a truckload or two of
money, I would rigorously document what I did, how much we saved (metrics
METRICS metrics), future places we could employ the
technology/technique/whatever, etc.

After iterating this a few times, a) when I say "Hey boss, that will work, but
I can do it two man-months cheaper if you let me do it my way" they tend to
listen to me and b) other people come to consult with me about How To
Implement X issues because they've found that I often know what I'm talking
about or, in the alternative, can rectify my ignorance with a few weeks of
studying and rapid prototyping.

When I'm building stuff for the day job, usually I want to be leaving them
working systems or system improvements which will continue to generate value
long after I am no longer there (as opposed to daily firefighting). I also
want to be building personal capital which will continue to generate value
long after I am no longer there (as opposed to daily firefighting).

Note that if you have a small side business, you can create opportunities to
use a new technology without having to bring anyone else into the loop at all.
Earlier this year I wanted to do some work with NoSQL to see what all the fuss
was about. So I picked one of the upcoming tasks that looked like it would be
a good fit, and did it. (Presumably you can do the same with OSS if you don't
have a business handy.)

~~~
WesleyJohnson
Another very good idea and something I hadn't thought of. As I mentioned, I'm
only 1 week into the new job, but was given wind of a new project coming in
that's going to require a classic ASP webapp to be migrated over to ASP.NET.
This may be a great opportunity for me to do just what you've outlined.

------
omouse
Don't. Learn the concepts and ideas behind the "technologies" and work with
them instead. Then it just comes down to messing around with the details of
implementation. This way, whatever happens to be "the way of the future" next
will be easy enough to pick up (unless it's something absolutely horrid which
no sane business should use).

You aren't falling behind, don't worry.

~~~
WesleyJohnson
You make a very good point and I appreciate the suggestion. I suppose getting
caught up in the new and cutting edge is really less important than
understanding those core concepts and ideas as you've mentioned. I suppose in
some light I've already done this and just hadn't realized it. My last job was
my first experience with the Microsoft Stack and I worried about picking
things up quickly enough. However, even the limited experience I had with VB,
PHP and MySQL had exposed me to enough general programming concepts that
picking up ASP and SQL Server proved to be far less difficult than I had
imagined. Thanks for reminding me of this.

------
ramanujan
At the risk of being downvoted, I'd say to look at other stacks besides MS
(esp. Linux, OS X, Iphone, Android).

With the noted exception of Stackoverflow, most innovation in tech today does
not involve MS.

~~~
patio11
A quick meta-tangent: "at the risk of being downvoted" adds little to the
discussion in the best of times. "At the risk of being downvoted for
criticizing Microsoft" adds little to the discussion and requires about as
much courage as an American presidential candidate taking a principled stand
strongly in favor of apple pie.

A good portion of the innovation taking place these days is on the web, and
the stacks at issue aren't what the client is running ("a browser") nearly as
much as they are how you generate the stuff you pass over to them. (I know
browser incompatibilities are a headache -- a four-figure headache for me last
month, actually -- but they're quickly becoming a headache that some
ubermensch JS framework author suffers so that I don't have to.)

A portion of current innovation in tech is the web stack (notably absent from
your list). A portion of it is associated technologies that may not interact
with the customer directly ever, such as cloud stuff (anything from S3 to
Azure to VPSes). A portion of that is taking the wealth of data/apps already
available and reusing it in new and innovative ways. And a portion is process
innovation, which has very little to do with your technology vendor of choice
and a lot to do with how you use the tools you're using.

I have never done development dedicated to a MS platform (although my Swing
apps and web apps are most commonly used on them), but I'm pretty sure you can
write A/B tests in .NET.

I think you get this, because you cite StackOverflow. StackOverflow could be
written in any of a dozen languages, in almost any web stack. It isn't
innovative because of magic that it does on the server side -- it is
innovative because of how they have incentivized a community to work for them
via the karma/badge system, how they work the StackOverflow-is-an-executable-
advertisement-for-StackExchange business model, etc etc.

~~~
ramanujan
:)

I know that MS bashing is de rigueur. So de rigueur, in fact, that many tend
to downvote the most mindless variety of the genre to prevent from descending
into proggit. Hence my little throat clearing.

As for whether the web stack is different from the OS -- of course it is _to
an extent_ , but the initial poster is proof positive that there is a strong
correlation between low level platform and tools. I suppose it is possible to
use Django and git and emacs on Windows, but it would not be pleasant unless I
was using Cygwin, at which point you may as well use OS X or Linux.

Re: cloud and other components: come now, is there anyone in high performance
computing still paying per node for closed source MS licenses? Is there anyone
in HPC who wasn't using rsync before MS came out with their clone for "branch
office" management? And what proportion of people using EC2 use Windows
instances that are just not as easy to automate as their Linux counterparts?

These questions answer themselves. The hypothetical concept of platform
equivalence is as academically valid and practically irrelevant as the Turing
equivalence of Brainf@@k and Python. You are bending over too far backwards to
be fair to Redmond :)

tl;dr = people working on the MS stack in 2009 tend to be behind in their
thinking about tech. The next big thing will not be on Windows.

------
jdale27
_I was late to the game [...]_

What game?

Newer technology isn't always better. It's just... newer. What really makes
you think you have to keep up with the latest technology? Are you just trying
to keep up with the other code monkeys, or do you really want to learn
something?

 _[H]ow do you force yourself to step outside your comfort zone of doing
things the way you know how and trying something new?_

If "step[ping] outside your comfort zone" is what you want, then you don't
need anything that is new in absolute terms, but only something that is new
_to you_. Here's a suggestion: learn Lisp. It's fifty years old, and yet the
main dialects (Common Lisp, Scheme -- 20-30 years old themselves) contain
interesting features that are only beginning to make their way into
"mainstream" languages.

~~~
WesleyJohnson
_What game?_

I suppose I was referring to the fact that I jumped on board with using the
Microsoft Stack starting with classic ASP when they were well into ASP.NET
2.0. It was also a reference to the fact that I had one programming class in
High School, never went to college and didn't get my first programming gig
until I was 26.

 _What really makes you think you have to keep up with the latest technology?
Are you just trying to keep up with the other code monkeys, or do you really
want to learn something?_

Very relevant question and something I hadn't paused to consider. At first
thought, I'd say it's a little of both which tells me I should really take
some time to evaluate that and go from there.

Thanks for your suggestion with Lisp as well. As someone else pointed out, it
should be more about learning underlying concepts and ideas of programming and
less about the language, framework or etc. I would imagine there are some
great fundamentals I could learn by taking on a language like Lisp that, as
you mentioned, would be well outside my comfort zone.

------
rykov
Side projects! I always try to incorporate promising new
platforms/technologies into new side projects both as a way to learn and as a
way to test the technology.

You won't use everything you play with, but over time, your toolset and skill
will grow and you'll be able to deliver better and more unique solutions that
will get you noticed. Capitalize on that by doing a brown bag or by helping
other teams when they follow the scent of success. Rinse/Repeat. In 7-8 years,
everyone will know that you're indispensable.

------
Tangurena
A long time ago, I used to jump on every bandwagon that seemed interesting.
That lead to lots of wasted time and effort with technological dead-ends. So I
over-reacted and only bothered with technology that had been around a minimum
of 2 years (or if a "for dummies" book on the subject came out).

Some of our shipping products are based on VB6, while some of the others are
.NET 3.5. Generally, if some new technology adds an edge, like Entity
Framework (the shiny new name for "linq to whatever"), then we use it. Also,
for internal tools, any new technology is fair game. So our internal tools
have all sorts of bizarre stuff in them, and if that new stuff is useful, we
end up using it elsewhere.

I don't blog, but I'm thinking of doing it for some educational projects.
Making a public promise to do something generally makes you more likely to go
through with it and do it: whether it is a project or losing weight. One
example is the "build your own CAB" [composite application block] series.
[http://codebetter.com/blogs/jeremy.miller/archive/2007/07/25...](http://codebetter.com/blogs/jeremy.miller/archive/2007/07/25/the-
build-your-own-cab-series-table-of-contents.aspx) Something like this project
might be what you're looking for to push yourself out of your "comfort zone."

~~~
WesleyJohnson
Thanks for the link, I've added it to my bookmarks for stuff I wanted to
review in the coming weeks and will definitely be checking it out.

I also see what you mean about being too quick to jump onto the bandwagon. I
realize it's in debate right now, but there IS talk that Linq to SQL will be
replaced by Linq to Entities. So with that (and the comments people are
posting about learning the meat and not the seasoning), not diving into it a
year ago when I first heard about it may not have been such a missed
opportunity after all.

~~~
jjs
The problem here is that you're on a treadmill where someone else sets the
pace.

------
donaq
If your fundamentals are sound, you should not have to fear. That said, you
might want to pick up some non-Algol descended languages such as Lisp or
Prolog, just to expose yourself to different programming paradigms. :)

------
wisty
You just learnt interfaces? Those are in Java, C++, Python (2.6+) and any
other OO language you care to mention.

I don't use C#, so I'm not sure what Linq is exactly, but it seems to be
similar to an ORM with baked in transactions. Lots of languages have ORM
layers, and they will have some similarities with Linq. If I recall correctly,
Erlang does this quite nicely with it's database system.

Anyway, most of the techniques and pattens you learn will be widely
applicable. Vendors will often claim that they are special (by cooking up new
terms for old technologies), but it's usually just the same old features with
a new sticker.

.Net looks like it's innovating because it's new, but it's mostly pretty
conservative. The whole "cross language platform" thing is cool, but that's
it.

Remember the lessons DCOM, COM+, and CORBA. Not all the new bandwagons are
worth jumping on.

------
wglb
I think it is incumbent on each of us, practitioners of this craft, to take
responsibility for our own education in this field.

Vendors of software have an interest in what you learn, as it helps their
products work better. And it can be useful to you as well. But if you rely on
vendors to set your horizons, it won't necessarily work to your enlightened
self interest.

Additionally, employers are not always going to have the same objective
regarding what you learn. A medium or large company is interested in getting
their projects done on a likely slipping schedule. They are not necessarily
going to be aligned with your educational self-interest.

One defense against this is to see what other vendors are offering. If you are
working on SQL Server learn what you can about how Oracle does things. If you
are working in .net, learn a bit about Java (although that is not exactly a
vendor-driven environment in the same way).

Another step is to look outside the vendor-influenced areas. Look at how
things are done in the open source world. Understand some of the ideas behind
the nosql movement. What is hadoop? memcached? For some of the technologies
discussed on HN (which is certainly filled with talk of more recent
technologies), dive into some of them a little. Expand your comfort zone.

If you have spent a lot of time in the OO world, check out some of the
functional languages and why they might solve some problems more easily than
the OO approach.

And perhaps find an interesting open source project and read lots of code.

I have been in the business several decades and am still learning new things
constantly. While this sounds like a lot, perhaps develop a habit or routine
of doing a little of this each day. If you have in your mind the goal of
expanding your technical horizons, then you will see opportunities to learn.

------
kaitnieks
The technology does not change as fast as it claims to. There are new
languages, frameworks and even concepts all the time, but most of them are the
old things with a twist and most of them do not even catch on. So if you don't
want to be living on the bleeding edge, there is a good strategy: stick to the
stuff that has been time proven. An indicator that something is good and works
is that it's considered old and uncool. Keep an eye on technologies that are
being widely used and when they become practical standard (there should be
lots of documentation, tutorials and books around this time) - learn if you
could use it and if so then learn the technology.

------
dpcan
I have been dealing with similar feelings lately.

It's not so much the "new", rather what's "hot" that makes me nuts. When a
non-techie Client asks me if my stuff is in Rails, but he has no idea what
he's asking, I get very frustrated.

Lately I've been lost trying to grasp what new technologies are going to
matter: Go, Lisp, Closures, Python, Rails, JQuery, NoSQL, Linq, etc, etc? I'm
exhausted from trying to keep up.

I think the best course is just to master those technologies I know and am
comfortable with.

------
jonny_noog
I can empathise with you though, as I started programming later than it seems
most in this line of work do. I too sometimes think, "damn I would be much
further along now if I had gotten into this stuff earlier." But then I guess I
wouldn't be the person I am in other ways and mostly, I don't mind who I am.

 _I'm still learning new things on regular basis_

If that's the case, then I'd say you're OK at the moment. Keep doing that. :)

------
huntse
Well to answer your final point, there is never any absolute guarantee, but
your best insurance against unemployment is to become really good at what you
do. The second best is to make what you do be something commercially valuable.
If you combine these two it's very unlikely you'll ever be unemployed for
long.

Now to the first point. The most important part of learning is the process
itself: ie learning the thing itself is less important than becoming good at
learning. Once you have a sound grasp of the basics, the more diverse your
curiosity and the deeper the insight you are able to gain into each specific
technology, the easier it will be for you to pick up new ones. There's no
excuse for ever becoming obsolete. Read widely, maintain your curiosity and
keep learning.

Finally, the technologies you have picked may or may not be the way of the
future. The future has a way of being unpredictable. Don't be so sure that you
know what is going to happen that you close your eyes to what is actually
happening.

------
warp
I rarely have to force myself to step outside of my comfort zone, because it's
not all that comforting to begin with. For many things I do, I keep thinking
there must be a better way to do things -- sometimes a better way comes along
and I'm satisfied for a year or so, but eventually you'll get to a point again
where you get the feeling you've just written the same thing over and over, or
where your project is slowly turning into an unmaintainable mess and you're
looking for better ways to structure your application.

If the thing you're working on is modular enough, you should be able to use
new technologies in new modules if it significantly improves any aspect of how
you write code (maintainability, performance, time-to-market, etc..). You'll
have to convince your team-members that using a new technology is worth it,
but that's a good thing because you'll be more inclined to actually research
the benefits of a new technology instead of just going with the latest
fashion.

------
vineet7kumar
I believe that if you are real good with your concepts - Algorithms, Data
structures, OOP concepts, etc. there is no reason to worry about the
technology. The job remains the same- giving right set of instructions to
process the data. Moreover, I personally believe that it's hard for anyone to
be even familiar with so many technologies that are coming up everyday.

------
spc476
Eventually, you'll come to realize that not only are you late to the game, but
you're also early to the game, and even on time, depending upon the
technology.

When I started in the web hosting business, Linux had just crossed the 1.0
milestone, and the CGI spec was the sample code (in C and Perl) from NCSA, and
Apache had just been formed. In that time, I've seen Perl wax and wane,
MetaHTML stillborn (back sometime in the 90s I was asked to pick between
MetaHTML and something called PHP; I picked MetaHTML. You can't always pick
winners), PHP, Python and Ruby on the rise.

Personally, I tend to avoid the hype (I'm still using code I wrote a decade
ago on my personal website) and go for what interests me, with the occasional
shove in a particular direction when my boss requires it.

I've been a (paid) programmer since 1990 and have seen quite a few waves of
technology come and go, and I'm still employed. I've even heard that Cobol
programmers still exist.

------
jacquesm
I think the big trick is to know when _not_ to chase what's new and hot, but
simply to concentrate on solving problems, and solving them well. If you use
the right tool for the job behind the scenes nobody cares what you built it in
if you just expose the front end and it works well.

Technology is becoming more and more like the fashion industry, "What, you're
still using (insert name of language here), that's so 2003...".

If you try to chase the ever changing bleeding edge you'll end up knowing lots
of tech but only shallow, pick a blade, learn it until you know it inside out,
_then_ look further.

Though it won't hurt you to at least know what's going on out there there is
absolutely no way a single person can actually keep up and stay current with
all that's out there.

------
tom_b
I second the much mentioned idea of building timeless/technology independent
skills. For example, use pure SQL as much as possible in your T-SQL procedures
- this experience will transfer nicely to Postgres, Oracle, DB2, etc. Course,
you'll have to convince employers that it transfers, but techies will know if
you speak it or not.

Experiment with small pieces when you can. I'm working on learning a bit about
REST programming with Ruby for a small web app/service I'm deploying at work.
For someone who has been a back-end code guy, playing with the web frontend is
. . . interesting.

------
Tichy
Don't follow every new trend. However, if you are stuck in .NET world, it
might really pay off to look at other worlds for inspiration now and then.

Reading Hacker News now and then should give you enough ideas? Every now and
then you could read a book or do some exercises, or best create a small
project in another technology stack.

I think reading SICP and learning a bit of LISP might be a good start - just
because it introduces a lot of concepts that might be unheard of by enterprise
programmers.

If I was on .NET I would probably be looking at F# right now.

------
jacobolus
Not sure how realistic it is, but today’s Dilbert is relevant and somewhat
amusing: <http://dilbert.com/fast/2009-11-16/>

------
bumblebird
I don't think technology changes that much, fashion certainly does. So if you
want to be 'hip', keep up with what's "in" and what's "dead". But if you just
want to get stuff done, use what you like.

------
known
I think we've _professional programming life_ till 40. After that either you
become a _entrepreneur_ or a _MBA_.

------
scorpion032
We invent it.

Or so I'd love to do; So should you!

