I would like to know what other developers do when a situation arises to implement a couple of features in language unknown to you.

You are familiar with Javascript, and you do not know jquery, how do you go by implementing some features in jquery assuming you have not much time.

  • 3
    btw: jQUERY isn't a language, it is a library to supplement the functionality of JavaScript. – JohnFx Oct 8 '10 at 2:17
  • you mean there's another way than to just go out and get your hands dirty? – jwenting Feb 21 '11 at 13:17
  • I agree. Surely if you know Javascript, JQuery should be relatively easy – Richard Feb 21 '11 at 13:19
  • Perhaps a bad example from OP. – Chris Feb 21 '11 at 14:01

I know this is not great advice, but my take on the issue is:

Just do it.

Do it the best you can, and try to have a mindset in which you consider trying new things the rule instead of an unfortunate exception.

Don't worry too much about not knowing what is the best way of doing things, your goal at this stage is just getting things done. You can later (hopefully not much later) analyze how others would have done it and compare.

More specific techniques I find useful:

  • Try to look for lots, and lots of example code written by people more experienced in the technology.

  • Set up a rapid prototyping environment that makes it easy for you to try quick and dirty pieces of code to see what works and what doesn't. This could be a unit testing framework, a REPL interpreter, an existing sample application that you can modify.

  • Set up from the beginning a source control system to store every piece of code you write, specially all the experiments you are going to be writing so you can refer to them later.

  • Try to find the best book on the subject and buy it. Read it in the bus, during breakfast or lunch, at the movies.. everywhere.

  • Look for the forums, IRC channels, mailing list where the experts hang out and try to browse the archives reading random conversations just to familiarize with the kind of topics that are common with the technology.

| improve this answer | |

Google it.*

*Note: In order for this to work, you need to try to learn abstract concepts as a developer in order to know what to Google, as opposed to just learning how to do something in a particular way. Learn how things work, not just that they work.

| improve this answer | |
  • 2
    +1 and also maybe learn how to write good search queries in google using advanced search ;) – user2567 Oct 8 '10 at 6:05
  • 1
    @Pierre You'd be surprised at the number of my classmates who ask Google questions. I.e., "How do I make my program draw a rectangle?" – Maxpm Feb 21 '11 at 7:09
  • 1
    In my last job interview, I was asked how I'd approach a particular problem, and my answer was, "With Google at my side!". I got the job. – Dan Ray Feb 21 '11 at 13:30

Google, Google like the wind.

There is so much code out there you are very likely to find something you can manipulate clumsily into what you need for a small project until you learn to do it right.

| improve this answer | |

Come up with an environment that makes it very easy to do these three things:

  1. Execute a small snippet of code and see the results
  2. Debug something that's broken
  3. Test something that seems to be working

For instance, if I were going to go write something in Erlang tomorrow, I would:

  1. Google {repl erlang}; if I can't find one, set one up
  2. Google {debug erlang} and look for (a) a download of the standard debugger for the language, and (b) a screencast which shows someone using it
  3. Google {unit test erlang} and figure out if there is some kind of commonly-used test framework I can write a little automation in

(Of course, I left out 0.: Google {erlang tutorial} to find instructions on installing an Erlang interpreter and hopefully some sample code. Hopefully that one's obvious.)

If you can optimize these parts of your process - and you usually (always?) can - you'll get a lot of trial and error done really quickly. Trial and error is what allows you to learn new languages.

| improve this answer | |

For me, how I work in unfamiliar environments depends on the time pressure I'm under:

  1. If I'm under a lot of pressure, I'll just dig in. I'll start with a mental design in an idiom I'm familiar with and try to more-or-less translate that into the new environment. I'll google each little stumbling block until I get something working. This method is far from ideal, and it will produce code I'm very likely to curse later if the impedance mismatch is too large. It's also not a good way to learn, in my opinion.

  2. If I have less pressure, I'll do more preparatory study. I'll read documentation, go through tutorials, explore the language, and try to get a feel for its idioms and conventions. Then I'll code. I'll still make design mistakes, but they likely won't be as bad or as pervasive as those that happen in a rush situation. In my opinion, this is the right way to learn.

| improve this answer | |

Dig in and get dirty but try not to leave a mess. Try to find good examples at sites you trust and if you can try to talk to someone that is experienced in the technology and run your design by them... you could have someone peer review your code too. Don't just settle with the first thing you get to work, question if there is a different way you should consider.

| improve this answer | |