10 ms·

> A good developer can pick up any language or platform in a few weeks Yes and no. There's a major difference between "picking up" and actually being good at s

> A good developer can pick up any language or platform in a few weeks Yes and no. There's a major difference between "picking up" and actually being good at something. If you have nobody on the team that is either already intimately familiar with the language/platform, or has experience with various languages/platforms, you're going to be spending a lot of time figuring out how to do stuff properly instead of just building stuff. And if you are a startup with a limited runway, that difference is crucial.

ddoolin 12y ago
I'm glad you made this distinction. With enough time, yeah, sure, we can be "good" at any of them, but I've seen companies bring people on without a developed skill set in a particular technology only to find out the ramp-up time to be as efficient as someone familiar with it to be much longer than they bargained for.
- m3mnoch 12y ago
  agreed. it's really about lifecycle. near the beginning of your startup, you need multi-hat-wearing-swiss-army-knives for developers. once you get traction and growth, you need to bring in vertical expertise.
offwhite 12y ago
I think the point is that a good developer is happy to start using a language/framework because it is the best tool for the job (regardless of their experience using it), rather than just sticking to what they know. I think that's probably more useful in a start up. But I go more for the 'get shit working and see what happens' approach to developing. I mean, making it look pretty is what iterations are for. maybe. or whatever.
- jkestner 12y ago
  "Best tool for the job" is not a knowable truth. Best for what time frame? For what shifting array of tasks? Often we pick the tool that will be perfect for high performance or a known task, but if you're still figuring out the product, why not make an MVP using what you know? I rarely see anyone fail because they chose, say, PHP. <cough>Facebook</cough>
  - aswanson 12y ago
    Good point. FB may be an existence proof that the utility/power of the language, at a certain point, is not necessarily the bottleneck in execution.
    - AnimalMuppet 12y ago
      Can we say this? A startup is more likely to fail because it couldn't iterate fast enough than because it didn't start with a powerful enough platform/stack? If so, then you should pick the platform/stack that lets you iterate the fastest. Consider both your experience and your problem space when making the choice...
    - emodendroket 12y ago
      Is that really the lesson to take away? They have lots of projects that are not in PHP and designed a superset of the language with features it didn't have and their own VM for it, among other things, so, while they may have overcome the issues, I'm not sure that it didn't matter.
- nahushrk 12y ago
  this may be a great way to go about in hackathons where one has very less to loose and success is greatly rewarding. if nothing, at least you learn something new. contrarily, in a startup a lot of things are on bet - money, opportunity, time - or may even mean difference between success and failure. it all boils down to reward-risk tradeoff.
ohashi 12y ago
Seems like an odd caveat. Why would you pick something nobody on the team is good at? Who made that silly decision to begin with. I'd expect at least one person is good/familiar with the language chosen.
- pyre 12y ago
  > Why would you pick something nobody on the team is good at? This is more likely than you may think... "I want to learn Ember.js, so even though I'm proficient at using Angular.js let's write everything in Ember.js instead. Then we can spend months chasing our tail learning all of the 'Gotchas' of Ember.js. Also, just to make things interesting, let's use a bleeding-edge version of Ember.js. Also let's do this at a time when articles on Ember.js that are just 4 months old are already out-dated and no longer apply to the current codebase." Though I doubt that a warning on HN will deter such people.
  - ProAm 12y ago
    It will make a good 'lessons learned' blog post later.
    - pyre 12y ago
      I'm sure that the investors in such ventures are thrilled at the idea of paying developers to spin their wheels for a few months in order to create material for a "lessons learned" blog post.
      - chipsy 12y ago
        sometimes I get the impression that a large portion of software developers act like consumers in their professional lives. Find shiny, try shiny, discard for new shiny. Doesn't matter if it's a personal gadget or something the company is counting on.
        anoother 12y ago
        hammer.strike(nail['head'])
daenz 12y ago
I agree. I've seen an experienced new hire "pick up" a new language, and the result was them writing non-idiomatic, difficult-to-understand code. They know they want to do Z, but they don't know the language's way of doing it, so they do X and Y to get to Z, making it difficult to understand their actual intentions.
- greenyoda 12y ago
  This can be solved with code reviews, in which a developer who is experienced in the language can teach the new developer the right way of doing things. Of course, you shouldn't wait until the new developer has written thousands of lines of incomprehensible code before doing a review.
  - daenz 12y ago
    I totally agree with that, in theory. In practice, sometimes teams can be spread too thinly to allow adequate code reviews, developers can have egos associated with their titles that prohibit constructive criticism, and management can favor "if it looks like it works, it works" style of project delivery. These real world scenarios bias me towards people who know the language they will be using daily.
ChuckMcM 12y ago
Interesting, I read this as being open to hiring good developers even if they don't know your current platform/language. You can train that, and if you have existing expertise then you can pair them with someone who is experienced to teach them the nuances.
- simonw 12y ago
  +1.
- joshred 12y ago
  Your ability to train an employee is going to be hampered by the size of your company. You need someone with both the experience and the time to already be on payroll.
  - balabaster 12y ago
    If that's the case, most companies would just give that person the work to do. If they've already got the time and experience, very few managers [in the real world, at least from my experienced] have the foresight to use that person to train another developer. Usually they'd just give that person the work until there's so much work they can't scale and then someone else would be hired to pick up the shortfall... Of course, the first developer is still so snowed under that they have little to no time to mentor the new guy. So they look for someone who may be experienced in the language but only a mediocre developer by definition. In real world terms, it appears to be expected that a senior developer can just be dumped into the empty seat and get on with it - thus, the expectation also appears to be that this senior developer needs to understand the language and pick up the business knowledge quickly enough to be productive without costing more than absolutely necessary.
- jksmith 12y ago
  If one of the intended features of a language is that it can be picked up quickly, that certainly helps. I'd suggest that this is a feature of golang and historically modula-2.
- talkingquickly 12y ago
cdnsteve 12y ago
I think this point should be: - A good developer is open to any new language or platform and willing to learn.
moron4hire 12y ago
There's also a difference between a really good programmer just starting in a new language and a really bad programmer having 10 years of experience in the language. I'll take the former, please. But really, it's a false dichotomy. No good developer would choose to start a new project in earnest in a new language they don't understand well. They might enter a team that is using a language they don't know yet, and that is what "any good developer can learn a new language quickly" is about. That's all any of this boils down to: are you working with intelligent, thoughtful people who know how to get work done, or are you working with losers? Every. Single. God damn. Tired. Argument. Good people or losers? That X vs. Y technologies "worked" is not data that X is better than Y, it's data that your team is not comprised nearly completely of losers.
- nostrademons 12y ago
  "No good developer would choose to start a new project in earnest in a new language they don't understand well." There are plenty of developers who chose to do just that, eg: PlentyOfFish (started as a weekend project Markus Frind wrote to teach himself .NET). WhatsApp (Jan Koum's previous experience was in C++, but he wrote it in Erlang because the best open-source XMPP server was ejabberd, written in Erlang). Google (You can find Larry Page's questions on how to do URLConnections in Java on UseNet, then it was rewritten in Python by Scott Hassan, then in C++ when it became a real company).
  - moron4hire 12y ago
    Those are clearly weekend projects that took on a life of their own. Hence the qualifying "in earnest" in my post.
    - tim333 11y ago
      Whatsapp certainly wasn't a weekend project that took on a life of it's own. More of a multiyear project where the guy figured he may as well use the best technology because he'd have plenty of time to learn it. From startup school: ..why did you choose Erlang? Jan Koum: Oh. [Laughs] It's one of those intuition, intuition, things. I knew nothing about Erlang and when we - I actually we still don't; we have a lot of our engineers who do - and we actually have like a really small server team, probably seven or eight people supporting our entire user base on the backend, who are insanely brilliant and who wake up in the middle of the night and fix servers. The thing about Erlang is that I was looking for an open source chat server to drop into this backend that we built that could identify which of your contacts are WhatApp's users. I was thinking, we can probably use XMPP, which was an open protocol for messaging, and I was looking for an open source XMPP server and I couldn't find one. There was one written in C, but it was outdated. There was another written in Perl and I knew that wouldn't be able to scale. And then I came across Erlang -- "What is this Erlang thing" and it was the first time I'd heard of it and so I began to research. It turned out to be the best engineering decisions we ever made, by just -- we were forced to because there was nothing else to use. It allowed us to scale really well. It's like built for what we need to do and it's a functional program -- a language that has message passing. It lets you cluster servers into nodes and the others like devalued database that's really cool. It can like synchronize all the data across the servers. We obviously tweaked it a lot internally. We have a couple guys who specialize in tuning Erling, but part of it was like we have no choice. It was the only one available at the time and it works really well for us.
joshmarlow 12y ago
Agreed. I'd say "You can pick up 90% of any language or planform in a few weeks." That last 10% though is some edge-case/deep understanding that you won't even know about until you really need it (and it's probably shown up in production).
- digikata 12y ago
  I think that different languages have their own level of how much edge-case there is in total, as well as how much may be exposed edge there is visible now vs later. It's akin to having icebergs of different volume, but unlike icebergs, also different proportions of 'ice' below and above the water.
deleted 12y ago
[deleted]
cbhl 12y ago
I think the the context of this statement refers to hiring, as opposed to choosing what language/platforms your team should build with. All other things equal, for a startup, I'd rather hire a smart freshman over a middling candidate who had five years' experience with the language/framework I wrote my app in. Plus, there are a number of startups where the speed at which you can "build stuff" is not the limiting reagent towards success. Even if you were the fastest builder in the world, if you don't build the right product, no one will pay you money, and you'll run out of runway. (Dozens of student "startups" out of the University of Waterloo run into this exact problem during every four month term.)
mooreds 12y ago
As someone who just 'picked up' a rails 3 app to add an online order form, I agree that, while you may be able to 'get stuff done', you'll be slower than someone who has experience, no matter how senior you are. At least for a few months. I banged my head against tasks that a RoR developer would have finished far quicker. However, by being willing to train senior folks (and I'm talking my book here, as I am a senior developer), you gain two things: access to a larger pool of applicants, and the value of cross pollination. (I've seen a lot of ORMs in my time, and concepts translate between them.) How to choose whether to train or not? It depends on the length of your runway (longer means you'll have more time, obviously), how many other current folks have knowledge of the solution (and can offer code review or other guidance), how committed the applicant is (tough to judge, but desiring employment vs wanting a contract is a proxy), how far you are pushing what you are building (if it is a normal use case--crud app for rails--a book and a few days may be enough training time. If it is not--high traffic erlang application--you may have a harder time training someone up without extensive partnering), and how hard it is to find someone who has experience with your current technology (there is an opportunity cost to training someone, but there is an opportunity cost to having an empty seat as well). Certainly any senior developer worthy of the name is going to be able to pick up a language and be productive with it in a few weeks. However, they'll make mistakes, just like anyone will, that may require rewriting later. Junior folks are a whole different ballgame.
- tracker1 12y ago
  I have to agree with you... we all go through it. I always considered myself pretty good with JS (very senior), when Node/npm started getting bigger (3-4 years ago), a lot of things really made me feel out of my depth. You get used to it, you observe, learn and adapt. Most of the concepts of application development will always apply, and context is everything. On the flip side, I've met plenty of developers who have absolutely no desire to look at different languages, tools or ideas. To me, that's what is really scary. I can't imagine having that mindset and where I will be in a decade if I did. I just turned 40 a few months back, and feel like I am learning about as much as I did in my 20's. The difference being the objectivity on what to dive deeper into with regards to learning more.
gaius 12y ago
As the old joke goes, a good developer can write FORTRAN in any language.
Pxtl 12y ago
Depends on the platform. To me, that's a big measure of how well-designed a platform is that I can pick it up quickly and stop being bitten by its idiosyncrasies. For example, I've been supporting old ASP.Net Web Forms projects for about a decade and I'm still getting stunned by that damned monstrosity.
emodendroket 12y ago
The famous Norvig piece "Teach Yourself Programming In Ten Years" touches on this: > In 24 hours you might be able to learn some of the syntax of C++ (if you already know another language), but you couldn't learn much about how to use the language. In short, if you were, say, a Basic programmer, you could learn to write programs in the style of Basic using C++ syntax, but you couldn't learn what C++ is actually good (and bad) for. So what's the point? Alan Perlis once said: "A language that doesn't affect the way you think about programming, is not worth knowing". One possible point is that you have to learn a tiny bit of C++ (or more likely, something like JavaScript or Processing) because you need to interface with an existing tool to accomplish a specific task. But then you're not learning how to program; you're learning to accomplish that task.
- jkoudys 11y ago
  I've always liked that quote, because it really goes both ways. We see languages change over time, when we learn what one language is good for and start to incorporate some of that thinking into another. e.g. we're seeing `class` syntax in es6, but that's been present in many other languages for a while. PHP has been adding improved support for `list()`, which is basically its way for managing tuples, something very popular in the Python world. The right way to make this progress isn't by just blindly dumping syntax from one language into another, but by learning many and having it change the way you think.
- kamaal 12y ago
  >>you're learning to accomplish that task. If you are learning anything other than that, you should be in academia not building real world applications. Out there in the industry you don't have 10 years to give towards a specific cause. Given the overall pace of our industry, the rate at which tools are changing, and age related discrimination. In two ten year sprints you will be due for retirement.
  - emodendroket 12y ago
    Our tools keep changing but we're all still relying on the same 50-year-old data structures and algorithms (or, I guess, in many cases, solving the same problems in a less effective way because many of us aren't familiar with them). That one gives me pause. Ten years is an obvious extreme but the point is that hiring managers who try to get people who already know the programming languages and tools their company is using aren't idiots. It's a defensible posture.
lordnacho 12y ago
I thought it meant "as long as s/he has done something similar with a similar tool". Ruby/Python/PHP web CRUD, that kind of thing. I think it's believable, as long as you have at least a few weeks to play around first. As long as designs are similar, it shouldn't be too hard to port. Also, any number of "from X language to Y language" pages exist, and they should give you the most obvious caveats.
deleted 12y ago
[deleted]
whalesalad 12y ago
A good developer + a patient, knowledgable and humble mentor is a winning combo.
guelo 12y ago
In a startup context it doesn't matter, the technical founders should be able to whip something up in whatever tech stack as you're ramping up. Once you have some funding, employee #1 or 2 should be an expert and be able to bring in all the cargo-cult best practices for that tech stack and teach the rest of the team.
nahushrk 12y ago
true. this can be compared with learning math(or any foreign language for that matter). you can have a one page cheat-sheet of all the rules and formulas, but that can only help you solve textbook problems. there are tricks and caveats that are learnt only by practice. googling 'how-to' is a very slow process, even with stackoverflow.
reilly3000 12y ago
I love Rich Hickey's analogy of the language as an instrument. I am a pretty good musician and can make decent sound from most instruments within a few hours. That doesn't mean I can make music with it. For example, the tambourine has over 90 unique sounds it can generate in the hands of a master. Concertos have been written for the instrument. I can do about 3 of them rather poorly. Better to hire experts than polyglots if you want to make a concerto. Actually, it is better to design great software with the advice of great players then let them rock out while you stay out of their way.
deleted 12y ago
[deleted]
mbell 12y ago
I don't think there will be meaningful slowdown from taking a 'good developer' with a lot of experience in Rails and throwing them into Django development. It takes very little time to figure out the proper way to do something when you're already heavily versed in the core concepts and ideas behind what your doing, in this case MVC web development in an OO imperative language. Where this doesn't work as well is when you take a 'good developer' who's worked mostly in C++ writing game engines and throw them into web development using Clojure. It's hard to figure out the proper way to do something when your not even sure what your trying to do, or what terminology to use to efficiently google the question. I think the author is primarily referencing the former situation, not the later.
narrator 12y ago
Picking up a language for me involves reading the O'Reily book cover to cover -- every single word. That way I get familiar enough with the language that I don't spend weeks doing things "the wrong way" just because I'm used to doing things a different way in another language. This, and the initial ramp-up time usually takes a few weeks. For really big languages like modern C++ it would probably take longer than for node or something like that.

ddoolin 12y ago

I'm glad you made this distinction. With enough time, yeah, sure, we can be "good" at any of them, but I've seen companies bring people on without a developed skill set in a particular technology only to find out the ramp-up time to be as efficient as someone familiar with it to be much longer than they bargained for.

m3mnoch 12y ago
agreed. it's really about lifecycle. near the beginning of your startup, you need multi-hat-wearing-swiss-army-knives for developers. once you get traction and growth, you need to bring in vertical expertise.

offwhite 12y ago

I think the point is that a good developer is happy to start using a language/framework because it is the best tool for the job (regardless of their experience using it), rather than just sticking to what they know. I think that's probably more useful in a start up. But I go more for the 'get shit working and see what happens' approach to developing. I mean, making it look pretty is what iterations are for. maybe. or whatever.

jkestner 12y ago
"Best tool for the job" is not a knowable truth. Best for what time frame? For what shifting array of tasks? Often we pick the tool that will be perfect for high performance or a known task, but if you're still figuring out the product, why not make an MVP using what you know? I rarely see anyone fail because they chose, say, PHP. <cough>Facebook</cough>
- aswanson 12y ago
  Good point. FB may be an existence proof that the utility/power of the language, at a certain point, is not necessarily the bottleneck in execution.
  - AnimalMuppet 12y ago
    Can we say this? A startup is more likely to fail because it couldn't iterate fast enough than because it didn't start with a powerful enough platform/stack? If so, then you should pick the platform/stack that lets you iterate the fastest. Consider both your experience and your problem space when making the choice...
  - emodendroket 12y ago
    Is that really the lesson to take away? They have lots of projects that are not in PHP and designed a superset of the language with features it didn't have and their own VM for it, among other things, so, while they may have overcome the issues, I'm not sure that it didn't matter.
nahushrk 12y ago
this may be a great way to go about in hackathons where one has very less to loose and success is greatly rewarding. if nothing, at least you learn something new. contrarily, in a startup a lot of things are on bet - money, opportunity, time - or may even mean difference between success and failure. it all boils down to reward-risk tradeoff.

ohashi 12y ago

Seems like an odd caveat. Why would you pick something nobody on the team is good at? Who made that silly decision to begin with. I'd expect at least one person is good/familiar with the language chosen.

pyre 12y ago
> Why would you pick something nobody on the team is good at? This is more likely than you may think... "I want to learn Ember.js, so even though I'm proficient at using Angular.js let's write everything in Ember.js instead. Then we can spend months chasing our tail learning all of the 'Gotchas' of Ember.js. Also, just to make things interesting, let's use a bleeding-edge version of Ember.js. Also let's do this at a time when articles on Ember.js that are just 4 months old are already out-dated and no longer apply to the current codebase." Though I doubt that a warning on HN will deter such people.
- ProAm 12y ago
  It will make a good 'lessons learned' blog post later.
  - pyre 12y ago
    I'm sure that the investors in such ventures are thrilled at the idea of paying developers to spin their wheels for a few months in order to create material for a "lessons learned" blog post.
    - chipsy 12y ago
      sometimes I get the impression that a large portion of software developers act like consumers in their professional lives. Find shiny, try shiny, discard for new shiny. Doesn't matter if it's a personal gadget or something the company is counting on.
      - anoother 12y ago
        hammer.strike(nail['head'])

daenz 12y ago

I agree. I've seen an experienced new hire "pick up" a new language, and the result was them writing non-idiomatic, difficult-to-understand code. They know they want to do Z, but they don't know the language's way of doing it, so they do X and Y to get to Z, making it difficult to understand their actual intentions.

greenyoda 12y ago
This can be solved with code reviews, in which a developer who is experienced in the language can teach the new developer the right way of doing things. Of course, you shouldn't wait until the new developer has written thousands of lines of incomprehensible code before doing a review.
- daenz 12y ago
  I totally agree with that, in theory. In practice, sometimes teams can be spread too thinly to allow adequate code reviews, developers can have egos associated with their titles that prohibit constructive criticism, and management can favor "if it looks like it works, it works" style of project delivery. These real world scenarios bias me towards people who know the language they will be using daily.

ChuckMcM 12y ago

Interesting, I read this as being open to hiring good developers even if they don't know your current platform/language. You can train that, and if you have existing expertise then you can pair them with someone who is experienced to teach them the nuances.

simonw 12y ago
+1.
joshred 12y ago
Your ability to train an employee is going to be hampered by the size of your company. You need someone with both the experience and the time to already be on payroll.
- balabaster 12y ago
  If that's the case, most companies would just give that person the work to do. If they've already got the time and experience, very few managers [in the real world, at least from my experienced] have the foresight to use that person to train another developer. Usually they'd just give that person the work until there's so much work they can't scale and then someone else would be hired to pick up the shortfall... Of course, the first developer is still so snowed under that they have little to no time to mentor the new guy. So they look for someone who may be experienced in the language but only a mediocre developer by definition. In real world terms, it appears to be expected that a senior developer can just be dumped into the empty seat and get on with it - thus, the expectation also appears to be that this senior developer needs to understand the language and pick up the business knowledge quickly enough to be productive without costing more than absolutely necessary.
jksmith 12y ago
If one of the intended features of a language is that it can be picked up quickly, that certainly helps. I'd suggest that this is a feature of golang and historically modula-2.
talkingquickly 12y ago

cdnsteve 12y ago

I think this point should be: - A good developer is open to any new language or platform and willing to learn.

moron4hire 12y ago

There's also a difference between a really good programmer just starting in a new language and a really bad programmer having 10 years of experience in the language. I'll take the former, please. But really, it's a false dichotomy. No good developer would choose to start a new project in earnest in a new language they don't understand well. They might enter a team that is using a language they don't know yet, and that is what "any good developer can learn a new language quickly" is about. That's all any of this boils down to: are you working with intelligent, thoughtful people who know how to get work done, or are you working with losers? Every. Single. God damn. Tired. Argument. Good people or losers? That X vs. Y technologies "worked" is not data that X is better than Y, it's data that your team is not comprised nearly completely of losers.

nostrademons 12y ago
"No good developer would choose to start a new project in earnest in a new language they don't understand well." There are plenty of developers who chose to do just that, eg: PlentyOfFish (started as a weekend project Markus Frind wrote to teach himself .NET). WhatsApp (Jan Koum's previous experience was in C++, but he wrote it in Erlang because the best open-source XMPP server was ejabberd, written in Erlang). Google (You can find Larry Page's questions on how to do URLConnections in Java on UseNet, then it was rewritten in Python by Scott Hassan, then in C++ when it became a real company).
- moron4hire 12y ago
  Those are clearly weekend projects that took on a life of their own. Hence the qualifying "in earnest" in my post.
  - tim333 11y ago
    Whatsapp certainly wasn't a weekend project that took on a life of it's own. More of a multiyear project where the guy figured he may as well use the best technology because he'd have plenty of time to learn it. From startup school: ..why did you choose Erlang? Jan Koum: Oh. [Laughs] It's one of those intuition, intuition, things. I knew nothing about Erlang and when we - I actually we still don't; we have a lot of our engineers who do - and we actually have like a really small server team, probably seven or eight people supporting our entire user base on the backend, who are insanely brilliant and who wake up in the middle of the night and fix servers. The thing about Erlang is that I was looking for an open source chat server to drop into this backend that we built that could identify which of your contacts are WhatApp's users. I was thinking, we can probably use XMPP, which was an open protocol for messaging, and I was looking for an open source XMPP server and I couldn't find one. There was one written in C, but it was outdated. There was another written in Perl and I knew that wouldn't be able to scale. And then I came across Erlang -- "What is this Erlang thing" and it was the first time I'd heard of it and so I began to research. It turned out to be the best engineering decisions we ever made, by just -- we were forced to because there was nothing else to use. It allowed us to scale really well. It's like built for what we need to do and it's a functional program -- a language that has message passing. It lets you cluster servers into nodes and the others like devalued database that's really cool. It can like synchronize all the data across the servers. We obviously tweaked it a lot internally. We have a couple guys who specialize in tuning Erling, but part of it was like we have no choice. It was the only one available at the time and it works really well for us.

joshmarlow 12y ago

Agreed. I'd say "You can pick up 90% of any language or planform in a few weeks." That last 10% though is some edge-case/deep understanding that you won't even know about until you really need it (and it's probably shown up in production).

digikata 12y ago
I think that different languages have their own level of how much edge-case there is in total, as well as how much may be exposed edge there is visible now vs later. It's akin to having icebergs of different volume, but unlike icebergs, also different proportions of 'ice' below and above the water.

deleted 12y ago

[deleted]

cbhl 12y ago

I think the the context of this statement refers to hiring, as opposed to choosing what language/platforms your team should build with. All other things equal, for a startup, I'd rather hire a smart freshman over a middling candidate who had five years' experience with the language/framework I wrote my app in. Plus, there are a number of startups where the speed at which you can "build stuff" is not the limiting reagent towards success. Even if you were the fastest builder in the world, if you don't build the right product, no one will pay you money, and you'll run out of runway. (Dozens of student "startups" out of the University of Waterloo run into this exact problem during every four month term.)

mooreds 12y ago

As someone who just 'picked up' a rails 3 app to add an online order form, I agree that, while you may be able to 'get stuff done', you'll be slower than someone who has experience, no matter how senior you are. At least for a few months. I banged my head against tasks that a RoR developer would have finished far quicker. However, by being willing to train senior folks (and I'm talking my book here, as I am a senior developer), you gain two things: access to a larger pool of applicants, and the value of cross pollination. (I've seen a lot of ORMs in my time, and concepts translate between them.) How to choose whether to train or not? It depends on the length of your runway (longer means you'll have more time, obviously), how many other current folks have knowledge of the solution (and can offer code review or other guidance), how committed the applicant is (tough to judge, but desiring employment vs wanting a contract is a proxy), how far you are pushing what you are building (if it is a normal use case--crud app for rails--a book and a few days may be enough training time. If it is not--high traffic erlang application--you may have a harder time training someone up without extensive partnering), and how hard it is to find someone who has experience with your current technology (there is an opportunity cost to training someone, but there is an opportunity cost to having an empty seat as well). Certainly any senior developer worthy of the name is going to be able to pick up a language and be productive with it in a few weeks. However, they'll make mistakes, just like anyone will, that may require rewriting later. Junior folks are a whole different ballgame.

tracker1 12y ago
I have to agree with you... we all go through it. I always considered myself pretty good with JS (very senior), when Node/npm started getting bigger (3-4 years ago), a lot of things really made me feel out of my depth. You get used to it, you observe, learn and adapt. Most of the concepts of application development will always apply, and context is everything. On the flip side, I've met plenty of developers who have absolutely no desire to look at different languages, tools or ideas. To me, that's what is really scary. I can't imagine having that mindset and where I will be in a decade if I did. I just turned 40 a few months back, and feel like I am learning about as much as I did in my 20's. The difference being the objectivity on what to dive deeper into with regards to learning more.

gaius 12y ago

As the old joke goes, a good developer can write FORTRAN in any language.

Pxtl 12y ago

Depends on the platform. To me, that's a big measure of how well-designed a platform is that I can pick it up quickly and stop being bitten by its idiosyncrasies. For example, I've been supporting old ASP.Net Web Forms projects for about a decade and I'm still getting stunned by that damned monstrosity.

emodendroket 12y ago

The famous Norvig piece "Teach Yourself Programming In Ten Years" touches on this: > In 24 hours you might be able to learn some of the syntax of C++ (if you already know another language), but you couldn't learn much about how to use the language. In short, if you were, say, a Basic programmer, you could learn to write programs in the style of Basic using C++ syntax, but you couldn't learn what C++ is actually good (and bad) for. So what's the point? Alan Perlis once said: "A language that doesn't affect the way you think about programming, is not worth knowing". One possible point is that you have to learn a tiny bit of C++ (or more likely, something like JavaScript or Processing) because you need to interface with an existing tool to accomplish a specific task. But then you're not learning how to program; you're learning to accomplish that task.

jkoudys 11y ago
I've always liked that quote, because it really goes both ways. We see languages change over time, when we learn what one language is good for and start to incorporate some of that thinking into another. e.g. we're seeing `class` syntax in es6, but that's been present in many other languages for a while. PHP has been adding improved support for `list()`, which is basically its way for managing tuples, something very popular in the Python world. The right way to make this progress isn't by just blindly dumping syntax from one language into another, but by learning many and having it change the way you think.
kamaal 12y ago
>>you're learning to accomplish that task. If you are learning anything other than that, you should be in academia not building real world applications. Out there in the industry you don't have 10 years to give towards a specific cause. Given the overall pace of our industry, the rate at which tools are changing, and age related discrimination. In two ten year sprints you will be due for retirement.
- emodendroket 12y ago
  Our tools keep changing but we're all still relying on the same 50-year-old data structures and algorithms (or, I guess, in many cases, solving the same problems in a less effective way because many of us aren't familiar with them). That one gives me pause. Ten years is an obvious extreme but the point is that hiring managers who try to get people who already know the programming languages and tools their company is using aren't idiots. It's a defensible posture.

lordnacho 12y ago

I thought it meant "as long as s/he has done something similar with a similar tool". Ruby/Python/PHP web CRUD, that kind of thing. I think it's believable, as long as you have at least a few weeks to play around first. As long as designs are similar, it shouldn't be too hard to port. Also, any number of "from X language to Y language" pages exist, and they should give you the most obvious caveats.

deleted 12y ago

[deleted]

whalesalad 12y ago

A good developer + a patient, knowledgable and humble mentor is a winning combo.

guelo 12y ago

In a startup context it doesn't matter, the technical founders should be able to whip something up in whatever tech stack as you're ramping up. Once you have some funding, employee #1 or 2 should be an expert and be able to bring in all the cargo-cult best practices for that tech stack and teach the rest of the team.

nahushrk 12y ago

true. this can be compared with learning math(or any foreign language for that matter). you can have a one page cheat-sheet of all the rules and formulas, but that can only help you solve textbook problems. there are tricks and caveats that are learnt only by practice. googling 'how-to' is a very slow process, even with stackoverflow.

reilly3000 12y ago

I love Rich Hickey's analogy of the language as an instrument. I am a pretty good musician and can make decent sound from most instruments within a few hours. That doesn't mean I can make music with it. For example, the tambourine has over 90 unique sounds it can generate in the hands of a master. Concertos have been written for the instrument. I can do about 3 of them rather poorly. Better to hire experts than polyglots if you want to make a concerto. Actually, it is better to design great software with the advice of great players then let them rock out while you stay out of their way.

deleted 12y ago

[deleted]

mbell 12y ago

I don't think there will be meaningful slowdown from taking a 'good developer' with a lot of experience in Rails and throwing them into Django development. It takes very little time to figure out the proper way to do something when you're already heavily versed in the core concepts and ideas behind what your doing, in this case MVC web development in an OO imperative language. Where this doesn't work as well is when you take a 'good developer' who's worked mostly in C++ writing game engines and throw them into web development using Clojure. It's hard to figure out the proper way to do something when your not even sure what your trying to do, or what terminology to use to efficiently google the question. I think the author is primarily referencing the former situation, not the later.

narrator 12y ago

Picking up a language for me involves reading the O'Reily book cover to cover -- every single word. That way I get familiar enough with the language that I don't spend weeks doing things "the wrong way" just because I'm used to doing things a different way in another language. This, and the initial ramp-up time usually takes a few weeks. For really big languages like modern C++ it would probably take longer than for node or something like that.