Nomadic programming | Hacker News Reader

Nomadic programming

edofic.com

18 pointsjoss8215 comments

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!"

> 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.

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.

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.

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.

Oh you will be suprised!

I think that some people suffer from a fear of learning something new and pushing the boundaries of their knowledge out further.

>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?

Absolutely, there are. I think hanging out on Hacker News probably skews our perception of this, but most programmers know one or two languages that they learned in school and use them for everything because that's what they know. Most people don't learn the intricacies of a bunch of different languages and platforms and choose whichever one seems suited for the job; they choose to use what they know.

Most companies choose a stack and keep it. Developers don't even get a say.

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.

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

Jack of all trades, master of none

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.

You're correct. I'm wrong.

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

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).

> 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".

Reply on news.ycombinator.com