Ask HN: How to succeed in tech as an introvert? - <AUTHOR> Just some background: Currently a student and introverted to a large extent. I tend to avoid company parties or any other large gatherings. I'm intimidated whenever I intern at a new company because it seems like every other intern is outgoing and making the most out of their experience. Just as an example, some interns invite random people working in completely different departments to lunch. I've noticed most people who go out of their way to do things like this do go on to to be successful in general.<p>So my question is, knowing that I'm (very) introverted, how do you think I should change or improve myself to have a more successful career? <comment><USER3> I am an extrovert. I had a corporate job for over five years. During that time, I was too sick to glad-hand everyone I met like I might have done in my twenties.

For this reason, I did a lot of communicating via email. I felt like I wasn't doing as well as the more extroverted types who were more obviously able to suck up to our immediate superiors.

Then me and some of my teammates were moved to a new team. My very professional and established track record of sending emails most of the time meant my questions were still getting the answer I needed. The seemingly successful extroverts were incredibly frustrated and tearing their hair out. They didn't know how to function in the new conditions. They began turning to me for advice on how to get things done on the new team, physically separated from the people they had established relationships with.

Learn to play to your strengths. Being an extrovert isn't necessarily all it is cracked up to be. Most of those so-called friendships are more shallow than you think.

If you can find a nice and sympathetic extrovert, they may be able to do some introductions and the like for you and bring down your stress levels. I did that sort of thing sometimes for a painfully shy teammate. But, beyond that, don't believe too much of the hype.

<comment><AUTHOR> Thank you, this advice means a lot. Email is something I never thought of and I definitely plan on doing more of it from now on.

<comment><USER4> I'm going to warn against it. Overdependence on email has hurt my career on several occasions. Most people hate reading work emails and they will resent you for making them do it (read: they usually won't do it at all; at best, expect them to skim). The best work emails are short -- and I mean short, like two sentences short.

Email can be a useful tool and learning to communicate over a distance is really important, but I can't help but think you're going to hurt yourself if you see email as a substitute for face-to-face.

<comment><USER3> There are times when face-to-face really matters and I did tell that to my frustrated coworkers. But their heavy reliance on face-to-face broke when things changed. So, it isn't inherently better in all ways, for all things.

I did make sure to get with someone in person (with a printed version of the files I was working on) for certain thorny issues. But if you communicate well and succinctly via email, about 90%-95% of routine stuff at my job that required input from one of my superiors could be effectively handled by email. This eliminated the need to try to arrange face-to-face time, which can be logistically challenging when you both have busy schedules and deadlines.

This was a big stress point for coworkers of mine who learned the hard way that, no, your boss that you are squeeing at all the time is not actually your friend. I cultivated a professional relationship with my superiors. I was not able to squee at them and suck up and blather on. I was too sick to do all that stuff.

They didn't need to like me. They did need to respect my competence, answer my work related questions and sign off on things above my pay grade that required authorization. I was still getting that after the new team was formed and lacked a dedicated lead, so everyone was still required to seek certain things from our old lead, whomever that happened to be, until they could free up resources and assign a lead to the team. Other people were tearing their hair out.

Email does not work for everything. But if you learn to communicate well via email, for many things, it is actually superior to face time because you have a written record of your boss's authorization, professional opinion or the resource they directed you to. It isn't your word against theirs if something goes wrong. There is a paper trail. If you, in fact, did as you were told and it was the wrong thing, they go after your boss, not you. If they told you verbally and are not some kind of paladin-like being, the odds are high that you and they will "remember" it differently and you are the one that will take the fall.

<comment><USER4> I agree to an extent. It's definitely beneficial to get a paper trail when you can. However, bosses know about the radioactive nature of email and actively avoid creating a trail for anything they're not willing to get on paper. It's also useful to know how to write an email that will get a task done and move things along.

However, I have to disagree 1000% on it not mattering if someone "likes" you. It matters a great deal. Of course, being an obvious brownnoser is contemptible. But being well-liked is the most important task of any and every employee. When push comes to shove, it's going to be easier for them to overlook your professional inadequacies than it will be to overlook their personal affectations.

</comment></comment></comment></comment></comment><comment><USER5> I recently read a post on Quora that asked how an introvert could succeed as a doctor.

Like that poster, it seems you are experiencing more than introversion. Perhaps you are shy and/or suffer from social anxiety. These are distinct from introversion and can be treated. Introversion by itself is nothing to worry about.

[1] [https://www.quora.com/Is-there-a-place-in-medical-school- for...](https://www.quora.com/Is-there-a-place-in-medical-school-for-an- introvert)

</comment><comment><USER6> I am an introvert software engineer, but I let my code do the talking and I take on mostly purely technical roles. I am a little shy and awkward at times but I can do my job just as good as if I wasn't an introvert.

I guess it's just about finding the right job for you, my advice would be if you love what you do don't let being an introvert divert your passion. Some of the best colleague programmers I have ever met were introverts.

<comment><USER7> > let my code do the talking

this is really it in a nutshell. we're here to make software, not to make friends. if you have the technical skills then you can do just fine for yourself.

<comment><USER4> This is true, but please do be aware that any social grace you can pick up will go a long way, and that someone with this attitude will never successfully progress into a managerial role.

<comment><USER8> Not only that. In order to work with other people you have to understand them to certain extent in order to have a peaceful coexistence. Having social grace is an essential quality to work with other people even if you don't want to be a manager.

</comment></comment></comment></comment><comment><USER4> Go to company parties. Skipping them hurts.

At the intern level, the most important thing you can do is build firm relationships with the people that are immediately associated with your work. Focus on impressing a substantial subset of them. In engineering, you'll lose credibility by looking too "businessy" and requesting lunch meetings with everyone and their dog.

Practice talking to people. Practice meeting new people. Go somewhere where you introduce yourself to strangers. Do this over and over and over again until you're good at breaking the ice and feel fine in a room full of new faces. That's really all you need.

The people requesting lunches from random people are not doing it because they're extroverted. Meeting new people/establishing new relationships is a high-energy thing and it's not likely they're excited about it either. They're doing it because they are consciously trying to expand their network.

Your network is critically important, but you don't have to go breadth-first. I'd suggest depth-first is better. Build stronger relationships with fewer people who are localized to your target expertise for now.

</comment><comment><USER9> I recommend looking for a new career path. Software is no place for introverts. You were born a few decades too late: back in the good ol' days, software was a good place for someone who liked a quiet office environment with their own office or cubicle, who'd be left alone most of the time to get their work done by themselves. Not any more. Now it's a "team sport" as 'timfrietas' says here: you're going to be in a noisy open-plan office environment with people interrupting you constantly. It's absolutely the wrong environment for an introvert. You're still a student, so you can change majors now and go into something more suitable for introverts, unlike us older guys who are now stuck. Sorry, I wish I had some more positive advice for you.

<comment><USER10> I don't agree that "software is no place for introverts". There are definitely many software engineers out there who are introverts. You just have to find an environment and team mates that are welcoming and accept you as who you are.

<comment><USER9> Yeah, but you'll never get any peace or privacy away from them. Welcoming teammates does not make work bearable when they're on top of you all day long because of the open-plan office.

<comment><USER4> It really depends on how you go about it. Software engineers are one of the few professionals that can do well for themselves working remotely from a home office. You won't make any political progress this way, but you can be a happy code monkey. It takes some effort to find good positions that accommodate this, but they do exist.

Source: over the last 8 years, I've spent a cumulative 1 year working in an office, and the remaining 7 from home.

<comment><USER9> From everything I've seen and read, these positions are becoming more and more rare.

</comment></comment></comment></comment></comment><comment><USER11> Hello fromtheshadows,

I will give you two pieces of advice you may think conflict, but they do not.

1) Your fellow interns might be trying too hard. You may be too young to recognize this but unless they are truly exceptionally gifted social animals (hint: they are probably not) they are trying very very hard to gain favor with senior management who will ultimately make the decision to hire or recommend them to other roles. This does not always work; it can work if they are genuinely personable (some actually are), and it can sometimes work if they are not but there are weak personalities in senior positions who think "this person must deserve it because they tried so hard too engage people". Just know that not every super-networker is admired by those they are trying to connect (read: brownnose) with. Ignore them and focus on yourself.

2) Software is a team sport. If you can't engineer as a team with your fellow developers; if you can't disagree yet compromise or think one one way but be swayed by another engineer's point of view; if you can't learn from the senior mentors who are teaching you that software is in part a social activity, well, I hate to be the bearer of bad news, but you're not likely to achieve the full potential of an exceptional software developer. You can get a job in the industry, surely, but you'll never be as truly valuable as someone who can communicate effectively with their peers. It isn't about being a hit at parties--but being someone whose opinion people can trust because you listen and thus people listen to you. This requires non-zero social skills, but you don't have to invite the Marketing team to play air hockey after work--you just need to be able to understand what you're building and why and ask for clarity if you are ever unclear. This DOES extend beyond your core engineering team (e.g., this means you have to talk to your product owner and other stakeholders). You have to be able to communicate with those people not just now but forever in this industry. If you just can't, either consider another role or consider a narrow, well-defined individual contributor role at a well- established company where you are ok with not advancing.

Do you need to change yourself? It is hard to say; I am not sure how old you are and where you are at in your career. But do be a team player who is curious; just know that you don't have to drink a gallon of beer or play ping pong until 9pm to be respected--you just have to be a good listener, a good asker of questions and someone people look forward to collaborating with.

</comment><comment><USER12> In today's world you won't pass the interview process as an introvert. You have to come up strong and confident otherwise interviewers (other dev folks) will eat you alive during technical interviews.

Long story short, it has become the most competitive field in the world. The Zuckerberg era is over. You need to talk a lot, friends, an active network, warm introductions, etc to make it pass the interview process. Otherwise you will hear things like "lack of passion", "not a culture fit", etc.

<comment><USER13> Being an introvert is not the same as weakness and lack of confidence. A confident introvert can exert social forces to look bubbly during an interview.

<comment><USER12> Sure... Being a software engineer is not the same as doing whiteboaring all day. But guess what, %80 of the final decision is based on your whiteboarding performance.

The interview process is so unfair and broken, anything not standard will go against you. Companies focus on the negatives and forget about all the positive things you've done. To get hired you need to score 100 (positive) - <USER2> (negative). Being an introvert is not a big deal but it'll be seen as something that can impact your performance at work => "and for this reason - I'm out" :) Shark tank style.

</comment></comment></comment><comment><USER14> Just because somebody is an extrovert doesn't mean that they will be successful. Regardless of your personality you need to produce good work and get recognition for it. Extroverts simply seem to be better at blowing their own horn. But if they don't produce they will be quickly found out.

In my experience you have a great deal to gain from join a local Toastmasters chapter. Not only will they help you overcome your social anxiety, but you will also gain skills to become a more effective communicator.

<comment><AUTHOR> I never meant to imply extroversion == success. I was just saying how, from what I've experienced, most people doing extraverted activities tend to be successful. Toastmasters sounds like a great idea! I am, however, 99% sure that I don't suffer from any sort of social anxiety. You can read my other comment on this. To add to it, I have no trouble talking to new people; I'm just not a huge fan of it due to my inherent introversion.

<comment><USER4> If you don't think there's a major underlying issue, Toastmasters is perfect. You just need to get used to meeting people and practice breaking the ice and you should have no problem. Do everything you can to get experience with this until you feel 0 reticence.

You don't necessarily have to start inviting random people to lunch, but being able to break the ice and being comfortable around new people is important. Other people are feeling that anxiety too and it's stopping them from getting out what they want. Practice until you become so good you can put the room at ease and make it easy for others to get out what they want to contribute and your skills will be highly valued.

</comment></comment></comment><comment><USER15> Leverage written communication. I'm somewhat introverted myself and I've worked with people who were very introverted. You'd be amazed at how well written communication can make up for infrequent and awkward social interaction. You may also find that you become more comfortable with people through writing and that helps things flow IRL.

What I would guard against is under-communicating. Don't allow your social aversion to hinder your communication. Bosses and teammates strongly prefer people who communicate what they are working on, what problems they are encountering, and what their expectations are. If people don't hear from you, they'll also tend to think you are slacking off. Never assume that people will see the code and know you're working. I've been burned by this. It's better to under-code and over-communicate, than the other way around.

</comment><comment><USER16> I think introversion is not what you are describing as the issue, it sounds more like some social anxiety.

<comment><AUTHOR> I'm pretty confident it isn't social anxiety. I'm great at talking to people I'm comfortable with, almost to a point that I love socializing with them. With people that I've just met, however, it's different.

<comment><USER17> I can relate a lot to what you've described; I've always felt uncomfortable in large social gatherings, especially with people I'm not familiar with. When interning at the company I work full-time at now, I knew of several interns who acted like you described (i.e. getting lunch with random coworkers from different departments), and I never felt comfortable to do the same. In my experience as an intern, it matters more to make connections with your mentors/teammates who you're working with over the course of your internship, since they're the ones who'll be providing the majority of the meaningful feedback that determines whether you get a return offer. That being said, it can be worth going out of your comfort zone sometimes! Meeting new people is something that will happen a lot over the course of your career, so my advice would be to focus on making a good impression when you do happen to meet new people rather than going out of your way to make a bunch of connections. Barring a toxic work environment, you'll do fine as long as you have a good relationship with your teammates and immediate superior and don't actively alienate anyone else.

(For what it's worth, I've seen quite a few threads like this that seem to get responses saying that the OP has such and such psychological condition; it kind of astounds me how so many people a feel that it's prudent to provide a stranger with unsolicited medical diagnoses based on a couple paragraphs they posted on the internet. You're under no obligation to respond to them, so feel free to disregard them if you'd prefer to.)

<comment><AUTHOR> Thank you for your advice! I definitely try my best to have genuine conversations and connections with my teammates and will continue to do so.

I was kind of surprised by the many comments saying I suffer from social anxiety, but I figured their lack of information about me lead to their diagnoses. So, I hope they think otherwise after my responses and instead provide great advice like yours.

</comment></comment></comment></comment><comment><USER18> Don't be distracted from delivering the highest quality most thoughtful work and contributions you can, that's what will count most. Use your social/verbal communication time efficiently; e.g. help others on your team, and be seen to do so. Otherwise you can ignore all the extroverted people and their gibbering. All the intelligent people in tech know that meetings are nearly always extremely inefficient and that people's off-the-cuff output in meetings is much lower quality than thoughtful written output. So don't worry about it; just concentrate on excelling at the stuff you love and fuck all the extroverted meeting-oriented stuff, it's nearly all nonsense.

</comment><comment><USER19> First be comfortable with it, introvert and proud. Be comfortable Not talking to people,its ok. If you are at some gathering learn to be completely comfy sitting alone and chillin. No one there is more important than you, so who cares what they think. People are drawn to people who are comfortable with themselves even if not outgoing.

Be quick to smile and look people in the eye.

Practice by simply giving someone a compliment (that you mean). "nice tie" "I dig your hair" whatever.

I find large gatherings tedious and people draining but oddly at this point I am really well received, mostly because "I dont care" and a smile goes a long way.

<comment><USER20> >be comfortable with it, introvert and proud

That's the hardest thing to understand. I had all these issues until I realized that: A) me is me, and it is permanent (and I _am_ important to me); B) my empathy and caring what others think is mostly my own illusion.

Meta-issue is that 'be comfortable' is probably a thing that doesn't come easily. First step for me was to start to accept future uncomfortable situations, instead of trying to prevent them. Acceptance is not a comfort, but it leads to it.

<comment><USER21> I'd just like to say that it isn't permanent. You can change. I used to be extremely introverted; now I'm extremely extroverted. I still need a certain amount of alone time, and I'm fine with that, but I'm no longer what I would consider "shy". And yes, there is a difference between "shy" and "introverted", but I think that in a lot of cases people who say they're introverted actually have social anxiety, which you can absolutely conquer.

<comment><USER4> Yes, this is very important. We give up way too much in modern society. "I can't help it", "I'm stuck like this", or "there's nothing I can do" are cop outs 99.99999% of the time.

Change is not always easy, but it is nearly always possible. Don't believe defeatists who want you to believe that you're stuck (a belief they usually push because they benefit from your non-movement).

<comment><USER20> From what I know from confident introverts (these guys and girls speak freely and not confused of sharp words, but never initiate pointless chit-chats), they actually hate people, their pointless emotions and dummy dreams. I'm not sure that they want to change.

</comment></comment></comment></comment></comment><comment><USER7> Yes, social anxiety can be crippling. But as you say, you are fine talking with people you are comfortable with. Well guess what? In software engineering over 90% of your interaction is with team members who you will be comfortable with.

Also, sometimes just being an expert at something makes it easier to be confident. You might still be awkward and anxious at a happy hour, but in a meeting or technical discussion you speak confidently/authoritatively, based on your expertise and interest in the subject.

</comment><comment><USER22> According to high performer Joshua Waitzkin (who is not an introvert), people perform at their best when what they do is aligned with their personality. So if you want to be successful, don't try to avoid what you are. Embrace it.

And read this [http://introvertdear.com/](http://introvertdear.com/)

</comment><comment><USER23> Twenty years into my career and also being very introverted, I will say you are most likely in for a very hard road ahead. As others have said, your work will literally have to speak for you and, unless you are truly outstanding, even that might not be enough to ensure a smooth career. People value other people whom they have a relationship with, whether formed through professional contact, lunches, company events, etc. (Even being an introvert, you will too; humans are social animals.)

What I would suggest is:

-Learn mannerisms to indicate that you're friendly to people you don't know well without having to interact much. For example, wave or smile (and I mean a sincere smile) at people as you pass them in the hallway that you know.

-The people you work closely with are the people that you will get comfortable with and be able to interact with more easily. These few people will have to form the basis of your professional network to help you find career opportunities in the future. While you are, of course, naturally helpful and hardworking, you're also going to need to be helpful, hardworking, etc. in a way that they can see and will vouch for to others.

-Maintain your network. Take the effort to meet with former colleagues every once in a while or contact them on social media to see how they are doing.

-Force yourself to attend corporate parties and other events, as much as you can tolerate. You don't have to stay the whole time but at least be seen and remembered by your immediate co-workers.

-Get an understanding of how performance reviews are done at whichever employer you eventually work for and make sure that you are known in a positive light to the people making the decision. The extroverts do it naturally, you may have to do it artificially (cynical as that may sound). Failing to do so will hamper your career growth significantly.

-Having difficulty talking to others doesn't absolve you of the need to communicate. You're going to need to be able to need to write email, documentation, code comments, and so forth quickly, clearly, and concisely.

-If public speaking is a problem for you, work on that until you're able to give at least a passable engineering presentation. Engineering is a team sport and the more senior you are, the more you're expected to speak up and guide others. Organizations like Toastmasters and course like the Dale Carnegie program can help with this. The earlier in your career you confront this, the better.

-Seeing a medical professional may be helpful in ameliorating your introversion. However, be very wary of medications; they may come with nasty side effects including reducing mental acuity (a massive problem, if you're a technology professional), rebound effects, tolerance effects, and withdrawal effects. Therapy and modifying your behaviors are the most likely to succeed in the long run but require a lot of hard work on your part.

-Be prepared for pain and frustration. Bad ideas communicated well by someone else will win out over good ideas that someone is unable to communicate. Less talented people who have good relationships with the organization will succeed more than a better person with no relationships with anyone.

Good luck.

</comment><comment><USER24> fake it til you make it

<comment><USER25> This advice applies to nearly everything and is a lot deeper than it sounds.

I first read it from Aristotle (if that's suppose to add credibility/draw attention).</comment></comment>


Umberto Eco: Exploring Imaginary Lands With One of Italy's Masters of Fiction - <AUTHOR> http://www.nytimes.com/2013/11/28/arts/international/umberto-eco-a-master-of-fiction-considers-historys-lies.html?hpw&rref=arts&_r=0

<comment><USER2> A terrific author whose philosophical work informs his fiction, but not in a heavy handed or didactic way. I only wish there were more novels.

If you haven't read anything by him, I'd start with _In the Name of the Rose_. The beginning is a little tough to get into, but if you persevere you are amply rewarded (in the afterwords it is disclosed that this was a deliberate literary choice, I won't spoil it by explaining the rationale, but it does make sense). _Foucault 's Pendulum_ is the magnum opus.

Edit: after _In the Name of the Rose_ I'd probably go with _Baudolino_ , but FP is a valid choice as well.

<comment><USER3> I've read _The Name of the Rose_ and really enjoyed it. What should I read next?

<comment><USER4> Foucault's Pendulum gets my vote too if you want to read something that is as straight forward as Eco can get.

The Island of the Day Before, Baudolino and The Mysterious Flame of Queen Loana felt more like he was trying to test you, in each of those books, to see if you are worthy of consuming the entire book. Every time you feel you have a reasonable grasp of what is going on, he'll descend into a phase where you'll be lost again.

The Prague Cemetery, on the other hand, was utterly fascinating. Really enjoyed it.

<comment><USER5> I read the Prague Cemetery after everything else and found it incredibly boring.

Perhaps not even Mr. Eco is immune from repeating clichés.

<comment><USER4> His works, after The Name of the Rose and Foucault's Pendulum, had become significantly mode self-indulgent. TPC is no exception to that, except that it is considerably less indulgent than the books between FP and TPC.

</comment></comment></comment></comment></comment><comment><USER6> Much of Eco's work was translated by the great William Weaver who passed away earlier this month. I came to appreciate Weaver's translations through another Italian legend, Italo Calvino. Calvino had a way of incorporating scientific and philosophical concepts within passionate human drama. HN readers might enjoy his work as well.

[http://www.nytimes.com/2013/11/17/arts/william-weaver- influe...](http://www.nytimes.com/2013/11/17/arts/william-weaver-influential- translator-of-modern-italian-literature-dies-at-90.html?_r=0)

[http://en.m.wikipedia.org/wiki/William_Weaver](http://en.m.wikipedia.org/wiki/William_Weaver)

<comment><USER7> > _He had a stroke several years ago that severely hampered his ability to > speak — an especially difficult hardship, friends and relatives said, for a > loquacious man who had built his life communicating in words._

That is sad to hear, but as Renoir supposedly said when asked why he spent three decades painting with painful arthritis: "The pain passes, but the beauty remains."

Thank you for your translations, William Weaver.

[http://www.openculture.com/2012/07/astonishing_film_of_arthr...](http://www.openculture.com/2012/07/astonishing_film_of_arthritic_impressionist_painter_pierre- auguste_renoir_1915.html)

</comment></comment><comment><USER8> _" The fact is that the world is divided between users of the Macintosh computer and users of MS-DOS compatible computers. I am firmly of the opinion that the Macintosh is Catholic and that DOS is Protestant."_

You need to read the whole column to get the joke[1]. I like to imagine that fully Libre Gnu/Linux would be Jain, and Android would be Baptist.

Eco's routine journalism can be really funny.

[1] [http://www.themodernword.com/eco/eco_mac_vs_pc.html](http://www.themodernword.com/eco/eco_mac_vs_pc.html)

</comment><comment><USER9> Why are there so many links towards this paywalled site? It's the only paywalled site that I see on HN, why is that?

<comment><USER10> answer> delete your cookies and the paywall is porous

<comment><USER9> I use private browsing.

</comment></comment></comment><comment><USER11> Non-paywalled link:

[http://www.nytimes.com/2013/11/28/arts/international/umberto...](http://www.nytimes.com/2013/11/28/arts/international/umberto- eco-a-master-of-fiction-considers-historys-lies.html?hpw&rref=arts)

</comment><comment><USER12> This is just a rather superficial interview with Mr. Eco. He does touch on the medieval belief in a spherical world but they don't go into detail about such things. Interesting, but brief and not what the title promised.

<comment><USER13> But it does show some hints as to why Eco is so unbelievably great.

" _Every writer, every artist, every musician, scientist is profoundly interested in the survival of his or her work after their death. Otherwise they would be idiots._ "

And, of course,

" _In the States, they publish an enormous collection of books called 'The Library of Living Philosophers.' It started with John Dewey and Bertrand Russell and the last book was about Richard Rorty. For mysterious reasons — probably because there is nobody else is around — they chose me for the next one. These are books of 1,500 pages. I am supposed to write 100 pages of philosophical autobiography. And there are 25 people, working at this moment, each writing a paper on my philosophical activity. And I am supposed to read all of them and to respond to each of them with at least three or four pages each. I think I have two years to work on it, and I am hoping to die before I have to do it._"

</comment></comment><comment><USER14> if you like eco, check out 'Q' by luther blissett, which is given away for free on his website[1] along with all of his other works.

1: [http://www.wumingfoundation.com/english/biography.html](http://www.wumingfoundation.com/english/biography.html)</comment>


Show HN: EVsnap – Used Electric Vehicle Marketplace - <AUTHOR> https://www.evsnap.com/ <comment><USER2> This site might find a better niche by growing it's own market through education. I.e. a buyer visits that wants their next car to be electric but doesn't know where or how to start.

Additional Feature Ideas: 1: Maybe add resources for new EV buyers, FAQs, etc.

2: Maybe also a Q&A for how users need to use their current car (range, seats, homeowner, renter, charging installation budget etc.) to filter for existing EV cars that would suit the majority of those needs (both listed on the site, and a database of existing cars not yet listed).

3: As with any marketplace, more listings makes it more useful so maybe could grow it by finding EV listings on other sites and encouraging them to list on your site too.

4: Don't be afraid to host new cars too if prices are high enough! Might be tough to keep all the rebates straight.

5: Add city/state combos into the location filter in case zip codes aren't known for a location that isn't yours (corner case probably).

6: Plug-in Hybrids like a Volt may also help people get involved that are nervous about dipping their toes in and likely make up the majority of the used market right now.

Nice job on the interface, slick UI builds confidence in users over some other EV focused news sites. The Elon fanclub can be intimidating and not always welcoming so this could be a huge option for less intense EV buyers.

</comment><comment><AUTHOR> Hey HN!

I'm looking for feedback on an electric vehicle marketplace I've been working on. A few months ago I was looking for a used electric vehicle and I was left unhappy with the go-to marketplaces, e.g. Craigslist, Autotrader, etc. I was only interested in EVs, and I found those sites catered their user experience to prospective gas-car buyers. Eventually, I found OnlyUsedTesla, a great marketplace for used Teslas, but I was left unsatisfied due to their search experience and the fact that I wasn't _only_ interested in Teslas.

That's when I decided to start working on what would become EVsnap. EVsnap is an EV-friendly marketplace for buyers and sellers. Try it out, I'd love your feedback! It's completely free to list while in beta, and will always be free for prospective buyers.

</comment><comment><USER3> For a used EV, I think a buyer would need to know the range and some indication of the useful life of the battery.

<comment><AUTHOR> Good idea, I think I'll add this. Essentially an estimated usable range field that a buyer can use to filter cars by.</comment></comment>


TLS/SSL implementation in Haskell - <AUTHOR> https://github.com/vincenthz/hs-tls <comment><USER2> A number of people are suggesting that this Haskell implementation must be worse than OpenSSL. It probably is. Writing good crypto code is hard. There are probably bugs.

Many are saying that one problem with Haskell is that you can't eliminate side-channel attacks due to features of the language. I disagree. There is no common language better than Haskell at encoding invariants in the type system. One could, for example, implement a "biggishnum" library in Haskell using large but fixed size integers and constant-time operations.

Free monads are a powerful idea in Haskell[1]. They allow one to easily generalize "interpreters" over sequences of commands. In Haskell, more-so than any other language I've ever used, one can decouple execution from algorithm specification.

Free applicative functors generalize further[2]. They define a computational structure that must be fixed a priori. That is, by definition a free applicative functor cannot know the state of the data during its execution.

There are some problems with this. Applicative functors have an operation which can lift regular functions into it. That operation would have to be hidden, so that only a kernel was exposed that offered the ability to initialize data, and then perform computations upon it.

But it's possible to do this. It is actually not a radical idea to imagine this being done in Haskell. Making a library and a set of primitive operations _that can be used by an end user safely_ , in provably constant time is possible.

[1] [http://www.haskellforall.com/2012/06/you-could-have- invented...](http://www.haskellforall.com/2012/06/you-could-have-invented- free-monads.html) [2] [http://paolocapriotti.com/assets/applicative.pdf](http://paolocapriotti.com/assets/applicative.pdf)

<comment><USER3> I'm wondering about a situation where forgetting a strictness annotation is the analogous Haskell situation of forgetting to bounds-check some input. There are lots of ways in Haskell for something not to be evaluated. (No, the simple fixes like 'use strict fields' do not cover all cases.) To put _all_ of them behind a free monad seems like it would be giving up a lot.

In C you could have made some 'safe buffer' struct together with some safe set of functions. But people didn't do that.

<comment><USER4> > In C you could have made some 'safe buffer' struct together with some safe > set of functions. But people didn't do that.

Exactly.

      struct buffer
      {
    	void* data;
    	size_t len;
      };

      void smemcpy(buffer* dst, buffer* src, size_t n)
      {
    	if(dst->len < n || src->len < n)
    		abort();
    	memcpy(dst->data, src->data, n);
      }

I mean how hard is that, honestly?

Buffer bugs in C don't come from the language, they come from the tendency of C programmers to value performance highly. "I just checked that the buffer is big enough, I don't need memcpy to waste cycles checking it again. I don't need that length variable sucking up memory when I know how big the buffer is." Except when you do.

<comment><USER5> They come from the C language allowing it.

<comment><USER4> All Turing complete languages allow you to do anything all Turing complete languages allow you to do. You can allocate a huge block of memory in Java or C# and then write your own malloc to allocate buffers from subsets of it. In some cases that may have better performance. It also allows you to have buffer overruns. You can run right off the end of one buffer and into the next and the language won't stop you because it only knows that you haven't reached the end of the array _it_ allocated.

<comment><USER6> Do Turing machines have a concept of "undefined behavior" in the same way that C does? AFAICT all behavior of a Turing machine is defined -- sure you might not calculate what you want, but that doesn't admit arbitrary behvaior _outside of the semantics of the machine_ as in the C language.

<comment><USER4> > Do Turing machines have a concept of "undefined behavior" in the same way > that C does?

Sure they do. For example, nothing in the Turing machine specification tells you how fast they are. Whether a given program will run on a Turing machine in a given amount of wall clock time is undefined.

Here's a real example with real machines. Suppose you have a program with two threads. The first thread computes data and puts it on a queue for the second thread, the second thread writes it to the filesystem. When the compute thread has computed all of the data, it sleeps for 10 seconds and then terminates the program without checking whether the write thread has actually completed writing all the data to the filesystem.

That results in undefined behavior in every real language I've ever heard of. Whether the data is all written depends on how fast the CPU is, how fast the filesystem is, what other programs are scheduled on the machine that compete for CPU and filesystem access at what priority, etc. Languages don't define any of those things so you have undefined behavior.

<comment><USER7> That's a different abstraction than "Turing Machine". Turing machines do not have '"undefined behavior" in the same way that C does' \- it would look like a "in state 3, if you read a 0, move to an arbitrary state, write arbitrary symbols to arbitrary locations on the tape, move head to an arbitrary position on the tape, and possibly restructure the state machine in arbitrary ways."

<comment><USER4> Turing machines have undefined behavior in exactly the same way that C does. What do you suppose happens if a Turing machine reads from a location on the tape that has never been written? The value the machine observes in that circumstance is not required to be well-defined in order for the machine to be able to do all computations required of a Turing machine. Moreover, the more you add features of actual machines like parallelism and timers, the more opportunities for undefined behavior you introduce. What do you suppose a multiprocessor Turing machine does if you write concurrently to the tape without locking?

<comment><USER6> "What do you suppose happens if a Turing machine reads from a location on the tape that has never been written?"

It reads the default symbol (see e.g. the description of a TM on Wikipedia). It's semantics are well-defined.

The semantics of TMs are well-defined. The semantics of C's "undefined behavior" is not well-defined.

<comment><USER6> I should have said "blank symbol" not "default symbol".

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER8> While Haskell mitigates or eliminates some classes of bugs common in C (such as buffer overflow), it also makes it more difficult to guard against side- channel attacks like timing attacks[0], because lazy evaluation makes it more difficult to reason about the actual behavior of the code at runtime.

This isn't a dig at either Haskell or C; the point is that all programming languages and environments have their "gotcha!" moments.

[0] [https://en.wikipedia.org/wiki/Timing_attack](https://en.wikipedia.org/wiki/Timing_attack)

<comment><USER9> [http://hackage.haskell.org/package/securemem implements](http://hackage.haskell.org/package/securemem implements) constant- time bytestring comparisons for haskell. With the bonus that the data is scrubbed when GC'd. This is used by parts of the haskell TLS stack, for example [http://hackage.haskell.org/package/cipher- aes](http://hackage.haskell.org/package/cipher-aes)

I don't think that laziness makes things much harder. Compare a C function with if foo return 0 in the middle and a Haskell function that lazily builds thunks that don't end up being evaluated in a particular branch. There's obvious things to do to both to make them run in constant time. The hard part about dealing with a timing attack in both cases is recognising that the function is used in such a context and needs to be constant time.

AFAIK, the haskell TLS stack has not yet been audited. For this reason, there's some reluctance to use it in parts of the Haskell community. Although http-conduit and http-client-tls do use it, so everyone writing programs that hit https from haskell using conduit is using it already.

<comment><USER10> > > [http://hackage.haskell.org/package/securemem](http://hackage.haskell.org/package/securemem) > implements constant-time bytestring comparisons for haskell. With the bonus > that the data is scrubbed when GC'd.

As far as I understand, this is not sufficient.

Some things that are needed in addition are (at least):

* constant time math operations (multiply, divide, exponentiation, etc.)

* no branching based on secrets (running the code results in no branch conditions based on secret data)

Here's an interesting article on implementing a form of Elliptic Curve Cryptography without even local timing attacks: [http://blog.cr.yp.to/20140323-ecdsa.html](http://blog.cr.yp.to/20140323-ecdsa.html)

<comment><USER11> Why can't timing be handled external to the scrambling or descrambling operations? Look at the time, do the crypto, then check the time and sleep as necessary so that this particular operation takes about as much time as the worse-case. Something like:

      cryptofunc x = do
        begintime <- gettime
        result <- purecryptofunc x
        endtime <- gettime
        sleep (worstcase - (endtime - begintime))
        return result

<comment><USER12> Properly implemented crypto takes a constant number of instructions to encrypt/decrypt, regardless of key, plaintext, etc.

Time to sleep() would vary across processors, os-es, and even load (!), so it's not exactly a workable solution. Not to mention it would be grossly inefficient (Context switch on every crypto primitive? No thanks).

</comment></comment></comment></comment></comment><comment><USER13> Possibly more interesting is a machine checked implementation.

[http://www.mitls.org/wsgi](http://www.mitls.org/wsgi)

<comment> jude- From the website, it seems that they proved that their implementation is correct with respect to their formalization of the interfaces in the RFCs. That is, their implementation is _logically correct_.

However, this says nothing about whether or not the implementation is _secure_. They admit that they don't model time in their proofs, so I doubt their implementation is free of timing attacks. Moreover, its written in F#, so you have to trust your CLI implementation to be bug-free as well.

<comment><USER14> > its written in F#, so you have to trust your CLI implementation to be bug- > free as well

Is that any different to an implementation in C relying on the processor being bug-free?

<comment> jude- If you count up all of the possible states a processor can be in, as well as the number of transitions between them, you'll come up with a very big number of possible execution paths you'll need to verify work correctly. However, if you do the same for the CLI (or any non-trivial piece of software), you'll come up with a much, much, _MUCH_ bigger number. As in, each additional state the CLI can enter potentially _doubles_ the number of possible execution paths you'll need to check.

The number of states and transitions for a processor today is large, but not so large that engineers can't formally and automatically verify that the processor will behave correctly under all inputs. Also, the structure of the processor and the way it is specified (i.e. Verilog) make it amenable to formal verification.

This is not true for most software, not even things written in Haskell. You can cover a lot of cases with automated software testing, but you'll find that it's very, very, VERY hard to prove that you've covered every possible case. Even if you can, modeling multiple instances of the system as they evolve in time (i.e. any networked system or interactive system) means you have to consider all possible _combinations_ of states they can be in.

To put into perspective how _hard_ formal verification of software is, I have a story. A friend of mine did his masters thesis on modifying TCP to allow for host mobility, and formally proving the correctness of his new TCP protocol. Despite having a 100-node cluster of beefy (48GB RAM) compute nodes at his disposal, it simply didn't have enough total RAM to verify the correctness of his protocol beyond five rounds of communication between one client and one server.

Unless the CLI developers add machine-checked but hand-crafted proofs of correctness for each and every method, I trust the processor to be bug-free _far more_ than any piece of software it runs. Now of course, if the NSA tampers with either, then all bets are off :P

</comment></comment></comment></comment><comment><USER10> This seems interesting.

I'm completely ignorant about Haskell. I see there's some code in a "Benchmarks" folder; I think it would be highly interesting to see a comparison in speed between OpenSSL's SSL implementation and this one (the operations that a web server would normally have to do).

Can anyone make that happen? I can't even figure out how to execute Haskell code in Ubuntu 13.04.

Seems to me like if the code base is 20 times smaller than OpenSSL, _and_ we can assess whether timing attacks are present or not -- and if they are, replace the timing critical code with C code, perhaps -- that this would be a real alternative to OpenSSL. Am I being unrealistic in thinking this? Not that everyone will adopt it, mind you, but that adopting it would be a wise thing to do?

<comment><USER15>
        sudo apt-get install haskell-platform

You can install development packages through the "cabal" command line tool. The REPL environment is "ghci".

On one hand, it is a very high performance language with tons of purity, abstraction, and invariants built in to the type system and semantics. On the other hand, certain aspects can be problematic to reason about.

<comment><USER10>
        E: Unable to locate package haskell-platform

The package seems unavailable for Ubuntu 13.04. I think it's time to install 14.04 for me.

<comment><USER16> [http://www.ubuntuask.com/q/answers-haskell-platform- on-13-04...](http://www.ubuntuask.com/q/answers-haskell-platform- on-13-04-298601.html)

</comment></comment></comment></comment><comment><USER17> If you're curious (like I was) if anything else in the Haskell ecosystem is using this, this page lists packages that have dependencies on tls in Hackage (the Haskell package repository). There are 26 packages that depend on tls.

[http://packdeps.haskellers.com/reverse/tls](http://packdeps.haskellers.com/reverse/tls)

Meanwhile, HsOpenSSL (Haskell bindings for OpenSSL) has 22 dependencies:

[http://packdeps.haskellers.com/reverse/HsOpenSSL](http://packdeps.haskellers.com/reverse/HsOpenSSL)

</comment><comment><USER18> Nice and everything, but I somehow cannot imagine people massively jump over it. Maybe it's superstitious, I dunno…

On the other hand, I undoubtedly agree that we should start making and deploying alternatives in more safe modern languages. In fact, I guess we should start step-by-step rewriting _everything_ that's written in C/C++ and OpenSSL is a good thing to start with.

I guess it's a good chance for Rust & friends.

<comment><USER19> Crypto poses a unique challenge with the threat of timing attacks. A major benitif of using low level languages is that it is easier to assure that your code takes constant time regardless of the input.

<comment><USER20> So what candidates are there? While C may make it possible to write code that avoids timing attacks, a quick glance at [1] shows one must avoid memcmp and array lookups based on secret data, neither of which would be prevented by the compiler, and both probably similarly easy mistakes as heartbleed.

Can Rust compile to a shared lib the programs can use as easily as a C library? (I think the answer is "not yet", but I'm not sure? At least, I've seen projects for compiling Rust without any runtime library).

Today I learned this is possible with Ada [2], but it seems there is some boilerplate to start/stop the runtime. Does Ada provide the necessary low- level control to implement crypto?

Are there sufficiently strict dialects of C?

NaCl [1] says "There are an increasing number of cases where the C implementations and assembly-language implementations are automatically generated from code that was actually written in another language, such as CAO or qhasm."

CAO is a "a domain specific language for describing cryptographic software" [3], while qhasm [4] is a portable assembly seemingly not focused on safety.

[1] [http://nacl.cr.yp.to/internals.html](http://nacl.cr.yp.to/internals.html)

[2] [http://gcc.gnu.org/onlinedocs/gcc-3.4.3/gnat_ugn_unw/Creatin...](http://gcc.gnu.org/onlinedocs/gcc-3.4.3/gnat_ugn_unw/Creating- an-Ada-Library-to-be-Used-in-a-Non_002dAda-Context.html#Creating-an-Ada- Library-to-be-Used-in-a-Non_002dAda-Context)

[3] [PDF] [http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.113...](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.113.8971&rep=rep1&type=pdf)

[4] [http://cr.yp.to/qhasm.html](http://cr.yp.to/qhasm.html)

<comment><USER21> _Can Rust compile to a shared lib the programs can use as easily as a C library?_

Yes it can! You use the `#[no_std]` if you wish to be rid of the runtime, and the `#[crate_type = "lib"]` for outputting shared libraries (or use the `--crate-type` compiler flag).

Here's an older blog post on it, though the rust code there probably won't compile as-is with current Rust: [http://bluishcoder.co.nz/2013/08/08/linking_and_calling_rust...](http://bluishcoder.co.nz/2013/08/08/linking_and_calling_rust_functions_from_c.html)

<comment><USER22> Unfortunately, this means giving up the powerful Rust standard library and threads. Fortunately, third-party devs are creating a "zero-runtime" standard library that can be used in situations like this, and in embedded programming:

[https://github.com/thestinger/rust-core](https://github.com/thestinger/rust- core)

Right now, rust-core only provides basic collections and io, but more may be in the works. I suspect rust-core will eventually grow into a small but capable standard library.

<comment><USER23> rust-core has been coasting along in maintenance mode for quite a while now, because it was only intended as a temporary stopgap. Nobody really wants to fragment the community with a third-party standard library.

Instead, the Rust devs intend to restructure the standard library such that it has multiple profiles, and that you can jettison parts of it (such as the parts that require the runtime) without losing all of the other goodies. Here's the most recent RFC for doing so, filed yesterday: [https://github.com/rust-lang/rfcs/pull/40/files](https://github.com/rust- lang/rfcs/pull/40/files)

<comment><USER22> Oh, very cool. I was hoping something like this would emerge.

</comment></comment></comment></comment></comment></comment></comment><comment><USER24> The response to a subtle weakness in cryptographic software should not be to reimplement the cryptographic implementation from scratch. This inevitably introduces far more problems than it solves.

<comment><USER25> Haskell is a particularly odd choice for a project like this, as lazy evaluation makes it difficult to reason about the runtime of various operations under various conditions.

Something with a bit more ML in its blood would be better, and for a library that pretty much means OCaml.

Edit: I do not at all mean to imply that it is impossible to implement TLS securely in Haskell. Only that there are more natural choices if one wants the advantage of a strong algebraic type system.

<comment><USER26> Could you elaborate on how lazy evaluation is problematic for such a project?

<comment><USER25> In cryptography, for most operations, you need to be sure that the operation takes the same amount of time for all possible inputs. Otherwise, you leak information.

The classic example of this is checking string equality with strncmp(): this takes a different amount of time depending on how similar the strings are. If one string is secret and the other is controlled by an attacker, the attacker can use a clock and multiple attempts to discover the secret.

Obviously this particular one isn't relevant to SSL, but there are a number of other possibilities to worry about in most languages, most obviously short- circuiting operations like boolean AND/OR. Lazy evaluation makes every operation short-circuit, so you need to worry about this in every operation.

It can be done, but it's harder than it needs to be.

<comment><USER27> So we should choose the approach that gives us trivial attacks that reveal 64K straight out of Compton to the approach that may be slightly harder to defend against timing attacks?

<comment><USER25> This is such an obvious false dichotomy that I'm sure most people will notice, but I'm pointing it out anyway.

We could use something that gives both advantages, like the OCaml I already mentioned. Or, we could take a hybrid approach, where something like Haskell generates C code that provably can't have buffer problems. Or, we could statically verify that the library is written in a known-memory-safe subset of C++. Or, we could use a language like Rust, which (once it's eventually complete) seems ideal for this sort of application.

<comment><USER7> I think the "define a strict, branchless DSL" approach is the right one, if you're going with Haskell. Then use the type system to ensure that only that stuff can touch key data. No problems with laziness or timing attacks, if the core of that is implemented correctly.

</comment></comment></comment></comment></comment></comment></comment><comment><USER28> TLS implementation in Go. [http://golang.org/pkg/crypto/tls/](http://golang.org/pkg/crypto/tls/)

Go is probably better at this.

<comment><USER29> According to Adam Langley, a Go contributor, it can still be side-channeled. [https://twitter.com/agl__/status/453370970552532992](https://twitter.com/agl__/status/453370970552532992)

<comment><USER30> s/Go contributor/primary author of the Golang TLS package/g

(Also, he's one of Google's point people on TLS.)

JFWIW.

</comment></comment></comment><comment><USER31> How bad are timing/side-channel attacks, really? I think that half of the people who talk about this are showing off. Some nerdy one-uppance.

<comment><USER32> >How bad are timing/side-channel attacks, really?

Bad. They are _not_ something to blow off. They may seem "out there", but they are actually leveraged somewhat frequently. They are particularly dangerous in certain shared-hardware environments (e.g. VPS services like DigitalOceal, AWS, etc), and against physical devices that are supposed to resist data extraction (like smart cards).

</comment></comment><comment><USER33> Totally off topic, but programmers, I REALLY need your help... [https://news.ycombinator.com/item?id=7559067](https://news.ycombinator.com/item?id=7559067)

</comment><comment><USER34> and you can still write bugs in Haskell.

<comment><USER35> I'll notify the Haskell people straight away, sir.

</comment></comment><comment><USER36> With all due respect, I don't know that TLS/SSL implementation problems will be largely solved by changing programming languages.

<comment><USER37> If changing languages lets you reduce code size 20-fold, it's very much worth it.

 _Reasoning_ about a smaller code base is nonlinearly easier. This is especially important for security software where letting your reasoning slip usually renders the whole thing useless.

<comment><USER38> Is that really the case? In Java (my native language, so to say) I quite regularly browse through the language library implementation. I found it quite easy to read and comprehend. I almost always learn something new by doing so.

Not so much for Haskell. When I started with it, I similarly tried to learn by going through the language libraries. Even when I gained some more experience (I am still a beginner and only casual user, though) I have a very hard time to understand what's going on. The code is so dense that I find it hard to understand.

<comment><USER39> You have an easy time understanding the libraries of your native language, but a hard time understanding the libraries of a language in a completely different paradigm that you're a beginner at? You don't say.

Seriously, the Haskell libraries are understandable and informative - once you learn the language.

<comment><USER38> That's what I exactly tried to convey: I used that tactic when I was a beginner at Java and hadn't many problems with it. I used the same tactic when Generics came up. I hadn't any problems with it. The beginner can become a better programmer by reading the code. Now I am in a state where I can say: "this shouldn't be implemented that way". Which is completely different and grounds in being Java my native language.

I have casual encounters with Haskell since two years now. Library code is still hard to grok. Don't get me wrong: I like Haskell very much and I am pretty sure that its a decent language to write security critical code in, but I think this is still a problem for many beginners out there. I very rarely stumble on something and say: "hey, that's cool, I will use that in my code". But I admit that I give up after the third nested "lift-<whatever>" ;-).

I want the libraries help me understanding the language, not vice versa. But of course, that's not their primary goal.

<comment><USER39> When you were a beginner at Java, did you by chance already know how to program in an imperative or OO manner? I find it highly unlikely that anyone unfamiliar with imperative/OO programming in general would get _any_ benefit from reading Java libraries. If you want to get benefit from reading Haskell libraries, just like in Java, you need to learn how to program in the paradigm. Not just "have casual encounters" with it, not just reading things about it, but actually learn the thing.

A direct analogy to what you're saying: When I was studying French, I was able to read articles above my level and get a decently good idea of what they said. Now I'm studying Chinese, and I can't tell at all what characters mean! _This should not be surprising._ French is very similar to English, where Chinese is very different. Of course picking things up in the latter will be more difficult. It would be absolutely absurd to blame the Chinese language for that.</comment></comment></comment></comment></comment></comment>


Show HN: Crowd-sourced medical diagnosis (feedback?) - <AUTHOR> http://headachestory.com

<comment><USER2> Love the concept. It's a shame something like this doesn't already exist. Best of luck!

<comment><AUTHOR> Thanks, this is part of a larger project that we'll share soon. We're just gathering some feedback and data about how people interact with this sort of web offering.</comment></comment>


Extrasolar - Dev Diary 1: "Rover" an alien planet - <AUTHOR> http://www.lazy8studios.com/2012/extrasolar_blog_1

<comment><AUTHOR> Indie game developer, Lazy 8 Studios just posted a developer diary for a game they are working on called "The Extrasolar Project" (<http://www.exoresearch.com/>)

The game allows you to control a rover on an alien planet as you explore and take hi-res photos of the planet's surface.

Lazy 8 Studios has previously released a Steampunk themed puzzle game called "Cogs" (<http://www.cogsgame.com/>)</comment>


Show HN: Had nowhere to practice coding interviews, so we built Pramp - <AUTHOR> https://www.pramp.com/practice

<comment><USER2> Nice idea. Coding interviews are a true pain for so many hackers. I like the approach of connecting similar people to help each other improve. That makes a lot of sense, especially for geeks.

But that also seems somewhat troubling... especially because I'd normally inexperienced or first time job seekers using the site. Would that be like the blind leading the blind in a sense? There is a lot to learn to turn into a good interviewer.

Even if you don't test someone's ability, having them declare if they are interested in conducting interviews or being mock interviewed would likely get a good separation and better experience for all.

<comment><AUTHOR> Peer practice isn't professional coaching, but we think you don't really need a pro to prep well. You just need the right practice buddy and good prep materials.

We pair you up against someone similar to you and provide full prep material (problems, solutions and specific tips and guidance) ahead of time. Both you and your peer with interview the other after you know how a right solution should look like and how to judge other solutions. You can also access the problems & solutions after your interview and learn about it.

</comment></comment><comment><AUTHOR> Hey HN, one of the co-founders of Pramp here. We're a free peer-2-peer practice platform for coding interviews. It's like online dating for technical interviews.

After a few years of coding interviews, my friend and I noticed we always have a hard time finding good practice buddies. The web is full or great interview prep resources for self-learning: books, blogs, coding challenges and Q&A sites. Yet, there's no free place to practice live interviews. Interviewing is not something you can learn from a book or from coding by yourself. This is because interviewing and coding are 2 different skills.

Pramp pairs you to other hackers at your level to practice interviews together. On each interview both your and your peer will interview the other. We take care of everything you need to prep well: scheduling, interview problems & solutions, video chat, collaborative code editor and peer written feedback.

Would love to hear your feedback and thoughts.

</comment><comment><USER3> Hey - I really like the idea! Can you explain how the interview process will actually work? Do you oversee the interview process or is it a nominated "interviewer"? I'm also interested to know - can anyone sign up to be an an interviewer or do you select a pool of interviewers who then conduct the interviews for users? How do you incentivise people to act as interviewers? Finally (as i'm not too techy) will there by a way for beginners / less developed coders to practice too?

<comment><AUTHOR> Thanks!

Practice interviews on Pramp are bi-directional. Every user is both an interviewee and an interviewer on each interview. We oversee the process by matching between likeminded peers with similar skills, background and abilities and by providing prep material before interviews.

We're not a fit for beginners yet, as our interview questions take solid understanding of CS & coding just like real technical interview at tech companies. However, we plan to add this later.

<comment><USER3> Fair enough- looking forward to the beginner mode :)

So over time is it that a user get ranked for being a better or less good interviewer and the better you are, the higher level of interview partner you get?

<comment><AUTHOR> Yes. We consider that when pairing you to your peers to make sure that you are both a fit for each other.

</comment></comment></comment></comment><comment><USER4> Thanks David. This is pretty good.

I'll start recommending this service to students in our interview prep bootcamp ([http://interviewkickstart.com](http://interviewkickstart.com)), who want more practice. We also do intense practice and mock interviews, but they are with seasoned interviewers working at Google etc, and hence there is a cost to it.</comment>


Nine billion company names - <AUTHOR> http://www.economist.com/news/business/21676804-businesses-are-coming-up-ever-sillier-ways-identify-themselves-nine-billion-company <comment><USER2> Wow. It's the Economist version of saying the Millennials aren't as good as the Slackers (who aren't as good as the Baby Boomers (who aren't as good as the Greatest Generation ...)).</comment>


What I learned hanging out at the vascular surgery conference - <AUTHOR> http://petdance.com/2011/09/hanging-out-at-the-vascular-surgery-conference/

<comment><USER2> My girlfriend, who is a landscape architect, has a subscription to Interlocking Concrete Pavement magazine (<http://www.icpi.org/node/745>). On average, I probably spend twice as much time reading it as she does. Most recently, there was an article that described different parking lot geometries designed to prevent rainwater that lands on the parking lot from making it out of the parking lot, carrying lots of toxic crap with it. I also learned recently about horseshoe swales, which collect runoff from things like tennis courts.

I've previously read issues of Appliance Design and American Laundry Digest and found similarly interesting stuff.

[Edit: In trying to find a diagram of a horseshoe swale, I discovered that there exists a social network for landscape architects: <http://land8lounge.com/> Looking at the source, I think it's a Ning site branded to look independent (or at least there are a bunch of ning.com assets linked).]

<comment><USER3> You would love "Design News"

<comment><USER2> Thanks for the suggestion.

Strangely, that's approximately my field of expertise. I got Design News for a few years, but it was less interesting because I was already familiar with most of the tech. Contrast that with ICP Magazine: they have pictures of machines that make racks of bricks shaped with interlocking profiles.

</comment></comment></comment><comment><USER4> A friend of mine in grad school in Atlanta, which hosts a bunch of conferences in the big hotels downtown (partly due to the well-connected airport), used to crash them mainly for free food, but found some pretty interesting conversations as a result. One pointer was to go to "boring-sounding" biz conferences where people are mostly there because their company sent them. The novelty of you _not_ being from the conference makes it fairly easy to talk to people, they don't usually care about you crashing it (unless perhaps they're the organizers), and it's a good way of finding out what people in an industry/sector think is broken in their industry (by the 2nd or 3rd day of a conference on Subject X, many attendees have a lot of rants about Subject X collected on the tip of their tongues).

</comment><comment><USER3> Last week, I was talking with a guy at a cocktail party who was reading "Ways of Seeing" by Berger _and_ studying physics by reading The Feynman Lectures. He was one of the most fascinating people I have met in a while because he was genuinely interested in your life (even though we only talked ten minutes, I was left wanting more...). And he was a marketing guy.

<comment><USER5> He's not just a marketing guy. He's a _good_ marketing guy. Building rapport is a key skill for a salesman.

</comment></comment><comment><USER6> My grandpa once advised me to read a new book or magazine about something I was unfamiliar with every month. Terrific advice, I have so much more general knowledge that lets me interact with customers and new people than many of my peers.

<comment><USER7> That's what I like about Khan Academy just sit back and watch so many subjects as well so many universities have free videos.

In a way reading HN feels like I'm crashing a vascular conference.

<comment><USER8> The cool thing about crashing the HN conference is you don't have to go to school for twelve years to pick up some tools and start hacking away (pardon the double entendre).

</comment></comment></comment><comment><USER9> I used to work for a surgeon and was tangentially involved with some conferences. I'll confirm they're like he described. The only person I've ever heard of being asked to leave was a malpractice lawyer digging for dirt.

Surgeons, like developers, tend to be very particular about their tools. The one I worked for designed a few of his own and worked with medical device companies to produce and sell them.

The sales reps are an interesting mix of "sales-ey" and technical. One medical device sales rep I knew became one after having sold his business stocking sandwich vending machines. Other sales reps were practicing PAs (Physician Assistants) who were known to scrub in and sometimes perform parts of the surgery.

</comment><comment><USER10> Hmmm, I've always said if I quit programming I'd probably go into Civil Engineering. Perhaps it's time to look for some magazines next time I go to the library. I'll read just about anything, for precisely the same reason Andy crashed the conference - gaining new knowledge is fun!</comment>


EU diplomats to use mystery app for secure messaging - <AUTHOR> https://netzpolitik.org/2020/eu-diplomats-to-use-mystery-app-for-secure-messaging/ <comment><USER2> If you cannot google for exploits using the name it's safe. Checkmate hackers.

Security through anonymity?</comment>


Bill Gates: Books I loved in 2018 - <AUTHOR> https://www.gatesnotes.com/About-Bill-Gates/Best-Books-2018 <comment><AUTHOR> The books:

1) Educated: A Memoir - by Tara Westover;

2) Army of None - by Paul Scharre;

3) Bad Blood - by John Carreyrou;

4) 21 Lessons for the 21st Century - by Yuval Noah Harari;

5) The Headspace Guide to Meditation and Mindfulness - by Andy Puddicombe</comment>


Ask HN: How come some group of hacker Uber drivers hasn't disintermediated Uber? - <AUTHOR> The Uber (etc) drivers could be paying themselves instead of the owners investors if someone were just to write an open source gig manager and apply everywhere. <comment><USER2> Because there's way more to Uber than an app.

There's so many facets I don't know where to start

\- Background Checks

\- Payment Infrastructure

\- Insurance, and not some off-the-shelf insurance, complicated messy layers insurance

\- UX

\- Expensive marketing and subsidies (which is what creates trust in brand so we all feel comfortable hopping into cars with strangers)

\- Local laws (even if they break a lot of them, they do still follow some)

There's an open source Uber-like platform: [https://libretaxi.org/](https://libretaxi.org/)

But making an Uber app is easy, making an Uber platform is expensive.

<comment><AUTHOR> A union of drivers could easily do all that.

<comment><USER3> 1\. If it's so easy, why hasn't anyone done it yet? I've seen this idea mentioned on HN dozens of times already.

2\. Even if you could set this up, you'd still be competing against Uber, which is a name everyone knows already and which can afford to burn billions of dollars a year to grow their business. They could temporarily lower their rates or driver's fees in the area that you operate in and quickly put you out of business, since they can afford to lose money much longer than you can. The same drivers who'd use this app will still be driving for Uber and Lyft (they'll go wherever the money and customers are).

</comment></comment></comment><comment><USER4> > could be paying themselves instead of the owners investors

Uber isn't "paying the owners [sic] investors," it's (still) consuming huge amounts of their capital. From [https://investor.uber.com/news- events/news/press-release-det...](https://investor.uber.com/news- events/news/press-release-details/2019/Uber-Announces-Results-for-Third- Quarter-2019/default.aspx) :

"As such, we are improving our full year Adjusted EBITDA guidance by $250 million to a loss of $2.8-2.9 billion"</comment>


How do Promises Work? - <AUTHOR> http://robotlolita.me/2015/11/15/how-do-promises-work.html <comment><USER2> > Another way of solving this problem comes from the realisation that we only > really need to keep track of the dependencies for a promise while the > promise is in the pending state, because once a promise is fulfilled we can > just execute the function right away!

This is a common gotcha in Javascript implementations, in that you think you want this, but you really don't! Now you never know if your code is synchronous or will run in a subsequent tick. Your call tree will look completely different depending on race conditions...

This comes up in user code as well; any time you write a function that takes a callback, it's probably a good idea to either always run it either in the same call tree or in a new stack, but never mix the two. It's usually easier to just do the latter using process.nextTick.

<comment><USER3> Promises also solve this problem. If you immediately resolve a promise it isn't actually resolved until the next event loop "tick":

        new Promise(resolve => resolve("resolved!")).then(result => console.log(result));
        console.log("next statement");

Prints "next statement" then "resolved!".

<comment><USER4> You don't even have to resolve the promise via a callback for that to be the case - you can use the static resolve method. This is really useful if you have a function that can sometimes return a promise and sometimes a "normal" value.

        Promise.resolve("resolved!").then(result => console.log(result));
        console.log("next statement");

</comment></comment></comment><comment><USER5> I have seen how Promises' concept was abused in a project at work. All the promises were just returning Future objects, and they were exposed everywhere. And, in case a future fails for some reason, there was no way to have a new Future: all users were doing future.get, resulting in an exception thrown to the caller. What a mess.

<comment><USER6> What is the difference between "Promise" and "Future"?

From what I read, it is basically the same thing.

<comment><USER7> People do not use the terms consistently.

The difference is _SUPPOSED_ to be that a Future is read-only while a Promise is settable. And should be set at most once! So you can use a Promise as a Future, but you can't always use a Future as a Promise.

Linguistically you can understand this as, "I Promise you'll see a Future answer." I need to be able to write to the Promise to fulfill it. You can only hope that some day the Future will arrive.

<comment><USER8> That changes by language - what you say is true in Scala, but in JavaScript the terminology is different. A future is not defined, a promise is a future and a deferred is a promise.

<comment><USER7> That is what I mean about people being inconsistent.

The ideas are much older than Scala, JavaScript, and many of the people commenting in this discussion. Believe it or not, both terms date back to the late 1970s.

Scala got it right. JavaScript got it wrong. And polyglots like me have to suffer with having to sort out who means what, where, on what platform.

</comment></comment></comment></comment></comment><comment><USER9> Nicely done, thanks! Still, having to explain a concept as simple as eventual computation reinforces my belief that promises as a whole is broken, and should be done in something that looks like synchronous code with some help of the underlying runtime. (And no, ES7's async is not good enough for me here)

<comment><USER10> NodeJS: you needed 5% of your code to be async, so we made everything async so you get to write awkward async-but-not-really code for the other 95%, too. That's better, right?

At least that's how it's always felt when I've used it for anything non- trivial yet well within its typical set of use cases.

<comment><USER11> Despite the downvotes, you are absolutely correct. My feeling, after working on a moderately complex server application in Node is that it was designed for only very simple applications that can be done with one level of callback. I find the "it works this way because its better" cult quite irritating. It works that way because the #*(^#$&^ JS interpreter isn't multithreaded.

<comment><USER12> It wouldn't even need to be multithreaded, I don't thnik. You could have some green threads-type system, using asynchronous I/O, a single-threaded server, and something along the lines of Lua's yieldk. Have a new script spring into life for each connection, suspend it when an I/O operation starts, and resume it when the results are ready (or when something goes wrong). I think this will be what Erlang does.

(I'm sure there are potential problems with this, but hopefully it would be overall no worse than the current situation, while being easier to work with.)

</comment></comment></comment></comment><comment><USER13> I found this document : [https://github.com/kriskowal/q/tree/v1/design](https://github.com/kriskowal/q/tree/v1/design) very helpful to understand how promises work behind the scene Also liked being able to access the author's reasoning and the motivations behind his design decisions

<comment><USER8> If you're going to mention Kris and concurrency, you better mention: [https://github.com/kriskowal/gtor](https://github.com/kriskowal/gtor)

</comment></comment><comment><USER14> TIL: fulfil vs fulfill [1]

1\. [http://grammarist.com/spelling/fulfil- fulfill/](http://grammarist.com/spelling/fulfil-fulfill/)

<comment><USER15> The second nGram linked there (showing the rise of fulfill - with 2 l's in American English)[1] seems to show that the increase in use of 2 l's started around the same time as Noah Webster's dictionary was first published. [2]

I've always been fascinated why there is such a difference between spelling in "British" and "American" English, I remember reading that the main reason was Webster's dictionary and his desire to reform spelling according to pronunciation. That Wikipedia article though quotes John Algeo: "He was very influential in popularizing certain spellings in America, but he did not originate them."

So now I'm as confused as ever. Why DID the spellings change so significantly. I can accept that they took hold due to Webster's work, but I wonder why the differences arose in the first place?

[1] [https://books.google.com/ngrams/graph?content=fulfil%2Cfulfi...](https://books.google.com/ngrams/graph?content=fulfil%2Cfulfill&year_start=1800&year_end=2000&corpus=5&smoothing=3&direct_url=t1%3B%2Cfulfil%3B%2Cc0%3B.t1%3B%2Cfulfill%3B%2Cc0)

[2] [https://en.wikipedia.org/wiki/Noah_Webster#Dictionary](https://en.wikipedia.org/wiki/Noah_Webster#Dictionary)

</comment></comment><comment><USER8> Another good classic about it is Domenic's you're missing the point of promises at [https://gist.github.com/domenic/3889970](https://gist.github.com/domenic/3889970) from 2012

</comment><comment><USER16> Stupid Cisco blocked this site on my corp network, due to "pornography", assuming due to "lolita" in URL.

<comment><USER17> Maybe you can load this? [https://archive.is/rQmhY](https://archive.is/rQmhY)

<comment><USER16> thanks!

</comment></comment></comment><comment><USER18> I can't wait for async/await enough myself.

<comment><USER19> Just use babel.

</comment></comment><comment><USER20> Nice summary! I wish I had this when I started getting into Promises a couple of months ago.

For a really interesting look ahead to how Promises (and more!) might address sync/async symmetry in ES6/7, check this out: [https://youtu.be/DqMFX91ToLw](https://youtu.be/DqMFX91ToLw)

</comment><comment><USER19> Really a lot more explanation than necessary. Get a feel by using them and using a debugger or just console.log to trace execution. Then compare with equivalent callback code and async/await with babel.

Then use async/await and look at node-modules.com to find modules that convert to promises so you can use async/await.

</comment><comment><USER21> See section about handling error and promises. Very well done!

You won't see that in the typical "check out how cool promises are, async and fast all the things".

And promises indeed look cool, and make for nice short demos and they are easy to understand in short examples. Only when you start building a large applications based on them, where error handling has to be done, you start realizing they are bit like threads. Promise callback chains started from one event, can interfere with other promise callback chains that started from another event. And if they modify the same data, you now also have a race condition as well.

I would basically look at this statement "In the synchronous world, it's very simple to understand computations when thinking about functions: you put things into a function, and the function gives you something in return" and follow through, but in a different direction -- pick the synchronous world if you can.

Sequential things should be sequential and concurrent things should be concurrent. Single request processing is sequential. For this request do x,y,z in order. Can't do y unless x finished. Well sit and wait for x to finish. But requests themselves can be concurrent and run in parallel. For example a request comes in, reads the database, updates the database, bumps metrics, makess other sub-requests and then responds. It is sequential and should be kept sequential. If you platform cannot handle that, think very well about your platform, and perhaps pick a better platform. What does that mean practically? It means picking green threads (Python gevent, eventlet), it means Elixir, Erlang, Go goroutines, Rust's threads. Streams can be used as a higher level abstraction sometimes and so on.

<comment><USER22> Rust no longer has green threads.

Another good way to make things sequential is C#-style async/await, which is enough syntactic sugar over promises that everything looks sequential again.

<comment><USER21> It has regular threads but with appropriate data race safety guarantees. So that won't help in context when large number of concurrent contexts are happening, but perhaps it should first become a bottleneck and then solved, because it might just be good enough.

</comment></comment></comment><comment><USER23> They abide by the beautiful monadic laws.

<comment><USER24> When the event driven programming / promise hype started, I was like `Maybe $ exists thisConcept`

</comment></comment><comment><USER25> Maybe JavaScript isn't the best language to explain Promises in considering how verbose they seem to be next to procedural code.

</comment><comment><USER26> This article has put me over the ledge of taking some time to really study Go. Goroutines are starting to sound very attractive.

</comment><comment><USER27> And here I thought someone besides Mark Burgess was writing on Promise Theory...

</comment><comment><USER28> Came expecting psychology, was disappointed.</comment>


Embedly (YC W10) Launches New Website - <AUTHOR> http://blog.embed.ly/spring-cleaning

<comment><USER2> I think the site explains things much better now. It took me two visits to realize how cool Embedly was; I can't remember if that was from version 1 or 2.</comment>


Digital Evolution - <AUTHOR> http://www.paraschopra.com/blog/biology/digital-evolution.htm

<comment><AUTHOR> The blog post which I posted is a little old but I guess the topic of digital evolution is interesting. By the way, I have one digital simulator written in Python. If anybody needs it, let me know.</comment>


Show HN: AnyAPI – Documentation and Test Consoles for Over 150 Public APIs - <AUTHOR> http://any-api.com/ <comment><USER2> Could add the Stack Exchange public API?

[https://api.stackexchange.com/](https://api.stackexchange.com/)

<comment><AUTHOR> We use API Definitions like Swagger, WADL, I/O Docs, API Blueprint etc. to generate documentation. I can't find one for stackexchange, but I bet they have it somewhere.

I'm also toying with scraping HTML documentation to generate Swagger.</comment></comment>


What is the best RoR book for beginners? Best online resources? - <AUTHOR>

<comment><USER2> By far the best: Agile Web Development with Rails—Second Edition <http://www.pragmaticprogrammer.com/titles/rails2/>

DHH wrote it.

<comment><USER2> Ruby for Rails is a good one too. I haven't read it though. <http://www.amazon.com/Ruby-Rails-Techniques-Developers/dp/1932394699>

</comment></comment><comment><USER3> I highly recommend the Lynda.com online training for rails: <http://movielibrary.lynda.com/html/modListing.asp?sid=229> It does a great job of explaining the theory of rails and is a great intro to ruby as well.

Obviously Agile Web Development with Rails is the bible of RoR books: <http://www.pragmaticprogrammer.com/titles/rails2/>

I'd personally be wary of many of the RoR tutorials you'll find online: none of the ones I used did a good job of explaining rails at the conceptual level: you'll end up with a rails app from the tutorial, but limited understanding of what you did and why.

Updated:

This page has a good selection of relevant books: <http://www.sapphiresteel.com/Ruby-and-Rails-Books-the-essential>

My opinion is that one should begin with a Rails-specific book or tutorial and not feel the need to learn Ruby first. Much of rails code is specific to rails and, while you'll want to master Ruby eventually, you'll get enough from the Rails books.

<comment><USER4> I second the thought on getting Agile Web Development with Rails. Best damn book I've ever bought concerning Rails. It is true that there is code specific for Rails(which kinda peeves me from my comfortable Ruby shell) but I highly recommend you learn Ruby first just to get the feel of programming in it. I must say coming from Java(ugh) programming is Ruby is such a pleasure. As long as you can think idiomatically then you're pretty much set!

</comment></comment><comment><USER5> <http://www.digitalmediaminute.com/article/1816/top-ruby-on-rails-tutorials>

List of 12 very good tutorials.

</comment><comment><USER6> <http://poignantguide.net/ruby/> is one of the most entertaining writings I have read, not just out of technical books, overall. Highly recommended.

Rolling On Rails from OnLamp is a very quick and useful tutorial found here: <http://www.onlamp.com/pub/a/onlamp/2005/01/20/rails.html>

This is the easiest and fastest way to get started: <http://tryruby.hobix.com/>

<comment><USER3> Use this tutorial from oreilly/onlamp instead:

<http://www.onlamp.com/pub/a/onlamp/2006/12/14/revisiting-ruby-on-rails- revisited.html>

It's nearly 2 years more recent and up-to-date with Rails changes.

</comment></comment><comment><USER7> "Ruby for Rails" by David A. Black is a good choice if you're new to Ruby as well as Rails. It spends a lot of time on Ruby fundamentals and only brings in the Rails stuff after having explained the necessary bits of the language so that it actually makes sense. I read the Agile book first, and as a Ruby newbie, it gave me only a very vague understanding of the language. R4R did a much better job of that.

<comment><USER8> I have to second this. "Ruby for Rails", I feel, is a great resource for learning not only the Ruby language, but how to program with it. It really did not need the Rails section. I've only flipped through "Beginning Ruby" (apress), but that looks like a good Ruby book too.

</comment></comment><comment><USER9> I've heard good things about 'Ruby on Rails: Up and Running':

<http://www.oreilly.com/catalog/rubyrails/></comment>


Are random trading strategies more successful than technical ones? (2013) [pdf] - <AUTHOR> http://arxiv.org/pdf/1303.4351v4.pdf

<comment><USER3> The most interesting point I think is in the conclusion, namely the idea of central banks _adding_ uncertainty in the hopes of bursting bubbles while they're small.

"...if the policy-maker (Central Banks) intervened by randomly buying and selling financial assets, two results could be simultaneously obtained. From an individual point of view, agents would suffer less for asymmetric or insider information, due to the consciousness of a 'fog of uncertainty' created by the random investments. From a systemic point of view, again the herding behavior would be consequently reduced and eventual bubbles would burst when they are still small and are less dangerous; thus, the entire financial system would be less prone to the speculative behavior of credible 'guru' traders."

</comment><comment><USER4> "Thinking fast and slow" by Daniel Kahneman dedicates an entire chapter analyzing why traders think that they know how to predict the future of markets, even when faced with real data that proves otherwise. In fact, a completely random algorithm often outperforms professional traders.

</comment><comment><USER5> Relevant:

[http://cymetica.com/tuatara/returns- long-v07.html](http://cymetica.com/tuatara/returns-long-v07.html)

[http://cymetica.com/tuatara/returns-long- random-v07.html](http://cymetica.com/tuatara/returns-long-random-v07.html)

</comment><comment><USER6> Isn't this what you'd expect to see in a relatively efficient market? If technical strategies did yield an advantage, wouldn't that suggest that not all of the available information has been exploited?

</comment><comment><USER7> So-called 'technical analysis' is bullshit. News at eleven.

<comment><USER8> there are two types of technical analysis, subjective and objective.

subjective ones, like "head and shoulders" patterns, are totall bollocks. Objective ones, like MACD, EMA, RSI, etc... can be useful when _applied correctly_.

Unfortunately it seems like the author of the paper was working with some very naive use cases, causing him to not get very good results (I will admit, I only skimmed the paper as it didn't seem that useful to me).

I can tell you from first hand experience that technical analysis trading strategies, when applied correctly, are very, very, very effective.

<comment><USER7> >Objective ones, like MACD, EMA, RSI, etc... can be useful when applied correctly.

True, they can serve as useful tools for describing market conditions. If I want to tell a computer to do something when the market is falling rapidly, then I might define "falling rapidly" as "price below the 15-second EMA" for example.

But do they have any _predictive_ power? No.

>I can tell you from first hand experience that technical analysis trading strategies, when applied correctly, are very, very, very effective.

I doubt it. I've never met a professional trader (i.e. at a reputable firm) who uses them, and they'd be laughed out of the industry if they did - <USER2> least in all the places I've worked. I imagine the only people who 'use them successfully' actually derive their edge from elsewhere (institutional advantages, etc.) and just don't realise it.

<comment><USER9> I think it's possible they have both short-term predictive power, and for it not to be profitable to trade the signals they generate. For example, something like _" price below the 15-second EMA"_ might mean in the short-term there is large probability of the price falling, and in the small possibility it reverse, it spikes a lot higher, making it not profitable to take a directional bet on the price. This can make those signals good for investors to decide whether to invest in a rising bull market with low yield and a tail risk of large negative return or a falling bear market with high yield and a tail risk of large positive return. There may be no objective profit, while allowing "subjective" profit in utility by matching investor's risk profile. It does sound like gd1 has more experience than I do, though, so don't trade off my perspective.

</comment></comment></comment></comment><comment><USER10> Or maybe technical tradings are no better than random ones.</comment>


Ask YC: Ripping RealMedia streams - <AUTHOR>

I found a Godel, Escher, Bach class on MIT's OCW (http://ocw.mit.edu/OcwWeb/hs/geb/VideoLectures/index.htm ) but the video lectures are in streaming Real Media  format.  It'll be over my cold, rigor mortis locked body that I ever install RealOne on my computer again, so I was hoping someone could recommend a (preferably free) program to rip the .rm streams to a local file format.<p>Thanks in advance! <comment><USER2> mplayer -playlist [http://mfile.akamai.com/7870/rm/mitstorage.download.akamai.c...](http://mfile.akamai.com/7870/rm/mitstorage.download.akamai.com/7870/hs/godel_escher_bach/OCW_7.01.07_Godel-220k.rm) -dumpstream -dumpfile OCW_7.01.07_Godel-220k.rm</comment>


Show HN: Gonutss.com – Upgrade Your Food to Vegan - <AUTHOR> https://www.gonutss.com <comment><USER2> Doesn't work with an ad blocker enabled.

<comment><AUTHOR> It does now :)</comment></comment>