[JackMorgan]

I have been writing and rewriting a post for the better part of a year on this same thing. I think I've finally accepted that a majority of programmers actually are not interested in learning new things.

I got into software because there was so much to learn and explore, so this realization still baffles me. Why on earth would someone want to do this job and not want to learn new things? It's like a baseball player who hates being outside.

Not only that, but often times I'm faced with the prospect like the author's, where people I've worked with actively prevent those around them from learning new things on the job. "No, don't write this standalone module in Python, our standard is PHP; it was good enough 5 years ago, it's good enough now!" (in a four man shop).

As someone who loves constantly learning more, it's suffocating to be around people who are so paralyzed. I simply cannot fathom the fear that drives someone to say to the offer to learn something new on the job, "no thanks, I'm happy becoming obsolete, and you can't learn it either, because I might have to one day support it, and I'm not interested in learning anything new!"

[zzzcpan]

No, they are interested, learning is fun for them too. But not everyone is interested in learning the same things you are. For me, for example, there is absolutely nothing more boring, than some new fancy framework, API or a language. I am, however, very excited to try things that might reduce amount of bugs and potential security issues in my code, make it cheaper to run, cheaper to support.

[JackMorgan]

So long as you don't have to learn a language, API, or framework to do it... I'm not sure what things are left you could do differently? Your list excludes all technology-related changes, so the rest becomes meta-activities: pair programming, documentation, planning, a good nights sleep, etc. Those are excellent, but I'm curious why are you willing to change those other areas but are resistant to technological ones?

That irrational fear of technological change is exactly what I'm talking about. There's a joke around some of my friends, "What's the best way to get a mediocre .NET programmer to stop talking about safety and reducing bugs? Bring up the safest most secure .NET language that exists: F#."

As the joke goes, most of these developers are confronted with the reality that they don't really care about bugs enough to even bother learning a different fully supported .NET language that will find entire classes of bugs automatically and is orders of magnitude safer than C# and is faster to write.

Most people when they have told me they "care about bugs, not languages" have been just saying something nebulous to kill the discussion and defend their life choices.

I'm not trying to be snarky to you, I'm actually very interested to know what changes you've made that are not technological to reduce bugs, fix security holes, etc. I'm always on the prowl for such stuff, and this sounds intriguing.

[RogerL]

Let's see, I'm learning about unscented Kalman filters, moving object tracking in computer vision, PCA, and more. I'm learning about the problem domain that I'm working in. I have no interest in learning yet another API unless I absolutely have to, because it isn't really interesting knowledge that I have to call the fibble() function before calling xacxtyor() in this poorly documented API. That's not learning, it's the accumulation of facts.

Of course, sometimes learning new API/languages enables meaningful learning, and I'm all for it. Want to quickly get a handle on Kalman Filters? Probably a lot faster to put something together with numpy (say) and experiment on the REPL than to program it in a performant language like C or C++, even if that is where it will eventually end up running in your project. So, yes, there's a great reason to learn those languages (or Julia, or whatever).

But the endless march of APIs is pretty tiring to me, and I do everything I can to isolate myself from that. I'm pretty happy writing my C++, and Python (2.7, btw), while trying to solve rather hard problems.

Another way to put it - what I value is intellectual work, not memorization/puzzling things out. Learn a new math technique? Awesome! Learn a byzantine set of calls I need to make to make a widget widge on the screen? Not so much.

[JackMorgan]

Well it sounds like you have no qualm learning the right tool for the job. I would consider numpy to be an API, but the difference here is it's one that helps you with your domain. If widging widges was your domain I'd expect the professional thing to do would be for you to learn that API. I'm talking about people who in your job wouldn't bother with Julia or numpy and would just trundle along with C.

[noelwelsh]

This is great, but it's not addressing the point, which is "I am, however, very excited to try things that might reduce amount of bugs and potential security issues in my code, make it cheaper to run, cheaper to support."

Also, if you like math go learn some functional programming. The ideas of abstract algebra, which you will encounter in FP, are increasingly relevant to machine learning as well. E.g. http://jmlr.org/proceedings/papers/v28/izbicki13.pdf

[auvrw]

> But the endless march of APIs is pretty tiring to me

i hear you on that one

> and I do everything I can to isolate myself from that.

but still, you can't stop thinking about design entirely. when a new ideally-pure-C-but-C++-if-you-really-need-stl library is ready to actually be put to use you'll have to put an api of some sort on it. hopefully that api will be informed by your use of other people's apis, both good and bad.

don't forget that the whole point of computers is that they're immediately useful. you can still do most of the math you want with a pencil, paper, and stack of books.

[zzzcpan]

  > I'm not sure what things are left you 
  > could do differently?

There are so many thing that are left - one cannot do them in a lifetime! Analyze as much bugs as you can, invent your own language that prevents them from happening, write your own compiler for this language, make it fast, with better memory management, not some stop-the-world GC, but with something, that honors low-latency and so on.

EDIT: As RogerL is saying, useful to me intellectual knowledge is what I want to learn. It's pretty much never the same thing as anyone else in the room wants to learn.

[JackMorgan]

So clearly you are not the class of person I have ever dealt with in the past. It would be an incredible breath of fresh air to work with someone who cares enough about their work to write their own compiler for it.

Right now I'm working through SICP, having just finished PLAI, do you have any suggestions for a book on compilers I could do next? I was recently steered away from the dragon book as it's "missing a lot of recent compiler research", but that person had no good alternative.

I think there is definitely three main groups of software people: those that wire together languages and frameworks, those that write languages and frameworks, and those that use a tiny subset of languages to do research. My problem is I think I've been heading down the path of learning that leads more to the second, and you sound like someone who manages to do a job similar to mine, but by being good at that second far more interesting path. I'd be really interested to hear any advice you have. Do you basically have to just work alone?

[playing_colours]

I found this book on compilers to be rather up-to-date, clear and useful when you start going into the topic: http://www.amazon.com/Engineering-Compiler-Second-Edition-Co...

[dinkumthinkum]

There are a lot more interesting things in CS than 100 different mvc frameworks and 20 upstart languages that do exactly what LISP did in 1960.

[JackMorgan]

Oh sure, right now I've been deep into Scheme as I just finished PLAI and am halfway through SICP. I'm not chasing every new Perl derivative every six months, but I'm mostly stuck in the day job using C#. It feels constraining to be learning all this awesome about languages and not get to use most of it, hence the desire to sometimes try other languages at work.

What sort of things have you been learning that you would recommend that are off the beaten path of just another mvc framework? I'm thinking of learning about compilers next, but I'd like a book to work through rather than just "the internet". Also I'm trying to catch the type safety bug by working through Real World Haskell, I'm open to other suggestions for that too.

[gaius]

there is absolutely nothing more boring, than some new fancy framework, API or a language

Hear, hear. There must be 100+ "frameworks" out there, all for the task of rendering a web page. If you learnt them all, you would be stupider than when you started. Pick a handful of technologies - ones that will last - and get deep into them. Step off the crazy treadmill and go for quality, not quantity.

If you had gotten into a "full stack" (lol) of Unix, Oracle, C++ in 1994, you would still be very, very employable today as long as you remained more or less current with them, and you'll still be in 2024. Whereas if you learn "frameworks", you'll be starting again from scratch every year or two.

[url404]

What's the best way to determine quality over quantity?

Is it best to wait languages out for a while and see how much they are adopted by others first?

[noelwelsh]

If your main concern is reducing bugs and security issues, then you really should look into modern typed languages like Rust.

[zzzcpan]

I did, doesn't seem to be particularly focused on neither bugs nor security.

[noelwelsh]

Wow, we have a very different reading of Rust.

Safe concurrency and memory management doesn't lead to reduced bugs? Eliminating unsafe memory access doesn't lead to increased security?

[zzzcpan]

You are assuming that most of the languages people use don't have safe automatic memory management, right? This is of course incorrect. Now, lets compare Rust and Go, what makes Rust programs have fewer bugs, than Go programs? Is there any supporting research that shows how Rust eliminates any particular class of high level bugs? No, there isn't. So, no, Rust doesn't focus on eliminating bugs.

[noelwelsh]

I'll make one effort in good faith to answer your questions, though I expect you're not interested in hearing the answer.

There is a class of programs where manual control over memory layout is important. For example, if you're writing an OS, as Mozilla is, you need this control to talk to hardware. It is also important in some domains where performance is important (e.g. games and big data.) Rust is the only language (outside of research) that offers control over memory layout while also providing memory safety. That is, no access to uninitialized memory, etc. This clearly eliminates a huge class of bugs relative to C/C++, the only language with substantial usage in this space.

Race conditions (data races) are considered important enough by the Go developers that they have a tool to detect them: http://blog.golang.org/race-detector In Rust these error cannot happen as programs containing data races cannot compile.

Then there is the usual modern type system stuff of eliminating nulls and so on.

[Derbasti]

A former coworker of mine said it straight out. He said: "I don't want to learn anything new. I'm too old for that.". He is 50, and a terrible C++ programmer, a good assembler guy and quite the hardware wizard. But he refuses to learn anything new. He still can't type with more than four fingers, despite spending half his life programming. He programs object oriented C++, with obvious lack of understanding of almost everything about OOP.

I am baffled by him. After spending two years with him, I still can't understand his motivations. I quit that job in large parts because of him.

[watwut]

Technical decisions should not be made on "which technology sounds cool on CV" basis.

Unless there is strong reason, codebase should be in one language. Having it in multiple languages makes learning curve for newcommers unnecessary steep, especially if the company is willing to hire juniors. It also makes maintenance more difficult and expensive. Too many languages will also force your people to have very shallow knowledge.

We are going to do this one module in python should be done either cause you consider to move to python altogether or because the usual language is really bad fit. "Someone wants to learn it" is both bad reason and unprofessional.

[klibertp]

> Too many languages will also force your people to have very shallow knowledge.

I spent the last 10 years learning programming languages and PLT; it's a hobby of mine and I put quite a lot of effort behind it. While I certainly forget some things I learned (I regret not using C on a daily basis and not keeping with C++ advancements), at any given time during those past ten years I was fluent in at least 3-4 languages. Without needing a refresher, right now I can speak and I really know in depth the following languages: JavaScript, OCaml, Erlang, Racket, Python, LiveScript and Pharo Smalltalk. I have about 20 other languages I could become similarly fluent in with a week's effort. It's not shallow knowledge, it's just 10 years of work. There is really nothing to force you not to have deep understanding of many different languages and technologies.

On the professional side - I have quite big system under my care which is mixed Python, JavaScript, Ruby and Erlang, not to mention bits of C, shell scripts and Makefiles and two compile-to-JS languages, some compile-to-CSS and compile-to-HTML languages. The system works - and believe it or not, working on it is a pleasure and using the right tool for the job really feels liberating. It let's me move twice as quickly with twice as good results than I'd get trying to do for example fault tolerant, concurrent backend service in Python instead of Erlang (or quick data mining script in Erlang instead of Python for that matter).

I believe using the right tool for the job is the very definition of professional. Of course, the learning curve is probably steeper for newcomers, but for professionals above a certain level language specifics are rather easy to grok and becoming fluent in a language takes a few weeks tops. Besides, it's not like every team member is required to know every technology used in a project - there's a tech lead for this and I wouldn't want to work with one who can't easily convert iterative algorithms to tail-recursive ones and switch from algol-like to prolog-like to python(-like) syntax on the fly.

Anyway, I know what I know and I know what I do and you're basically saying that these skills are irrelevant and using them would be unprofessional. In short, what I'm saying in response is: bullshit.

[adamredwoods]

some people feel that their lives do not revolve around programming, that there are other interesting things like traveling and child raising that take a chunk of their ever precious and limited time.

so it's not to say they aren't interested, but rather lack the time to dedicate. therefore, it helps if the company they work for can offer a little time to learn new things.

[JackMorgan]

I'm talking about developers who when offered a chance to learn something new at work reject it, usually while getting pretty defensive.

My current hypothesis is people get so used to internally defending their neglect of the skills that earn them travel and shelter that when the opportunity arises to actually get paid to improve, all the reasons they normally use prevent them from even doing that.

[dinkumthinkum]

I thinks there's truth on both sides of this. There are many blub programmers that know some narrow scope of Java or C# and a little SQL and that's their whole programming life. This is true regardless of age.

[jasonlotito]

> some people feel that their lives do not revolve around programming,

Your life doesn't have to revolve around programming to invest time in advancing your own career.

> so it's not to say they aren't interested

Well, that aren't interested in learning things on their own. You said it yourself.