jasallen

There is no penalty to being told "no". That also applies to "I think I know the answer". There is no penalty for being told "no" there as well, so once you have a reasonable guess why not check it? Disagree with their analysis.

Would kill for dates on each these messages!

Purely a guess, but I'd say the alcohol rinses away the standing water on the blades, leaving only the airborne moisture to deal with.

Totally agree. I simply cannot see Lynda.com's current (amazing) setup blending well with LinkedIn. Lynda.com is going the way of the History Channel.

I think with "No, Totally" in particular, the "no" is refuting something implied. So with "Makes you want to hit them", you are instinctively saying "no" the cultural prohibition against violence. "No that's not normal behavior, but yeah, totally I want to hit them."

For "Would you like ice cream?" you'd say "Totally" because the connotation is good. "Don't you just want to eat the whole tub of ice cream" -- "no, totally", is a reasonable response because you're resisting the negative connotation of pigging out.

I think this is actually unrelated to the "Yeah, No" phenomenon.

If you worked at a start up in Detroit, you were defacto a part of the Gilbert Mafia. I don't say that disparagingly, Dan Gilbert crew have done great things for the city, but its a one shop town.

A2 lacks a Dan Gilbert to make all the things happen, but it has a much more vibrant, Bay-like share-and-share alike, encouraging, open start-up culture.

Plug for A2-NewTech, a start-up meetup I'm a huge fan of (I'm not affiliated, just a fan)

No, it's just utterly nonsensical.

That deals particularly with mixing and matching awaits and Results in complex manner. I wouldn't call "don't do that" "very complicated".

My mistake and too late to edit. I don't use "await" and I misread this at first. Actually the classic tasks way would be to add these to an array of tasks, and then "WhenAll" for the continuation.

Noone suggested it was not built on top of Tasks.

I make it a rule never to question Eric Lippert, and I won't do so here. That said, right, the current continuation bit requires IL foo, but as the ones writing the code, there is always a way besides needing the current continuation bit.

And if you're going between languages much at all, Tasks are a lot more like promises and other paradigms in other languages. Whereas the whole await business is just... weird.

Exception propagation is one area I have to agree. Still, there was no reason to invent whole new language semantics for that. As far as simple flows, I'll disagree. The Task Library allows for normal workflow operations and your decisions are much more (to me) explicit when you see "WaitAll", "WaitAny" chaining things together.

Why is that easier than using a blocking call directly on the Task object that ReadAsync returns? Like ".Return" or ".Wait"

I continue to find using explicit "Task<T>" types directly more intuitive. I've wedged in ASync/Await here and there to see if I felt good about it, but I never did. I would always find declaring a Task and attaching to it's ContinueWith (or whatever I needed ) to be more to my liking.

Honestly, the things you describe are not that bad. If they are writing code that passes the test cases, move on and be happy. If you'd described things like circular dependencies and passing brittle "magic strings" through multiple layers -- things that will GENUINELY cause maintainability issues I'd sympathize more.

I doubt anyone named it the "...last6hours" but then parameterized the number of hours -- so you're changing that code anyway if the number of hours changes. If you have a requirement to parameterize that, do so, otherwise YAGNI, move on.

Hardcoded strings is another one. Frankly, unless you are using the string in more than two places or it's part of a "set" of values, where referencing the full set is useful, you may just be making more work to do it 'correctly'.

You reference timeline pressure. "Good, Fast, Cheap, pick two". If you don't have enough programmers for the timeline alotted, the powers-that-be have already selected Cheap and Fast. Deliver a product that does the job asked, a few maintenance iterations (if the product is one of the 30% that make it that far) will teach you want areas of code are touched a lot and need to be "made maintainable"

He gave an off the cuff answer that was wrong. He didn't write an essay about it that was proofread and considered. I'm not surprised that people are assuming they 'know his heart' based on one quick answer, but I am disappointed.

Something I've not seen pointed out elsewhere too, is that (unfortunately) this is an answer that every manager of every large company has ready at the tip of their tongue. It pops out from rote memorization. Not about women, but about all employees: "We only give raises as part of the normal annual review process. I understand you think your compensation needs to be reconsidered because ...... and I'll make sure to discuss that with the rest of the management team at review time." It's not good, but it's a well rehearsed blow off answer for which every manager is trained.

I think he's a good guy who is handling the aftermath well. He gave a stupid answer and apologized. I honestly the bigger mistake is telling employees to trust the system, rather than a single off the cuff answer that didn't fit well.

It's a skill to speak well in public quickly and smoothly. Unfortunately sometimes you don't have sound bites ready, and the thousands of faces staring at you make it hard to do analysis on the spot, so you answer the first answer that comes to mind, and thanks to that skill, it sounds thought out and considered.

Sometimes that skill is a detriment, obviously. Usually it's a boon.

Even in the cartoons it seems most are correct. As someone who first learned how to focus and get-things-right by drawing at an early age and since, I found it pretty unlikely this premise could be correct.

Not thrilled with the drawing guides either. All I can tell you is I never draw from a picture and I never make this error. Nor it seems to most of the people on google images.

The pressure is still 1/3 of an atmosphere approx, regardless of mechanical or gas. The more salient question, to ask those who have experienced it, how do those parts of the body respond to less than normal atmosphere pressure. Sounds like that could be a 'sensitive topic' as well.

Parent is referring to the "demo application", though I personally disagree that one should worry about it on the demo app. The docs sure, but the demo app is readable enough even if you're not a coffeescript aficionado.

More opinion and supposition masquerading as dietary advice. Morals and feelings of "eeeww" do not count as sound scientific nutrition principles.

Should have stopped at "Eat food. Not too much." Mostly plants is fine, but so is mostly lean meat and some plants.

Which is why for so long people believed that salt was the cause. But in your situation salt is also a proxy for a lot of other things that were wrong with your diet. Gobs of processes carbs, no 'good' cholesterol, a lack of protein, just to get started.

Since anything that cuts processed salt considerably almost assuredly improves those other metrics, I'm not sure why you believe your anecdotal evidence is so convincing.

He managed avoid the "flat" vs. "dead" controversy by making up a new convention altogether.

Unless while away you are on any page with a facebook 'like' button. In which case they can monitor exactly your behavior. Fortunately there are very few of those. 0_o

Yes, yes they are. I have a problem with this, as I don't foresee a hockey stick growth business model that doesn't also involve false claims, but maybe I'm just that guy who didn't get it.

As previous poster said, focusing on something like pre-natal would be a viable and honest model, but I'm not sure it's a hockey stick model.

I would take 'enjoy the ride' a step further. Use the ride. If you are never anything but a successful entrepreneur you will fail:

1) To be a good boss to anyone except the elite talent 2) To understand how/why gears of productivity can grind to a halt as you get layers of management beneath 3) To have a vantage point to appreciate what you achieve later. 4) To meet anyone who you can say forever was there for you when things weren't going rockstar sexy.

I am currently scraping for brand product and nutrition data. Having to build custom scrapers per brand is hell.

I have a dream to use something closer to OCR against a rendered page, rather than parsing DOM. That way it would be less custom, and I could say, for instance, "find 'protein', the thing to the right of that is the protein grams".

I, personally, don't know how to do this, but I'd be willing to pay for a more generic way to scrape nutrition data (email in profile :) )

Well, you are correct that fat has been incorrectly vilified.

Most of the rest of what you say is logical leaps based on inconclusive data, which is just as bad as what the fat haters did years ago.

Don't get me wrong, a lot of what you say is even a good best guess based on what we know right now, but so was fat hating at one time, and stating best guesses like proven fact is what gets us to the point of having entrenched, demonstrably incorrect policy.

Let's just say "currently best available evidence..."

Xamarin's IDE is not as good as VS, but it is often much better than XCode, and C# and F# are both more pleasant languages to work in for people with the vast majority of experiences (C++, Java, .Net, Ruby), so even without all the cross platform goodness I prefer to work with Xamarin. (Swift may change some of that, I haven't looked into it yet).

I've never had a problem easily translating Obj C StackOverflows or blog posts to Xamarin/C# so essentially you get the whole community as well, with no worries about Xamarin specificness.

That said, I think their current pricing structure makes sense for them right now. They are not 'quite' at the polish level, not quite at the level that average people can do things averagely. There is still just a little more cross platform knowledge and effort required. The price serves as both a barrier to entry to manage the community size, and provides them enough capital (on top of outside investment) to keep investing toward a fully mass market approach.

This post is brilliant and correct. The best part is where he closes with the acknowledgement that the system works... to a limited degree. He's not just slamming it. It is actually an ok way to minimize risk at the cost of upside in the short term.

But it is unscalable for a couple key reasons. (1) Lack of diversity is lack of ideas and experiences, you may fail to find the "next big thing" simply because your echo chamber doesn't include that experience. (2) raw scale. There are only so many Stanford grads et al out there. When you need your 25th, 100th or 150th technical person you will need to have achieved either Google's cachet or start expending your parameters quite a lot.

Finding people's value is a very important management skill that seems to have been eschewed in this "cultural fit" culture. It's true there are some people that will be poison, but if the majority of people with the right skills are bad for your organization rather than the majority being able to be a positive, you should ask yourself if your organization is adequately healthy and robust, or is it an infant in an incubator, only surviving as long as you obsessively manage every input.