|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 19
Messages: 19
Messages: 19
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
Re-Live the Past, or Predict the Future?
At TheServerSide Java Symposium in Europe this week, ThoughtWorks architect and popular speaker Neal Ford spoke of how a static reliance on specific skills almost guarantees obsolescence within a few years. He spoke of the 19th century blacksmith, who seemed to have stable career prospects, until technology change (the automobile) rendered the entire role obsolete.
I can truly relate to Neal’s message. When I was an academic teaching object-oriented programming, one of my adult students was a true expert in C programming. In fact, he specialized in C using Borland Turbo C 3.0. As he struggled to learn the concepts behind C++ and Smalltalk, he loaded his programs into Turbo C, either believing or hoping that Turbo would somehow be able to make sense out of the different languages.
This person believed that single-minded specialization would bring about job security. Three years later, he was out of a job, and out of programming.
That is an extreme example, but is one that we always face, because of the rapid change in technology. Such change doesn’t even have to be grounded in technology. My father was a lifelong steelworker; his job went away when it was no long economically feasible to manufacture steel in older US plants. But it happens terribly quickly when technology changes.
Neal also asked the question of what types of trends would cause disruption in the future. He focused on novel but practical ways of solving existing problems, technology that enables people to do things that weren’t possible in the past, and older technology that is ready for replacement or aggregation. He acknowledged that the wave caused by the World Wide Web was a combination of factors that will probably never be replicated in our lifetimes.
I don’t know if we are capable of anticipating change. Change is certainly apparent after the fact. Before change impact our lives, or while it’s happening? I don’t think so. We might be able to discern that change is occurring, because new skills are being required, and new companies being created. If we are being observant.
But I don’t think we can easily prognosticate on how those changes will play out for us as individuals. Some that seem world-changing may not change our careers much at all. A few small changes could put us out of business for a long time.
So what do you do?
1. Don’t fall in love with any technology. You may find yourself hanging onto it far too long.
2. If you tell yourself “There’s still plenty of life in <pick your language>, you are hanging a bulls eye on your chest. Don’t ever find yourself in that position.
3. Continually add to your toolkit. Learn at least two significant new tools every year.
4. Don’t ever believe you are an expert in anything. There is always more to learn and apply.
|
|
|
Message #328503
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
The way to happiness
I am starting to believe that the way to happiness at work is a profession in HR or Marketing. I don't think I have ever seen a miserable HR or Marketing person at any company I have ever worked.
However, since I can't turn back the clock, I'm downloading Scala and JRuby. I'm going to make them work in this project if it kills me.
cheers :)
|
|
|
Message #328507
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Re-Live the Past, or Predict the Future?
This has to be one of the most inarticulate things I've heard on TSS in a while (and that's not saying much). Really, maybe I should go out and start writing R++ (http://en.wikipedia.org/wiki/R%2B%2B) before I lose my job. I mean really, other than an old school RPG or COBOL programmers, who sticks with one thing forever. You can meta-program, so you are not limited to a particular language. Or maybe realizing there's better frameworks out there than the same old ROR or hibernate/spring stuff.
|
|
|
Message #328509
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Predict the Future?
You forgot :
5- Read TheServerSide news each day to see if you gonna keep your job :-)
|
|
|
Message #328511
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Re-Live the Past, or Predict the Future?
This has to be one of the most inarticulate things I've heard on TSS in a while (and that's not saying much). Really, maybe I should go out and start writing R++ (http://en.wikipedia.org/wiki/R%2B%2B) before I lose my job. I mean really, other than an old school RPG or COBOL programmers, who sticks with one thing forever. You can meta-program, so you are not limited to a particular language. Or maybe realizing there's better frameworks out there than the same old ROR or hibernate/spring stuff.
What bothers me about this kind of thing is that it's so focused on learning new tools and languages. Knowing how to swing a hammer doesn't make you a carpenter. Knowing how to use a pneumatic nail-gun doesn't either.
Tools are important but the real skill is using the tool between your ears. What makes you obsolete is thinking your job is knowing COBOL or Java or Lisp etc.
|
|
|
Message #328512
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Re-Live the Past, or Predict the Future?
Exactly and to extend your point, languages are somewhat immaterial, it's the framework availability that allows you to attack verticals efficiently. How valuable would JRuby be without access to all the Java frameworks out there?
|
|
|
Message #328513
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Re-Live the Past, or Predict the Future?
Exactly and to extend your point, languages are somewhat immaterial, it's the framework availability that allows you to attack verticals efficiently. How valuable would JRuby be without access to all the Java frameworks out there?
But to be clear, a framework is just another tool. The point I'm making is that first you need to understand how to solve problems. That's the most important thing. Applying a tools to those solutions is secondary. It's important but not the of primary importance.
|
|
|
Message #328514
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Re-Live the Past, or Predict the Future?
Exactly and to extend your point, languages are somewhat immaterial, it's the framework availability that allows you to attack verticals efficiently. How valuable would JRuby be without access to all the Java frameworks out there?
But to be clear, a framework is just another tool. The point I'm making is that first you need to understand how to solve problems. That's the most important thing. Applying a tools to those solutions is secondary. It's important but not the of primary importance.
But tools can be fun. You shouldn't be married to them, but one aspect of the job I enjoy is learning new things. And if those things are fun? So much the better.
I had fun learning and using Spring and GWT, for example. I felt pleasure using them, so much so that it didn't really seem like work. And some pretty boring jobs were made interesting because of these tools.
|
|
|
Message #328515
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Re-Live the Past, or Predict the Future?
But tools can be fun. You shouldn't be married to them, but one aspect of the job I enjoy is learning new things. And if those things are fun? So much the better.
I had fun learning and using Spring and GWT, for example. I felt pleasure using them, so much so that it didn't really seem like work. And some pretty boring jobs were made interesting because of these tools.
I'm not saying that tools aren't good. Tools are good. tools are great. I want to take my tools to Hawaii as thanks for their wonderful contributions to my success.
The point is that if you think being a developer is knowing how to use tools, it's no different than thinking that a carpenter is someone who knows how to hammer nails. All of the worst programmers I have ever known thought this way. You tell them to solve a problem and they solve it from the perspective of what their favorite tool can do even if it's the completely wrong tool for the job. just knowing lots of tools (languages, frameworks) isn't going to make you a great developer. It's what you do with those tools that makes you good.
Obviously knowing lots of tools is useful. Learning new languages will expose you to different ideas. But tools are the trees, not the forest.
|
|
|
Message #328516
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Re-Live the Past, or Predict the Future?
But tools can be fun. You shouldn't be married to them, but one aspect of the job I enjoy is learning new things. And if those things are fun? So much the better.
I had fun learning and using Spring and GWT, for example. I felt pleasure using them, so much so that it didn't really seem like work. And some pretty boring jobs were made interesting because of these tools.
I'm not saying that tools aren't good. Tools are good. tools are great. I want to take my tools to Hawaii as thanks for their wonderful contributions to my success.
The point is that if you think being a developer is knowing how to use tools, it's no different than thinking that a carpenter is someone who knows how to hammer nails. All of the worst programmers I have ever known thought this way. You tell them to solve a problem and they solve it from the perspective of what their favorite tool can do even if it's the completely wrong tool for the job. just knowing lots of tools (languages, frameworks) isn't going to make you a great developer. It's what you do with those tools that makes you good.
Obviously knowing lots of tools is useful. Learning new languages will expose you to different ideas. But tools are the trees, not the forest.
I agree. I once told a customer, a DB, that I(but really any good dev) needs to know 70% of everything involved in a project outside of development.
You have to know business development.
Be good at requirements gathering.
Be able to absorb the vocabulary of whatever the project involves.
Be able to tell the users "Hey. This systems will not cost you your job. I'm hear to make your life easier."
You have to be part-DBA, part-GUI guy, part-QA, and part-technical writer.
The person who can talk to mgnt, customers, and other devs, will, I think, always have a job.
But man! I enjoyed working with GWT! ;-) I was up a few times, on a Saturday night, at 2am, just...tinkering.
|
|
|
Message #328517
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Re-Live the Past, or Predict the Future?
I was up a few times, on a Saturday night, at 2am, just...tinkering.
That's because you're a loser ;-)
Captcha: 'Hurting Grandchildren' WTF???
|
|
|
Message #328520
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Re-Live the Past, or Predict the Future?
I agree. I once told a customer, a DB, that I(but really any good dev) needs to know 70% of everything involved in a project outside of development.
Absolutely agree but I wasn't even going that deep. At a job a while back I was doing technical interviews for Java developers. We kept getting these damn JCP people who ostensibly could pass a quiz about how and when longs are converted to ints but couldn't tell me what a Map was or what you would do with one. Learning a language is great and all but unless you have several hundred hours of development time in it, you don't know jack about it.
There are so many crucial things that most developers don't know anything about. I'm working on something and I proposed that we could use a salted hash to address some security concerns. I have to keep bringing it up because the suggestion is ignored and much more painfully expensive options are brought up. All I can tell is no one knows what I mean. I didn't know until a few years back. Understanding encryption is way more important than learning 2 new languages a month or whatever but I don't see many bloggers recommending to learn about it.
|
|
|
Message #328521
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Re-Live the Past, or Predict the Future?
Good point on the encryption. I went quite a bit of time without using any.
Let's face it. The breadth of software development seems nearly boundless: Languages, algorithms, encryption, UI, DB,networking,QA,deployment, libs, it simply goes on and on.
Focusing on any single item as a means to success may well make that success you seek...elusive.
|
|
|
Message #328527
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Predict the Future?
6. Read theserverside.com new's blog, try new things and change your attitude like language or technology independent. Like Architect, Business Analyst, Manager etc.
|
|
|
Message #328534
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Re-Live the Past, or Predict the Future?
There has been no real innovation after the invention of the spreadsheet and relation algebra. Everything else is re-living something existing before...
|
|
|
Message #328535
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Re-Live the Past, or Predict the Future?
Point taken, guys. I directed that remark toward the large segment of developers who learn how to do their first job out of college (or out of high school), and don't think they have to learn anything more for the next 40 years. I think you folks are well beyond that.
|
|
|
Message #328546
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Evolution of a language or technology...
I was looking for opinions on -
what if a language evolves over time, and so a techie sticks to it ( like say Java, with Java6 and Groovy/Grails/GWT etc ). Instead of learning the next "cool" thing - like RoR...I belong to the former camp and I notice that maybe the nextgen has "moved" on to RoR/PHP5 etc based on the opportunites available. Are these languages that advanced ( or productivity gains so different )when compared to Java or .Net ? I have tried learning RoR and didnt continue because I felt I could do almost everything there with Java with the available support/documentation/open source/knowledge on the web, I could do things much faster.
I am wondering if I have to learn RoR just because it is the cool thing to know ? I would rather become better in Java ( depth vs breadth )...
|
|
|
Message #328548
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Evolution of a language or technology...
I was looking for opinions on -
what if a language evolves over time, and so a techie sticks to it ( like say Java, with Java6 and Groovy/Grails/GWT etc ). Instead of learning the next "cool" thing - like RoR...I belong to the former camp and I notice that maybe the nextgen has "moved" on to RoR/PHP5 etc based on the opportunites available. Are these languages that advanced ( or productivity gains so different )when compared to Java or .Net ? I have tried learning RoR and didnt continue because I felt I could do almost everything there with Java with the available support/documentation/open source/knowledge on the web, I could do things much faster.
I am wondering if I have to learn RoR just because it is the cool thing to know ? I would rather become better in Java ( depth vs breadth )...
There is something to what you are saying here. You should consider that perhaps the speed at which you can do things is because of your comfort level with Java vs. RoR. It's hard to know until you get pretty familiar with the new tool. In any event, in won't hurt you to learn a new tool.
|
|
|
Message #328556
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
What, not what with
New experiences will make you a better programmer (and more hireable), not a new language or tool. For example, take on some build engineer or sys admin responsibilites for awhile. Work on some benchmarking and performance analysis. Write a presentation. Write some documentation. Do something you've never done before.
|
|
|
Message #328570
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: What, not what with
New experiences will make you a better programmer (and more hireable), not a new language or tool. For example, take on some build engineer or sys admin responsibilites for awhile. Work on some benchmarking and performance analysis. Write a presentation. Write some documentation. Do something you've never done before.
That's why I like small companies. Many times you have to do all those things.
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
Reza Rahman explores the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(November 2, Article)
SAML is an XML-based standard for exchanging authentication and authorization data between security domains. The single most important problem that SAML was created to solve is the Web browser Single Sign-On problem. Many organizations are debating whether to stay with version 1.1 or move to 2.0. This article makes observations about both options.
(September 28, Article)
Joe Ottinger takes a look at how people learn, and applies it to the practice of programming. He notes that understanding how people learn is an essential part of working in a programming team.
(September 22, Article)
Stephen Maryka gave us an article about the Asynchronous Web and posed a number of questions that get examined like an approach to delivering Asynchronous Web capabilities through extensions to existing Java EE technologies.
(July 14, Article)
JavaServer Faces Flex goal is to provide users capability in creating standard Flex components, part of flexSDK which is open sourced through MPL license, as normal JSF components. This article by Ji Hoon Kim will provide an overview of creating a simple multilingual JSF page consisting of JSF Flex tags.
(June 29, Article)
In this session Jeff explores the key characteristics of successful SOA projects. He covers some of the patterns, and anti-patterns, tool sets, and strategies that he himself learned the hard way. Last, he provides a strategy and blueprint for achieving a high likelihood of success in your SOA project.
(June 23, Tech Talk)
Ari Zilka, CTO of Terracotta, Inc., talks about the new features in Terracotta 3.1, announced during JavaOne and available now.
(June 15, Tech Talk)
In this Tech Talk, Josh Long explores an integration challenge using Spring Integration and walks through the implementation, employing and expanding on the basic patterns of Enterprise Application Integration to tie together components into a function integration solution, and then demonstrates how Spring Integration helps address the integration requirements.
(June 15, Tech Talk)
In this Tech Talk, David Geary teaches you: The basics of Google Web Toolkit; How to implement Ajax-enabled applications in Java; Internationalization; Hooking into the browser history mechanism; Remote procedure calls.
(June 4, Tech Talk)
Jon Kern discusses the best architecture/technical solutions and ensure that they are repeated by all developers. By tackling the architecture up-front in a serial manner, subsequent parallel development will be much more manageable and predictable.
(May 28, Tech Talk)
This keynote describes the frustrations of modern knowledge workers in their quest to actually get some work done, and solutions for how to guard yourself against all those distractions. Neal Ford talks about environments, coding, acceleration, automation, and avoiding repetition as ways to defeat the misguided attempts to sap your ability to produce good work.
(May 26, Tech Talk)
Gil demonstrates how new, aggressive uses of already abundant compute capacity by common applications offer competitive value for application designers.
(May 21, Tech Talk)
Chris Keene introduces WaveMaker as a new way to automate the ability to generate Hibernate classes in order to more quickly bring OR mapping into an application.
(May 19, Article)
In this session Nati Shalom demonstrates how to take a standard Java EE web application and scale it out or down dynamically without changes to the application code. Seeing as most web applications are over-provisioned to meet infrequent peak loads, this is a dramatic change because it enables growing your application as needed, when needed, without paying for unutilized resources.
(May 19, Tech Talk)
Mastering EJB was one of the original and most influential EJB books in the industry. Mastering EJB III now returns with two new expert co-authors, updated for EJB 2.1 and 30% new chapters including security, integration, best practices, open source, and more.
(Book PDF Download)
The Application Server Matrix is a detailed listing of J2EE vendors and their application server products, with information on latest version numbers, J2EE spec support and licensing, pricing, platform support, and links to product downloads and reviews.
(Application Server Comparison Matrix)
|
|
