Ask HN: How do you keep up with changing technologies?
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 <-> 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.
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.
37 comments
[ 2.4 ms ] story [ 93.4 ms ] threadYou aren't falling behind, don't worry.
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.
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.
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.
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.)
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?
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."
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.
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.
With the noted exception of Stackoverflow, most innovation in tech today does not involve MS.
I really fell in love with open source when I realized that it's a huge playground, and the only real limitation is me.
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.
http://news.ycombinator.com/item?id=944284
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 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.
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.
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.
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. :)
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.
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.
Or so I'd love to do; So should you!
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.
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.
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.
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.