That sounds rather blunt, but most organisations that aren't startups don't change technology quickly if at all. C++ has served me well for two decades; I probably ought to adopt C++14 but on the other hand my current job requires that the codebase build with a 2008 compiler.
I'm also extremely skeptical of the extent to which AI and VR are new, as opposed to incremental improvements to technology which takes it over an adoption barrier. Have you seen the 80s VR headsets? SHRDLU? The "AI winter"?
If you're worried about this stuff then it's helpful to develop a level of knowledge about it that's slightly higher than Wired but lower than actual implementation detail, in order to talk about it in interviews. You can then pick this stuff up as you go. Machine learning in particular is maths-heavy, matrix algebra in particular, and that's never going to go obsolete.
I also agree with the commentators who are saying that you should ignore the latest flash-in-the-pan frameworks unless you really have to to get frontend gigs.
I started in this field in 1992. I've seen the coming and goings of many flash-in-the-pan technologies.
If you are a dev and are selling yourself on your skillset, ask yourself, "is this sustainable?" The answer is "no." A fifty-year-old brain simply does not absorb new technologies as fast as a 25-year-old-brain. If your plan is to continually adopt new cutting edge technologies in order to stay marketable, I politely submit you need to rethink your long term plan.
As an almost 50-year-old, I promise you that the world is not a gentle place for older devs. Plan your exit into management, a related field, or some other job altogether. If you expect to be a coder at age 50 you're going to be disappointed.
As for me, I jettisoned the "technical skill set" war decades ago. I do not sell myself on my technical skill set. I sell myself as the ultimate generalist. This comes with its own set of problems. However, it has allowed me to age more gracefully in my field, because I do not create the expectation that my primary value-added is code generation.
I'm in complete agreement. I've been working steadily with older platforms for 20+ years. I pick up newer frameworks if needed, but as I rarely choose to work with startups, they are rarely needed. I have been working through some Deep Learning coursework... you are right that the math behind it all is not new, but the practical application of it all with readily available GPUs and libraries is starting to make it approachable to the average coder, so I feel it is time to become familiar with it. And a few such things have come along over the years... SPAs via AJAX, MVC/MVVC patterns, etc. But I don't consider a new pattern every few years to be exactly a fast pace to keep up with. And underneath it all, for us web developers, we still are working with the same basic HTTP request/response model, just doing fancier stuff with it at either end.
I have to say, as a student it is very comforting to read this.
I've been worried sick trying to learn the things I see people commenting here or in hackernoon. I had the idea that by the time I graduate, these technologies will be trending or have a good market share.
This is a good answer. Anyways, I was going to say that hopping a new technology is going to be a lot less profitable than really mastering the old which lots of systems are built on and will be built on, and which new talent never wants to sit down and really learn.
It may not be in the spirit of HN, but deliberately being 3 years behind on the latest technologies is a really good way to stay employable without driving yourself mad keeping up with the latest and greatest. After 3 years, the flash-in-the-pans and the duds have been winnowed out and you can just concentrate on the stuff which will earn you paying gigs.
I agree with that. I don't think it's counter to the spirit of HN. I build apps for clients with the tools I know I'm proficient with but I play and hack a lot too. Sometimes that leads to use with client software though more often it doesn't, but learning is always good.
There are only a few patterns in programming: imperative, OO, functional, etc. Learn those.
There are only a few abstraction levels in problem solving: meta, business, system, physical. Learn those.
There are only a few types of patterns in ML and Big Data. Looks like it's time to learn those.
But the principle is the same. Learn the patterns of various forms of solutions, not actual languages or tech (they'll be required, of course, but they're only a prop). Be able to move between these various patterns. Then deep dive from time to time on various projects in each area.
We've passed the point where a person could keep up long ago. Now it's simply about being both broad and deep at the same time. T-shaped people. If you want to make a lot of money you can be that one guy who knows everything about some tiny point -- but you'd better hope that point doesn't become obsolete in ten or twenty years. I've seen this happen far too often in tech.
I've wrestled with this question virtually since the day I began coding professionally:
Should I become an expert at one language/domain, or, should I constantly learn new things and change roles?
I've done the latter, and I don't know yet if it will have been worth while. I worry about being a "jack of all trades, master of none". Yet, as you point out, a master of one trade had better hope it doesn't become obsolete in their life time.
So my hope is that the investment in learning, and adapting, will pay off in the long haul. I can write an iOS app, I can write an android app, I can code a backend server in scala + akka, or I can write a backend server in PHP. Can I do these things as well or as quickly as a master in each domain? Certainly not.
Do you mind expanding a little bit on the "few types of patterns in ML and Big Data". Do you mean models, pipelines etc or something different. I am studying ML in grad school and I'm seeing way more patterns than just a few, almost too many to be honest if by patterns you mean models. I'd love to hear your view and what you meant by only few types of patters.
Have to do side projects. In my past life, I was getting sucked into becoming a very conservative tech stack lifer at a huge, all-encompassing company. Most people that surrounded me, even the good, hard-working ones, were 9-5 and expressed surprise and hostility to learning anything outside of the company bubble. Then one day a new, more active guy joined our team and whipped up a complete REST-based service in a week. My mind=blown. I quit for the startups, and moved on to using dozens of different stacks since and never looked back. The best, most educating moments typically happened outside of work, when you combine the patterns and observations from work with a different stack or a smart outsider friend who chimes in on your daily struggles from a surprising different angle.
Another enlightening moment for me was when I was working on a hobby machine learning project, and shared my design concerns with a brilliant but very much non-ML coworker, and all of a sudden that coworker laid out the whole design in a pretty convincing detail, like he's been doing this work for years. After the initial shock from his seemingly birth-given ML skills, I noticed that he simply takes a lot of good online classes and goes through all the top ML material on the web in his spare time, even though it was irrelevant to his tech focus at the time. Well guess what, two years later he got promoted and he's making that sweet data science money, and guess where he would have been if he only focused on his old day-to-day instead.
My current strategy has a bit of complexity and might take an entire blog post to explain clearly. The high level view is this:
Skills vary both in how much the market values them and in their durability. There's often a trade-off between these two characteristics. For example, half a year's worth of study in a foreign language or pure math is only somewhat valuable to the market but that value doesn't tend to decrease over the years. Learning AngularJS in 2013, on the other hand, was so highly valued by the job market that it was a great way for junior programmers with no degree to break into a software engineering career.
I believe it's best to generally focus most learning efforts on durable skills, but occasionally when there's an opening, to flop and focus 100% on an ephemeral skill that's highly valued and appears likely to be even more highly valued in the near future. After capitalizing on the opportunity, return to mostly focusing on durable skills.
A lot of the technology on the bleeding edge will be gone in a couple of years. AngularJS v1 used to be the next big thing, now it's obsolete. Who knows if v2 will stick around.
So following the latest technology in detail is unnecessary.
Far more useful is just having a broad sense of what tools are available out there; it takes less time, and it's more useful since it gives you access to a broader set of tools on-demand.
Beyond technology, the things that persist are much more fundamental skills:
1. Ability to read a new code base, and ability to quickly learn a new technology.
If you can do this you don't need to worry about new technologies since you can always learn them as needed. E.g I just wrote a patch for a Ruby project (Sinatra) at work even though I don't really know Ruby and never saw the codebase before. It got accepted, too.
2. Ability to figure out what the real problem is, what the real business goal is. This makes you a really valuable employee.
Technology is just a tool. More fundamental skills are your real value.
While Angular 1 might be 'obselete', there's still a lot of corporations out there with tons of Angular 1 code, and most of them are not going to be upgrading anytime soon. Angular 2 is enough of a paradigm shift that it would require rewriting those apps from scratch, pretty much, and there won't be a business need to do so for another 5+ years for a lot of these companies.
We're still doing new apps in Angular 1 here, because everyone knows it, we can reuse more code, we know most of its quirks and how to squeeze performance out of it, and we can get the apps out the door a lot faster. Eventually we will have a new project where we decide to use something more current, though.
Depends. I'm shepherding http://www.airwindows.com/ through a switch to Patreon, by expressing new DSP ideas in a context of very, very old audio plugin frameworks. The dev tools I'm using won't even work on current computers. I code on a time capsule laptop and depend on the very simplified plugin formats I've chosen (generic interface AU and VST) to remain functional. They'd have to break the most fundamental interfaces to kill my stuff (which doesn't make it impossible to do, just very user-hostile)
Don't confuse advances in technology with intentional churn generated by vendors and platforms. The latter is a plague, and it doesn't only cost people money, it costs them productivity. You may be getting confused and mistaking skillset for toolset. Large companies will always be able to replace your toolset and demand you learn a whole new one, because the more you do, the more you'll be locked in to their toolset. If you can abstract out the functions being implemented and express them in different ways, you can take your skillset different places.
Whether you do that, depends on how good you are at finding niche markets. As someone who's stayed in business for ten years selling GUI-less audio plugins with no advertising and no DRM of any sort, I can tell you (1) niche markets exist and they're loyal, and (2) they're small, which is what makes them niche. :)
> Don't confuse advances in technology with intentional churn generated by vendors and platforms. The latter is a plague, and it doesn't only cost people money, it costs them productivity.
Do you think churn is intentional within a single vendor, e.g. to force upgrades? Could churn be a by-product of competition between vendors, e.g. AWS refactored most of enterprise computing into "low-end" services that steadily improved, but were proprietary and increased lock-in.
> The dev tools I'm using won't even work on current computers. I code on a time capsule laptop and depend on the very simplified plugin formats I've chosen (generic interface AU and VST) to remain functional.
Is the time capsule laptop for old operating systems or old hardware? COuld the old operating systems work in a virtual machine?
> They'd have to break the most fundamental interfaces to kill my stuff (which doesn't make it impossible to do, just very user-hostile)
Apple tried to get ride of files (!) entirely, but they are slowly making a comeback on iOS, e.g. now you can insert an attachment within an email, with the right application plugin. Social networks have done their best to replace RSS push notifications with proprietary pubsub. WebDAV, CalDAV, CardDAV are thankfully still supported by a few good apps.
> niche markets exist and they're loyal, and (2) they're small, which is what makes them niche.
How do you market your services/products within your niche?
It depends on what you already know, I think embedded development with systems level languages and hardware know-how is a very durable skill.
On the other hand, some fields like web development have peaked a while ago, I would argue that 2012 was the high watermark. I think it's a very precarious choice of career right now. It has been steadily going downhill since the introduction of trendy front-end frameworks that don't offer any value to the end user (including React, Angular, et al). The culture stopped being about making usable and accessible interfaces for people, and more about "component architecture", "server-side rendering", "tree shaking", that solve problems created by the very tools they are using.
That isn't to say that web development is dead, but I think that the future will be more specialized around certain features of the platform such as WebAssembly, WebRTC, WebGL, Web Audio, et al. And these will be more readily picked up by people with more durable skills, than those who only know the most popular front-end framework.
> The culture stopped being about making usable and accessible interfaces for people, and more about "component architecture", "server-side rendering", "tree shaking", that solve problems created by the very tools they are using.
Speaking as a confirmed cynic, that seems overly cynical. ;-)
The problems being solved by the web framework hamster wheel are those of rising bars for usability and speed, with measurable in $$$ effects (ie. an extra 1s delay could increase shopping-cart abandonment rate by 1.5%). Which matters a lot more at web-scale.
So, these trendy frameworks are solving problems that most developers shouldn't worry about (it is premature optimization) but that matter a great deal to the companies that release them (Google: Angular and Polymer; Facebook: React and Flux; etc.). OTOH, it is tempting to tap into of all the engineering effort that goes into libraries like these. You just have to know where to stop before sinking into the HammerFactoryFactory mire. ;-)
Just like you have to fight feature creep in your products, you have to fight "shiny new tool / language / framework" creep in your skillset. Become an expert in your topic of choice and use the best tools to get it done quickly, whether its 20 years old or two. If you spend too much time learning new tech, you won't get it done quickly, but you shouldn't force an old tool to do something just because you don't want to learn something new.
As for the anxiety, turn off HN every so often and just focus on being a good engineer with your current tools. Nothing changes so fast that you can't go a few months or even a year without being in the know. When it comes time to stsrt a new project, spend a week researching the current tools and see how they fit into your stack.
To give you some context, I'll answer this as a [largely] life-long consultant. As such, I don't chase technology, I anticipate the trajectory of job growth. I want the project that I decide to work on next to propel me to a project that will likewise broaden and deepen the experience and skillset I have to offer. <p>I also try not to get trapped into working for clients whose only interest in my experience is to recreate one of the last things I did. The easiest way to kill your value is to do the same thing over and over - even twice is too much.
It's true technology progresses in dog years. When you are working you are not learning outside that bubble. When you are between assignments you absolutely must treat that time as a sabbatical to learn something/anything new.
By broadening your skillset through selective project engagement, you are better off than Skippy who has worked on the same application with great job security for 5 years - Skippy will not be someone you will re-encounter 10 years from now unless you are buying a used car and they happen to be the sales person. The industry is self-selective this way. The complacent "I got mine" mentality is toxic to longevity in the industry.
Let me also dispell the meme that sticking to a specialty is a desirable thing. The fact of the matter is that the ocean of legacy code grows exponentially and there is always a need for someone who knows a legacy language or technology. this kind of career trajectory is as desirable as cleaning out septic tanks. There's job security to be had and you'll hear plenty of "Ho, ho, ho - I don't need no stinkin' new fangled whatever" to be indispensible. My advice is not to be that guy/gal.
It is a much harder and a much richer experience to navigate a career in the flow of technology than to get myopically paralyzed by a desire to featherbed where you are today.
But your question is "how" to keep up. IMO, the answer is to skim lots of material and only dive in at the last most relevant moment. The generalist is far more qualified that the specialist these days because most companies cannot afford a prima donna - they need people who can perform many jobs and serve many needs.
For me, the answer is side projects. I keep playing with new ideas, and use new techs by the way.
It not only allows me to discover the tech, it's also especially important because I refuse to make first contact with a tech by implementing it directly in a production project meant to stay around for years. The most projects I've used a new tech in before introducing it in my main project, the more comfortable I am that I did not do gross mistakes.
For me, it's not the amount of time using a new tech that matters, it's the amount of projects I used it in (because each time, I can try a different architecture).
I developed a checklist to spot technologies that are in an early stage of the hype cycle and avoid them.
The following are signals that a technology is in and early part of the hype cycle:
* It has the backing of a major corporation or a startup with a marketing budget.
* There are a lot of rave articles/blog posts about building relatively simple or small self contained applications using this technology.
* There is a small but vocal contingent of users who are passionately against the new technology. Their arguments often link to bugs on the bug tracker, cite edge cases that occur under heavy usage and indicate fundamental oversights in the design as well as assumptions (and often arrogance) on the part of the architects.
* The benefits cited are either A) vague or B) explicitly aimed at beginners.
* Arguments in favor often appeal to authority (e.g. "Google uses it" or "XYZ company use it in production"), popularity ("everybody's containerizing these days") or cite benefits which were already possible.
* A high ratio of talk to action: the technology is talked about on Hacker News a lot but there appears to be very little real life stuff developed with it and a lot of the talk involves jamming it in where it's not really necessary.
* Sometimes I experiment with a technology for an hour or two and I see if there's anything obviously wrong with it or if the criticisms are valid.
- Be aware of new trends. You don't have to learn everything. But pickup and try those that are promising to solve real problems in your current position.
- You should be able to move back and forth between management and technical positions. They are not mutually exclusive. You can a skill set that allows you to do either. It gives you greater perspective and flexibility. One piece of advice that I was given in college is that even if you are the Director of IT you should leave small (non-critical) pieces of software for you to work on. So you never lose touch.
- Try to work for good companies. My definition of good companies are those where you can be productive every day.
- Some skills will be helpful all your life. I learned Unix in 1989 and have used it almost every day.
- Learn the fundamentals. Data structures, algorithms, relational theory, structured programming, object oriented programming, functional programming, networking, Operating systems, theory of computation, et al.
- Understand the business domain in which you are working. That makes you extra valuable for your current company.
Focus on the fundamentals. How do you find the write tools and libraries? How do you translate requirements into projects? How can you communicate with other people effectively? How can you learn what you need to know when you need to know it? How do you recognize sunk costs? What makes good code good code, regardless of language? What compromises should you make, and when? How do you ask the right questions?
1. Relevant skills don't change. Your abilities to reason on problems are never becoming irrelevant.
2. New technologies are adopted, doesn't mean old ones quickly disappear. Sometimes not even slowly.
3. Area focus. If my area of expertise is networking, what do I care about VR? We can't be generalists any more than we could be 20 years ago.
4. If you feel like being a generalist, understanding & internalising (basic) principles is more important than being familiar with specific technologies
5. Critical, transversal thinking. You can weed out heaps of new technologies by understanding _how_ they fit in a system and the tradeoffs they require, before you have to become intimately familiar with them. Base your approach on tangible end-to-end measurements to understand how technologies might fit in a system, and after that you'll have to keep up with a lot less than the various FOTM
Well, a critical eye is a must. Just keep away from the noise and pay attention to what would really make an improvement on your current framework/workflow.
For example, I still do my web development in Django or Flask because they do the job, I'm pretty good at Python and most projects don't really need the concurrency Go or Elixir offer.
One of the best recent additions to my skillset was Docker... a lot of people say containers are not a must but they really made my life easier and allowed me to do cool things for clients from different industries.
It doesn't sound as cool as doing machine learning, computer vision or natural language processing, but don't let the AI/VR hype make you anxious, just focus on what you really want to do.
I'm more worried about people constantly believing that every new framework is a major advancement for programming and that it's not just something that could be learned in an afternoon (e.g. React). Or about people following the latest hyped trend without learning anything and without producing much other than more hype.
AI,ML and VR are all really interesting, but as we all know they are not completely new and will not likely account for the majority of the future jobs.
Fundamentals are what matter, most of these "new things" are just something that you can learn with relatively limited effort if needed. Classic programming skills, analytical skills or things like the ability to reason about concurrency issues never go obsolete.
[+] [-] pjc50|9 years ago|reply
That sounds rather blunt, but most organisations that aren't startups don't change technology quickly if at all. C++ has served me well for two decades; I probably ought to adopt C++14 but on the other hand my current job requires that the codebase build with a 2008 compiler.
I'm also extremely skeptical of the extent to which AI and VR are new, as opposed to incremental improvements to technology which takes it over an adoption barrier. Have you seen the 80s VR headsets? SHRDLU? The "AI winter"?
If you're worried about this stuff then it's helpful to develop a level of knowledge about it that's slightly higher than Wired but lower than actual implementation detail, in order to talk about it in interviews. You can then pick this stuff up as you go. Machine learning in particular is maths-heavy, matrix algebra in particular, and that's never going to go obsolete.
I also agree with the commentators who are saying that you should ignore the latest flash-in-the-pan frameworks unless you really have to to get frontend gigs.
[+] [-] riprowan|9 years ago|reply
I started in this field in 1992. I've seen the coming and goings of many flash-in-the-pan technologies.
If you are a dev and are selling yourself on your skillset, ask yourself, "is this sustainable?" The answer is "no." A fifty-year-old brain simply does not absorb new technologies as fast as a 25-year-old-brain. If your plan is to continually adopt new cutting edge technologies in order to stay marketable, I politely submit you need to rethink your long term plan.
As an almost 50-year-old, I promise you that the world is not a gentle place for older devs. Plan your exit into management, a related field, or some other job altogether. If you expect to be a coder at age 50 you're going to be disappointed.
As for me, I jettisoned the "technical skill set" war decades ago. I do not sell myself on my technical skill set. I sell myself as the ultimate generalist. This comes with its own set of problems. However, it has allowed me to age more gracefully in my field, because I do not create the expectation that my primary value-added is code generation.
[+] [-] codingdave|9 years ago|reply
[+] [-] no_cake|9 years ago|reply
I've been worried sick trying to learn the things I see people commenting here or in hackernoon. I had the idea that by the time I graduate, these technologies will be trending or have a good market share.
[+] [-] hacknat|9 years ago|reply
[+] [-] ihaveahadron|9 years ago|reply
[deleted]
[+] [-] throwaway6845|9 years ago|reply
[+] [-] oblib|9 years ago|reply
[+] [-] DanielBMarkham|9 years ago|reply
There are only a few patterns in programming: imperative, OO, functional, etc. Learn those.
There are only a few abstraction levels in problem solving: meta, business, system, physical. Learn those.
There are only a few types of patterns in ML and Big Data. Looks like it's time to learn those.
But the principle is the same. Learn the patterns of various forms of solutions, not actual languages or tech (they'll be required, of course, but they're only a prop). Be able to move between these various patterns. Then deep dive from time to time on various projects in each area.
We've passed the point where a person could keep up long ago. Now it's simply about being both broad and deep at the same time. T-shaped people. If you want to make a lot of money you can be that one guy who knows everything about some tiny point -- but you'd better hope that point doesn't become obsolete in ten or twenty years. I've seen this happen far too often in tech.
[+] [-] rubicon33|9 years ago|reply
Should I become an expert at one language/domain, or, should I constantly learn new things and change roles?
I've done the latter, and I don't know yet if it will have been worth while. I worry about being a "jack of all trades, master of none". Yet, as you point out, a master of one trade had better hope it doesn't become obsolete in their life time.
So my hope is that the investment in learning, and adapting, will pay off in the long haul. I can write an iOS app, I can write an android app, I can code a backend server in scala + akka, or I can write a backend server in PHP. Can I do these things as well or as quickly as a master in each domain? Certainly not.
[+] [-] vjankov|9 years ago|reply
[+] [-] twelve40|9 years ago|reply
Another enlightening moment for me was when I was working on a hobby machine learning project, and shared my design concerns with a brilliant but very much non-ML coworker, and all of a sudden that coworker laid out the whole design in a pretty convincing detail, like he's been doing this work for years. After the initial shock from his seemingly birth-given ML skills, I noticed that he simply takes a lot of good online classes and goes through all the top ML material on the web in his spare time, even though it was irrelevant to his tech focus at the time. Well guess what, two years later he got promoted and he's making that sweet data science money, and guess where he would have been if he only focused on his old day-to-day instead.
[+] [-] xiaoma|9 years ago|reply
Skills vary both in how much the market values them and in their durability. There's often a trade-off between these two characteristics. For example, half a year's worth of study in a foreign language or pure math is only somewhat valuable to the market but that value doesn't tend to decrease over the years. Learning AngularJS in 2013, on the other hand, was so highly valued by the job market that it was a great way for junior programmers with no degree to break into a software engineering career.
I believe it's best to generally focus most learning efforts on durable skills, but occasionally when there's an opening, to flop and focus 100% on an ephemeral skill that's highly valued and appears likely to be even more highly valued in the near future. After capitalizing on the opportunity, return to mostly focusing on durable skills.
[+] [-] itamarst|9 years ago|reply
So following the latest technology in detail is unnecessary. Far more useful is just having a broad sense of what tools are available out there; it takes less time, and it's more useful since it gives you access to a broader set of tools on-demand.
Beyond technology, the things that persist are much more fundamental skills:
1. Ability to read a new code base, and ability to quickly learn a new technology.
If you can do this you don't need to worry about new technologies since you can always learn them as needed. E.g I just wrote a patch for a Ruby project (Sinatra) at work even though I don't really know Ruby and never saw the codebase before. It got accepted, too.
2. Ability to figure out what the real problem is, what the real business goal is. This makes you a really valuable employee.
Technology is just a tool. More fundamental skills are your real value.
More detailed write-up on how to keep up without giving up your life: https://codewithoutrules.com/2017/01/11/your-job-is-not-your...
[+] [-] cableshaft|9 years ago|reply
We're still doing new apps in Angular 1 here, because everyone knows it, we can reuse more code, we know most of its quirks and how to squeeze performance out of it, and we can get the apps out the door a lot faster. Eventually we will have a new project where we decide to use something more current, though.
[+] [-] Applejinx|9 years ago|reply
Don't confuse advances in technology with intentional churn generated by vendors and platforms. The latter is a plague, and it doesn't only cost people money, it costs them productivity. You may be getting confused and mistaking skillset for toolset. Large companies will always be able to replace your toolset and demand you learn a whole new one, because the more you do, the more you'll be locked in to their toolset. If you can abstract out the functions being implemented and express them in different ways, you can take your skillset different places.
Whether you do that, depends on how good you are at finding niche markets. As someone who's stayed in business for ten years selling GUI-less audio plugins with no advertising and no DRM of any sort, I can tell you (1) niche markets exist and they're loyal, and (2) they're small, which is what makes them niche. :)
[+] [-] walterbell|9 years ago|reply
Do you think churn is intentional within a single vendor, e.g. to force upgrades? Could churn be a by-product of competition between vendors, e.g. AWS refactored most of enterprise computing into "low-end" services that steadily improved, but were proprietary and increased lock-in.
> The dev tools I'm using won't even work on current computers. I code on a time capsule laptop and depend on the very simplified plugin formats I've chosen (generic interface AU and VST) to remain functional.
Is the time capsule laptop for old operating systems or old hardware? COuld the old operating systems work in a virtual machine?
> They'd have to break the most fundamental interfaces to kill my stuff (which doesn't make it impossible to do, just very user-hostile)
Apple tried to get ride of files (!) entirely, but they are slowly making a comeback on iOS, e.g. now you can insert an attachment within an email, with the right application plugin. Social networks have done their best to replace RSS push notifications with proprietary pubsub. WebDAV, CalDAV, CardDAV are thankfully still supported by a few good apps.
> niche markets exist and they're loyal, and (2) they're small, which is what makes them niche.
How do you market your services/products within your niche?
[+] [-] avip|9 years ago|reply
===============
0. Assume any "new" thing is worse than the "old" alternative - until proven otherwise.
1. Critically filter out hype/PR.
2. You're left with much less to learn.
3. Invest "out-of-work" time in something really valuable.
[+] [-] d0m|9 years ago|reply
[+] [-] sapeien|9 years ago|reply
On the other hand, some fields like web development have peaked a while ago, I would argue that 2012 was the high watermark. I think it's a very precarious choice of career right now. It has been steadily going downhill since the introduction of trendy front-end frameworks that don't offer any value to the end user (including React, Angular, et al). The culture stopped being about making usable and accessible interfaces for people, and more about "component architecture", "server-side rendering", "tree shaking", that solve problems created by the very tools they are using.
That isn't to say that web development is dead, but I think that the future will be more specialized around certain features of the platform such as WebAssembly, WebRTC, WebGL, Web Audio, et al. And these will be more readily picked up by people with more durable skills, than those who only know the most popular front-end framework.
[+] [-] webmaven|9 years ago|reply
Speaking as a confirmed cynic, that seems overly cynical. ;-)
The problems being solved by the web framework hamster wheel are those of rising bars for usability and speed, with measurable in $$$ effects (ie. an extra 1s delay could increase shopping-cart abandonment rate by 1.5%). Which matters a lot more at web-scale.
So, these trendy frameworks are solving problems that most developers shouldn't worry about (it is premature optimization) but that matter a great deal to the companies that release them (Google: Angular and Polymer; Facebook: React and Flux; etc.). OTOH, it is tempting to tap into of all the engineering effort that goes into libraries like these. You just have to know where to stop before sinking into the HammerFactoryFactory mire. ;-)
[+] [-] wheelerwj|9 years ago|reply
As for the anxiety, turn off HN every so often and just focus on being a good engineer with your current tools. Nothing changes so fast that you can't go a few months or even a year without being in the know. When it comes time to stsrt a new project, spend a week researching the current tools and see how they fit into your stack.
[+] [-] AnthonBerg|9 years ago|reply
[+] [-] krasicki|9 years ago|reply
It's true technology progresses in dog years. When you are working you are not learning outside that bubble. When you are between assignments you absolutely must treat that time as a sabbatical to learn something/anything new.
By broadening your skillset through selective project engagement, you are better off than Skippy who has worked on the same application with great job security for 5 years - Skippy will not be someone you will re-encounter 10 years from now unless you are buying a used car and they happen to be the sales person. The industry is self-selective this way. The complacent "I got mine" mentality is toxic to longevity in the industry.
Let me also dispell the meme that sticking to a specialty is a desirable thing. The fact of the matter is that the ocean of legacy code grows exponentially and there is always a need for someone who knows a legacy language or technology. this kind of career trajectory is as desirable as cleaning out septic tanks. There's job security to be had and you'll hear plenty of "Ho, ho, ho - I don't need no stinkin' new fangled whatever" to be indispensible. My advice is not to be that guy/gal.
It is a much harder and a much richer experience to navigate a career in the flow of technology than to get myopically paralyzed by a desire to featherbed where you are today. But your question is "how" to keep up. IMO, the answer is to skim lots of material and only dive in at the last most relevant moment. The generalist is far more qualified that the specialist these days because most companies cannot afford a prima donna - they need people who can perform many jobs and serve many needs.
[+] [-] oelmekki|9 years ago|reply
It not only allows me to discover the tech, it's also especially important because I refuse to make first contact with a tech by implementing it directly in a production project meant to stay around for years. The most projects I've used a new tech in before introducing it in my main project, the more comfortable I am that I did not do gross mistakes.
For me, it's not the amount of time using a new tech that matters, it's the amount of projects I used it in (because each time, I can try a different architecture).
[+] [-] crdoconnor|9 years ago|reply
The following are signals that a technology is in and early part of the hype cycle:
* It has the backing of a major corporation or a startup with a marketing budget.
* There are a lot of rave articles/blog posts about building relatively simple or small self contained applications using this technology.
* There is a small but vocal contingent of users who are passionately against the new technology. Their arguments often link to bugs on the bug tracker, cite edge cases that occur under heavy usage and indicate fundamental oversights in the design as well as assumptions (and often arrogance) on the part of the architects.
* The benefits cited are either A) vague or B) explicitly aimed at beginners.
* Arguments in favor often appeal to authority (e.g. "Google uses it" or "XYZ company use it in production"), popularity ("everybody's containerizing these days") or cite benefits which were already possible.
* A high ratio of talk to action: the technology is talked about on Hacker News a lot but there appears to be very little real life stuff developed with it and a lot of the talk involves jamming it in where it's not really necessary.
* Sometimes I experiment with a technology for an hour or two and I see if there's anything obviously wrong with it or if the criticisms are valid.
[+] [-] huherto|9 years ago|reply
- You should be able to move back and forth between management and technical positions. They are not mutually exclusive. You can a skill set that allows you to do either. It gives you greater perspective and flexibility. One piece of advice that I was given in college is that even if you are the Director of IT you should leave small (non-critical) pieces of software for you to work on. So you never lose touch.
- Try to work for good companies. My definition of good companies are those where you can be productive every day.
- Some skills will be helpful all your life. I learned Unix in 1989 and have used it almost every day.
- Learn the fundamentals. Data structures, algorithms, relational theory, structured programming, object oriented programming, functional programming, networking, Operating systems, theory of computation, et al.
- Understand the business domain in which you are working. That makes you extra valuable for your current company.
- Develop your soft skills. http://www.skillsyouneed.com/general/soft-skills.html
[+] [-] jaibot|9 years ago|reply
[+] [-] swah|9 years ago|reply
[+] [-] mfukar|9 years ago|reply
2. New technologies are adopted, doesn't mean old ones quickly disappear. Sometimes not even slowly.
3. Area focus. If my area of expertise is networking, what do I care about VR? We can't be generalists any more than we could be 20 years ago.
4. If you feel like being a generalist, understanding & internalising (basic) principles is more important than being familiar with specific technologies
5. Critical, transversal thinking. You can weed out heaps of new technologies by understanding _how_ they fit in a system and the tradeoffs they require, before you have to become intimately familiar with them. Base your approach on tangible end-to-end measurements to understand how technologies might fit in a system, and after that you'll have to keep up with a lot less than the various FOTM
[+] [-] luisehk|9 years ago|reply
For example, I still do my web development in Django or Flask because they do the job, I'm pretty good at Python and most projects don't really need the concurrency Go or Elixir offer.
One of the best recent additions to my skillset was Docker... a lot of people say containers are not a must but they really made my life easier and allowed me to do cool things for clients from different industries.
It doesn't sound as cool as doing machine learning, computer vision or natural language processing, but don't let the AI/VR hype make you anxious, just focus on what you really want to do.
[+] [-] drtse4|9 years ago|reply
AI,ML and VR are all really interesting, but as we all know they are not completely new and will not likely account for the majority of the future jobs.
Fundamentals are what matter, most of these "new things" are just something that you can learn with relatively limited effort if needed. Classic programming skills, analytical skills or things like the ability to reason about concurrency issues never go obsolete.