Derik Whittaker

Personally, I think the focus has been placed too heavily (in general, not specifically by you) on tooling and technologies. I'd rather take someone who has good knowledge of patterns and principals, over someone who's up to scratch on the latest Microsoft jingle.

Learning languages is a good thing, but as long as they're sufficiently different to what you currently know. Just learning one with a slightly different syntax isn't going to have as much benefit as jumping to functional, or dynamic.

If you already have a good principal basis, then tools/technologies are a good way to keep fresh, but I don't think they're that important.

Great advice. I also agree with James' comment regarding the choice of language. There's much more value for a C# developer to learn something like Ruby, Erlang, F#, than learning a language that is too close like Java and VB.NET (well, if you get my idea of "close").

But @derik dont you think you are going to become "master of none and jack of all" by tasing all such frameworks etc.

I think one shud learn 2 new things and has command on 1 other thing , at a time.

dont you think you are doing too much? and also its hard to remember once you are not in practise, of new tools and techs.

I think the big thing here is to be out there learning.  Becoming "Master" of any technology tends to get you where the COBOL programmer in the story was, enamored with one technology and thinking that it's all you'll need.  

Plus once you become a "Master" of a tool (or pattern), you tend to find ways to use it instead of finding the right tool for the job.  If you are familiar with a lot of different things, you can dig into it more once you've found an user for it, instead of learning a tool and searching for a way to use it.

I personally don't think the specific programming language is important but employers do.  

The fact is knowing designs patterns and principles is not very important to employers.  But the language is, hence they mention the language in the job specification.

I have spent some time after leaving university understanding design patterns and principles but when going for job interviews I seem to have to know what API's do (that's generally the type of questions you would get asked).

Anyway learning Java syntax and API's so I can get out of this testers job.

I think that junior developers are lucky to get the jobs - simply because they know the syntax.

What the difference between a 32bit and 64bit machine?  Whats 13 decimal as a hexadecimal representation?

If you don't know the answers to these basic q' how did you become a developer.   I am sure that anyone reading this post knows this but its for other developers out there.

You've been kicked (a good thing) - Trackback from DotNetKicks.com

you missed the part of the story where the guy still makes a lot of money maintaining legacy systems written in COBOL

anyway... keeping up with C# alone is hard, most developers don't know how to use all the features of C# 2.0 yet

I take a similar approach like you, I get myself familiar without getting too deep

If I didn't already know you, I'd say you have way too much free-time (which learning a new language, unless part of paid employment, takes much of).

I think it would be more important to learn how to do different things in the same language, than just learn a new language.

Example:  I can learn how to do data access in ruby, c#, java, etc.  or I can learn how to do, e.g. Code Security in my language of choice.

Think the latter is better.

Learning is good, agreed. I will always be an advocate of learning no matter what.  The problem is, as JDN said, when do you find the time?  If my job is to run my website that I built myself in VB.NET, what benefit do I get from taking time out of my day to learn, say, F#, a language I will probably never use? Yeah, it's nice to say that I know another language, but really, have I just wasted so many hours of my time?

That COBOL Dude retired a multi-millionaire on 01/01/2000.

A student of many is a master of none.

It is better to be a content specialist in one area and provide quality work in that area than be lost in multiple different technologies - you will probaly earn more too.

Language isn't important, knowledge of frameworks is. I wouldn't employ a java progammer to write .NET code even if he is a good programmer (and Visa Versa). I would employ a c# programmer to write vb.net code.

It is really hard to find good programmers now days. Generalists are less likely to get paid as much as specialists simply because they don't have enough knowledge in a single area.

Some.NET(Guy) said: "what benefit do I get from taking time out of my day to learn, say, F#, a language I will probably never use? Yeah, it's nice to say that I know another language, but really, have I just wasted so many hours of my time?"

The benefit is that you learn new ways to look at problems, new programming concepts and new patterns that you can often use in your favourite language. Interested in keeping a server running 24/7 for years, with hot code updates? Have a look at Erlang, they're doing this, maybe you can learn something from them. Want to use Linq most effectively? Have a look at F# and functional programming, that's where Linq came from, they've already developed good coding practices and patterns for that, you can probably use that.

Also, you often have to choose what tool to use for a particular job (sometimes this choice is made for you, but you can often choose for smaller sub-problems like e.g. log-file-scraping). How do you think you'll be able to pick the best tool if you know only one?

There's more to avoiding extinction than staying abreast of the latest technological trends.  The *reason* the COBOL programmer became a dinosaur was that he stopped adding value to his employer.  The fact that it was because he wasn't a language hipster may or may not have contributed to this.  Maybe he was just an @$$ and difficult to work with.  Where I live there are still COBOL jobs seeking bodies, so they're still relevant and making money.

Learning languages keeps you sharp, but frankly you should get to a point where a new language becomes a "do you have an evening" exercise.  The value in a software engineer is in their ability to apply the craft to solve real problems.  For example, a genetic engineer with a little COBOL knowledge is going to be a whole lot more valuable to a genome sequencing project than a cutting-edge software engineer who can't spell GATC.

@beefarino:

There are two ways to learn a new language. One is best described as "a fortran programmer can program fortran in any language" - i.e. you learn the syntax of the new language, and then write the same programs you would have written in any other language in that new syntax. This makes learning a new language a "do you have an evening" exercise. Unfortunately, you don't learn much through that kind of exercise.

The other way to learn a new language includes learning, practicing and reflecting about the common idioms of the new language - things like object-orientation (Java), pure functional semantics (Haskell), lightweight processes (Erlang), dynamic typing (Python), syntactic macros (Lisp), generic programming (C++ templates) to name just a few. Unfortunately, learning these is a lot harder than learning a new syntax or learning a new framework. But that's the kind of thing that will help you be more productive in your later life as a programmer, no matter what language you're actually using.

@Niki:

Excellent points.  

But most of the "hard parts" you describe aren't really language features, they're engineering or design principles.  You can understand the principle without learning the language.  For example, you can write object-oriented code in C, it just looks a lot different than C++ or Java  or C# because there are no language features directly supporting it.  Dynamic typing is taken for granted in many languages today, but the same effect can be achieved in, say, C with a lot of work.  

And in that sense I wholly agree with you - learning the practices is hard, it requires you to drink the kool aid and commit yourself; my point was that  once you've made that choice, learning the languages should come pretty easy.

@beefarino:

It seems that when I speak of "learning a language", I mean learning the syntax and the programming style of the language, while you mean only learning the syntax. So that's just a philosophical disagreement about words.

I do think however, that learning ideoms like purely functional programming, higher-order functions or syntactic macros is easier when you learn them *through*  a language that enforces them or makes them easier. You could probably learn most of these things "the hard way" in C or assembler, but that's far harder, and I have rarely seen a programmer learn the concepts mentioned above that way. A language like Haskell or Lisp can give you a far cleaner vision of what these ideoms look like, which then makes it easier to translate them into [insert favourite language here]. That's my experience, at any rate. (And the reason why I learn new languages from time to time)

I'm a C# developer, now I was considering learning Cobol (joke). I'm bewildered by how much there is to learn. So i'm going shallow in various areas. But looking at

*Erlang

*F#

*MVC Framework <-- Loving this

*WCF

*NHibernate

*Nant

does learning javascript or php count?

Pingback from  The Links Have Built Up&#8230;Link Dump Time! &laquo; IS Department

100% Agreed

Also a lot of environments (some I've actually seen in the past) do not support learning new languages or technologies in terms of good OOP, ORM, and best practices.

For example, a lot of mom & pop or even huge family owned organizations typically buy out all their software (CRM, use Sharepoint for everything, etc.) instead of actually building some solid applications using a true n-layered architecture.  If you come from shops who have successfully used ORM, then you know that even though it can take a bit more time, it's much more extensible and maintainable.

With that, if you're not in an environment which allows you to dig into a good .NET solution, and you're constantly having to code in 3rd party plug-in type environments, it's going to slow you down in this area and learning true OOP.

So I tend to think that if you really want to code a lot of OOP, do not look to work at places who are against custom code or don't know any better than to just buy everything and have the developer "maintain" it.  You run into business limitations and developer limitations when you place all your cards and money in all these 3rd party software packages.

Granted I did not say you can't use and should not use SOME packages.  But you should not be going against the grain by creating solid quality n-layered architecture from scratch as well.

So with that, if your work environment doesn't facilitate learning new things (e.g. I can't use .NET 3.5 because the "3rd party package" would have to be upgraded and that would never happen in the next 5 years) then you're kinda screwed in developing your skillset.

And one could argue fine, then you should do it at home.  For me, it's not that easy to find time to code LINQ at night when my kid is crying all night.  Granted anytimeI find time I do but organizations also stunt their employee's development in many cases and I've been there early in my career and learned not to work in environments which are against doing any sort of custom code and environments which do not do n-layers in their architecture.

>>>Sorry, but you simply have to make time.

This is one Derik I do not see eye to eye on and you know it.

making time is relative to what is going on in your life.