
Nomadic programming - joss82
http://www.edofic.com/2012/11/nomadic-programming.html
======
noelwelsh
Much as I love the thesis of this post (I love it's formatting much much less
-- more paragraphs breaks please) I don't agree that it is in fact possible to
be an omni-competent generalist. Switching between Rails and Django is
definitely pretty easy, but that experience isn't going to help you switch to,
say, programming DSPs, or designing streaming algorithms, or architecting
massively concurrent systems. There definitely is specialisation, and if you
don't see it it's because you're blind to the box you're currently living in.

Total agreement with "You should always strive to become better!"

~~~
delwin
> You're blind to the box you're currently living in.

I definitely feel this all the time. Just about the time I start feeling
comfortable building webapps, I step back and see _all the programming_ I'm
not doing. Writing webapps in Ruby, Python, PHP, JavaScript in any number of
flavors (Rails, Django, Flask, web.py, node, Backbone) still has the same
feel, because it's all for the web; there's a common goal.

"Sprachgefühl" is perhaps a useful word here — having a "feel" for languages
is all you need to start learning new ones. It's even truer for programming
than it is for natural languages.

------
Swizec
I know edofic and he's a cool guy, but man was I disappointed to find out this
essay isn't about taking a laptop and traveling country to country while
solving cool engineering problems remotely from random coffee shops and hotel
rooms.

To be honest, I am a bit confused. Are there _really_ people out there who
don't switch stacks at a whim's notice? Whenever the job might be done better
in a different technology?

This is a great time to be an expert generalist.

~~~
elemeno
If you work on sufficiently large projects or in enterprise there's a high
cost in switching stacks even if a particular project could be done better in
a different technology. When all your software runs on the same stack, or on a
limited number of stacks, there's less friction - it's easier for people to
move between stacks, it's easier for different projects to work together, it's
easier to use all the libraries which have already been written etc.

~~~
_delirium
Even as an individual there's considerable friction in switching imo, though
it's not as insurmountable, and comes with the added benefit/fun of learning
something new. The conceptual part is not that bad, and is the _most_
interesting: learning a new language/approach/framework that takes a new
general approach to things, e.g. learning a functional language for the first
time. But there's a lot of more "accidental" knowledge that takes a long time
to pick up and has more to do with becoming familiar with a
language's/framework's idioms, warts, best practices, common pitfalls, good
solutions to those pitfalls, etc.

Particularly true for debugging, at least for me. I'm a _lot_ faster at
debugging in settings where I've accumulated a lot of experience, just because
there are a lot more cases where I instantly recognize exactly what's
happening and how to fix it.

------
hudell
I worked for 7 years with the same language and tools, but lately, I can't
tell which language I'll be using next week. And I love this.

But if I hadn't been a specialist in something at some point of my life, I
don't believe I would be writing good code in those new languages. And I still
think it's better to have at least some specialists on the team too, because
sometimes you get some bizarre bugs that someone that knows the language for
some time may be used to.

------
cousin_it
Yossi Kreinin wrote a good essay on that topic in 2009:
<http://www.yosefk.com/blog/the-nomadic-programmer.html>

------
acuozzo
Jack of all trades, master of none

~~~
delwin
No, that's not apt at all. The "trade" isn't C, Java, Ruby, Python, whatever.
The "trade" is solving problems with computers. Usually the same types of
problems.

~~~
acuozzo
You're correct. I'm wrong.

With that being said, how does his approach work for, e.g., writing software
for airplanes?

~~~
jamesjporter
In the spirit of noelwelsh's comment above, we could say that the "trades" are
things like "writing webapps" or "writing control software or airplanes" or
"writing simulations of chemical systems."

"Solving problems with computers" is too broad for any one person to master
all aspects of it. There are so many different kinds of problems! Many of them
also involve domain specific knowledge that has nothing to do with computers
or computation (my airplanes and scientific computing examples above).

~~~
acuozzo
> we could say that the "trades" are things like "writing webapps" or "writing
> control software or airplanes"

People don't usually __die__ as the result of a bug in a webapp, but they can
as the result of a bug in airplane software. I claim that a NomadicProgrammer™
(armed with "Learn Ada in 24 hours!", of course) would be __dangerous__ if
tasked with work in this "trade".

