runT1ME

I think the idea isn't bad. There are people who want to mentor and people who are in need of mentors, makes sense.

However, I have two main questions:

Does having a person to talk to offer a compelling alternative to a blog post/book etc. that emphasizes the things you just mentioned: "brand that exudes quality, land speaking engagements, push to hit goals" etc. ?

The second question is: what about people who already do that? Will this be mainly geared towards entry level folks looking to go from mediocre jobs to good jobs? What do you have that would entice someone like me (happy with my current job, well paid, an online brand to some degree, does speaking/open source)? Perhaps I am not the target customer?

Hah, so will you tell us the company? Sounds like some of us should be applying there... (though it did seem to make you not want to stay and be a developer there?)

Maybe this is true, but plenty of big companies are hiring tons of engineers... so I don't know how this is true universally.

So you've never worked at those companies, and you are assuming what it's like to work there? And are you claiming you make 500% more than say a senior engineer at G/FB?Am?

Scalaz, Http4 for web stuff, Netty/scalaz-stream otherwise. We really don't need "frameworks" to be insanely productive in Scala, just a few tried and true libraries. This also really helps when jumping into new projects, there's never "magic" beyond just the features the language provides.

I work with some larger Scala codebases too and the compile times are not that bad either. Maybe 30 seconds is more common for the large ones. Certainly not worse than C++, only a bit slower than Java.

>2. Modify your IDE habits to be more REPL friendly

Plenty of people use IDEs, I just think if that's what your main sticking point when picking a language, go with C#. It has the best IDE of any language.

>3. Modify your team coding habits even if it makes it hard for one person to work on the other person's codebase.

Nope, not a problem. I can work on any code base in the company. It's spooky how fast we can jump into others teams projects and contribute, and a lot of that is due to the power of the language.

I work on a large Scala team. We use microservices so my regular compile times are somewhere between 4s and 20s. I rarely have to do a full rebuild.

IDE support is bad, that's a good criticism but a good chunk of us don't use IDEs, and instead write it like a dynamic language. Live inside the REPL, copy paste back and fourth.

As for 'subsets' everyone uses, I find this advantageous. Our team strongly encourages a pure functional style, but we realize not everyone is going to start out that way, and it doesn't get in the way of shipping software.

It's not that there's anything wrong with someone changing their mind. I certainly thought FP was useless ten years ago, java was the best and generally had some bad ideas about software engineering. However, the difference is I had the sense to not blog about things I only had cursory knowledge of while attempting to sound like the ultimate authority on the matter...

Does anyone remember when he wrote this?

http://steve-yegge.blogspot.com/2008/06/rhinos-and-tigers.ht...

And in the comments section he got lit up because he was unfamiliar with Haskell/Scala/OCaml type languages...

and here he is 9 years late to the party touting a baby version of these statically typed FP languages. I actually laughed out loud reading this blog post.

Except, you know...software engineer, IT, DevOps, Infosec, WebDev, etc.

Netflix has an employee stock purchase program that let's them purchase stock at a discount. Netflix's stock went from 80 to 160 in the last year, so I think it's not too far fetched to assume some of the less risk averse Netflix employees did fantastic in the last couple years.

Why would we have the same number of jobs? If more women are working who didn't before, they will need some way to commute to said job, to buy work clothes as well as leisure clothes, have more disposable income, etc.

I think you fundamentally misunderstand what the word abstraction means and the point of it.

I've worked on teams of various sizes and skills writing OO applications and trying to use inheritance and OO to get code reuse is always a nightmare. I currently work on large project with hundreds of Scala engineers of various abilities, and structuring our code in functional ways has bought us a ton of reuse and prevented a lot of technical debt.

We primarily write libraries, and our 'applications' are more or less throw away code because of how small they end up being (because they can leverage many of our libraries). Testing is easier in functional land (for various reasons), which means regressions are much harder to introduce, which means refactoring can happen faster, which means less technical debt.

Anathem by Neal Stephenson is basically hard sci-fi directly inspired by Penrose's book "The Emperor's New Mind". Also one of my favorite books. :)

>Beyond the magic of map/flatmap/etc, the things that allow you to achieve terseness

I think if you assume 'terseness' is the goal of constructs such as map/flatMap you're missing the forest for the trees. Yes terseness can be a good thing, it sacrifices familiarity for the ability to understand more going on in a quicker amount of time. This can definitely reduce cognitive overheard for someone familiar with the constructs being used.

This however, is a secondary (but pleasant) side effect of the main goal which is (non leaky) abstraction. By using familiar abstractions it allows readers to reason about code in a powerful way, allowing for more reuse and composition.

I find this claim dubious. I have been in the industry a long time and I have found the opposite.

I work remotely from Orange County for a big company that 'doesn't do remote'. I contributed to open source projects that were already in use by the company, and I had to start out on a '3 month contract' (working remote) before they were ok with hiring remote.

You're close to inventing monads! I did this once too for async reasons also, and it's how I wandered into the world of Monads and functional programming. I would definitely take a look at Scala's futures and what it means to be a monad. This is probably the best way to internalize them. :)

Doesn't this say more about the flaws of the business and/or the management than it indicates this being a good idea? Many of the most successful software companies do everything they can to attract and retain the upper end of software engineers and they don't do this because it's bad for businese. Presumably they do this because it provides more value for the company than having more programmers or trying to save money on salaries/perks.

I work at Verizon and they gave me a MBP with root access...so this is not universal at the company.

Then the best option is to live frugally on a high salary in an expensive COL location. Really only housing scales linearly. If you can save on that, your base salary can be doubl, which affects your 401k match %, your bonus %, any raises, etc. so even if your entire salary adjustment goes to rent in a couple years you would be saving way more.

No, you need to raise compensation. If someone is worth 250k at Google, they may work for your company for 150k if they get 600k worth of options paid out over four years at a reasonable valuation.

Very good on the coast, high paying, fun work. Pretty sparse otherwise. I'm sure there are exceptions, but it does seem like it is growing. And, ironically, the main reason companies cite not choosing Scala (or only dip their toes into Scala) is lack of Scala engineers.

>Generics would be really nice for generic data structures (heaps, trees, etc), but code generation is ok at that.

Either code generation is an implementation detail of generics, or this is an afterthought that adds incidental complexity and was almost assuredly better off being a core language feature.

>I think it's hard to quantify the massive benefit Go's simplicity is to onboarding developers

This is really only applicable to small applications using new languages where the main cognitive onboarding is learning a new language/paradigm. As soon as you reach a certain size of application, the frameworks, architecture and domain knowledge heavily outweigh the cost of learning even the most esoteric of language features.

>Any language features which increase cognitive overhead had better offer some extremely compelling benefits to outweigh an increased learning curve

I wonder what kind of language feature you're talking about? The whole idea of generics in a more functional oriented language is to reduce cognitive overhead. The beauty of parametricity is it takes things away from the developer to help them reason about the code!

Our (very large) team of engineers use this to great affect throughout our codebases. There is no such thing as a silver bullet, but this comes as close as I've seen in the 12 years I've been an engineer (from startups to a Fortune 10 company).

I quite enjoyed playing with Reason and would love to get a chance to use it for something at work. We use a ton of Scala on the backend here at Verizon Labs (so many of us are into hardcore FP) but we occasionally run into GC issues, so the OCaml runtime is something that could potentially mitigate that.

Can you talk about what FB uses Reason to develop, and what kind of services are being built with it?

Don't have kids so I can't comment on that, but I reserve time for fun. I almost without fail reserve friday night as a night out with either my wife or friends doing something that's not related to work/tech/programming.

I love programming, sometimes I even want to spend friday night doing it, but none the less it's good for my long term mental health to get away and do something else.

I spend a few hours on the weekend learning 'long term' stuff, like math or technology not related to my job. I try to do this in a coffee shop or outdoors so it's a pleasant experience. A little over half the time I eat lunch while wokring but I never work through dinner. That's time for socializing or with friends, even if I have to go back to work.

> just data structures and algorithm skills seem starkly lacking among the autodidactic programmers

remove autodidactic from the sentence and it is still true.

>t's very easy to learn programming on your own these days, sure. But it's a lot harder to learn public speaking, finance, management principles, marketing, college-level reading and writing, technical writing, time-management, political science, biology, physics, and all of the other stuff that you're taught in college.

Am I insane, or really bad at programming? Because with the exception of biology and physics, the other things you mentioned are significantly easier and more intuitive to learn on your own compared to say, computer science concepts and math.

But could all practicing lawyers pass the bar right now in their respective state? I'd guess no. The problem is not the questions necessarily, it's that you have to study a bit and do the same goddamn interview questions at multiple companies, sometimes with very different interviewers. Some are helpful, some make me nervous, some are asking the hardest possible questions without warmup easy questions, etc.

Whiteboard or live coding is not the problem. Bad or untrained interviewers are, along with the fact we can't do one interview that proves to multiple companies what level we are at.