With languages like Python, PHP, JavaScript, Java, or C#, sure -- they're fundamentally very simple languages with a handful of gotchas to learn, they're easy and fairly interchangeable, and your overall programming skill is what really matters.
But there are other technologies or "languages" which, paradoxically, many developers think are trivial to learn, like CSS and SQL, but in which years of experience matter far more than any kind of natural programming aptitude. CSS and SQL are heavily implementation-specific, with edge cases upon edge cases upon edge cases that often wind sucking up the majority of your time. If you want complex queries that are still performed efficiently, or complex layouts that don't take weeks to get working properly in all the different browsers, no astronomical IQ or general programming aptitude is ever going to win against years of experience.
I absolutely agree. Not to sound like I'm tooting my own horn...but at my job I jump around between backend work in java and some UI work with javascript/backbone with at least a good amount of efficiency in each. It's more of a change of environment/tools/goals (java - Use eclipse, log performance and errors with log4j, run unit tests. javascript - use a text editor, debug or maybe profile in chrome, test in different browsers etc)
However, I consider myself seriously unqualified to do anything relating to advanced styling/css.
I can't tell if you mean 'because I find it difficult too', or if you mean 'because it means I have less/easier competition'. Of course, this could have been your intention all along, but if it wasn't could you clarify?
Because I find it difficult too. :) Been using CSS for 7 years and still have some trouble with it, compared to typical programming which tends to be quite easy.
Anyone know of any good tutorials? Everything seems either really basic, or really advanced. I know csszengarden has loads of examples, but I would prefer something that explains it (I can't find anywhere that explains the nesting and the relationship to the syntax / structure of the css file. I always feel like I am just trying random things until something works).
CSS does feel a lot more complex than it ought to be, but it's dominated in every variable of badness by XSLT. That's the one language that defeated my efforts to learn it (mainly by killing all desire to do so).
haha. I actually love XSLT. It's closer to a language like Haskell than it is to any common language, which is probably part of the difficulty people might have in learning it. It also uses structural pattern matching, which doesn't exist in any common language at all. That's unfortunate considering pattern matching is almost as powerful a feature as first-class functions are.
One of the primary goals of a domain specific language is allow people to pick it up fairly quickly. If CSS and SQL fail right there, then we have a problem. I bet most of the difficulties you mention are historical accidents, which could be remedied if only our industry pulled its act together.
The problem with SQL is that you have at least four widely used implementations (MySQL, Oracle, Postgres, and SQL Server), all similar or consistent at the core, varying wildly at the edges. In this case, "pulling its act together" would mean Oracle and Microsoft taking on massive expenses and risks to converge on a consistent syntax and procedural language.
Historical accident, sure, but remedying it might benefit future users at the expense of the vendors and the current ones.
One should hire people who care, and who continuously broaden their own horizons. When it comes to developers, these inevitably happen to also be polyglot programmers in my experience.
First sentence is correct. Second sentence, the jury is still out. Plenty polygots fail short in writing high quality idiomatic code due to focus in breadth not depth.
Writing web apps backed by db in Python, Java, and Ruby are considered as breadth repeated 3 times.
> 2 years of Ruby, 1 year of Python and 2 years of Java
She is anybody but a polyglot programmer.
So this thing the author writing about is common misconception. Yeah, if know some mainstream(ish) languages and can do some common tasks you will unlikely have problems doing some common tasks in another ruby-java-python. Now go write me something rock solid in Erlang. Or (oh boy you better forget your java) Haskell.
Not to mention that to many rubyists, pythonistas or Javaneze 1 and 2 years of experience, is like saying that you just learned the language.
I use ruby ~ 3 years, not professional but more than 5 hours per week and I can say that I don't consider myself a pro or advanced in any way. There are huge parts of the language that eludes me, even in things/frameworks/situations that I have successfully used/implemented.
"The person with the second CV could be a better developer on a C# project than your language expert, despite having little or no C# experience."
No. What you're essentially stating is more experience is detrimental. That someone with a few months experience who is writing her first application in a particular language / stack will perform better than a veteran. Knowing the basics is important, but having experience not only with the language but with the libraries, apis, build tools, frameworks etc. is what separates a good programmer from a decent one. Both programmers in this case have the basics but the experienced person has a lot more than the basics. I'm not against hiring a polyglot, even one with no experience in the language/stack that will be used. Hiring a polyglot does not make up for experience and knowledge, however.
"What you're essentially stating is more experience is detrimental."
It's not so simple. Not all experience is equal. Some folks have 10 years of experience developing software. Others have one year of experience, repeated 10 times.
They are exactly at the same level of proficiency. Writing a loop in a different dialect does not make you one step better. You're still walking albeit with different rythm.
In the end, they are essentially performing the 11th time.
I went from Java to Perl (back when Java was all the rage). That really opened my eyes. Perl is dynamic, and you can program functional / imperative. You could do so much more with it in way less lines. You learn to use hashes / maps / dictionaries (instead of arrays being the obvious way to do things) because hashes are encouraged by the language.
Also, while Perl's standard OOP, is a bit of a hack on top of the language, it helped me really understand what was going on, unlike Java, where a lot of these things are like a black box.
Maybe I should have emphasized learning a second language with a different / multiple paradigms.
(Saying that when I later moved to a job using Visual Basic 6, I didn't feel like I learned much).
My experience was the other way around Java => Perl, not liking it. I suppose people have different taste buds.
While there are (small) values that one can get out of Java => Perl, being dynamic and functional, your experience seems seasonal (hashes, maps, etc). I felt that these days if one wants to learn algorithms and data structure, Java Collection libraries and Guava seem to be the defining standard.
I don't disagree if one is learning Erlang to write scalable message queue coming from Rails. But I definitely disagree if one is learning another programming language and ended up coding the basic web-app, which seems to be the case these days.
The problem here is that that 5 years of C# is quite possibly spent working on the same codebase...that person with 3 languages either solved significantly different problems, or worked on different codebases.
While yes, the 5 year C# coder is probably a veteran of the language, they probably don't have the breadth of experience of styles you get.
I'll take a bloke with a year of C, a year of Javascript, and a year of Ruby/Lisp/Smalltalk over a veteran of a single language for three years. You learn to think differently about problems.
The thing is the guy that is new to the language is not going to be writing idiomatic code. In C# this means you are going to see unnecessary ISerializable implementations, problems with Data Binding/MVVM, fighting with the GC, and not knowing what you get out of the BCL. Depending on their personality and who else is on the project this may not be a problem, but without some mentoring you can end up with an unmaintainable mess very quickly.
I don't think you are giving the language enough credit, especially one as well designed as C#. I'm not a Windows programmer so I hardly get to use it, but I once tried writing a Windows Phone Application and I was surprised at fun it was to use C#. The plethora of resources available also made it simple to write (what I thought) was idiomatic code - not much unlike Go.
Now, this experience has left a wonderful taste in my mouth with regards to C#, and I wish I had more opportunities to use it. And honestly, how long do you have to be immersed in a codeabse to being writing idiomatic code. A month of hands-on C# is enough for someone to write idiomatic code, and I wouldn't expect someone to be fully integrated into a team in under a month, so it kind of evens out.
But there are always those who don't bother learning the language. Like one of my predecessors who more or less wrote C# like C++ (pre-C++98). My apprentice then tried learning the language from existing code and in turn took a bit of mentoring to write idiomatic code. I do agree that the language is nice and well-designed, but people can write crap in any language and googling around doesn't necessarily lead you to the authoritative or most current documentation but oftentimes to crappy tutorials, beginner forum posts and the like. It's not that hard to pick up bad patterns, sadly.
I'm not so sure about this. I think you'd be surprised by how rapidly some people can grok things, including things you might believe are only visible through extensive experience. What it takes is the ability to follow structural ramifications to depth, therefore being able to anticipate aspects of the system that others usually learn through experience.
This is, after all, how Thoughtworks make their money - they insert polyglot (read graduates/juniors with a smattering of experience in different languages) into projects and bill for experienced professionals (the "seasoned" developers in this article). This article conflates "varied experience" with "good developer" and "seasoned developer" with "bad developer". In the real world, this is not the case. So whilst I agree with the premise that varied experience contributes to being a good developer and that polyglotism is very healthy and a positive sign, I disagree with the broad conclusions implied by this article.
A lot of great points. I've worked with a lot of people that know one language well but are almost willfully ignorant to others... even when the skills are needed on the current projects. I've gotten to where when I interview applicants I worry less if they know the answer to esoteric questions about rarely used features of certain languages and spend more time on architecture, testing/debugging and deployments. It's amazing how many people interview with 15 years of Java but no experience with Continuous Integration and testing techniques beyond JUnit.
In this case polyglot seems to mean, "has experienced a lot, traveled the world and is primed for stuff." One can get that and still only have Java or Python or C++ on their resume. We don't litter our CVs with all the stuff we dabble in. Exposure and priming matters, but most of these labels, using github as resume all seem like shortcuts to actually interviewing and talking to people. There are no shortcuts, building teams is difficult and shit is always way more complex than we make it out to be.
Agreeing with the comments here and the post - I'd like to add that having experience with many different languages also shows that the dev has a drive to learn, and that's a + in my book.
I see your point, however for me It's a pretty safe bet that a dev having experience in multiple languages has a drive to learn. Jumping the bandwagon is not necessary always a bad thing (it could be of course), sometimes it's a sign of curiosity and experimentation.
I don't disagree with curiosity and experimentation. But it's a very slippery slope with short attention span as well which seems to be the case nowadays (look at various Rails plugins, majority of NPMs, and 10001 Python web framework out there).
When it comes to programming, attention to details matters.
When I was working on a visual basic app, the (single language) developers hadn't even heard of a regular expression. Never met a moderatley experienced Perl developer that didn't know what a regular expression was.
I'm new to this game but I think there's a lot more to programming than "programming".
I'd love to be a polyglot but I spend so much time learning the differences between App Store "guidelines"/tools, IDEs, application life cycles and the minimum required to use/design for different OSes.
That I don't have time to fully grasp each language I use.
Does it get easier or do new technologies always have differ just enough to require new learning, for them to be useful?
You should aim to learn languages that are different. The point of learning very different languages is that you can start generalizing in ways that make mastery of future languages easier.
For example, Python has something called "list comprehensions". These might be interesting to a new programmer, but if you've used a functional programming language before, you have already used something more general (list comprehensions are essentially a syntatic sugar for a couple basic FP functions). Same with many other things like iterators/generators, which are a special case of coroutines. Etc.
So if you're familiar with functional programming, you can instantly understand Python's list comprehensions, whereas someone learning Python as one of their first languages might have trouble with them or might not be aware of the various constructs they can get away with.
So you really should seek out languages that are very different. As a point of comparison, I wouldn't consider Python, Ruby, Lua, Javascript to be very different from each other. You should try harder than that. But it does pay off and it does get easier as a result.
But there are other technologies or "languages" which, paradoxically, many developers think are trivial to learn, like CSS and SQL, but in which years of experience matter far more than any kind of natural programming aptitude. CSS and SQL are heavily implementation-specific, with edge cases upon edge cases upon edge cases that often wind sucking up the majority of your time. If you want complex queries that are still performed efficiently, or complex layouts that don't take weeks to get working properly in all the different browsers, no astronomical IQ or general programming aptitude is ever going to win against years of experience.