5 ms·

I think companies need to do a better job of listing what technologies they use without making it sound like it's required to have mastered all of them. People

I think companies need to do a better job of listing what technologies they use without making it sound like it's required to have mastered all of them. People who've taken Haskell or even Scala into prime-time production are extremely rare. People who would be excited to try, and who could be trained up into that role are a lot more common. I'm getting to the point where I'm realizing that I'm only going to grow as a software engineer if I'm extremely selective about the work I take. I'd go into management before I'd work in Java or C++ full-time. (Of course, I'll use these languages if small projects require it, but if you're a "Java shop" I'm not interested.) I wrote about this effect here: http://michaelochurch.wordpress.com/2012/01/24/how-any-software-company-can-cross-the-developer-divide/ http://michaelochurch.wordpress.com/2012/01/24/how-any-softw... . It's long, but the TL;DR of it is that it's very easy for a company to become good at hiring if it gets its core technologies right.

mmahemoff 15y ago
"I think companies need to do a better job of listing what technologies they use without making it sound like it's required to have mastered all of them." A good way to do this is a humans.txt, whose purpose is not just to credit the developers but also the technologies in use. It's funny that a lot of companies are crazy about hiring right now, but haven't taken 30 minutes to add this simple file to their web server.
scott_s 15y ago
I'd go into management before I'd work in Java or C++ full-time. I suspect that statement is more absolute than you intend it to be. Would you not work on a new language if the compiler for that language generated C++, which meant that the language's runtime was implemented in C++? Which, of course, implies that you will have to write a decent amount of C++ code. If you would work on such a project, then I suspect you mean "If the problem and solution itself are not novel, then I have no interest in using Java and C++."
- michaelochurch 15y ago
  Fair point. Actually, you've nailed it. C++, for example, isn't some horrible language without purpose. It has a niche that it fills well (although I'd prefer C) but most C++ jobs aren't in that niche. My experience is that language adjustment is up to a 0.5-point drop (the scale is here: http://michaelochurch.wordpress.com/2012/01/26/the-trajectory-of-a-software-engineer-and-where-it-all-goes-wrong/ http://michaelochurch.wordpress.com/2012/01/26/the-trajector... ) in an engineer's ability. This is on a 3.0 scale where most engineers are between 1.0 and 2.0, so that's a huge change. Compensation tends to be linear in proficiency but exponential in value-add. 0.5 points is about $50,000 in market pay but a 2-4x (depending on the type of company) difference in productivity. Sometimes it is worth the drop, such as when one's learning a dramatically new and more effective approach, or solving a fresh class of problem (e.g. real-time software, which is done in C). That isn't the case with enterprise, "pattern"-afflicted Java. Instead of solving the problem appropriately and well because I know how to do it, I have solve problems inappropriately and badly because I don't know the crappy idioms that people invented because they don't have appropriate tools. On that scale above, I put myself around a 1.7. If I set foot in a typical C++ or Java shop, I'd drop to 1.2 or 1.3. Which means I'd risk falling to the level of a junior programmer and being typecast that way. Which means I wouldn't get the benefit of the doubt if I say, "This project wouldn't be complete shit if we'd done it in an FP language" (in some nicer words, of course). Your first 6 months determine whether you have technical credibility or not. If you don't, you can't blame the tools, even if bad tools are (as they often are) the cause of the problem. The unenlightened tend to think of all tools as equally good (all languages are Turing complete). No, not so. A 3x difference in CPU performance may not matter for most problems, but the 3x difference in human performance that hinges on whether one uses the wrong tools certainly does. The drop to 1.2 is something I'd tolerate if moving to something genuinely interesting, knowing it'd only take a year to pop back up to the same or even higher level. An example might be high-performance C++ in weather forecasting, bioinformatics, or artificial intelligence. I'd gladly become a junior again for a year for that kind of stuff. On the other hand, most enterprise Java/C++ bullshit isn't really worth learning, not for a creature that has 60 years left to live instead of 600,000 (#ShitYouCantSayAtWork). So yes, my language bigotry is more directed at the typical C++ or Java job than at the language itself.
  - 15y ago
matwood 15y ago
I'd go into management before I'd work in Java Tried that. Now I'm back coding Java, Groovy, JS and looking into Scala. The perfect management role for me is one where I can shape product direction, mentor some younger guys, and still code. The problem is that in all the companies I've seen, management ends up being I sit in meetings all day and get completely cut off from coding or even having deeper tech discussions. I just don't feel like I'm still creating at that point.
- SoftwareMaven 15y ago
  What you describe is what has kept me in my current position. It takes a small company to make it happen, though.
gtani 15y ago
Interesting read: skimmed/bookmarked. I think it's the 2 surfers outpaddling the shark scenario: you don't have to be great at hiring, just slightly better than other companies in your demographic(geographic and "itch yoru scratching". You do have to be great at dev retention.
eli_gottlieb 15y ago
>People who've taken Haskell or even Scala into prime-time production are extremely rare. Not that rare, actually. I have a hard time finding companies that want to use Scala.
- anonymoushn 15y ago
  I currently write Scala at work. As far as I can tell, it's a lot like C or C++, except that you have to use while loops instead of for loops and you have to perform unholy incantations to fake arrays of structs. If you don't do this, you can either try to allocate a few hundred million tuples and OutOfMemoryError, or you can allocate one array of a primitive for each field of the struct and give up on the idea of having decent cache locality. It's less capable of TCO than gcc, which is pretty hilarious for a functional programming language. Generic programming in Scala is lots of fun until you try to use an Ordering[Double] or an ArrayBuffer[Double] in a critical path. Manageable parallelism is nice, though.
  - soc88 15y ago
    Almost every problem you mention is a problem of the underlying runtime. Are you sure you bash the right thing?
    - anonymoushn 15y ago
      This is true. The only things that are trivial to fix are the absence of for loops and the use of ArrayBuffer[AnyRef] to implement ArrayBuffer[Double]. It might also be possible to make TCO of mutually recursive final methods work, but it's probably more trouble than it's worth.
      - soc88 15y ago
        Aren't for loops already fixed since months? (see https://github.com/scala/scala/commit/4cfc633fc6cb2ab0f473c2e5141724017d444dc6 https://github.com/scala/scala/commit/4cfc633fc6cb2ab0f473c2...) Regarding ArrayBuffer: It is not as easy as it looks like, because of the conflicting nature of Arrays vs. Generics (yet another JVM problem). Amusingly I tried using Manifests to do exactly that last week. I hit the wall because the Manifests seemed to spread arbitrarily. Will try with TypeTags/macros when they become available.

mmahemoff 15y ago

"I think companies need to do a better job of listing what technologies they use without making it sound like it's required to have mastered all of them." A good way to do this is a humans.txt, whose purpose is not just to credit the developers but also the technologies in use. It's funny that a lot of companies are crazy about hiring right now, but haven't taken 30 minutes to add this simple file to their web server.

scott_s 15y ago

I'd go into management before I'd work in Java or C++ full-time. I suspect that statement is more absolute than you intend it to be. Would you not work on a new language if the compiler for that language generated C++, which meant that the language's runtime was implemented in C++? Which, of course, implies that you will have to write a decent amount of C++ code. If you would work on such a project, then I suspect you mean "If the problem and solution itself are not novel, then I have no interest in using Java and C++."

michaelochurch 15y ago
Fair point. Actually, you've nailed it. C++, for example, isn't some horrible language without purpose. It has a niche that it fills well (although I'd prefer C) but most C++ jobs aren't in that niche. My experience is that language adjustment is up to a 0.5-point drop (the scale is here: http://michaelochurch.wordpress.com/2012/01/26/the-trajectory-of-a-software-engineer-and-where-it-all-goes-wrong/ http://michaelochurch.wordpress.com/2012/01/26/the-trajector... ) in an engineer's ability. This is on a 3.0 scale where most engineers are between 1.0 and 2.0, so that's a huge change. Compensation tends to be linear in proficiency but exponential in value-add. 0.5 points is about $50,000 in market pay but a 2-4x (depending on the type of company) difference in productivity. Sometimes it is worth the drop, such as when one's learning a dramatically new and more effective approach, or solving a fresh class of problem (e.g. real-time software, which is done in C). That isn't the case with enterprise, "pattern"-afflicted Java. Instead of solving the problem appropriately and well because I know how to do it, I have solve problems inappropriately and badly because I don't know the crappy idioms that people invented because they don't have appropriate tools. On that scale above, I put myself around a 1.7. If I set foot in a typical C++ or Java shop, I'd drop to 1.2 or 1.3. Which means I'd risk falling to the level of a junior programmer and being typecast that way. Which means I wouldn't get the benefit of the doubt if I say, "This project wouldn't be complete shit if we'd done it in an FP language" (in some nicer words, of course). Your first 6 months determine whether you have technical credibility or not. If you don't, you can't blame the tools, even if bad tools are (as they often are) the cause of the problem. The unenlightened tend to think of all tools as equally good (all languages are Turing complete). No, not so. A 3x difference in CPU performance may not matter for most problems, but the 3x difference in human performance that hinges on whether one uses the wrong tools certainly does. The drop to 1.2 is something I'd tolerate if moving to something genuinely interesting, knowing it'd only take a year to pop back up to the same or even higher level. An example might be high-performance C++ in weather forecasting, bioinformatics, or artificial intelligence. I'd gladly become a junior again for a year for that kind of stuff. On the other hand, most enterprise Java/C++ bullshit isn't really worth learning, not for a creature that has 60 years left to live instead of 600,000 (#ShitYouCantSayAtWork). So yes, my language bigotry is more directed at the typical C++ or Java job than at the language itself.
- 15y ago

matwood 15y ago

I'd go into management before I'd work in Java Tried that. Now I'm back coding Java, Groovy, JS and looking into Scala. The perfect management role for me is one where I can shape product direction, mentor some younger guys, and still code. The problem is that in all the companies I've seen, management ends up being I sit in meetings all day and get completely cut off from coding or even having deeper tech discussions. I just don't feel like I'm still creating at that point.

SoftwareMaven 15y ago
What you describe is what has kept me in my current position. It takes a small company to make it happen, though.

gtani 15y ago

Interesting read: skimmed/bookmarked. I think it's the 2 surfers outpaddling the shark scenario: you don't have to be great at hiring, just slightly better than other companies in your demographic(geographic and "itch yoru scratching". You do have to be great at dev retention.

eli_gottlieb 15y ago

>People who've taken Haskell or even Scala into prime-time production are extremely rare. Not that rare, actually. I have a hard time finding companies that want to use Scala.

anonymoushn 15y ago
I currently write Scala at work. As far as I can tell, it's a lot like C or C++, except that you have to use while loops instead of for loops and you have to perform unholy incantations to fake arrays of structs. If you don't do this, you can either try to allocate a few hundred million tuples and OutOfMemoryError, or you can allocate one array of a primitive for each field of the struct and give up on the idea of having decent cache locality. It's less capable of TCO than gcc, which is pretty hilarious for a functional programming language. Generic programming in Scala is lots of fun until you try to use an Ordering[Double] or an ArrayBuffer[Double] in a critical path. Manageable parallelism is nice, though.
- soc88 15y ago
  Almost every problem you mention is a problem of the underlying runtime. Are you sure you bash the right thing?
  - anonymoushn 15y ago
    This is true. The only things that are trivial to fix are the absence of for loops and the use of ArrayBuffer[AnyRef] to implement ArrayBuffer[Double]. It might also be possible to make TCO of mutually recursive final methods work, but it's probably more trouble than it's worth.
    - soc88 15y ago
      Aren't for loops already fixed since months? (see https://github.com/scala/scala/commit/4cfc633fc6cb2ab0f473c2e5141724017d444dc6 https://github.com/scala/scala/commit/4cfc633fc6cb2ab0f473c2...) Regarding ArrayBuffer: It is not as easy as it looks like, because of the conflicting nature of Arrays vs. Generics (yet another JVM problem). Amusingly I tried using Manifests to do exactly that last week. I hit the wall because the Manifests seemed to spread arbitrarily. Will try with TypeTags/macros when they become available.