Ask HN: How do you keep up with changing technologies?
23 comments
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.)
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.)
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.
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
How do you generate the difference between the project that you got done with your method versus the project that wasn't done using a different method? Is it real cost of your way versus estimated cost of doing it the other way, are you re-writing a project that has already been written by a different team, or what? If the cost of the other way was an estimate, are the metrics trusted because you have a great track record with your estimates, or do you have some sort of estimate-aiding tools that your employer relies on and trusts?
How do you generate the difference between the project that you got done with your method versus the project that wasn't done using a different method? Is it real cost of your way versus estimated cost of doing it the other way, are you re-writing a project that has already been written by a different team, or what? If the cost of the other way was an estimate, are the metrics trusted because you have a great track record with your estimates, or do you have some sort of estimate-aiding tools that your employer relies on and trusts?
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.
You aren't falling behind, don't worry.
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.
I couldn't agree more.
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.
With the noted exception of Stackoverflow, most innovation in tech today does not involve MS.
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.
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.
:)
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.
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.
As for your quick meta tangent, I completely understand why the GP wrote that, it is quite normal for posts that even mention microsoft or one of their products, critically or in passing to get modded down.
http://news.ycombinator.com/item?id=944284
http://news.ycombinator.com/item?id=944284
Open source has the huge advantage that you can study it to your heart's content. If you want, you can replace Linux's scheduler with one of your own devising, or write your own code to optimize GCC's ARM output, or read just how Erlang does garbage collection.
I really fell in love with open source when I realized that it's a huge playground, and the only real limitation is me.
I really fell in love with open source when I realized that it's a huge playground, and the only real limitation is me.
As several others have noted below, I need to take a step back and figure out if I'm wanting to be on the cutting edge because I'm really motivated to learn or if I'm more concerned with keeping up with the trends. I know that for the foreseeable future, I'll be working with the MS Stack as it's my means of living. Of course, if they stick with what works and don't deviate from the norm too much - it would be much easier for me to spend time to learning something like Lisp (as someone had mentioned) or digging into another platform or language as you've suggested.
I did sign up for the iPhone Dev Program and buy an iPod Touch at the same time the Dev Program launched, but stress at my previous job left little motivation for me to program in my free time. My dev license/subscription ran out and I sold my iPod a while back, but perhaps it's time to revisit it or the Android platform.
I definitely have some options and some stuff to think about. Thanks!
I did sign up for the iPhone Dev Program and buy an iPod Touch at the same time the Dev Program launched, but stress at my previous job left little motivation for me to program in my free time. My dev license/subscription ran out and I sold my iPod a while back, but perhaps it's time to revisit it or the Android platform.
I definitely have some options and some stuff to think about. Thanks!
Yeah, more generally the advice could be not to be so attached to any of the stacks, just know the stuff that doesn't change that much (algorithms, protocols, etc.) and get your stuff done with whichever tool is at hand.
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.
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.
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.
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.
Newer technology isn't always better.
This is a great point that one would think obvious enough, except that there's usually some pretty powerful vested interests that I suspect like to try hard to obscure it in order to keep users and devs on the constant upgrade treadmill, in turn padding their bottom line.
Case in point: My favourite Linux distro Debian, knows newer isn't always better very well. They are sometimes criticised for their stable release being "behind the times", but if you want the cutting edge you can pretty easily run the Debian Testing or Unstable releases (even Unstable is pretty stable most of the time). What people don't get or perhaps don't want to accept is that Debian stable values stability over all else, it's meant for server applications and the fact that it's a bit "behind the times" makes it better for this role than it would be otherwise.
This is a great point that one would think obvious enough, except that there's usually some pretty powerful vested interests that I suspect like to try hard to obscure it in order to keep users and devs on the constant upgrade treadmill, in turn padding their bottom line.
Case in point: My favourite Linux distro Debian, knows newer isn't always better very well. They are sometimes criticised for their stable release being "behind the times", but if you want the cutting edge you can pretty easily run the Debian Testing or Unstable releases (even Unstable is pretty stable most of the time). What people don't get or perhaps don't want to accept is that Debian stable values stability over all else, it's meant for server applications and the fact that it's a bit "behind the times" makes it better for this role than it would be otherwise.
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.
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.
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... Something like this project might be what you're looking for to push yourself out of your "comfort zone."
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... Something like this project might be what you're looking for to push yourself out of your "comfort zone."
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.
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.
The problem here is that you're on a treadmill where someone else sets the pace.
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. :)
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.
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.
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.
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.
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.
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.
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.
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. :)
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. :)
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Not sure how realistic it is, but today’s Dilbert is relevant and somewhat amusing: http://dilbert.com/fast/2009-11-16/
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.
I think we've professional programming life till 40. After that either you become a entrepreneur or a MBA.
We invent it.
Or so I'd love to do; So should you!
Or so I'd love to do; So should you!
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.