Staying On-Top of Programming Trends?

GhettoPeanut asks: "Trends are constantly changing, upgrading, or become popular due to high end user demand or just basic usefulness. I do my best to keep up with the trends, believing that for the most part they will be better then the current methods in place, or just comfort in knowing that if enough people use it, that there will be allot of help out there. Ultimately though, its keeping up with these trends and trying to figure out what's a fad versus what's actually useful that's the difficult part. What do some of you do to keep up with the trends? Websites? Magazines such as Dr. Dobbs? Forums? I know there's not one solve all, but for the sake of argument, suppose you wanted to stay on the forefront of Java based web development, what would you do?"

Comments

Ignore them...

[ResidntGeek]

This isn't what you asked, but you shouldn't follow trends, you'll just end up with a little knowledge of everything. Just concentrate on C or C++ for *NIX (or something similarly consistent) and you'll eventually be a guru, able to do anything you wish with it.

Re:Ignore them...

[illuminatedwax]

The C++ specification book (Stroustrup) is a thousand pages and very densly written.

And contains tons of stuff which is meaningless to memorize. .NET is the same way, too. Who needs to know all of the subclasses and methods of some obscure function? If you know the general concepts of how computers work, you can apply it to anything, leaving the specifics in the manual when you need them. Having the concepts means you know where to look.

"I say now, as I said then, that a man should keep his little brain-attic stocked with all the furniture that he is likely to use, and the rest he can put away in the lumber-room of his library, where he can get it if he wants it. --Sherlock Holmes

Re:Ignore them...

[Jerry Coffin]

Everything is cake when you are an undergrad, and one week's or even one summer's experience with C++ and .NET is just scratching the surface. The C++ specification book (Stroustrup) is a thousand pages and very densly written. .NET is enormous and also takes a year to years to master. The best thing you can do during the summer job is learn from the more experienced people working there (their methods, working with the customer/management, etc.). The programming aspects of the job mainly just bolster the buzzwords on your next resume and provide talking points during interviews.

While you make some good points, you also have a couple of mistakes there. First of all, it's been quite a while since any of Stroustrop's books was really the C++ spec. Anymore, the spec. is the 2003 edition of the C++ standard (aka ISO 14882), and before that it was the 1998 edition of the same. Oh, and FWIW, while it's certainly densely written, it's less than 800 pages long. :-)

.NET is huge, but that's not necessarily very closely related to the time it'll take to master it. In fact, I'd almost go so far as to say that .NET simply isn't oriented toward toward what I would normally consider real mastery. At least from my viewpoint, it's a rather "flat" library -- very large, but not a lot of real depth. Most of the functions just "do what they do", and that's the end of it. To a large extent, "mastery" is mostly a matter of sufficient familiarity that you can quickly find the functions you want/need at any given time.

That's a direct contrast to, for example, the Boost Library or the Loki Library, which are a lot smaller, but a whole lot deeper. Here much of mastery is simply wrapping your head around some of the concepts involved. A few people accustomed to Lisp, Scheme, Ocaml, etc., may already be accustomed to some of them, but most typical programmer have never even considered doing the kinds of things it covers (and even the Lisp crowd is likely to find a fair amount of it somewhat challenging as well).

To put that contrast a bit differently: if you were accustomed to Java (for example), using .NET would mostly mean learning different names for classes and member functions, but the classes and member functions would still be on the same order as you were used to (a bit cleaner in some places, a bit grungier in others, but ultimately the same general kind of thing). By constrast, either Boost or Loki is much more likely to cause fundamental alterations in how you think about and solve your problems.

Re:Ignore them...

[1iar_parad0x]

It's not hard to pick up a book/documentation on a new langauage and start writing code. However, it is difficult to design an application effectively without knowing something about the language. Could I design a large scale C++ app effectively if I were a Java or Perl guru? Would you want some crusty old engineer with years of embedded systems experience and C++ skills designing a large scale J2EE database app. You take for granted the complexities of the software engineering process when your part of a team. Incidentally, if you think you can tackle a small project with a new language and not make some mistakes, you're only kidding yourself.

Re:Ignore them...

[readin]

The problem with this approach is that you can't look up what you don't know is in the book. You may know enough .NET to do your job, you can code anything you need to, and if you suspect something already exists you can look it up. But what about the code that's been written that you don't know exists? One of the advantages of great experience with a language is that you already know that certain things are available. Another advantage is not having to take time out to read up on something because you haven't used it before. Hand in hand with that is already knowing the quirks and crannies that someone who just skims the documentation may miss or that may not be documented at all.

Re:Ignore them...

[Anonymous Coward]

Most CS instructors will cram down students' throats that if they concentrate on principles they can pick up any language/platform as if it's nothing at all. It's a lie, but that's what they say.

They actually aren't lying, although they might not be teaching principles as effectively as they could.

Alan Perlis once said that any programming language which doesn't change the way you think, even a little bit, isn't worth knowing. Most languages fall into this category: assembler, C, C++, Lisp, Scheme, ML, Perl, Smalltalk, etc. But I've talked to a number of people who learned Java after learning another object-oriented language, and not one of them thought that Java changed the way they think.

Java is a very useful language, as much as I personally dislike it. Its biggest theoretical weakness (the fact that the module system is conflated with the object system) is also one of its biggest practical strengths, since it localizes any problems which mediocre programmers could cause.

But this also makes Java a terrible language for teaching the principles of object-orientation. I can't tell you the number of people I've talked to who are convinced that encapsulation is by far the biggest benefit of OOP. I've tried to explain to them that there are certain things you can do in five minutes in object-oriented languages, like having run-time polymorphism, that would take you weeks to write and troubleshoot in C (although I hope that no one in their right mind would try to roll their own vtables anymore). Even C lets you do encapsulation -- you just declare "public methods" in the header file -- but C clearly isn't an object-oriented language, is it? Alas.

But anyway, my point is this: If the only language you ever learn in school is Java, learning additional languages will take a lot of work. But if you learn (like we do at Brown) Scheme, then ML, then Java, then C and C++, and then take a course where you write a fair number of programming languages yourself, you will be well equipped to learn whatever you need to. Yes, some schools pretend they're teaching "principles" when they're really teaching Java, but that's the fault of the school, not the idea.

Side note: If you really think that using C for everything will make it easy for people to understand your code, then you might want to come out from underneath your rock. There have been a huge number of advanced in programming languages in the 30 years since C first came out. For one, OOP is actually useful for many problems (again, you don't actually write your own vtables, do you?). Also, consider a language like Python. Not only does it support first-class vectors and hashtables, but it supports list comprehensions:


>>> [x**2 for x in range(100) if x**2 in range(100)]
[0, 1, 4, 9, 16, 25, 36, 49, 64, 81]


I would call that clear, wouldn't you? The equivalent function in C (and I apologize if my syntax is wrong) would take significantly longer, especially considering you'd have to include a list library.

C may be simple, but that doesn't mean code you've written in it is easy to understand.

Read and Succeed

[Unoti]

Two key thoughts to share: Read, Succeed.

Read

First, you need to read a lot. Dr Dobbs, MSDN, developer blogs, books. To separate fad from rad, I recommend you use your own common sense.

For example, a few years back I worked hard to learn and understand the Unified Process. There were a lot of great ideas in there, but I felt it was too heavyweight and over the top for what I was doing. But I did feel it had brilliant ideas and revolutionary concepts. So I took what I thought were the most practical ideas and used them. The most important ideas I took were things like 1) throwing out the waterfall approach and developing iteratively, testing and "releasing" after each iteration, 2) identifying the biggest show-stopper risks up front and doing research to make them not so scary, 3) getting the customer/end user involved up front and through the whole process. A lot of people might shoot me for saying this, but it turns out that the Unified Process was pretty much a fad, and those key concepts turn out to be the foundation for "Agile Development" and "Extreme Programming."

The point is, read and study anything that interests you, and decide for yourself what's useful.

Succeed

Second, you need to do stuff to get success stories you can tell when you're interviewing or selling yourself to your current employer. A lot of book knowledge doesn't do diddley if you don't put things in the done basket. Ever see people at work with dozens of spiffy certifications that can't code their way out of a paper bag? Don't be like that. Do lots of stuff and do it successfully.

I recommend you work on anything you have some passion for, even if it's not directly work related. For example, I did a lot of 3D programming when I was working as an Oracle PL/SQL developer. Totally unrelated to work. But I honed my OO skills, learned OpenGL and DirectX, learned a lot about 3D math. Although it took a while to pay off, all of it did eventually pay off. Knowledge of C++ helped me answer tricky STL interview questions, and I later got a job with a company that makes interactive 3D training software for jet mechanics-- way cooler than Oracle. And even though this wasn't work-related, I was able to include that work in my list of success stories I could tell potential employers and other people making decisions about me.

So do whatever you have a passion for, and do it successfully and to completion.

Re:Read and Succeed

[Anonymous Coward]

Hmmm...I guess people need to ask themselves if the are in love with this programming stuff or just doing it for a paycheck. Reading everything on the earth plus having programming hobbies in addition to work isn't practical for most people, especially if they have any interests outside of computers. I've found that living in a cubicle at work and living in a darkened computer room at home is absolutely and utterly depressing. I'm actually quitting the computer-biz entirely and getting a job where I work outside. Mmmmm...sunshine.

Re:Read and Succeed

[bladesjester]

I enjoy programming and I like learning new things, but I do not want to spend every waking moment focusing on new trends in software development.

There are those of us who really do like what we do, but still consider it a job and want to do other things besides on our free time.

Immerse yourself in RSS feeds

[smug_lisp_weenie]

Set up an RSS reader like reader.google.com or bloglines.com, then find a bunch of RSS feeds that cover that domain in some fashion. For Java, for instance, you can find some feeds here.

The key is that that it's really quantity and regularity that's most important- If you spend a little time each day immersing yourself in the terminology you'll start to get a feeling of who has the most credible opinions in that field and what those persons are excited about (so eventually you'll have quality covered as well).

There's a good chance that this will, of time, allow you to spot patterns and predict technology trends.

Don't limit yourself to Java

[Anml4ixoye]

The best advice I have heard was from I believe Martin Fowler who said to learn a new language every 6 months. So, instead of learning the differences between JSF and Struts, pick up a Rails book, or Python, or Boo, or Lua. (Except if part of your job is figuring out the differences between JSF and Struts)

Several of my coworkers attended JavaOne, and while I would have liked to have gone, I'm much happier going to Agile 2006 where I will get exposed to a wider variety of things going on. For example, if you haven't tried Rails, it is a great way of seeing how using sensible defaults can get something up and running quickly, and how extension can keep it maintainable as it grows.

Same thing with ASP.NET. The event model for web pages is really great, and I've built some neat apps in ASP.NET which let me use some of the cleanest MVP seperation possible.

So, if you want to know more about Java, pick up some other languages. You'll find yourself wanting to do even more.

Ignore it.

[jlarocco]

I know there's not one solve all, but for the sake of argument, suppose you wanted to stay on the forefront of Java based web development, what would you do?"

Shoot myself.

More seriously, trying to stay up to date on every new trend is pointless. You're better off picking a few things and learning them well.

Be good at what will always be needed.

[triskaidekaphile]

I know Java very well, but my true strength is in design. It doesn't matter what languages come and go, those skills will always be useful.

Learn good communication skills so others will think you are competent. Even if you aren't.

Learn persuasion skills so you get good compensation.

Prepare side interests that you can ramp up into money-making ventures in a few months. If your company folds, you get laid off, or you decide to retire (or just plain quit) and the job market sucks, you at least have an avenue to pursue.

Re:Be good at what will always be needed.

[Atario]

Learn good communication skills so others will think you are competent. Even if you aren't.

And, remember, writing is communication. In fact, it's a form of communication that lingers on long after you've forgotten about it, making you look smart or stupid, as the case may be, the whole time.

My point here, of course, is that the submitter's summary is chock-full of screwups.

GhettoPeanut, please: the language you should be working on is not Java or Ruby or SuperDuperCPlusPlusPlus. It's English.

A blend of sites.

[shoolz]

I don't think what you're looking for exists!

I find that I generally have a good idea what's going on by frequenting /. and many other geekly news-aggrigator sites. I keep my ear to the ground and keep track mentally of how often new programming/tech buzzwords get kicked around. I investigate every technology on a high-level, and when I see a new trend emerging that seems to offer a solution that nothing else has so far, get involved on a granular level. I make my own decisions based on what information I can gather.

Bottom line is, to use your example, if you were looking for what was going down on cutting-edge Java, you would simply spend a good portion of your time researching Java. But the point I'm trying to shoehorn in here is that to stay on edge, you have to be on edge. Which means investing time and researching and *actually* knowing what's going on. Otherwise you'll remain a tool to the hype-machines that have felled so many good programmers / managers.

Sorry... I wish I could give you the "visit site X" answer that you're looking for. I really do.

C/C++

[SirSlud]

Thats it. Know how to program in C/C++ and you will find a job.

What it really comes down to is knowing your data structures, knowing how much memory you're using, knowing how brutal your algorithms are, knowing the time to add/remove/find elements in your structures, and once you know C/C++, everything is a cakewalk. Seriously. Jesus I still wish I was doing web programming, where wasting massive cpu was okay. Learn C/C++ and find a job where you need to keep things speedy like games or web servers that need to deliver massive amounts of requests per second. Spend 2 years doing that, and you'll need and know everything you need to know for a career in programming.

Read Slashdot

[wysiwia]

Read Slashdot of course!

Yes. Slashdot has quite a reputation for attracting knowledgeable people, yet be aware that some are rather biased towards OpenSource. And don't forget that people who do OpenSource (me including) have a rather absolute opinion. So as long as you are a little sceptic you should be able extract the trends.

As you mention Java you may well notice that currently any Java discussion always tends toward flame wars. Flame wars are always signs that something isn't good, that the there isn't an uphill trend. Flame wars always arises when the future (a trend) isn't going as wished.

I'm probably much biased but IMO the future trend in software development is "cross-platform". So far for many years you could do resonable cross-platform development only with Java. Today you can equally well do cross-plaform development with AJAX or with wyoGuide (binary applications, http://wyoguide.sf.net/). So regardless which of the different technology takes the lead, cross-platform development will increase to the point where single-platform development won't be accepted.

O. Wyss

Re:Read Slashdot

[wysiwia]

Ok, so call me an un-trendy old-fart. Let's see ..... a quick review of my resume since

1980, when I first became a programmer .....

I wrote my first Fortran program in 1974 and it work fine on an IBM computer and a few years later on a Digital PDP-11. Albeit it was my first cross-platform code, there's no way to sell it these days.

... that languages are not, nor have they ever been, nor will they EVER be, a magic bullet.

Languages were never the problem and even for the same task several different languages could be used. But you can't expect users to enter countless numbers on a console or copy back the resulting numbers. So even if you code a simple square root function you have to code a GUI around which is many times more code than the function itself. Yet if you want to sell your function depending on its kind users expects sufficiently good look&feel.

O. Wyss

User Demands?

[Fulcrum of Evil]

Trends are constantly changing, upgrading, or become popular due to high end user demand

Why the hell should users care what language their stuff is written in? They're USERS!

Re:Pick a language

[XaXXon]

Take what this person said and do the exact opposite.

If you only have a hammer, everything starts looking like a nail.

That's the sign of a bad programmer.

Who moderated the parent insightful?!?

Keeping it simple.

[Anonymous Coward]

I will just answer your question. Since you asked for *what* you would do to keep with trends and not *whether* you should keep up with trends (that is a seperate discussion)

- Tinkering with technology is key. Learning to program is an iterative process. Download the tools, look at the demo code. Mess
    with it. See what happens. Break it, fix it. Don't read a book just yet. Experiment first.

- If you are stuck. Google for forums, start asking questions on the newbie section. Make sure you stick to the "newbie" section
    if you think you are one. Posting simple questions on the advance section will just frustrate everybody.

- If you really want to get to know the trend. Cook up a personal project. Set goals (reasonable ones). Make sure the project
    solves a realistic problem/need. Start working on the project. Seek help from forum on the project. If your project is an
    interesting one maybe someone will volunteer to join in. Seek sourceforge/java.net or sites that allow for team projects to
    reside.

- Read book on what you are experimenting (This is really the last resort). I usually don't have the patience to go through a book
    There is plenty of "quick and dirty" info online and reading book would be only in cases where you are trying to evaluate a
    vendor specific technology and the vendor insist on you buying a book or paying for a subscription to get to know their
    technology (vendor = Microsoft). I think we will make contact with alien life before Microsoft makes Visual Studio
    freely available for download. The former is more likely to happen than the latter...

    Anyways.. you get my drift.. just be interested in what you do and the rest will follow.

Don't Follow

[tedgyz]

In general, avoid the trends. Stay away from magazines - they are the greatest purveyors of trends. I generally wait until the technology has matured. It will either die on the vine, or fix the most annoying issues. For example, early versions of JSP were pretty horrible, but now it is the cornerstone of the web apps that I build.

Boring anecdote: I am glad that I fended off the EJB hype. Now, most of the industry has realized what I suspected all along - EJBs are mostly useless and usually create more problems than they solve. About 5 years ago I had a technical manager that insisted we use EJBs for all our new development. I resisted the best I could. One engineer on the team even proved that for database access, the EJBs were 10x slower. The manager didn't seem to care. We ended up putting in enough EJBs to satiate his mandate, but mostly avoided them like the plague. EJB == Extra Java Bloat