Discussions

News: Re-Live the Past, or Predict the Future?

  1. Re-Live the Past, or Predict the Future? (19 messages)

    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 , 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.

    Threaded Messages (19)

  2. The way to happiness[ Go to top ]

    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 :)
  3. 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.
  4. 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.
  5. 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?
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. 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???
  11. 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.
  12. 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.
  13. 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.
  14. Predict the Future?[ Go to top ]

    You forgot : 5- Read TheServerSide news each day to see if you gonna keep your job :-)
  15. Re: Predict the Future?[ Go to top ]

    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.
  16. There has been no real innovation after the invention of the spreadsheet and relation algebra. Everything else is re-living something existing before...
  17. 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 )...
  18. 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.
  19. What, not what with[ Go to top ]

    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.
  20. Re: What, not what with[ Go to top ]

    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.