It's really not bullshit, I think. The stuff about fear rings totally true to me, it aligns perfectly with my experiences. But, I know that being on the other side of it, it can sound like a bunch of hokum. (That's part of the reason why people keep living that way - the logic is pretty watertight.)
I've read books about it too, and not been helped that much beyond perhaps gaining some insight, or setting expectations of what happiness is like. But that doesn't invalidate the information in the books, it tells you that merely reading about happiness does not make it so. You can read all the books about how to be a great basketball player, but you won't improve until you actually get on a court and shoot some shots.
Wow, gotta disagree there. I found that having projects on Github was impressive to potential employers 100% of the time I brought it up. Before I had them on there (in particular, two small personal side projects) it was much more difficult to prove that I know stuff because I commit to private repos.
This is very thorough, and I'm sure it's helpful to a lot of folks. So thank you to the author. For me, it's probably a syntactical issue, but I find things such as the below too hard to comprehend.
What did we get just by doing this? Let's see:
λ> :type EitherIO
EitherIO :: IO (Either e a) -> EitherIO e a
λ> :type runEitherIO
runEitherIO :: EitherIO e a -> IO (Either e a)
So already we have a way to go between our own type and the combination we used previously! That's gotta be useful somehow.
OK, looks like a pair of parentheses moved. I have seriously no idea why that is interesting or useful. Conceptually what's going on is probably not complicated, but that syntax makes it inscrutable to me. (I could be wrong and the problem could be at a deeper level of understanding.)
They're different representations of the same thing.
This is useful because we can do easy error handling in the EitherIO monad but we can't run it. We can run the IO monad but handling errors in it sucks ass.
So we handle errors in EitherIO, and make it runnable (ie. convert to the IO monad) by calling runEitherIO.
It's like calling a function that takes a pair when some other API gives you a two element list. The same kind of data, just munging the shape so things work. In pseudocode:
// EitherIO and runEitherIO in this analogy.
fun toList((a, b)) -> [a, b]
fun toPair([a, b]) -> (a, b)
// Gotta convert to a "runnable" pair before calling the function.
var latLngList = [blah, blah]
var resultPair = api1ThatRequiresPair(toPair(latLngList))
// Convert representations to do operations with a different API.
api2ThatRequiresList(toList(resultPair))
data EitherIO e a = EitherIO {
runEitherIO :: IO (Either e a)
}
But, for the sake of clarity, it can be written as
data EitherIO e a = MakeEitherIO {
runEitherIO :: IO (Either e a)
}
The author pointed out two functions that this EitherIO declaration gave us. One is a constructor, MakeEitherIO, with type
IO (Either e a) -> EitherIO e a
In other words, MakeEitherIO takes a value of type IO (Either e a) and returns a value of type EitherIO e a (you could think of this as "wrapping" the original IO value).
The second function, runEitherIO, is an accessor function for EitherIO's named record field "runEitherIO". It has type
EitherIO e a -> IO (Either e a)
That is, runEitherIO takes a value of type EitherIO and returns the internal value of type IO (Either e a) (you could think of this as "unwrapping" the IO value).
Very strange comment, I'm sure execs expected all of this when the deal was done. Their expected outcome probably does not look "catastrophic" to them.
Actually, I would say that by the time the deal rolled around the catastrophe had already played itself out at Nokia. It's sad what happened to Nokia, but the acquisition is the least of it.
> Instead of being a programmer auditioning to sling code, he was already “part of the club” (management) and just engaging in a two-way discussion, as equals, on whether he was going to join that particular section of the club.
Hmm! The latter is typically how I approach interviews (I'm a developer). I feel that if that's not the case then why am I here? Sometimes you get people that are smart in a dumb way, like the last interview in the story here. Just looking to be intellectually dominant, the "winner". But you just have to recognize those situations for what they are and not get discouraged. Developers are in demand, we get to act like it. And sometimes people get treated like shit because they allow it to happen.
I find this suspicion suspicious. I know that some people are melodramatic about it, but why can't people just have their food without gluten if they don't want it? Nobody ever backlashed against the anti-MSG thing, and that was arguably way dumber.
On the other hand, I have heard that this has resulted in lowering of standards for handling gluten, and people who are severely allergic are being exposed to small amounts, while people without celiac don't notice those small amounts. So, that's bad.
Yes, these lowering standards cause by people not really allergic is a problem.
I have the same problem with my son having multiple allergies (real severe ones) is that the employees think when you say you're allergic that your just being fussy and that just removing something from the top of the dish is OK.
But in any case, it hard to trust restaurants at all on these matters.
I've read books about it too, and not been helped that much beyond perhaps gaining some insight, or setting expectations of what happiness is like. But that doesn't invalidate the information in the books, it tells you that merely reading about happiness does not make it so. You can read all the books about how to be a great basketball player, but you won't improve until you actually get on a court and shoot some shots.