cdegroot

Indeed. I've seen Macs as an option, and then you sort of get "developers can get Macs, VPs can get them, but others can't" as the TCO is - apparently - higher, and, let's not forget that, remote manageability is way harder than with Windows, which has stuff like group policies, AD integration, etcetera, all built in (the Macs I used at a previous big corp employer had some terribly hack-ish layered software to get to almost the same level).

With Win10 and WSL (which I've been actively testdriving on my personal hardware) I'd be totally fine to get a Lenovo from BigCorpEmployer. For private use, I won't buy any MBPs anymore anyway for the same reason.

Also, IIRC, they were a very early Linux adopter, I think in the '90s one of the largest users. It seems that Ikea has some smart techs on board and that - here comes the actual surprise - they listen to them.

My biggest "surprise" always is how little we have progressed if you just look at how the planes look and how fast they fly (6h11m NY->London in 1958, that's pretty much what they do today, not?). It seems like the airline industry got a lot of stuff just right the first time and since then just has been doing performance tweaks (where I take "performance" to be very broad to include things like safety, economy, ...).

I think I re-implemented rpcgen a couple of times in Ye Olde Days, so it can't be hard. Then DCE came by and then I lost track of serialization protocols that are essentially rehashes of SunRPC/XDR. So yeah, I've been thinking along the same lines as Scott - why?

These days, I've mostly thrown the towel and plunk in JSON everywhere. At least it's hip, and if I ever find a piece of code where the serialization is the bottleneck, early enough to start pushing XDR (not ASN.1 - I once tried to write a parser for _that_ and ended up with some extra grey hairs ;-)).

It's a loss in my books. I like Clojure but pretty much the only thing that's been putting me off is how the JVM "shines" through in lots of aspects.

The JVM indeed quickly got me disinterested in Clojure. However, I have similar issues with other (free) Lisps, with probably only Emacs Lisp being the exception.

As a Smalltalker ("the other heroin of the programming world") I'm used to a highly integrated and responsive development environment; from what I heard from other Lispers, the quick feedback and gradual building up of your program is a shared aspect, but the thing that Smalltalkers always bring up and Lispers less so is also that your program and your IDE are basically indistinguishable, which is quite powerful because it makes it trivial to adapt your IDE to your project as you go. In the Lisp environments I've tried - latest being Emacs+SBLC - the split between editor and REPL seems unnatural to me, more so because in the standard case you work with two different dialects of the language. It seems that only ACL and LW have more unification.

Am I wrong and are the $$$$ versions not better in that respect and should I just drop my Smalltalk habits/arguments when learning CL?

Exactly that. You do agile, you do teamwork is everything, but at the same time you see people perform at more than their pay grade and you want to promote them. Some modicum of objectivity is needed - accomplishments are _mostly_ the team's accomplishments (I guess that is the main reason we all want lunch&learn talks, so you have some individual accomplishments), so looking at skills seems to be a decent next best thing.

I have no clue. I mean, on the one hand I don't like evaluating people by checklists/matrices, but on the other hand - assuming that having to evaluate people for raises and promotions is a given - what's the alternative?

Squeak guy here - I did a lot of prodding around the relicensing and it was pretty much the same situation. An old code base and a license that was "open source" at heart but had problematic language. It's impossible to reach everybody - Squeak has code going back to 1978 I think :-). We got the thumbs up from the main contributors (Kay and friends - in fact, I think it was Alan who started pushing for this), we got the thumbs up from Apple (that took a while but they were very cooperative and nice), we decided that Disney didn't own any of the code (that was a big relief ;-)), and then when we didn't get any objections from major contributors we went ahead and hoped for the best. Law is not mathematics, it's a human endeavour and that makes the application of the rules, however precise they're written, often more messy than we techies are comfortable with. 90% of my encounters with legal stuff is "what are the trade-offs". Ditto here - you trade off the burden of having a shitty license against the vanishingly small risk that some contributor will want to retract its code and live with the decision - if you can show you did your due diligence the impact should be low.

I once drank the Scala cool-aid as well. Even wrote an enthusiastic article about it [1]. Since then, my enthusiasm has been replaced by disappointment: the JVM interop is a lie, as Java libraries often are a bad fit, people won't have time to write the extensive wrapper code needed to hide it, and as a result ugliness starts permeating your codebase - yes, bad, but that's how teams under time pressure work; the multi-paradigm-and-widening (back in 2009, Scala was a smaller language) is one big headache - everyone has an opinion of how you should write code in Scala, so inevitably you spend a lot of time debating features you should or shouldn't use in your teams (instead of writing code. In Elixir, we never have to debate paradigms, we write code); sbt is a sorry mess - no-one understands it and it's slow.

I still think it's a very well designed language, the choice of the JVM+Java ecosystem as the target just has bogged it down with legacy crap like everything else on that environment and the designers should start to make some choices instead of offloading that on every single development team in the world. I think that "single-paradigm" is one of the reason that simple languages that get shit done, like Golang and Elixir, are so successful these days.

Were I bound to the JVM, I'd still give it a good look (not sold on Clojure or Kotlin yet and it _is_ nicer and less frustrating than Maven+Java if you keep it simple); I'm just not married to the JVM so can freely consider other options.

[1] http://www.artima.com/weblogs/viewpost.jsp?thread=260478

I still remember a Google screening call I had a long time ago. "You have 1 petabyte of data you need to transfer halfway the world, what kind of network protocol would you implement for it". I, of course, "a truck/ship/container with tapes?". "No it needs to go through <i think a satellite link>". "Well, lemme see, larger frames, window sizes, capacity of the link becomes sort of the leading issue, but seriously, I'd Google for some papers and take it from there". I found it an extremely strange interview, as it went on like that.

That. Our office office: open plan, glossy Apple monitors with "interesting" light fixtures to make the glare as bad as possible and it's a 45 minute commute away. My home office does not (yet) sport an adjustable desk, but has all the amenities I'd expect in an office. Like a door. I'm so happy I even wrote a quick blog post about it last week :-) http://evrl.com/working/2017/02/08/no-commute.html. It's my office, I like it, and I think that goes back to the author's "control of environment" argument.

I think the problem here is that Scala doesn't make any choices for you. Now you're busy having to do a ton of code reviews to make sure that everyone stays within the chosen paradigm, stuff will of course slip through and bite you, and there you are with one big nice mess. Plus, it's too simple to just pull in a Java library which doesn't mesh well paradigm-wise with what you have (or a Scala library for that matter). I've done a ton of Scala and I've been left with the same conclusion as I had waaaay back with C++ - too many potential solutions, too many pitfalls and ways to make a mess. I guess I'm a person that wants to make the language make the paradigm choice for me and then I'll happily stick with that. One reason I like a language like Elixir so much - the language made the choices, it matches the problem set I work on pretty well, all the libraries look the same, life is simple, I can just write code (instead of trying to understand a moderately complex build.sbt file which basically comes with a paradigm of its own).

It is too bad though that e.g. IntelliJ cannot tell the difference, will offer you the transitive dependency's stuff in code completion, and now you are tied to it. Of course, the thing _you_ used went away in the newer version that the newer version of your direct dependency uses, and now you're spending time figuring out dependencies instead of writing code. Which, in my experience, happens pretty much all the time in Java/Scala land. (and I won't start about the sorry state of build tools for the JVM; seen them all, nothing is as nice as what I'm using now (Elixir/Mix)).

Windows 10 is solid, stable and fast. And runs my games, and Lightroom, and... And now, with Linux Subsystem for Windows, also runs the Ubuntu 14.04 userspace quite well. I've setup the dressed-down version of mintty with VcXsrv for the occasional X11 app, and to my surprise it does what it wants. Now, for most of my day-to-day development I either use Tmux or iTerm2 with tiled terminals or IntelliJ, so YMMV, but I'm actually seriously considering to have my next workstation be on Win10.

One good spot that comes to mind is when you implement "Backend For Frontend" style APIs for your clients in a microservices environment. Assuming you have a single page app in JS, you can have the front-end team own their specific API implementation and have them work in the language they know best. There's often also the possibility to reuse some code between the two.

Apart from that, I'm a JS hater, so I would personally always avoid Node - I neither like the language nor the server-side model, I don't think either one scales well, and there are better solutions out there for the server side (besides the JVM and .NET based stuff in the other comments, I like BEAM-based things like Elixir these days).

pagerduty.com moved to Route53, but the TTL on NS records can be very long. Flushing (restarting, ...) whatever can cache DNS records in your infra will help to quickly pick up the new nameservers.

Personally, I think this is more an indicator that, whatever you do, growth sucks. Semco is most likely still doing well because they have an enormous amount of small subsidiaries.

Something similar happened to Toyota - once the poster child of lean companies, then they wanted to become the largest car producer in the world, the rest is history.

I wonder - maybe it is time to pick up these clues and start being satisfied with working at companies that are fun and stable and stay small?

Fwiw, my current screening is: first resume screening, then I send candidates a simple programming exercise that sort of is in our domain. I can assess the delivered work in around five to ten minutes, so it scales well. Then a further skills/team fit check through interviews, and for those who survive that, the expensive bit: pairing with developers on actual production code.

Especially the exercise works as a good screen. We get quite a number of "deafening silence" responses, which says something about the candidate's motivation. We also get responses where people try to show off alternative language skills but deliver something totally non-idiomatic. And we get good submissions, showing some patterns knowledge, unit testing, at cetera. These typically end up being hired.