Skype options turn out to be worthless - <AUTHOR> http://blogs.reuters.com/felix-salmon/2011/06/24/upgrading-skype-and-silver-lake-to-evil/ Am I the only one who finds this pretty shocking? <comment><USER4> Absolutely zero surprise on my side. VCs, and acquiring companies are always looking to maximize their return, as legally as possible during an M&A deal, even (sometimes particularly) if that means screwing over employees who are no longer with the company.

I actually like the honesty of this quote:

"Silver Lake declined to comment. When asked about Lee's situation, Skype spokesman Brian O'Shaughnessy said, "You've got to be in it to win it. The company chose to include that clause in the contract in order to retain the best and the brightest people to build great products. This individual chose to leave, therefore he doesn't get that benefit.""

Most people will look at it and say "What an Asswad" - but at least he's not being a hypocrite. That's precisely what everyone in the M&A team is _thinking_ they just aren't _saying_ it.

This is another take on what Oracle did when they bought Oblix (I had just left Oblix in 1999) Oracle gave MegaBonuses to all the existing employees and executives, two of the founders, and paid absolutely nothing for the common shares. The acquisition price was still $100Million plus, but there was only enough money to cover the preferred options + liquidation preferences in the "on the record" purchase prices. Effectively, they wiped out all the employees who were common shareholders, but no longer with the company (or were part of the 15-20 out of 100 who were laid off during the acquisition) while taking care of the VCs and the acquired employees. (As a side bonus, they called the money they gave to the acquired employees "Retention Bonuses" - which resulted in the top people having to hang around for another year)

Lesson to be learned: When you leave a company, and it is still private - <USER2> they are Sold, instead of going public, there are probably any number of ways that you will get wiped out if you are no longer with them - <USER3> exception if you are a founder with a significant percentage of the company, and you might be able to raise a stink for minority shareholder rights. Then you'll get a "consulting bonus" to shut you up.

This story is more common than not.

<comment><USER5> In my experience it's very rare for employees with vested stock to get ripped off in an acquisition. Usually the amounts involved are so small that it would not be worth the bad publicity.

Curiously enough, one of the consequences of the rise of YC-like investors is that it will no longer be so easy to pull the sort of trick you claim Oracle pulled. We get common stock, so you can't screw the common sharedholders without screwing us, which most people would think twice about.

<comment><USER4> That, single handedly, has to be one of the strongest reason I could ever think of someone wanting to work for a YCombinator company. In particular, because YC doesn't take very large portions of the common stock, they wouldn't be able to leverage their position into a "Consulting Fee" agreement with the acquirer, so their _only_ recourse is the documentation surrounding the common.

You can rest assured that if you put your 4+ years into a YC company, and it gets sold while you are no longer with it, your interests and YCs will be aligned. With a YC company, your vested common stock actually _means_ something when you leave the company. (Or, at least it means you and YC will get screwed equally - and as PG rather ominously said, that is something "which most people would think twice about." :-) )

I respectfully disagree with PG on how rare it is for employees who've left a company to get zeroed out or severely diluted compared to the ongoing- employees in an acquisition deal. I've heard enough anecdotes to convince me it is far from "very rare."

Like O'Shaughnessy said: "You've got to be in it to win it."

<comment><USER6> Nit: Employees don't vest stock. They vest options.

<comment><USER7> Nit: Some employees vest stock. Some vest options. Companies are different. I've been in a multitude of startups. Two were stock, one was options. For example, the current startup grants restricted stock units.

</comment></comment></comment></comment></comment><comment><USER8> 1\. By no means do I want to defend Skype here, but the prose in the linked documents isn't especially incomprehensible, at least not for documents of this type.

I teach contract drafting to third-year law students. It's hard work to take a complex if-then-else concept and render it in plain English.[a]

And here's the rub: Few clients want to pay lawyers to spend extra time on readability -- "good enough" (whatever that means) is the goal.

2\. [EDITED TO ADD THIS:] It's not unusual for a private company's employee stock plan to include a "call" option that gives the employer the right to repurchase employee-owned shares when the employee leaves the company.

That makes sense when you think about it -- if you're a private company, you don't want a lot of random ex-employees owning dribs and drabs of your shares, especially if you're worried about the 500-shareholder limit (under current law).

On the other hand, for a company with an upcoming exit to buy back the shares at the employee's cost, instead of at a good-faith estimate of the stock's then-current value -- well, that does indeed seem unusual.

(EDIT: Some documents like this provide that, IF: The company wants to do its buy-back EITHER: (i) after an exit is announced, OR: (ii) if an exit is announced within 30 days or so after the employee's departure; THEN: The employee is entitled to the exit pricing for the buy-back.)

3\. Again, not to defend Skype, but conceivably they might not have had a choice about the buy-back price, at least not without jeopardizing some kind of favorable income-tax treatment.

If I had to guess, I'd venture that, X number of years ago, some overzealous junior lawyer decided to draft the relevant documents so as to put the company in the strongest position s/he could. Now that zealousness may be tying their hands. I stress that I'm speculating here.

* * *

[a] If you have occasion to write a complex if-then-else sentence, try using all-caps and punctuation like this: _IF: It rains at least one inch today but not more than two inches; AND: It doesn't rain tomorrow; THEN: You will turn on the sprinkler system tomorrow; AND: You will not do so the day after._

<comment><USER9> Tech employees should not be required to take a third-year law school contracts course to understand their employment agreement.

<comment><USER8> > _employees should not be required to take a third-year law school contracts > course to understand their employment agreement._

@jeffreymcmanus, I'm in violent agreement ....

<comment><USER10> Please don't use the @name convention on HN.

HN is not youtube, where there's no threading of comments and where it's impossible to divine who you're responding to without the @name.

Here it's quite obvious who you're responding to, because your comment is indented under the comment you've replied to.

Also, while we're at it, replies that say no more than "I agree" or "I disagree" are generally frowned on here, since they're almost completely contentless and don't contribute to the discussion.

<comment><USER8> > _Here it's quite obvious who you're responding to, because your comment is > indented under the comment you've replied to._

Right now that's indeed true. If later on there were to be a lot of intervening comments, it'd be more difficult to tell immediately who the response was directed to. In that case, the @name convention likely would be helpful to readers.

> _Also, while we're at it, replies that say no more than "I agree" or "I > disagree" are generally frowned on here, since they're almost completely > contentless and don't contribute to the discussion._

That's certainly true in the general case, when you have a random third party chiming in with his or her agreement.

In this case, though, the "I agree" was a useful clarification: It signaled, _to someone who had responded to me_ with what could be interpreted as a challenge, that we were on the same page.

<comment><USER11>
        > Right now that's indeed true. If later on there were to be
        > a lot of intervening comments, it'd be more difficult to
        > tell immediately who the response was directed to.

Not really. Making relationships between messages clear is kind of the point of tree-structured comments.

<comment><USER12> It is the point, but it doesn't always work. I have had to use my mouse to record the current level of indentation and then scroll up to find the parent post on some sites.

<comment><USER13> But you do remember who said what without scrolling, even if it is 3 screens up? (do you even care WHO said it at all or just what was said?)

Also "use my mouse to record the level of indention" is wrong. It is perfectly visual.

"On some sites" - maybe, but not on HN. And we're discussing (on HN) a comment made on HN.

To me, your argument makes no sense and looks like a rationalization of "damn it, I'm used to seeing this style, and I'm going to find an excuse to use it on HN whether it makes sense or not"

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER14> The article leaves out some relevant context. It appears that Yee Lee was at Skype for one year one month 3/2010 - 4/2011. That entire period of time was after Silverlake had purchased Skype and more importantly after the right to repurchase vested options was in place.

It is difficult to see this as private equity screwing over founders or early employees (Skype was founded in 2003 and had been valued at more than $2 billion for five years when Lee Yee came aboard). Indeed given the short tenure of many of the people involved in the story, there seems to be more smoke than fire.

[Lee Yee on Linkedin: <http://www.linkedin.com/in/yeeguy>]

[Business Week article correlating Linkedin profile to article: [http://www.businessweek.com/magazine/content/11_27/b42350386...](http://www.businessweek.com/magazine/content/11_27/b4235038625596.htm)]

[my comments on previous versions of story: <http://news.ycombinator.com/item?id=2672786>]

</comment><comment><USER15> While I understand that legalese is necessary since English is ambiguous in its best moments, the only reasons I see not to include a "plain English" version of a contract are A) to save on lawyer hours, or B) to screw someone over.

For most contracts I suspect that the overhead on a plain English version would be very small, as the lawyers' understanding of the topics is necessarily deep to formulate the contract (or they're just shitty lawyers, another topic).

Plain English versions of contracts, with their plain English meanings of clauses, should be included in any contract between two parties of vastly different bargaining power, i.e. a corporation with loads of legal resources and a non-millionaire potential employee.

 _Update w.r.t. comments_ —I understand the points you're making, but I don't think it invalidates the argument. I'm racking my brain to find the examples I've seen, but there do exist in the wild "plain English" versions of contracts that are not binding (and they specify that) but instead contain comprehensible summaries of the salient parts.

<comment><USER16> Lawyers don't include plain English because, in general, legal code cannot have comments which are not executable code. Imagine the sort of comments you would write if they were all executable (and you could not trivially break this constraint -- it's a metaphor, work with me).

The business danger is that your plain English suggests, or is ambiguous with regards to, the meaning of something which your legal code is not ambiguous about, and the court holds that the meaning extracted from the plain English is controlling because, well, if you hadn't intended it that way you're a billion-dollar corporation with a dream team and you should have been able to phrase what you actually wanted in the contract you had drafted.

What's something which could easily be misconstrued... ooh, vesting schedules. "We grant you 10,000 options with a 4 year vesting schedule of 2,500 options per year." Lawyers will probably not be that loose with language. For one thing, this doesn't address the somewhat significant issue of when those 2,500 options accrue -- if I end my employment on day 1,000, do I end up with 5,000 options? Or 6,843 options? Or, perhaps more significantly, is the maximum number of options accrued under this 10,000? Or 20,000? (Lawyers don't get a DWIM operator any more than we do, and "with" is one treacherous little beastie now isn't it.)

<comment><USER10> _"The business danger is that your plain English suggests, or is ambiguous with regards to, the meaning of something which your legal code is not ambiguous about"_

That assumes that the legalese is less ambiguous than plain English. Quite often it's the other way around.

<comment><USER17> No, it really is not the other way around "quite often." Legal English is quite specific and not particularly or regularly ambiguous.

This is a common misconception held by most people. It is wrong.

<comment><USER10> I'm not sure I fully understand what you mean. Could you please rewrite it in legalese?

</comment></comment></comment></comment></comment><comment><USER18> A big part of business is who you're in bed with. MS should cancel the Skype deal, if at all possible. That would be one sign that they've turned a corner. I will never fork over a dime for any Skype service. This, while legal, is clearly unethical on a broad scale. And its the worst kind of unethical. Apple and MS play hardball with competitors -- but you don't do that with your employees.

<comment><USER19> What does this have to do with Microsoft?

<comment><USER20> If you lie down with dogs, you get up with fleas.

<comment><USER21> and if you rock'em sock'em you'll turn into a robot!

</comment></comment></comment></comment><comment><USER22> "It turns out the investor group...had secured a so-called repurchase right that gave them authority to buy back the shares at the grant price."

If this is true, it sounds like somebody didn't properly perform their due diligence before signing their options agreement. Although it's never right for a company or investor to exercise this buy back when it comes to an honest, hard-working employee, the onus really falls on the employee ensuring that this clause never sees the light of day in their contract in the first place. Perhaps in the event of "cause", one could make a case, but certainly under no other condition.

EDIT: It's an unethical clause to begin with - absolutely agree with the comments. Just saying that you can't count on anyone besides yourself to act on behalf of your own best interests.

<comment><USER23> Felix Salmon makes a good case that Skype's stock agreement was deliberately obfuscative:

[http://blogs.reuters.com/felix- salmon/2011/06/24/upgrading-s...](http://blogs.reuters.com/felix- salmon/2011/06/24/upgrading-skype-and-silver-lake-to-evil/)

Basically, Skype's claim is that the point of this clause is to retain employees -- you don't get cash in your vested stock unless you still work for the company. But as Salmon points out, none of the employees actually realized this -- the clauses are bafflingly worded, and refer to external documents, to the extent that you'd need a lawyer to figure them out -- so it doesn't make any kind of sense as a retention tool. Add in the fact that this policy is pretty radically different from standard tech industry practice, where if you're vested you're vested, and it really seems like it's just a way to screw employees.

<comment><USER24> Clearly nonsense. When I worked for KL Group, a unique incentive program was put into place to allow employees to participate in any "liquidity event" that might take place.

It was explained to everyone, clearly, that you only benefitted if you were an employee at the time, and that when you leave the company for any reason, the founders would buy you out according to a specific, written formula.

There was absolutely no ambiguity about the mechanism.

<comment><USER25> There's nothing wrong with such an agreement (as you describe KL), and though this type of explicit inventive plan is not so common in Silicon Valley, it is surely valid, ethical, and and useful wherever it arises. (To be more complete, in Silicon Valley there is usually such an incentive plan concerning liquidity events, but it's tacit and is anyway orthogonal to stock/option grants.)

But you say it explained to everyone at KL "clearly" what was going on. Don't you see that this is one complaint here is that not only wasn't this done, but perhaps the very opposite?

      And were you given detailed instructions on how (and how quickly) you must exercise vested options if you quit,

even though this had no meaning at all whatsoever? If the answer is no, please imagine it was yes. Would you have still been totally confident that you understood the mechanism (wouldn't you have wondered: why are they explaining something that is in practice irrelevant?)

<comment><USER24> When I said, "nonsense," I meant that it's nonsense to call it a retention plan if you don't actually tell people they have an incentive to stay after their options so-called "vest."

</comment></comment></comment></comment></comment><comment><USER26> This is why cash is king and "equity" is worthless.

Hey bizdev weenies out there that wonder why you can't find a technical cofounder/employee who will work for equity, here is your answer.

</comment><comment><USER27> I understand that Skype is a private company, and so that when they grant options it will have some odd terms that employees of public companies don't have.

They shouldn't use the terms "vested" and "unvested" then. His options were vested, yet were callable. That's not what vested means. They should call all options unvested until the company goes IPO.

</comment><comment><USER28> Silverlake is not the only investor in Skype; e.g. Andreessen Horowitz is too:

<http://a16z.com/portfolio/>

<comment><USER29> Good point. I'd like to hear either (Andreessen or Horowitz) speak out and say they opposed such tactics.

I'll have to add Skype to my list of "rotten ethics in Silicon Valley" ([http://blog.fairsoftware.net/2011/06/01/rotten-ethics-in- sil...](http://blog.fairsoftware.net/2011/06/01/rotten-ethics-in-silicon- valley/)). When will the investors speak up?

</comment></comment><comment><USER29> Amazing, this is the first time I see a stock options agreement where the employee is forced to enter into a partnership for his vested shares. I agree with the blog's title "upgrading Skype to evil".

On the other hand, you should have known Skype, incorporated in an international haven, was not your regular startup.

EDIT: also, the stock agreement just says "management partnership" on page 3, with no prior definition of what it might be. Later on, it gets more references, without ever being defined. A good lawyer may have a case?

</comment><comment><USER30> What is Microsoft doing about this? As the acquirer, they may still be able to "do the right thing" and make some of these guys whole. Sure, it may cost them a few million bucks; but can you imagine the goodwill it will generate for Microsoft? You can't buy that kind of good publicity!

But will Microsoft do such a thing? I doubt it very much. (I would love to be proven wrong, of course)

<comment><USER31> If I were "Microsoft", I'd be thinking more along the lines of "if they went out of their way to sneakily screw over their employees like this, what hidden traps lie in store for us?"

</comment></comment><comment><USER28> Silverlake portfolio companies:

[http://www.silverlake.com/partners/content.php?page=investme...](http://www.silverlake.com/partners/content.php?page=investments- current)

<comment><USER18> Good luck to the Groupon employees.

</comment></comment><comment><USER32> I wonder how many of us are now scrambling to dig up a copy of our stock option agreement. This sets a terrible precedent. In case you didn't get it yet:

READ YOUR LEGAL DOCS (sock options, IP, etc) and negotiate sketchy terms before you sign them!

</comment><comment><USER33> So the people who lost out here have any recourse? I hope they are talking to lawyers. I'm not typically the type of person to sue over everything but this is screaming for a lawsuit.

</comment><comment><USER34> Anyone interested in joining GoDaddy after the SilverLake deal should have their head examined.

</comment><comment><USER35> What's to stop a disgruntled software dev who gets treated this way from secretly using his knowledge to support an open source competitor? It doesn't have to be anything close to a line by line copy, just subtle hints here are there about better, but generic, ways of doing things.

<comment><USER36> The threat of being sued, regardless of whether the lawsuit would be successful

</comment></comment><comment><USER37> in the other thread on this <http://news.ycombinator.com/item?id=2691455> the article had the following line "the company's decision to repurchase would also cause a tax hit to him" - anyone know how that works?

<comment><USER38> I'm the guy in the article. So, I got a letter from the Skype HR folks indicating that if I were to persist on the path of exercising my options, then they would: (1) exercise their right to repurchase the shares at grant- price, leaving me with net zero gain; (2) demand tax withholding on the shares, valued at _fair market value_ (substantially higher than grant price, given that the MSFT deal had already been announced)

The sum effect of 1 and 2 being net-zero gain on the shares, minus a large chunk of cash out of pocket tied up in a tax withholding account.

Terrible.

<comment><USER29> At a minimum, if you are concerned with a huge tax liability, exercise ONE option. And tell everyone else in your situation to do the same.

It will cost you less than $200, and it will be very annoying to Skype. It takes the same amount of paperwork and lawyer time.

</comment></comment></comment><comment><USER39> I don't really have much to contribute on the story itself, but I suddenly realized that my former CS472 Artificial Intelligence project partner and friend from Cornell works for Silver Lake, which has led me down an interesting path of daydreaming now that I'm starting work with a Valley-based company in a few weeks.

It would actually make for a great short story or novelette to see former classmates on opposite sides of a deal like this. A lot of very smart engineers go straight into jobs in technology sector investment banking, private equity, etc. soon after college that could eventually put them on a collision course with erstwhile friends.

</comment><comment><USER40> This is yet another reason I refuse to use Skype. I won't patronize a company that treats it's employees like that.

</comment><comment><USER41> "that you will receive no value" is hardly opaque, even if the rest is. Any contract that said that would have me pouring over it with a fine-tooth comb. Or more likely, just rejected it and finding work elsewhere.

I wonder if that contract is subject to legal action, though? Seems to me that was a deliberate attempt to screw him over. He shouldn't have signed it, but they shouldn't have written it, either.

I'm now serious considering canceling my Skype subscriptions and finding alternatives, despite how useful they are to me a the moment.

<comment><USER42> The "receive no value" language is not in the original contract -- that's from a June 13, 2011 letter from one of Skype's attorney's.

</comment></comment><comment><USER43> I've seen swarms of employees get screwed in ways similar to this. It's not uncommon in Silicon Valley.

</comment><comment><USER44> I'm sure I'm not the only one who reviewed their stock grants... (good news :))

</comment><comment><USER6> They could also have executed their options to purchase the stock...</comment>


S.B. 727 Would Unfairly Restrict California Students' Use of Course Materials - <AUTHOR> https://www.eff.org/deeplinks/2017/08/sb-727-would-unfairly-restrict-california-students-use-course-materials <comment><USER2> Not sure how I feel about this. Allowing publishers to get compensated directly for the quality of their material theoretically improves it. But not allowing students to reference it after the class seems dodgy. But I can't remember any college textbook I've ever referred to post-university, either.

<comment><USER3> You can resell a book but you cannot sell DRM protected electronic materials. Therefore they can be sold for a higher price. Publishers just want to get more profit without improving anything.

</comment></comment><comment><USER3> It is interesting that modern advanced technologies (electronic books) are only worse for students because of DRM and license restrictions.

</comment><comment><USER4> Perhaps unrelated, but is this the same type of collusion that is continuing the practice of having middle & hs students carry around huge backpacks full of books instead of some e-device with the books on it? Or is the latter just impractical.</comment>


Overwork killed 45-year-old engineer - <AUTHOR> http://www.msnbc.msn.com/id/25607064/

<comment><USER2> 80 hours of overtime per month? 20 hours per week? He died of overwork when he worked 60-hour weeks?

It's tragic that he's dead, but it's nonsense to think that 'overwork' was the main factor.

<comment><USER3> I agree, based on the article it seems to be the stress of the job rather than the hours worked that he died of.

<comment><USER4> Those hours contributes to the stress no?

<comment><USER3> I'd probably say the stress contributed to the hours.

If I know there is a lot of pressure on me to finish something by a deadline, I'll end up working more hours to get it done. Not the other way around.

</comment></comment></comment></comment><comment><USER5> Before I even clicked on the article, I knew it was from Japan.

</comment><comment><USER6> <http://en.wikipedia.org/wiki/Kar%C5%8Dshi>

<comment><USER7> Karōshi (過労死, karōshi?), which can be translated quite literally from Japanese as "death from overwork", is occupational sudden death. The major medical causes of karōshi deaths are heart attack and stroke due to stress.

<from above link>

<comment><USER8> An interesting fact hidden in the article: the family had to prove that the death was caused by "overwork" in order to get a payout from his employer's insurance.

So I guess it's a concept which exists mostly for legal reasons. The only reason they have it and we don't is that our insurance system doesn't work the same way.</comment></comment></comment>


Candy Crush wants you to lose - <AUTHOR> http://blog.appszoom.com/2013/10/25/candy-crush-made-for-losers/

<comment><USER2> Candy Crush's recruit friends to unlock levels mechanic is evil genius. As a user I loathe it, and refuse to partake in fact. But its crazy success says its a great move.</comment>


Economic status cues from clothes affect perceived competence from faces - <AUTHOR> http://wws.princeton.edu/news-and-events/news/item/split-second-clothes-make-man-more-competent-eyes-others <comment> d--b It's nice that there's a study that confirms this, but it is pretty obvious that people do judge other people from the way they look. Clothes is only part of the mix. Skin color, gender, face shape, eye color, hair styling, general posture, micro movements, smell, sweatiness, etc. also alter the way people will categorize others.

And then once they speak, the way the voice sounds brings another massive layer of pre-conceived judgment. Add social background, education, occupation, sexual orientation, etc. In the end, all these elements will form an idea of who a person may be.

Then this image erodes as one gets to know the other person.

</comment><comment> rm_-rf_slash Not surprised at all to see so many engineer-y types here on HN dismissing the importance of clothing even the face of evidence. I used to be one, until I saw _Kill La Kill._

Fact is, clothing has power. The ability to shape people's perceptions of you is valuable, and it can mean the difference between a deal and dismissal.

It can also have the adverse effect: wearing mismatching colors or patterns or clothing of poor condition signals immediately to me that the wearer is either unconcerned with their appearance or unable to distinguish between attractive and unattractive aesthetics - a major red flag on my perception of their judgement.

If someone wearing clothing like that works in tech I'll spend 30 seconds determining if they're too much of a super-genius to be concerned with their appearance (and if they truly are then they should acquire an identical wardrobe, Jobs/Zuckerberg-style). Otherwise, I think to myself that if this person is so lacking in perception to not comprehend how hideous they look, then what other major blind spots do they have?

<comment><USER2> For those of us who did not see _Kill_ _la_ _Kill_ , if it's not a major spoiler, could you let us know what was it in that show that changed your mind?

<comment><USER3> I'm smiling at the idea there's a lesson to be learned from Kill La Kill. It's an anime where there's special clothing invented that gives you superpowers. It's similar to saying you learned this lesson from the Spider-man villain, Venom, or watching Iron-man movies.

I guess the above poster sees it as a metaphor.

</comment></comment></comment><comment><USER4> Makes me think of the Stephen Castor incident yesterday, and his use of a reusable shopping bag to bring in documents to the impeachment hearing.

</comment><comment><USER5> The clothing itself isn't really what I necessarily expected, if you look at the pictures themselves ([https://osf.io/v2j43/](https://osf.io/v2j43/)). The "rich" clothing is just more like "formal" or "conservative" clothing, and the "poor" is more "casual". They seem to have tried to control for the formality aspect but I'm not sure they did so completely (for example, there's still blazers in the set with "formal" attire removed). I also suspect there's an age dimension involved as well, in that some of the clothing is much more likely to be worn by younger individuals than older individuals, or vice versa.

Of course this will be correlated with wealth, because dressier clothes are more expensive, and older individuals probably will have more wealth than when they were younger. However, the clothing isn't the spectrum I was expecting necessarily, and I'm not sure "rich" versus "poor" are the right labels.

Also, I can understand how most of the clothing came to be categorized the way it was, some of it is confusing to me. There's definitely items that I think would be classified in the other category. It would be nice to tailor this more to specific individuals more.

To be honest I'm a bit surprised this is getting this much attention because the social psychology literature is full of findings like this already.

<comment><USER6> It does seem to boil down to the idea that people in ties appear more competent than people not in ties.

</comment></comment><comment><USER7> I believe this, my wife replaced my raggedy coat and I can see the first impressions of people changed.

<comment><USER8> I can only confirm, since I started buying more expensive clothes (and hardware), people seem to have a better impression of me. (Both in professional and private life) It's kind of a waste though...

<comment><USER9> It's waste by definition. It's social signalling. It's sort of like blockchain proof of work, you show your commitment by displaying hard to fake wasted resources.

<comment><USER10> Social signalling isn't necessarily a waste, especially if you have a very high profile. When Justin Theroux shows up at an animal shelter and posts a photo of some dogs on Instagram, those dogs get adopted and it raises the profile of those animal shelters.

</comment></comment></comment></comment><comment><USER11> The most rigorous, controlling aesthetic of all is the one where you claim to have none.

</comment><comment><USER12> Thank God I am walking around with the most casual clothe possible and feeling good about it. I can't imagine being part of any "circle" where clothing is looked upon as a factor of who you truly are as a person. And by that, I mean deeper than personality or character.

 _In the eyes of Others..._ Who are these Others? What makes us so different?

<comment><USER13> People outside of HN and similar circles usually get impressed with shiny things. "Regular people", most often in business situations, or with business minded people. I run my own businesses and deal with a lot of this sort of situations, but also with some family and acquaintances, normal folks.

Like it or not, I've most likely been referred and/or gotten deals through due to my Omega Speedmaster, my Burberry winter coat, hade made expensive leather shoes, etc. That sort of clothes and accessories. Because it makes me look successful in the eyes of Others, and people wants to be friends and partners with other successful people.

Shiny things/expensive clothings/etc = Seen as I must be competent to earn that sort of cash.

My friends couldn't care less about what I wear, but they understand why I do it.

<comment><USER14> > Like it or not, I've most likely been referred and/or gotten deals through > due to my Omega Speedmaster, my Burberry winter coat, hade made expensive > leather shoes

I hate to break it to you (or maybe you will consider it a good thing), but no one took the time to notice those minute details about you. Store bought leather shoes that are well-polished look virtually identical to handmade. Unless you hold your watch up to people their faces, few are gonna spot its an Omega, let alone that the make is a Speedmaster (cheers btw, I love the moonwatches).

People will spot that you take care of your appearance and try to go for a sophisticated style, but beyond that few will notice the minutia.

Hell, I can do you one better: one time when I was at my parents for an extended stay I decided to buzz most of my hair off whilst they were shopping. I had pretty long hair. When they came back I had a conversation for a full minute before my dad suddenly said 'wait.. what the hell did you do with your hair?!'

<comment><USER15> > Store bought leather shoes that are well-polished look virtually identical > to handmade.

No, they're not. Shoes have a fairly broad spectrum of quality and style. Not everyone notices and not everyone can tell, but it is something that many evaluate.

Yes, it's a status signaling mechanism, but it is a part of culture whether you like or not.

These kinds of evaluations happen not just with executives in suits but also with youth and their ridiculous athletic shoes. Even gender-wise, women are apt to notice minute details of shoes.

<comment><USER14> > No, they're not. Shoes have a fairly broad spectrum of quality and style. > Not everyone notices and not everyone can tell, but it is something that > many evaluate.

Yes they are. Not in comfort or longevity, but as long as you don't completely cheap out on store bought you will get _close_. You're conflating quality and looks. They're related, but not synonymous.

> Yes, it's a status signaling mechanism, but it is a part of culture whether > you like or not.

Which I never said. I merely pointed out that people look more to the style package than what logos you wear. Hell, if you for example buy high tier Polo Ralph Lauren the logo is often put on the _inside_ of the collar.

> These kinds of evaluations happen not just with executives in suits but also > with youth and their ridiculous athletic shoes. Even gender-wise, women are > apt to notice minute details of shoes

Few 21-year old women will care if their date is wearing flashy DCs, flashy New Balance, or flashy Nike Air limited edition. You mentioned minute details: for the Nike, how many of them would even be aware of the difference between a limited edition, Nike ID or normal Laser Red batch? And dress shoes usually don't even have visible logos!

</comment></comment></comment></comment></comment><comment><USER11> This is because we are only steps removed from a feudal society

</comment><comment><USER16> Isn't the reverse true in HN circles? Where looking like Stallman implies competency?

<comment><USER17> Or signaling that i can afford to not care about clothing

</comment></comment><comment><USER18> now i can pretend i am hiding something with my shitty dress code

</comment><comment><USER19> Most everyone can look "rich" with cheap imported knockoffs of expensive clothing.

But peoples' choice of whether to dress "rich" or "poor" provides information about them.</comment>


What social bookmarking site has "lists"? - <AUTHOR>

I want to be able to post lists of links that share a common theme.  Like "how to become a better writer" or "essentials to starting a business" or stuff like that.  It would be like Amazon's Listmania functionality, except it would work for any link, not just Amazon products.
It doesn't seem like Delicious will work for this because they only have tags, not lists.  Google bookmarks does have public lists and I like their interface, but it looks like I can only share links to individual lists, not a link to main page, showing all my lists.
Like I said, I should be able to have a static link like bookmarkingsite.com/profile/amber to point people to that shows all my lists.  Viewers should definitely not have to sign in to the site in order to view my lists or visit the sites.
Please tell me this exists already.
Thanks! <comment><USER2> I don't think there is a bookmarking service that uses lists. Most of them use tags, which, for bookmarks, are more useful.

<comment><AUTHOR> What can I say, I'm a lists girl. There was actually a social lists site some time back, but I can't remember it now. I think it allowed you to make and share lists of anything, not even just lists (like, "what to pack for a camping trip", "my favorite books", stuff like that) Would love to find it, might be good for my purposes.

<comment><USER2> That's TaDa list <http://tadalist.com/> Create a list, share it - TA DA!

</comment></comment></comment><comment><USER3> Have you given Diigo.com a try?

<comment><AUTHOR> This looks good. Fulfills requirements, but a bit cluttered. Will try using for awhile and then upgrade to ads free.

Thanks!</comment></comment>


Ask HN: Demo application ideas for a Angular workshop - <AUTHOR>

Pls give some ideas for a demo application to make for an Angular workshop that will be around 4 hours. The workshop will be an introduction to Angular for developers that are familiar with Jquery. <comment><USER2> A typical todo application where you can assign users to a todo list.

Want to expand? Copy features from Google Keep (my most used one is a list)

Best of luck ;)

<comment><AUTHOR> this was my first idea, but I know every tut online does this and I want something special

<comment><USER2> Assigning users to the todo list and a list of todo's in a todo list lets you think about design (or copied from Google Keep). PS. Google Keep doesn't have "assigning users"

Also , the todo-object has a type, eg: single, list, image, sound, ... So you could make an extensible architecture.

Is that your typical "Hello-world" todo app? :-)

<comment><AUTHOR> I have to say that this is an interesting idea :)

<comment><USER2> Tadzaam ;)</comment></comment></comment></comment></comment>


Microsoft addresses Windows 8 secure boot issue - <AUTHOR> http://news.cnet.com/8301-10805_3-20111545-75/microsoft-addresses-windows-8-secure-boot-issue/

<comment><USER2> > The truth is that UEFI secure boot is a valuable and worthwhile feature that > Microsoft are misusing to gain tighter control over the market.

How could they use it then, without "misusing" it? Should they force the OEMs to also include certificates for Linux, Hackintosh, OpenSolaris, ...?</comment>


OKWS, the Ok Web Server (behind OK Cupid) - <AUTHOR> http://www.okws.org/doku.php?id=okws

<comment><USER2> I worked at OkCupid for a bit and got to see OKWS in its full glory. Though it sounds kinda daunting from the documentation, it's actually reasonably workable. I was able to get a rough app up that talked to a bunch of different internal services via async RPCs within my first couple days (the first compile took forever, though...).

One of the coolest parts of the stack was that every function call you made was non-blocking unless you wrapped it with BLOCK{...}, and within a BLOCK code that was written sequentially got turned into callback-based async calls behind the scenes.

The other cool part of the stack was getting core dumps on segfaults. Heh.

</comment><comment><USER3> This is a good design. For a project I've been working on recently, I've organized it as a set of loosely-coupled async applications. That way, I can run them all in one process (with ZMQ inproc messaging), or run them all in separate processes (with TCP or Unix sockets), depending on my needs for reliability (more uptime because I can deploy-and-restart one tiny component at a time) or memory usage (all in one address space = more sharing). It's worked quite well; I love being able to stop one component, deploy a new version, and restart it without affecting the rest of the app or losing data. It makes "oh, this process seems to be behaving oddly right now" much easier to work with -- SIGTERM the faulty component, watch it return to normal, debug without stress, commit fix, run tests, deploy new version, SIGTERM again, problem fixed. Relaxation driven development, I'll call it.

But what I don't see is how this applies to OkCupid and web servers. To me, their website looks 99% static, with a web form that sends messages. The "secret sauce" is all offline background processes that builds recommendations, sends email, etc.; certainly nothing to do with HTTP. And once your website is nearly static, you stick a cache like Varnish in front of it, and you can serve pages as fast as your system bus can stream from memory to the network card. All without writing your own web server, and without using C++.

That said, it is the nicest C++ app I have ever used.

<comment><USER4> _To me, their website looks 99% static, with a web form that sends messages._

have you used okcupid?

<comment><USER3> Yes. It's pretty much the same every time I log in.

</comment></comment></comment><comment><USER5> Personally, I feel this is the Achilles' heel of an otherwise splendid website. Their NIH syndrome forces them to implement everything in C++ ( <http://www.okcupid.com/faq> : 200K lines of C++ ). I don't know how to be agile with a system like that, and it probably explains the rate of feature growth compared to other social networks (FB, Friendfeed, Quora)

<comment><USER6> > I don't know how to be agile with a system like that

I think that they're implementing a lot of stuff in client side javascript because of that. A few days ago a redditor discovered that there're a lot of parameters of each profile right there on the page source, like the number of messages received today, last week and some attractiveness scale.

<comment><USER7> Where else would those parameters be than in the page source?

<comment><USER6> I wasn't clear: I meant, if you visit other people's profile, you can see that info there, that is used to display whether the person replies frequently or not.

</comment></comment></comment></comment><comment><USER8> "OKWS allows developers to program their Web applications in C++"

An application server for C++. Well, this makes it kinda interesting. Although lines like

      okclnt_t *make_newclnt (ptr<ahttpcon> x);
      okclnt_simple_t (ptr<ahttpcon> x, oksrvc_simple_t *o) : okclnt2_t (x, o), ok_simple (o) {}

do not look especially appealing.

<comment><USER9> Is your objection just to C++ syntax in general (in which case: total agreement) or something particular about OKWS? It seems pretty self- explanatory, as far as C++ goes:

      okclnt_t *make_newclnt (ptr<ahttpcon> x);

This declares a function that makes a new client from an http connection. It returns a raw pointer, so I presume the caller is responsible for the client lifetime. Whereas the connection argument is some ptr template, which I expect is a ref-counted or otherwise managed pointer, which suggests the client will keep the connection object alive. This is copying the ptr value, which if this is a ref-counting ptr would do an unnecessary extra ref-count during the function call, so they might want to pass it as a const-ref instead.

      okclnt_simple_t (ptr<ahttpcon> x, oksrvc_simple_t *o) : okclnt2_t (x, o), ok_simple (o) {}

This is a constructor to make a simple client from an http connection and a simple service. The only thing unusual is that a _t suffix usually suggests a typedef, and I don't think you can use a type alias to define a constructor.

I haven't looked at the API or done any web programming; I thought it was interesting what I could tell from this snippet regardless.

<comment><USER8> I think my biggest gripe is that naming scheme. Is it really worth abbreviating "client" to "clnt" or "service" to "srvc". And single letter variable names, seriously?

<comment><USER10> It reads a lot like those medieval manuscripts back when the European languages didn't have so many vowels in them. Maybe the OKCupid devs should take another page from the monks and get rid of whitespace as well. After all <strike>parchment</strike> horizontal screen space is a precious commodity.

</comment></comment></comment></comment><comment><USER11> I'm not here to stifle innovation, but does a company like this really need to invent infrastructure technology? I've served some pretty high traffic stuff-- secure web services included--and the current web server offerings have always gotten me there. Is it really cheaper to invent this stuff rather than buy an extra server?

<comment><USER12> OKWS came before OkCupid. It was developed by Max Krohn (<http://www.okws.org/doku.php?id=okws:publications>) of MIT/Harvard with DARPA funding (<http://www.okws.org/doku.php?id=okws:sponsorship>).

<comment><USER13> This comment should really be at the top. It makes 99% of the discussion on this moot.

</comment></comment></comment><comment><USER14> I thought I'd answer a few questions raised below:

(1) I've recently made a few updates to the wiki, adding a pointer to the new subversion repository: svn://svn3.okws.org/okws2/devel/3.1. I'm still actively checking in fixes and smallish new features, but there won't be any big changes over the next few months.

(2) OKWS and all services written for OKWS are single-threaded, non-blocking asynchronous processes. All database calls still go through RPC-to-SQL translators, as mentioned in the paper. File system I/O goes through libasync's aiod system: a small blocking helper process does the file I/O, and the main process communicates with the helper over asynchronous RPC.

(3) The documentation is horrible, I realize. I never quite find the time to do a good job of updating the wiki, or fully documenting what's there. If anyone wants to help me on that, please contact me! Variable names often truncate vowels, true. I'm stuck on 80-column mode and hate line wraps. If you write OKWS subclasses (as you do when you make new OKWS services), you can add vowels to taste.

(4) We actually think that given the size of our team (~10 engineers), we get features out pretty quickly. When things take a while, it's not that we use C++, it's that either the feature is a challenging technical problem that's deeper than language choice, or there's a ton of front-end work required (i.e., compatibility with two mobile apps and two HTML versions of the site).

As for why we wrote OKWS, and was that a good idea, one important thing to realize is that the landscape was quite different back in 2003 when we started OkCupid. Since then, threading on Linux has improved, and multicore is where the performance gains are. Also, we've seen RoR and Django get big.

So a good question is: if we were starting OkCupid again now, and if OKWS existed as is, would we chose it over RoR, Django, PHP, etc? Maybe. OKWS has some really nice features now that make is worth considering, such as: (a) the tame source-to-source C++ translation system mentioned by aston below. It's a great way to manage server-side concurrency, and I prefer it over threads. It's most similar to twisted in Python, but I prefer tame's syntax (perhaps I am biased). (b) The "pub" templating system. There are of course many HTML templating systems out there today, but the "pub" system built into OKWS gives a natural split between front-end and back-end programming tasks; (c) Performance --- we're still serving tens of thousands of pages a second from a few dinky web servers. These pages are 99% dynamic! We draw every page from scratch, more or less. If we wrote OkCupid in Python, we'd need about 10x the number of machines, and our serving bills would increase. (d) Caching -- the OKWS architecture allows simple single-process caches, which are really fast compared to going to memcache or shared memory systems. (e) Security and robustness --- we're still able to separate code so that one service can crash, while everything else runs without a problem.

If you're considering using OKWS, I offer these suggestions: (i) build a good build system, because it's true, C++ is a slow dog when it comes to big recompiles; (ii) never hand-manage memory (i.e., don't use new/delete), but rather, always use reference-counted auto pointers and safe C++ string/buffer classes; (iii) make sure you can find good C++ developers, they are hard to find!

</comment><comment><USER15> _"As of 30 March 2010, OKWS is still being maintained and worked on. See our Release Plan for more details."_

<http://www.okws.org/doku.php?id=okws:releaseplan> isn't very reassuring

Neither is `svn co svn://svn2.okws.org/ok/okws2/devel/3.0 okws-3.0; cd okws-3.0; svn log | less`...

</comment><comment><USER16> I don't know enough about their traffic to know how much machine efficiency would help them... however given that there are always C++ programmers to be hired, and that each program just does one thing, perhaps it gives them a layer of isolation and programmer replaceability that makes management happy.

</comment><comment><USER17> So how does it handle blocking io? I doubt it's using async io. If it's single process, single thread does the whole program block on io?

</comment><comment><USER18> why....

<comment><USER19> "Despite its emphasis on security, OKWS shows performance advantages relative to popular competitors: when servicing fully dynamic, non-disk-bound database workloads, OKWS's throughput and responsiveness exceed that of Apache, Flash (the reigning king of Web server performance) and Haboob (an academic system reputed to be the fastest Java Web server on the block). Commercial experience with OKWS suggests that the system can reduce hardware and system management costs, while providing security guarantees absent in current systems."

That's why.

<comment><USER20> I'm not sure "hardware and system management costs" are the biggest challenge a startup like OK Cupid faces. When you look at the cost of development for something like a web server, you really have to ask if that money wouldn't have been better spent acquiring customers while building your app on one of the myriad of excellent server/framework/language stacks available today.

<comment><USER21> With their concept of "free-standing services" for each endpoint, it sounds like they took the idea of CGI scripts and compile the logic against an HTTP wrapper. It -could- work if the build process spits out separate binaries from a single source base. I think I'll stick with using elastic computing to scale horizontally and spend resources on customer acquisition instead.

</comment></comment></comment></comment><comment><USER22> Just ok? why not great?</comment>


Ask HN: How to work with a developer who avoids reading? - <AUTHOR> Someone recently joined our team as a junior dev. Their work is good, but I noticed that when they're learning something new they generally watch a video. Often it seems to me to find out how to do something that is effectively a couple of lines of code. I asked them about it and they said they remember things better when they visually see the effect it has.
Also there are times when I ask a specific question like "What does such and such a library function return?" and they'll say "two strings" but don't know if it's a list or a tuple, of if it ever returns None, or whether it raises an Error etc. So at that point I'll open up the library documentation and read it with them. But they will never on their own initiative open the docs. They do read SO and tutorials.
I'm struggling a bit to collaborate with them because I have a strong bias towards reading (docs or books) to understand and they seem to have the exact opposite. They seem almost sad when I send them a link to raw information. <comment><USER2> _What does such and such a library function return? " and they'll say "two strings" but don't know if it's a list or a tuple, of if it ever returns None, or whether it raises an Error etc._

I program in three languages in any given week, not to mention using CloudFormation where every resource type has its own configuration. Why would I try to remember what a function returns off the top of my head?

For instance, I do a lot of work with Python and Boto3 - the SDK for AWS ([https://boto3.amazonaws.com/v1/documentation/api/latest/inde...](https://boto3.amazonaws.com/v1/documentation/api/latest/index.html)). Why memorize what any of the literally hundreds of functions return when I can just call the function and inspect the response within the IDE?

<comment><USER3> I think OP's point was that the person gives a vague answer off the top of their head instead of checking the doc to see what the actual concrete type is.

<comment><USER4> If a dev stopped me from working on something to make me look up some documentation for them that they can easily look up themselves, I'd be sort of annoyed.

If the extra info in the documentation wasn't actually important to the code implementation, I'd be more annoyed.

If the goal of asking is to help me grow as a dev, please directly tell me what it is I need to learn.

It seems like the OP is just as vague as the junior dev when it comes to communicating.

If the senior dev saw something in the junior dev's code and thought it was important to look at the documentation, why not just tell the junior dev that? Why does the senior dev have to tiptoe around and ask leading questions?

<comment><USER5> It's called "training". Teach a man to fish or give a man a fish.

<comment><USER4> Yes, why not actually train the junior dev?

</comment></comment></comment></comment></comment><comment><USER6> > Also there are times when I ask a specific question like "What does such and > such a library function return?" and they'll say "two strings" but don't > know if it's a list or a tuple, of if it ever returns None, or whether it > raises an Error etc.

I am curious to understand why you need to do this step? Is it possible to have a more hands off approach?

Give them a task and a deadline and then let them come back with the work. If they have a problem, then they can come to you, but if they have not done their home work, then they need to solve it themselves. Is it possible this is too much of involvement in their work?

> So at that point I'll open up the library documentation and read it with > them. But they will never on their own initiative open the docs.

How about telling them that they need to look it up (either in front of you or after they need to return to their station)? Would that work for you?

> I'm struggling a bit to collaborate with them because I have a strong bias > towards reading (docs or books) to understand and they seem to have the > exact opposite. They seem almost sad when I send them a link to raw > information.

Maybe they associate this and what follows with a negative experience? Is it possible to take a more hands-off approach? Sometimes it helps to appear dumb to the person we are mentoring. Let them figure out the steps that are figure- out-able like reading API docs etc., Only help in steps that really need your expertise and experience, but not effort.

I think this is because this is how the current generation thinks. I am mentoring some interns and my own kid thinks looking up YouTube for the solution is the right thing to do. They in fact search on the YouTube app on their phone and then go to Google.

</comment><comment><USER7> The real question is are they effective? If not, that is the thing to focus on, not how they learn. If so, who cares how many videos they watch.

I will say that I think it nay hinder long term career growth and should be given as feedback either way. But that can be more informal (a conversation like "I noticed you seem glum when I send you a link to the docs. Was wondering why?").

<comment><USER8> Who knows, maybe they have dyslexia or anxiety with reading or something. There might be a good underlying reason for the avoidance.

Either way I think the most relevant factor is as you said, are they effective? If they are, it's up to them how they learn.

The only other thing is that I might explain to them why it's important to read documentation so that they don't get surprised by gotchas.

<comment><USER9> Yeah, before I got diagnosed with ADHD (and got meds), I would only read documentation in special situations, as a last resort; ie, almost never.

</comment></comment></comment><comment><USER10> >"What does such and such a library function return?"

I'll just say that I usually don't memorize library functions intentionally. I let it happen naturally. If I use a function a lot, it'll get remembered. Usually an IDE/auto-complete module will have that information anyway. C# has spoiled me immensely.

That said, you should really promote reviewing the docs for a particular thing after watching a video. Ask them to experiment with this and see if they like it. I think this will help that type of learner cement their knowledge. Use both, not one or the other.

The other concern is potential security gotchas which usually aren't covered in videos/tutorials and not mentioned in auto-complete, especially if they are skimming the material to just get work done: they will disengage as soon as their brain gets what it wants from the video. Ask them if they are checking the dates on these things, because it could easily be out-of-date but still stuck high on Google's results.

<comment><USER11> I've found that I usually don't even memorize class names and method names even when I use them somewhat frequently; what I memorize is shortcuts/keywords that help me navigate to the actual code.

</comment></comment><comment><USER12> As an experienced dev, I can glance at an API documentation and start coding to use or work with it instantly. But when you take a junior dev, they don't have enough knowledge of basics to comprehend the documentation. E.g let's say the documentation mention concepts like CORS or closure etc, they have to understand those and this only comes from experience over the time. What they are doing, like reading SO and tutorials help them to collaborate in-line with the timeline with experienced devs. As and experienced dev, you can slowly coach them through discussions to develop his overall basic knowledge on a tech or concepts which over the time help him take your approach.

</comment><comment><USER4> Based on the OP's comments and word choice, it seems like the OP needs to work on his communication if he wants to work effectively with the junior dev.

Have you directly told and then shown the junior dev that reading documentation might make implementing a 2-line code change easier or quicker than watching a video?

Do you want to know what a library function returns for your own benefit? If so, look it up yourself. Why ask the junior dev?

As a senior dev, if the point of asking what a library function returns is to help the junior dev grow, why not just explicitly tell them what they need to look for (different outputs, errors being raised), explain why those things are important, and then show them how to find/use those things? Maybe the junior dev seems sad because you just randomly send them a link without providing any guidance in how to parse it? Maybe they seem sad because you're communicating to them in ways that show to them that you doubt their abilities.

You said that you have a strong bias towards reading and the junior dev has the opposite. But you said that the junior dev does read in the previous paragraph. Hmm.

Can you imagine this same post being written from the junior dev's point of view?

</comment><comment><USER13> Encourage them to read and REPL side by side.

Someone once taught me that the right way to read a math textbook is with the book on the left hand side of the table and a pencil and stack of paper on the right.

Coding seems similar.

</comment><comment><USER14> I don't understand the problem at all.

You say that the quality of their work is good so why does it matter if you learn things in differently?

</comment><comment><USER15> The simple fact is that while learning from videos is " _nice_ " it's _not_ the most effective way of learning _advanced_ topics which are usually not covered or diving into code/docs to gain a deeper understanding that is _never_ covered in videos.

Three _irrefutable_ facts worth reminding the "junior dev" of:

1\. Most learning is not captured in videos. (so if you rely on them as your only source of knowledge acquisition, you will _always_ be "behind" your peers and have incomplete knowledge)

2\. Videos go "stale" when new versions of code come out, "living" _textual_ docs can be updated and thus always current.

3\. Text-based knowledge is far easier to find/reference than videos which makes it easier to lookup quickly when needed. Trying to remember which video you vaguely learned something 6 months ago so you can look it up again and re- learn is super time-consuming.

<comment><USER2> Learning to write code in any language is not an "advanced topic". Advanced topics are around architecture, concepts, and ecosystems those can easily be taught by a video. It's much easier to watch a video where the screen is split between the code and the results of running the code.

2\. If a framework is bring iterated so fast that a less than year old video is stale - that framework is probably at the "peak of inflated expectations" part of the hype cycle and most likely should be avoided.

3\. Most good videos also come with a corresponding git repo.

</comment></comment><comment><USER16> Some people are visual learners and some people are readers, you can't make him/her change to 100% reading just like that, it's how their brain functions, suddenly switching to reading is harder than you think.

I'm a visual learner myself, I would watch a little video on x2 speed or go directly to a code snippet and move on, yes it's bad and I've got my ass bitten by this few times in my early days, so I forced my self to read the API references, the docs, and/or source code at least around what I need to use in my code and it's getting better with time.

Don't be upset and don't try to force it, he's/she's a junior, advice/push them to read the API references or the source code, keep sending them the raw info they will adapt, just don't hate the fact that they are "visual learners"

<comment><USER17> Are you aware there is little to no evidence to support so-called learning styles[0]? While it is true that some people may have a preference for a one modality over another, there is no indication that anyone learns more or better when taught in a preferred style.

0\. [https://onlinelibrary.wiley.com/doi/abs/10.1002/ase.1777](https://onlinelibrary.wiley.com/doi/abs/10.1002/ase.1777)

<comment><USER16> Where did I say "they learn better"? I almost said the same thing it's how their brain works "aka enjoys/likes to receive information"

I really hate the "throw a research paper at them" approach we are talking about a human... a preference of watching vs reading if someone is not comfortable with reading you don't hate/force them.

I'm a 5th-grade dropout... I'm not used to reading large books I get bored after 10 min and I won't learn shit if I'm bored, even videos are boring for me that's why I use x2 speed.

It's not a black and white subject there is dyslexia, ADD, ADHD, and a huge list...

</comment></comment></comment><comment><USER18> Why in the world would you care if someone knows the exact return type of a function? I intentionally don't try to remember such useless things.

</comment><comment><USER19> I've always been a reader but for the last couple of years I've found that the videos on Pluralsight do a far better job of introducing a new framework in a concise way when compared to the best rated books.

My experience learning compilers and automata theory was similar. I had trouble slogging through the Dragon Book but I flew through the Coursera compiler and finite automata courses. After that the Dragon Book was an easier read (although I never finished it as there are better modern books on the subject).

Once you're up and running the documentation is usually better.

I assume that this is because most books are either targeted at inexperienced developers or are purely API reference material.

</comment><comment><USER20> Ability to filter the knowledge one injests is one of the skills which makes a capable engineer. Reading with understanding and fluent expressing oneself in writing are essential. I did encounter many, non only junior level, developers/contributors learning mostly from the first 1-2 pages of Google search results returned on 2-3 keywords - articles from Medium (someone is looking for a job and posted bunch of articles for visibility), video with the latest framework-influencer, or from the latest Cloud-provider marketing event. So called blog/influencer-driven development - it's exhausting.

</comment><comment><USER21> I think it this is normal. I remember early on I would watch videos and shitty tutorials about servers and libraries, but slowly you begin to seek and trust the spec/standard. But only when you are more advanced you can do that.

As a beginner you are not looking for the source of truth just yet. You are not ready to look into CPU registers and read the code. All you want is to discover what you don't know. Hence you look at videos and SO questions that have _meta-data_ and advice attached to them, like "dont use goto/eval" etc.

</comment><comment><USER22> I think it would be helpful if you gave a better example of a time where you struggled to collaborate.

The examples you've given serve well to demonstrate that you prefer manuals and documentation while this person prefers examples and videos, but they are not really examples of attempts to collaborate nor of a struggle.

Folks here have been critical of these examples, but a more generous interpretation would be to acknowledge that _of course_ it can be difficult to mentor or work with someone with a very different approach.

Sounds like this could be Python. Since this person remembers things better see the effect, I think an improvement over videos would be exploring new material in ipython or a Jupyter notebook, where they can discover through autocompletion and get immediate visual feedback. Another would be to pull up specific bits of documentation through an IDE. Maybe you could show them how to do those things, so that they can get the information they need efficiently but in a way that they are comfortable with. But this would only be an avenue to help you depending on the actual things you and this person are struggling with.

</comment><comment><USER23> I had the exact same problem with a junior dev. I blogged about it here [https://hadalin.me/blog/how-to-become-a-better- programmer](https://hadalin.me/blog/how-to-become-a-better-programmer)

Too many people take the path of least resistance and want to deliver quickly, because hey, who wants to spend time reading the docs, it's so boring. But that's just one of those things you have to do. The best programmers I worked with all share the thirst to go deep when they start using a library or framework. They spend a significant time reading the source code and the docs until they have a clear mental model how the thing works. The outcome of such approach is very few surprises when running the code, because the code behaves how you think it should behave.

My advice would be to mentor the dev of potential problems that would arise if you only partially understand how the library works. The most obvious are bugs or worse, you go against conventions and end up rewriting the whole app because it becomes unmaintainable.

<comment><USER24> _The outcome of such approach is very few surprises when running the code, because the code behaves how you think it should behave._

And when it doesn't, you know exactly where to look to find the problem and often its solution.

For me that's the biggest payoff of reading the documentation or skimming it multiple times, it's a huge time saver when things inevitably go wrong.

Then there's also the ability to think within the whole scope of the lib as opposed to the specific thing you pulled it in for.

<comment><USER23> Exactly this.

</comment></comment></comment><comment><USER25> What's the culture and workload like? Do they have the time and space to think about learning things for their own sake, rather than to solve an immediate problem.

Perhaps sit them down and explain that being a junior dev is job of two halves - delivering immediate value to the company, but also developing _themselves_ and their craft so that they can do away with the 'junior' tag.

</comment><comment><USER26> I'm also a reader, and in my experience devs who don't feel comfortable with reading (most of them) tend to get better information flow through talking, unfortunately they're about as likely to be shy as other devs and sometimes don't get a lot of professional development because of this.

Get in the habit of talking to them about code casually. ("Have you seen the X library", "I implemented another splay tree today, whoah!") I also send juniors youtube links unless they've expressed they don't like video, there's now a bunch of solid technical content there, better than books in terms of being up to date I would say.

A ton of people watch videos sped up 1.75x or 2x, and young people often are in the "classroom" mindset that everything where they are a passive receiver is made of gold and benefit from being explicitly told they can skip parts, watch vids out of order, speed up and then slow down, etc. This may help conserve his time.

</comment><comment><USER27> Give them some code to debug that fails on a technicality of one of the involved components. This is good practice and will help them understand why a formal definition of what something does can help you where a tutorial or stack overflow answer often can't.

</comment><comment><USER28> Let him learn his way and don't micromanage that. Don't go out of your way to search for videos for him either. When you have good text that cowers what he needs, sent that text.

You two should not need to learn the same way and have same preferences to collaborate.

</comment><comment><USER29> I have been in your situation.

Honestly though, not everyone learns in the same way. I have known this person for about 15 years and I can't say it has hurted his career at all.

(I have worked with him on several projects in these 15 years).

Just let them learn how they prefer to learn. ;-)

<comment><USER30> > Honestly though, not everyone learns in the same way.

I'm not really sure this is a true statement. In my experience people merely _remember information_ with different efficacy for different techniques. I suspect we all _learn_ \--that is, create an effective mental model of things-- in more or less the same way, which is by supposition, testing, and refinement. Maybe that's just me being biased towards my own mechanism though?

<comment><USER29> Agreed, I should have perhaps said a different _preference_ :)

</comment></comment></comment><comment><USER31> Two things:

1\. We read much faster than we speak, so watching a video is massively less time-effective. If the junior is doing this on company time, they're costing money.

2\. There was an article somewhere about a dev exhibiting these 'symptoms'. Turns out they were barely competent. Their entire method was to copy code they found on the Internet, and paste it in. They were entirely incapable of writing code from scratch. The article went on to elaborate that, after extensive (expensive) coaching from the senior dev who authored the article, the person turned out to be a pretty good developer. They just started their career trying to advance by gaming the system.

<comment><USER2> 1\. It depends. If I'm learning a new framework, language, or technology, I'll generally watch a video to get an overview. This will generally tell me the _what_. When I start working, I might not remember the _how_ but I'll look that up. Whether it's fair or not, a lot of companies look down on learning on the job - especially watching a video. I'll ususlly watch videos at home and just read docs for specifics at work. Most of the time you can cobble together the template of a solution from code you find on line and modify it if you know what you are looking for.

2\. The poster said "Their work is good...". If their work is good, why does it matter the how?

</comment></comment><comment><USER32> Have them write unit tests for a few functions until they reach some high bar for coverage maybe? That would seem hard to do without reading formal docs. And might show why they are _sometimes_ important.

</comment><comment><USER33> Do you RETAIN the answer you find in books? Maybe they only need to watch the video once and can retain it forever because the rich visual stimuli gives them so many different neural pathways for recall.

</comment><comment><USER34> The problem is today people learn programming by watching videos. When they go in a professional environment this knack of learning by videos remains there. I have suffered from it, and i attribute it ti video tutorial for everything sickness, but it hurts when there is no tutorial for the thing you are trying to achieve, then oneself is forced to read documentation to do the thing.

</comment><comment><USER35> I'm the complete opposite and always have been, i can't get past 1-2 videos, before I'm tired/bored. Give me a project/task and then some api docs or guides and I'll read/scan/trial and error the shit out of it till I accomplish my goals.

</comment><comment><USER36> Videos are an effective way of learning for many people. I personally hate them, but I also sometimes end up struggling with trying to figure out concepts on my own when it would've been 10x easier to look up a video and have someone more experienced casually explain it in 2 minutes.

</comment><comment><USER37> If he's not effective, then you should probably let him know that his methods are wasting time. If he's effective, then you're the one who is wasting time. I don't think it needs to be more complicated than that. One of you is in the wrong, the question is who.

</comment><comment><USER38> I think you are being a _bit_ harsh people have very different learning styles and if you are using an environment that has very fully featured IDE support (e.g. C# and Visual Studio) a lot of need to reference web based documentation is removed, at least most of the time.

</comment><comment><USER39> If they are learning... and learning effectively and efficiently. It doesn't matter. If you think the videos take too much time... you could suggest he try a "video speed-up" plugin... watch things at like 130% or 140%.

</comment><comment><USER40> I find this to be largely generational. Younger people tend to be more visual. As long as the source of the videos is accurate and complete, I would not worry about it.

<comment><USER41> I do find for basics that video tutorials often delve more into the _why_ someone's doing something than dry documentation often would.

I've been coding for two decades, so that's not something I need, but I can see why it'd be appealing to someone just starting out.</comment></comment>


Makerbot killer? Ultimaker: There's a New 3D Printer in Town - <AUTHOR> http://blog.makezine.com/archive/2011/08/ultimaker-theres-a-new-3d-printer-in-town.html

<comment><USER2> Does anyone make useful things with these? How come the article doesn't give the accuracy and resolution or are people just printing crude shower curtain rings really quickly?

<comment><USER3> My friend fabricates bottle openers, for starters, which go for as little as USD$4-5 on etsy.com.

<comment><USER4> How much time does it take? What are the materials cost? What are the operating costs? How much does the machine cost? Just trying to do a bit of break-even calculation and figure out what the profitability point is on a per-item basis... since I might do the same [grin]

<comment><USER5> back of the envelope, a thingomatic is $1300. If you get it working well, it'll happily print for days unattended. electricity and plastic i'd guess is less than a buck an hour. ABS plastic is dirt cheap. less than $20 per pound, stuff you print weighs a fraction of an ounce.

</comment></comment></comment></comment><comment><USER6> When is someone going to develop a quality desktop 3D printer? I know I would be willing to pay many times the price of a Makerbot for a proper printer.

<comment><AUTHOR> I think you can get a "real" desktop 3D printer for about $5K these days. But the consumer build-it-yourself designs are doing reasonably well, and actually give very, very good results - the catch is you have to be willing to put a _lot_ of time in.

<comment><AUTHOR> I guess I would also note that these guys are all kind of headed in the direction of competing with the "real" desktop 3D printers, but yeah, they won't be there for a while. I wrote some further thoughts here: [http://justindunham.net/2011/08/where-is-open- source-3d-prin...](http://justindunham.net/2011/08/where-is-open- source-3d-printing-going/)

</comment></comment></comment><comment><USER7> Higher resolution, but further from a finished product: Junior Veloso's experiments: [http://3dhomemade.blogspot.com/2011/03/high-resolution- compa...](http://3dhomemade.blogspot.com/2011/03/high-resolution-compared-to- fdm-kit.html)

He's using light from a projector to harden liquid resin.

</comment><comment><USER8> Whatever it is, it looks a clunky mess. This is not the leap in 3D printing I was hoping for.

<comment><USER3> To each his own, I suppose, as I rather like the build of exposed wires, bolts, rivets, and the likes -- I'm not alone.

I'm not sure what "clunky mess" means or how device asthetics correlate to "leap[s]" (in ability?) in 3D printing.

<comment><USER8> I was actually referring to the produced piece that came out of it. It seems to have rather poor resolution, and there are what appear to be stringy anomalies and uneven portions. The machine itself is not relevant to me. I don't care if that looks clunky. But if the produced piece is a clunky looking mess, that's a problem.

<comment><USER9> Ah, "clunky" tends to be used to refer to ungainly _machines_ , which is one reason most people reading your original post will assume you're discussing the aesthetics of the printer and not its products.

The other is of course that the title of the submission is about the printer, so using "it" without further clarification will not be read as referring to something mentioned only in the article.

</comment></comment></comment></comment><comment><USER10> Could anyone tell what it was making in the video?

<comment><USER11> On their blog they say it's a Mendel part: <http://www.thingiverse.com/thing:1768></comment></comment>


Apple scores limited victory in smartphone patent war - <AUTHOR> http://www.reuters.com/article/2011/12/20/us-htc-apple-patent-idUSTRE7BI24620111220 Apple Inc scored a narrow victory against Taiwan's HTC Corp in a patent lawsuit over smartphone technology that will set the stage for further battles between rival makers in the fiercely competitive market. <comment><USER3> I love this quote - "We think competition is healthy, but competitors should create their own original technology, not steal ours."

Reminds me of that time when Apple invented the mouse-driven GUI.

<comment><USER4> You could say that about much of their products.

</comment></comment><comment><USER4> "Limited victory" is right, starts with 10 patents and gets reduced to one patent covering automatically linking phone numbers to bring up the dialer on click? Seems to me the result is that Apple lost rather badly in this case. This is the second time I've seen a misleading headline suggesting a Apple victory in a patent case but turns out to be a loss once you've read the details. What's the deal with that?

But really? They have a patent for making telephone numbers in a document click-able to call that number? That seems so obvious a thing to do on a phone why grant the patent? Plus, if HTC can come up with a workaround so easily and quickly doesn't that also support the thought it's an overly obvious (i.e., useless) patent? Did I understand that part correctly?

<comment><USER5> I'm pretty sure I saw that functionality in devices that existed long before the iPhone.. fucking patents.

But to be fair, an import blockade is a pretty solid victory. Unfortunately for Apple, HTC can release a software update to disable the "infringing" functionality and quite possibly reinvent it in a way that isn't infringing anything.

<comment><USER6> A blockade now would have been a solid victory. A blockade months into the future for a trivially disabled feature is pretty much a joke.

I worked on a touch pad in '99 that had this functionality, and I'm pretty sure we didn't come up with the idea.

Unfortunately we never got it into mass production, and I doubt sufficient details were released to use it as prior art. Nokia's Screen Phone might have had similar functionality.

(Search for FreePad if interested - still a few articles available)

</comment></comment></comment><comment><USER7> Any victory for anybody in the patent mess is a loss for everybody, period.

<comment><USER8> Except patent lawyers :(

</comment></comment><comment><USER9> Pretty small potatoes. I wonder what the Apple executives, canny competitors by most accounts, really expect to accomplish from the legal campaign. Do they mostly intend to raise the stakes for their lower margin competition? Delay major Android phones at a crucial juncture in the race? This gets negative PR in tech circles, but you wonder if it plays well to the broader public - <USER2> more respected brand is making serious claims that lesser brands are copying/stealing from them.

It's easy to cast this as a Heart-of-Darkness style deathmarch, but unfortunately, I think Apple is finding value in the whole enterprise, even if there isn't a resounding victory.

</comment><comment><USER10> Earlier discussion here: <http://news.ycombinator.com/item?id=3371392>

</comment><comment><USER11> Honestly, any win for any company in that area is a loss for the whole industry.

</comment><comment><USER12> These victories all look rather like failures.

</comment><comment><USER13> It'd be cool if HP would smack apple up a bit with the Palm patents.</comment>


CSS Vertical Align for Everyone (Dummies Included) - <AUTHOR> https://medium.com/outsystems-experts/css-vertical-align-for-everyone-dummies-included-44af86f4ba40#.wwfriqyh7 <comment><USER2> O love the Toads. Personally an eye opener</comment>


Pure: A Static Analysis File Format Checker - <AUTHOR> https://github.com/ronomon/pure <comment><AUTHOR> The backstory:

Somewhere between an HN thread on July 4 2019 ([https://news.ycombinator.com/item?id=20352439](https://news.ycombinator.com/item?id=20352439)) and David Fifield's generous references to @ronomon/zip on his website and in his "A better zip bomb" paper, I received an email from Maxim Vainstein, an R&D Lead at Microsoft and the head of their Product Release and Security team, asking me to port @ronomon/zip from JavaScript to C, so they could use it as a static analysis tool to scan all software released by Microsoft.

Microsoft were happy for me to licence the work under the MIT licence and so @ronomon/pure was released today. I have only a few years experience in C, and am confident there will be some fairly embarrassing flaws in the code, please let me know what you think. I am also considering a port to Zig as a safer, simpler implementation that remains C-ABI compatible for portability and easy embedding.

At present, Pure does exhaustive file format checks on zip files, but I want to expand Pure as an open-source static analysis tool for more file formats, starting with MS-CFBF Office files. This recent paper in VirusBulletin shows some staggering results for static analysis to detect 90% of zero-day exploits in Office formats (see the table at the end): [https://www.virusbulletin.com/uploads/pdf/magazine/2019/VB20...](https://www.virusbulletin.com/uploads/pdf/magazine/2019/VB2019-Shah.pdf)

I think email might prove to be the perfect place where something like Pure could be put to good use, where a combination of policy (no executables, no macros) and static analysis on the remaining file formats can narrow the gap and obviate the need for machine learning or CVE-laden antivirus, protecting whole groups of users through an opt-in "please defend me from malware email attachments" mode, without requiring buggy software vendors to improve the quality of their software. At the same time, it's moving away from Postel's Law and helping to enforce and uphold open standards and debug software with fail-fast feedback.

Email is the number one delivery vehicle for malware but most email providers don't have the open-source tools available to protect their users. My hope is that independent email providers such as Hey and Fastmail will consider sponsoring work on new file formats in Pure and come on board to encourage adoption.</comment>