Since 2001 I have been employed in the software development industry, primarily focused in the design, implementation & maintenance of Java Enterprise Systems. As of December 2005 I was employed as a Java Development Team Lead and became a strong advocate for eXtreme programming and the Agile Manifesto. During 2008 I began to pay a lot more attention to Ruby on Rails and could see the benefits of combing Java & Ruby (JRuby) to provide greater opportunity for the future of enterprise systems and an increased time to market for software solutions. Christopher has posted 1 posts at DZone. View Full User Profile

How to Stay Technically Ahead?

02.25.2009
| 13823 views |
  • submit to reddit

In the software development industry, it is crucial for a software developer to keep their skills up to date. It concerns me however the amount of developers  I find that do not invest in their knowledge portfolio (Dave Thomas from the Pragmatic Programmer). They simply just plod along developing software which is given to them with little drive to do that bit of extra research or to investigate a potentially new technology.

I was recently saddened to hear of a former employee who had spent many years developing against a legacy system but did not pursue the opportunity to upgrade it enough. Unfortunately, when the contract was terminated and he left the company, it was a mad dash to begin tutorials on Spring & Hibernate to get an understanding on some of the technologies which have been out in the Java industry for ages.

So what is the best way to learn new technologies? And how can I develop a culture within myself of keeping up to date with some of the new things coming out? Below are some pointers that I have picked up over the years:

  • Subscribe to a technical mail post or RSS feed
    Within the Open Source community I read daily posts of new architectural patterns, Java components and Open Source tools. There is no human alive who has the time to sit down and develop a thorough understanding of them all. However it does not hurt to skim over some of the new technologies coming out or have a bit of dig into what is available. I personally subscribe to either JavaLobby or Java World and find 1-2 hours a week on the train to open my laptop and read daily what is emerging in the technical market.
  • Don’t get stuck into too much reading
    I once heard a speech on the influence of Greek practices on the Western world (resulting in an over dependence on knowledge rather than practice). There is a tendency to spend too much time reading articles, attending seminars and performing analysis before commencing code. This unfortunately leads to developers who can hold technical conversations but are unable to deliver. When learning a new technology my ultimate preference is to sit alongside someone who understands the technology and work on an example and ask questions. In my opinion, it is the best way to learn a new piece of technology. When that is not available I read the bare minimum and then just start coding - you will learn more when your reading is event driven by your coding experiences.
  • Have timeouts with colleagues to discuss technical ideas
    You should never underestimate the daily 5-10 minute conversations with colleagues over technical ideas. It is helpful to gain other points of view to either strengthen your case or change your perspective. In talking to some of the most junior developers, I have found things I was not aware of. Within my team we have weekly 1 hour innovation sessions. In this we investigate a range of new technologies and learn off one another. Developers love the opportunity for innovation and creativity,  and this kind of investment is crucial for staff retention.
  • Join a User Group (e.g. JUG)
    JUG’s (Java User Groups) are global, and it is the perfect place to get an understanding of new technolgoies and expand your network.
  • Establish a strong understanding of the common technologies
    Across many organisations you will find a common set of technologies or frameworks used. It is important to gather a moderate understanding of each of these as it will remove any lead up time if you change jobs or projects.
  • Work on or start and open source project
    I try to reserve a couple of nights in the week (mainly Thursday or Saturday nights) where I can work on a personal project. My family generally goes to sleep around 9pm hence I take the hour from 9-10 to work on something I enjoy. Doing this out of the office gives you more flexibility and uninterupted time to sit relax an enjoy your coding.
4.333335
Your rating: None Average: 4.3 (6 votes)
Published at DZone with permission of its author, Christopher Steiner.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

James Sugrue replied on Wed, 2009/02/25 - 2:38am

Nice set of guidelines Christopher. Joining an open source project has a lot of benefits. Even by taking part in the discussions on mailings lists/newsgroups, you get a better understanding of technologies, outside of the stuff that you work on 9-5. James

Jeroen Wenting replied on Wed, 2009/02/25 - 3:54am

"I was recently saddened to hear of a former employee who had spent many years developing against a legacy system but did not pursue the opportunity to upgrade it enough. "
In other words, you're sad that he did his job rather than pursueing a hobby on the side during work hours?
Reworking an existing system just because it doesn't use the latest and greatest hyped technology is NOT a good thing to do, it's what gets people fired for causing major failures.

Christopher Brind replied on Wed, 2009/02/25 - 4:39am in response to: Jeroen Wenting

I hear what you're both saying, but I definately side with the op on this one.

I'm not interested in working with people who just come to work, do their job and then go home, I would rather work with someone who's hobby is their work.  I am even happy for them to work on side projects a little during office hours so long as a balance is maintained between getting the job done, their hobby and their home lives.

I think the op's point was not that people should re-work systems for the sake of it, but to at least be able to identify when a system will benefit from new technology, especially so in the world of product development where "It ain't broke so don't fix it" just doesn't cut it if you want a product that will remain relevant.

The other benefit of updating legacy systems in particular is that it can free up the people who spend time maintaining them to do something more interesting, but again that is down to the invidual.  The op's colleague is probably what I call a 'plodder' and probably has no interest in keeping their skills up to date, or even in technology and probably considers themselves stuck in a dead end job.

Sometimes your employer can help (with training, seminars, team meetings, etc), but at the end of the day it is your career.  If you're happy plodding along and making no real progress then fine - but I see a day, probably quite soon, when there is no room for plodders in the industry, due to redundancies or whatever. 

An employee with up to date skills is more likely to survive a round of redundancy in a potentially harsh climate.

Sinan Karasulu replied on Wed, 2009/02/25 - 4:55am

Hello Christopher. Thanks for the information. I myself am a young coder so I find these guidlines to be very informative and useful. I will definitely try to make these guidlines a habit . Sam

David Latil replied on Wed, 2009/02/25 - 8:50am

I've found the culture at the workplace makes a huge difference.  In the beginning, I worked a job for 5 years where nobody was interested in keeping up, come to work, go home and get paid.  I then saw the light and moved to another job where learning newer technologies was the norm and was greatly encouraged (programming was fun again).  Long story short: for the new developer, if you feel you are stagnating, you probably are and should take action to fix it or consider looking elsewhere, there is no replacement for workplace culture when it comes to keeping up.

Frank Silbermann replied on Wed, 2009/02/25 - 12:01pm

There are too many dimensions of technical change and progress to keep up with all of them, and if you guess wrong you've just wasted your effort. Therefore, I think the most important aspect to keeping up is to be smarter than almost everybody else, so that what takes most people a year to learn takes you only a couple of months. That way you can quickly catch up whenever getting behind gets you into trouble. Everyone needs to be in the top 20%.

Dean Del Ponte replied on Wed, 2009/02/25 - 12:58pm in response to: Frank Silbermann

You'll never keep up with all dimensions of technical change and progress. And picking wrong is not a waste because, even if you pick to learn a technology which doesn't catch on, you've still learned something and I guarantee whatever you learned may be applied to different facets of your day to day job.

Alex(JAlexoid) ... replied on Wed, 2009/02/25 - 3:29pm in response to: Jeroen Wenting

Jeroen wrote:
In other words, you're sad that he did his job rather than pursueing a hobby on the side during work hours?
Reworking an existing system just because it doesn't use the latest and greatest hyped technology is NOT a good thing to do, it's what gets people fired for causing major failures.

That may be true, but if you develop software just because it is your job, don't expect people around you to like working with you.

Now you have to look a reworking an application to a new technology in a different light. If a technology that is being used is very old, you could argue that in the long run reworking would save a lot of money, by having a constantly fresh pool of developers available.

It is not a secret that newer technologies have bigger talent pools available to businesses.
And there is also the fact that newer technologies tend to make development easier, faster and increase quality of the end product.

I, myself, am currently fighting to move an application to Hibernate, currently it is using EJB 2.1 Entity Beans.
The development started 1 year ago, and it was started by people that view their job as a job only. Neither the architect, nor the technical lead have experience* with Hibernate, but the development team* has basically 0 experience with Entity Beans.

 

So my ending and summarizing statement is:
   By being narrow-minded in IT you will be screwing up life to other people if you are promoted.

 

* - Both the architect and the technical lead boast working with Java for over 6 years.

** - along with all of the talent pool they have access to.

Rainer Eschen replied on Wed, 2009/02/25 - 6:23pm

Don't loose too much spare time with coding to understand new technologies. Don't invest in technologies that will never be mainstream. Concentrate on realizing what is the next major step of the community and try to persuade your architect to use it in the project. Then you have enough time to code and understand. This know how is really worth to learn and can be used in future context, even if you leave the project.

Todays IT is much too complex to waste time with the useless stuff. I don't think that the results of such studies are helpful. If so, you learned something that is common sense, like design patterns. Or something you should have learned before ;-).

Programming languages come and go. Only the concepts are stable for a certain time. So, my suggestion for beginners: have a look at development process and design pattern principles. To learn a new syntax is the least effort.

Alex Miller replied on Wed, 2009/02/25 - 11:55pm

You should read Jared Richarson's new book Career 2.0 for a bunch of good advice along these lines (in a more fully-developed form). 

Jeff Mutonho replied on Thu, 2009/02/26 - 3:34am

I can atest to the second point "Don’t get stuck into too much reading"  .

I've had that experience myself where I just read stuff and never bothered with trying out the material practically, and then be shocked when I tried to use the technology I thought I understood well.Reading is indeed important , but it has to be matched applying the lessons practically.The other thing I noticed was that my threshold of getting bored by technical books lowered(i.e i got bored easily) , the more I read without doing practical things.In fact it got so bad that I usually would read the first 2 chapters of a technical book , lose interest and park the book in the garage.

Tracy Nelson replied on Fri, 2009/02/27 - 7:29am in response to: Jeroen Wenting

Reworking an existing system just because it doesn't use the latest and greatest hyped technology is NOT a good thing to do, it's what gets people fired for causing major failures.

This is superficially true.  However, you can often find non-disruptive ways to integrate new technologies into a system during the course of normal maintenance.  I also think it's disingenious to refer to this as "pursuing a hobby during work hours".  It should be a developer's responsibility to keep up to date on the current state of the industry.  Not to do that is cheating your employer (and yourself), IMHO.

Christophe Caenevet replied on Mon, 2009/03/02 - 3:45am

Greate article : "Within the Open Source community I read daily posts of new architectural patterns, Java components and Open Source tools." Can you tell me more about your sources of "new architectural patterns, Java components and Open Source tools" ?

Arul Kumaran replied on Wed, 2009/03/04 - 12:22am

Excellent post Christopher.

-- I also spend some time helping others at work and after hours via forums like Java Ranch. One can learn more and stay technically ahead by helping others. You can learn not only from your own mistakes, but also from others' mistakes.

-- Writing articles and books can also give a different perspective to learning. With the advent of print on demand publishers writing a book has never been easier and more affordable. It can be rewarding as well.

Weijian Fang replied on Tue, 2009/03/03 - 7:14am

Thanks for the author's great suggestions and others' valuable comments above. May I add another point IMHO: stay focused.

As mentioned above, there is no need to spend too much time reading and it is impossible to know everything. Then decisions are always needed on what our time is worthy spending and on what is not worthy. For instance, I doubt it is useful to jump between Java ME and Java EE. I feel there are always lots of exciting developments in my very specialised area. And it is good to build future career based on past experience.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.