An SSH server that knows who you are - <AUTHOR> https://twitter.com/FiloSottile/status/1229093553269362689 <comment><USER2> Discussed four and a half years ago, albeit the Tweet mentions having a new source of data: [https://news.ycombinator.com/item?id=10004678](https://news.ycombinator.com/item?id=10004678)

The top-rated comment mentioning having an "IdentitiesOnly yes" setting in your ~/.ssh/config is still relevant if you want to have multiple SSH keys and ensure that only specific hosts get specific keys.

EDIT: Also link is to a retweet, the source tweet is [https://twitter.com/FiloSottile/status/1229093553269362689](https://twitter.com/FiloSottile/status/1229093553269362689)

</comment><comment><USER3> The availability of developers' keys on github can be quite useful, a few jobs ago I leveraged this to auto-provision ssh bastion hosts with public keys for all of the collaborators of a repo. Much easier than getting people to send them to you and add them to authorized keys by hand.

[https://gist.github.com/femto113/ef9162d670def84b3c684d2d305...](https://gist.github.com/femto113/ef9162d670def84b3c684d2d30588037)

</comment><comment><USER4> In theory there is a way to do it without needing to have IdentitiesOnly yes. That is, if ssh did something like:

        server -> user: nonce
        user   -> server: nonce2, h(nonce || nonce2 || publickey) (for every publickey)

or alternatively

        user -> server: nonce
        server -> user: nonce2, h(nonce || nonce2 || publickey) (for every publickey)

It would still leak the amount of keys (for the user for the 1st protocol and for the server for the second) but nothing about them. (I would also suggest using a modern hash function for h, such as blake(2) or sha3)

There should be a way to extend this protocol as to not leak the amount of keys.

<comment><USER5> Look at kssh (Keybase SSH)

</comment></comment><comment><USER6> That's a neat demo. Am I right to think it's exceptionally difficult — without local exec access on a machine — to induce a machine to open an ssh connection to an arbitrary host?

<comment><USER7> If you try to SSH into some new machine that you own, someone can redirect your request to an attacker's machine (via DNS attacks or MITM), and since it's a new machine, it won't be in your known_hosts file, so it will prompt if you want to trust this machine and 99% of people will say yes.

<comment><USER4> openssh makes the situation worse because if the key is already in your host file and it's just the ip/domain that changed it will not tell you that it recognises the key.

<comment><USER8> I mean, if a mitm has your SSH server key, chances are you are screwed anyway.

<comment><USER4> In the case which I am describing nobody other than you has your key.

<comment><USER8> But the key you are talking about the SSH client recognising is the server key right? Or did you mean after authorising your SSH client to connect to the unknown machine, and the key you were talking about was the identity public key? I ask because the thread you commented on was discussing users not looking carefully which servers they connect to when connecting to new servers, and that is based on the SSH servers key, not your identity key, which is why I said that if someone who is able to redirect your SSH connection to a different server also owns the correct servers SSH server key (as you said "just the ip/domain that changed"), then there isn't much the client can do to help keep you safe anyway.

<comment><USER4> > But the key you are talking about the SSH client recognising is the server > key right?

Correct

> which is why I said that if someone who is able to redirect your SSH > connection to a different server

I will try to be more clear. Often when I am away I use ssh to connect to my desktop pc which has a dynamic IP address. Even though I have already stored the public key of my server in known_hosts it keeps asking me to verify if I trust its public key every time that it changes IP address without even mentioning that it has met said public key before. So if I am not careful enough I might end up accepting the public key regardless, even if I am being MITMed.

<comment><USER8> Ah, yes, I've always found that to be a little strange. It is cryptographically possible for the server to establish to the client that it is who it says it is, just on a different IP

Sorry for the confusion, I misread your initial comment, thought you were saying it does what we're saying would be a good behaviour, and was confused as to why you thought this was a problem, but it was just I who was confused!

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER9> Can somebody comment on why the exposure of public keys is a problem?

<comment><USER10> > _Can somebody comment on why the exposure of public keys is a problem?_

It is not, it just makes you identifiable. Public SSH keys are… well, public.

</comment></comment><comment><USER11> Aside from IdentitiesOnly setting. I assume storing keys outside of ~/.ssh and calling each key via config file or ssh -i would render this useless. Perhaps even a simple bash function to rotate the needed key in/out of .ssh.

<comment><USER12> You can still store your keys in ~/.ssh as long as you don't use the default file names. By default, ssh will only announce id_rsa, id_dsa, id_ecdsa and id_ed25519. But if your key for GitHub is stored in, say, ~/.ssh/id_github, it won't be offered unless explicitly requested with -i or the IdentityFile config option.

</comment></comment><comment><USER13> I wonder how does it match my public key at github? Does it use a popular accounts index, or maybe he crawled a bit?

<comment><USER10> > _I wonder how does it match my public key at github?_

> _Does it use a popular accounts index, or maybe he crawled a bit?_

Ben Cartwright-Cox (aka. benjojo) [1] crawled many "github.com/USERNAME.keys" some time ago [2].

Filippo, being colleagues, probably asked for a copy of his database to run this experiment.

For example, here are the public SSH keys Linus Torvalds uses on GitHub [3].

[1] [https://github.com/benjojo](https://github.com/benjojo)

[2] [https://blog.benjojo.co.uk/post/auditing-github-users- keys](https://blog.benjojo.co.uk/post/auditing-github-users-keys)

[3] [https://github.com/torvalds.keys](https://github.com/torvalds.keys)

</comment></comment><comment><USER14> I thought this was pretty obvious.... but ok, so don't ssh places you're not supposed to?

<comment><USER15> I really don't think there's anything obvious about the fact that logging into an SSH server also exposes other login information stored in your computer. Given that creating a Github account is one of the first things beginner devs are guided towards it's worth keeping such beginners in mind.

And it's not so much "places you're not supposed to" as "places you know haven't been compromised in any way", which is difficult to know unless you're the sysadmin.

<comment><USER14> The fact that people are using this tool regularly and fail to grep a basic understanding of what and how the protocol works in mind blowing.

<comment><USER15> Is it really? It's what Github recommends for every new user without explaining in real depth what's going on.</comment></comment></comment></comment>


Practical Tips for Hiring Ruby Web Developers - <AUTHOR> http://www.rubyinside.com/tips-hiring-ruby-web-developers-4757.html

<comment><USER2> Even if you aren't hiring, I think this is an excellent article to read. These are practical skills to practice, and I'll certainly be keeping them in mind before going into an interview.

</comment><comment><USER3> Good article. I disagree with making "Corner case identification" a major element of your sample coding session. While its great for developers to consider "what happens when X goes wrong", I've definitely spent time with programmers who spend more time thinking and writing about the 'what ifs' instead of writing useful code.

Overly defensive programming leads to code that is _never_ executed. That is wasted code, time and money.

So, in his example, considering that the twitter api may go down and how to handle that is probably a good thing. Trying to self-heal if Twitter suddenly changes their API is probably a waste of time.

</comment><comment><USER4> Good article with a lot of great tips. But I'd like to see a follow up that elaborates on the practice of hiring experienced developers who don't know Ruby. Many of these questions wouldn't apply in that case and it would be hard to detect any warning flags in that case.</comment>


The secret to a higher salary is to ask for nothing at all - <AUTHOR> http://qz.com/77020/the-secret-to-a-higher-salary-is-to-ask-for-nothing-at-all/ <comment><USER2> Throughout my career and my life I've followed this strategy disparagingly called being a doormat below. I have a friend who has followed the opposite strategy, always asking for and fighting for the most he can squeeze out of an employer and life. Strangely, I have often been paid more, been given more benefits and been generally happier. I think this works because unlike what many people seem to think, the other side aren't typically sociopaths trying to squeeze the last drop of blood out of the employees. But they will respond that way when pushed.

People generally have a solid understanding of what is fair and what isn't. When we start a negotiation from a point of unfairness and unreasonableness, both sides are then on the defensive which anyone who has read Dale Carnegie knows is a recipe for failure. I'm not sure I buy into the OP's idea of asking for $0 since that's just as unreasonable but it's unreasonable in a way that brings the other side closer instead of pushing them away. If you sincerely say you want to work for what you make, the majority of people will want to give you what you deserve. Are there people out there who will immediately try to screw you? Yes but that happens, you get as far away from them as possible. And if you can't recognize those people, you have far bigger problems than learning how to maximize your negotiations.

Negotiations seems to work best when they are discussions, not attempts to get the most of of the other side. Of course, if you're working for a boss who used to be a used car salesman or a sociopath, by all means, be prepared to have to fight for everything you want. And be prepared to be miserable to boot.

<comment><USER3> Are you and your friend working in the same field and having the same capabilities? I'm pretty sure a brilliant "doormat" programmer will make more than, say, an average "maximizer" salesman.

<comment><USER4> I was with you until the example. At any company I've ever worked at that had both sales and engineering, the salesfolks were making 50%-100% more. And those are the typical negotiating strategies of each group.

<comment><USER5> Exactly. At a software company, the sales people are paid dramatically more. At one company I was at, the new salesman made more than the CTO.

<comment><USER6> Well the adage is, the closer you are to where money comes into the company the more you can make. Most sales jobs are also commission based which means if a sales person is making a lot of money the company also made a lot of money.

<comment><USER5> I agree - I would rather pay sales guys all day. I tell each that I'd love to keep writing them big checks, as big as I can make them.

</comment></comment></comment></comment></comment></comment><comment><USER7> "Seventeen years later, I'm still with the same firm."

This isn't a small sample, it's a _single_ sample. It barely qualifies as an anecdote. OP just had the good luck to find a good company and recruiter.

<comment><USER8> I also wonder if his situation is unique to his industry:

He works in the "securities industry as a proprietary trader and hedge fund manager".

</comment></comment><comment><USER9> He didn't ask for nothing. He asked for zero salary along with the highest profit sharing percentage in the industry. He works as a prop trader and hedge fund manager, so his value delivered is totally quantifiable. In othe words, he offered to take on more risk in exchange for a higher percentage return in a business where it's hard for your employer to be dishonest about exactly how much value you delivered.

<comment><USER10> It also seems like the type of business where effective game-theoretic methods that maximize positive cashflow are going to be valued higher than, say, teamwork and team loyalty.

<comment><USER11> But aren't teamwork and team loyalty just two means to the same end--which is to maximize profits. So why does it matter that it's a type of business that only value the end instead of the means?

Reminds me of designer friends of mine that constantly harp on about their 'design process'--but, do your users like your product in the end or not? That's the key. The process is merely _a_ means to an end (there are many means in business, but generally one end: profit). If the end sucks, the means is worth very little (it's only worth is as a lesson in what _not_ to do).

<comment><USER10> You want the job don't you? The job involves working with people.

Here's how that negotiation would go with any hiring process I've ever worked with:

"So Mr. Pwnguinz, what are your salary requirements?"

"On this piece of paper I've written down the least I would work for. Now you please write down the most you are prepared to offer a perfect person, irrespective of whether I am that person or not. Then we shall exchange papers."

"This is highly irregular."

"If after exchanging papers, we find that your number is less than mine then we can save time."

Two ways I see this going:

A. "Thank you for your time Mr. Pwnguinz".

B. The hiring manager writes down what they were considering as an initial offer, you write down $0, and you become an HR office legend.

</comment></comment></comment></comment><comment><USER12> Here's another, equally replicable secret to a higher salary: Go for a walk. Run into a billionaire. You both get knocked down. Tell the billionaire to watch where he's walking. The billionaire stands up, says, "Hey, kid, you got moxie. I'm now going to hire you at twice your current salary." Say, "That's insulting." The billionaire responds, "All right, make it quadruple your current salary." Enjoy your new career and 4x pay raise!

It's that simple.

</comment><comment><USER13> This seems like the secret to get paid minimum wage.

<comment><USER14> Just keep demanding they pay you less, go lower man!

</comment></comment><comment><USER15> I think HN is reaching a tipping point with spam on this one.

<comment><USER16> You are rewarded for using Ghostery and other anti-spam measures when reading HN

<comment><USER17> What do you mean? Would Ghostery have blocked this post, or the article it links to?

<comment><USER16> In my experience, likelihood of spam content is correlated with number of ads or tracking cookies (the indicator number in ghostery). I expect posts with more than 5 tracking cookies/ads to be spam

(and yes, techcrunch rings in at 15, and almost all of their content is garbage)

</comment></comment></comment></comment><comment><USER18> > "Brooke Allen has worked for 30 years in the securities industry as a > proprietary trader and hedge fund manager."

Let me translate:

"Brooke Allen has worked for thirty years in a industry dedicated to fleecing the stupid rich. Hedge funds uniformly deliver lower-than-average returns with high volatility, but high payouts to the staff involved sucking from other people's money. Mr. Allen believes that working in an extremely-well-paid industry where he managed to get extremely-well-paid makes him a good salary negotiator."

</comment><comment><USER19> Okay, this is a very interesting article with a high risk approach used by somebody who hasn't ever had to change jobs so comes from the point of view of somebody with a single data point. I'm not saying disregard it, just that...your mileage will vary. As an employer, I'd never ever play these games with a prospect.

As an employee, I've used a different approach (note: this is not intended to be reflected on the very strange environment of a startup, but on more established businesses)

When you start the job, ask for a salary that you'd be happy with, in fact give them $5-7 thousand dollar range with your ideal salary somewhere on that range (usually on the low end), and would stay happy with so long as it continued to rise at a reasonable percentage slightly higher than inflation. You also get information based on where they come in on your range.

The very first time you get a pay raise under that percentage or that doesn't keep up with inflation? Change jobs. If your pay raise isn't even keeping up with inflation, congratulations your reward for your last year's work is a de facto pay cut. That's what your employer thinks about you. Time to leave, period.

In one case I secured a better paying job in another part of the company, gave my intent to leave and was given a counter offer with a promotion and a double digit pay raise that beat where I was going. I told them that if I stayed, I would be committing to 12 more months, if my pay raise was again unacceptable I would leave. The next year the raise was below inflation, and I left for a much better job.

If the economy is good, give yourself a raise when changing jobs, treat it like a promotion, give yourself two years worth of pay raises for the new job when getting down to salary negotiations.

If you get promoted, expect at least two years worth of pay increase percentages. If you don't receive that, it's not a promotion, it's just more work for you. Never take-on additional responsibility without additional reward.

If they don't ask for your salary requirement, see what they offer, if it's low don't feel afraid to point that out and ask for a more realistic salary. In many cases I've worked in expensive cities, in small offices, that are part of very large companies in different states. Their salary expectations may be great where their HQ is, but might stink in the city. Point that out.

I've also worked in places where the yearly raise percentages reduce as your pay increases. So a starting employee on a starting salary might easily see double digit increases year over year, while an experienced employee might barely keep up with inflation. They struggled to keep experienced talent around.

If you're offered a choice between a small bonus and a pay raise, take the pay raise. That increased base pay _makes a difference forever_. Say the bonus is $5000 and the pay raise amounts to $2000 the next year. In three years it's worth $6000. In ten it's worth $20000 _even if you never get another pay raise again_. It's pretty much the best guaranteed investment you can ever make. Now, consider that it'll become part of your base pay history that you then make raises off of, which are percents of your salary, that raise is worth even more! Employers know this and try and convert pay increases into bonuses all the time, it's a one time payment that then gets off their books if they have a bad year the next year. Don't fall for it. There are exceptions, extraordinarily large bonuses shouldn't be turned down of course.

One you accept a salary (this includes your pay increase), commit to working there for at least 12 months. It can suck sometimes, but long term it looks better on your resume. I've typically put in 3-5 years at most places. I've never had to have one of those "why did you leave this prior employer after 3 months?" discussions, but I have had to have "why did you leave this place after working there so long?". In this market, working too short or too long can be unusual. The employee who's working someplace for 17 years and then suddenly wants to change jobs is a red flag. It wasn't boredom that made them change their job, any job is boring after a few years. Getting to 17 means they can beat that problem. _Something else_ happened.

Following this plan, Over the last 18 or so years, starting out with a yearly pay of under $18k, I've managed to get consistent pay increases that are more than double inflation while working for bigCos, year over year pay increases of 15 to 20% have not been uncommon (if you aren't too stuck to a single company). I'm not "rich" by any means, but I live a _very_ comfortable boring suburban life free from any debt beyond a rapidly disappearing mortgage on a very comfortable home with enough left over for lots of overseas travel every year. In about 5-6 years I'll have paid off my home, gone completely debt free, and then will literally have more money than I can spend in a normal day-to-day life. I still have to work, but I rarely have to think much about what things will cost when going out shopping. I went to normal boring state school for university, and have managed to consistently make (or grow my salary faster) than every single one of my peers who went to a "better school". Any advantage they had starting out has more than disappeared over the years.

Startups are a very different beast. And I know that alot of this won't be popular with the startup founders here ;)

#1 Don't accept a bad salary. You'll get all the lines about equity and stock options etc. In the end, unless you are one of the first employees and you happen to hit the lottery and end up at the next billion dollar company, your equity will be worth at or less than most normal bonus packages you'd receive anyway if it's worth anything at all. Take a normal salary. A company with good funding shouldn't squawk at paying their people decent salaries. But you might take a small hit on the salary. Keep a mental note of what this hit is if you go back to a BigCo. Correct for it, act like you were paid the higher amount, when negotiating your new salary with BigCo.

#2 You are very tied to the ups and downs of the company. Expect not to get a pay raise from time to time, especially in the early days until the company starts making a profit. If the goal of the company is not to make a profit and that you'll get your reward out of options, consider your payout divided by the number of years you'll have to put in and see if that makes you happy. Consider what would happen if the payout is $0.

#3 If the business booms, time to renegotiate your salary. Sometimes the company hits super profitability, point out that you took a smaller salary to get the company through the lean years and now it's no longer lean. If you went multiple years without a pay increase, expect the first increase to be unusually large (to make up for it) and future increases to be more normal.

#4 Don't accept ridiculous paycaps. They're stupid. A couple very well known startups cap their employee pay at $120k. One I know of hasn't paid raises for years. The employees who took a pittance first-out-of-college salary are still getting paid that 3,4 and 5 years later -- but now many are married and quite a few are having kids. Their company recently advertised that their valuation is nearing double digit billions (but now in their 5th or 6th funding round with no public plans to sell or go public so equity these days is almost worthless). Does that sound right?

Remember, what's your payout going to be divided by years. Suppose bigCo buys this startup tomorrow, many of those employees might see a sweet $150k payout. Or $30k per year for 5 years of work. Suppose their starting salary was $50k that means they've been working for $80k the entire time. Instead of 5 lean years they could have had 5 satisfied pay years elsewhere.

Even worse, when moving on to another company, especially a bigCo, their suppressed salary puts them way down at the bottom of the pay scale. It's "diseased" their future salary prospects. Just like taking a small raise instead of a bonus "boosts" your future salary prospects, they've managed the inverse...and because the caps and pay policy of this startup are very publicly known, they can't negotiate or talk their way it.

#5 All is not lost, perks are awesome, figure out how much it would cost you out of pocket _for the perks you use_ and then figure that into your total compensation. Some places are receptive to "my total compensation at my last place was $xyz, but I'm looking for a different kind of mix of $qrzw". These are more complicated, but you can say "my last employer gave me about $5k a year in perks that I used. I'd rather have that as salary here". It's reasonable, even if not every place is receptive to it.

<comment><USER20> _Don't accept ridiculous paycaps. They're stupid. A couple very well known startups cap their employee pay at $120k. One I know of hasn't paid raises for years._

That is startling. Is this a popular thing in the Valley?

<comment><USER21> I worked at a startup in NYC that had a $200K pay cap. It applied to everyone, including executives. However, I believe they abandoned the policy because it made it too hard to hire.

</comment></comment></comment><comment><USER22> > _"I explained that my goal is to live a debt-free life, and therefore I > wanted to give value before receiving compensation."_

Really, "live a debt free life" by letting other people pile HUGE debts on you?

So the top dogs get lear jets, nice Jaguars and golden parachutes with the fruits of the work you and others like you contribute, since they get to keep all the extra profits off of your work (besides those needed to keep the company going and moving forward).

If you really want to eliminate debt, eliminate it on BOTH sides.

</comment><comment><USER23> I am a "taker" and, strangely, I love this approach. Why? Because this strategy leaves both parties feeling the opposite of driving off a used car lot (where someone got squeezed, and someone did the squeezing). Yet, it maximizes value.

For most of my career I've made more than my peers, simply because I asked, and asked, and asked. More often than not, when I asked my salary went up. It's that simple. The problem is that eventually my employers have begun to felt a little squeezed and when a rough spot came around, that smoldering ember lit a fire that sometimes ended with me leaving the company. It's not easy being the highest paid person in the company by a margin of 30%. I don't say that to boast. I mean it. Theres a massive expectation placed upon you.

I think I'll use this new negotiation strategy in the future instead.

</comment><comment><USER8> Part of what the OP is saying is true: I've been rewarded by employers (especially at the beginning) by working hard, not making demands, and delivering more "value" than I received in compensation.

Working hard and delivering more value than your receive is generally a good strategy.

However, eventually you will need to learn the art of asking for things: raises, benefits, etc... In my experience the squeaky wheel DOES get the grease.

<comment><USER24> Imagine two people working hard, doing their best. Imagine their boss, also working hard, too busy to stop and think about the future. One day, one of the workers asks the boss for a raise and a promotion. The other worker just assumes his hard work will be noticed and rewarded.

Who do you think gets the raise? The boss makes the easy decision and goes with the person who asked for it.

I've seen it happen time and again. You can either cry that the world is unfair, or just be the person who asks for what you want.

<comment><USER8> Exactly. This has been my experience as well (especially in companies with no set process for salary reviews).

</comment></comment></comment><comment><USER25> tl;dr employers will like you if you tie all your compensation with performance. For some positions this is a good thing when you have control over the outcome and you're confident you're upto par. Sales and trading for example are good areas as the performance is easy to quantify. Creative professions... not so much.

</comment><comment><USER26> This seems like a very long way to describe the very old advice of never being the first to say a number. There are better articles online, specific to salary negotiation and how to refuse to give a number without being a dick about it.

<comment><USER27> I hadn't realized, but you're right, he got them to give the number first.

Also, as many pointed out, the authors' industry is VERY special.

</comment></comment><comment><USER28> Reason for posting on HN: "come to our start-up and work for free. We will compensate. Maybe. Sometime. See that one hedgie-trader did that and was OK!"

<comment><USER29> Almost everyone is cynical in the comments today...must be the weather.

I actually found the article interesting; sure the author didn't test his theory over multiple jobs but one might argue that his approach was SO SUCCESSFUL that he deemed it worth staying there for 17 years (and likewise for the company).

The method sounds like a doormat approach (particularly the title, but it's meant to grab your attention) but what it really is doing is forcing both parties to be _honest about what they want_. Which, honestly, is a pretty smart move because it engages a less exploitive psychology in both parties and reveals _what the true value to be provided is_.

<comment><USER22> > _Almost everyone is cynical in the comments today...must be the weather._

Or the cynicism inducing post?

</comment></comment></comment><comment><USER30> I'm certainly going to try this in future negotiations. However I'm sceptical that a prospective client/customer is going to show their hand by revealing (albeit on a swapped piece of paper) their maximum bid in many cases.

No-one wants to pay the maximum for any commodity. It runs contrary to game theory.

</comment><comment><USER31> I strongly disagree with this. If you think that you can bring a good value to a company, you should price yourself at a premium level. If you don't believe in yourself, why would you expect the company to do that? After you get hired, every raise will be based on your current salary (so a 5% increase of a higher starting point will get you to a higher salary). After that, the only way to have a significant raise is to change jobs. At least this is what I've noticed in my case.

I know what I'm doing, I'm good at that and I know that it's hard for companies to find good people (most of them either lack experience or they simple don't care about the quality of their code). Why shouldn't I ask for more? I care about the job I'm doing and I'm expecting the same thing from my employer.

</comment><comment><USER32> A job where I can swing that type of contract and have the onus completely on me to prove my worth sounds perfect. The sad reality is that it seems like in my field of work the dependencies on others is enough to make such a move very risky. From my experiences I can imagine a few situations which of results in a "you didn't have a good year" kind of reward even though it wasn't my fault and I truly did the best that anybody could have.

When your work in a job that requires leverage and you have dependencies you need your entire dependency chain to do their job so yours can be judged accurately.

</comment><comment><USER33> The article says that the OP 'developed an approach'. If I'm to believe that this is a technique, and not just a fortunate hiring for employee and employer, then there would need to be more examples of how this works, not just one.

From the content of the article alone it seems like finding a good employer might be a way of securing a good salary. No shit.

</comment><comment><USER34> This theory should be strongly coupled to a culture. In many countries this will just never work.

</comment><comment><USER35> I'm forced to admit that this strategy reads like something out of the Vorkosigan Saga. Then again, there's a reason the Vorkosigan Saga is awesome. The question is, can it really be made to work outside the sample size of one?

<comment><USER27> I guess I'll have to read the Vorkosigan Saga sometime, then :) (note: I'm not the articles' author)

</comment></comment><comment><USER16> In the securities industry high salaries are common because they usually are paired with lower percentage payouts. If you want a higher payout, you are generally expected to take a small or no salary (in the extreme case)

<comment><USER5> I'd take that deal all day. It's like being a founder, with lots of resources, and much less risk!

</comment></comment><comment><USER36> "I explained that my goal is to live a debt-free life, and therefore I wanted to give value before receiving compensation."

Why? If someone is hiring you to do something, they're taking the risk of you not delivering enough value, but they're also entitled to whatever rewards they can get from your work, which can be several times what they're paying you. Basically the author wants to take all the risk, and if he doesn't have a substantial bonus, very little of the rewards.

Well, of course anyone can live to make other people profit more, but it's a bit strange to tell everyone to live like that.

</comment><comment><USER37> Excerpt from the link:

"We started with base pay. I wrote down the least I would work for and asked them to write down the most they would offer a perfect person, irrespective of whether I was that person or not. If when we exchanged papers, their number wasn't higher than mine then we could stop there and save time. Their number was twice the best base pay I had ever received in past jobs, and my request was for $0."

I am not understanding. The least he would work for is nothing? That can't be a "start base pay", can it? Could someone clarify? Thanks!

<comment><USER38> > _We did the same thing with profit sharing percentages. However, this time I > wanted the highest payout standard for our industry_

He was confident that his % share of any profit he generated would be enough that he didn't require a base pay.

</comment></comment><comment><USER39> Hahaha, go ahead and try it, and then you wonder why you are getting paid less than 100k while a incompetent new hire is making 150k fresh off of school.

</comment><comment><USER40> Slightly off topic, but not too much: the article offers good advice as far as compensation goes. I have found another trick works really well in consulting: avoid locking in customers. Document everything, be willing to help train replacements, train employees to take over your tasks, etc. This gives customers a warm-fuzzy feeling about using your services, which seems to attract more work.

</comment><comment><USER41> Why does Ghostery[1] keep the blog content from showing up at all?

Hmm, seems to be in particular "Adobe Digital Marketing (Omniture) [2]. If you have ghostery block this, you can not see the blog text.

[1] <http://www.ghostery.com/>

[2] [http://www.ghostery.com/apps/adobe_digital_marketing_(omnitu...](http://www.ghostery.com/apps/adobe_digital_marketing_\(omniture\))

<comment><USER42> > Hmm, seems to be in particular "Adobe Digital Marketing (Omniture) [2]. If > you have ghostery block this, you can not see the blog text.

I have it blocked and the site works fine.

<comment><USER41> Huh, weird.

</comment></comment></comment><comment><USER43> Does anyone else have trouble reading this on Android? Every time I touch the screen to scroll it bumbs the text to an unknown location.

<comment><USER44> In Windows I cannot scroll with the keyboard or the mouse wheel. I have to grab the scroll bar and drag it down. Their layout is FUBAR.

</comment></comment><comment><USER45> anyone else feel like qz.com's layout is awful and cramped?

</comment><comment><USER46> I can't read the article. This URL ends up showing me "All the paths to immigration" or something. Does anyone have a copy of the actual content I can read?

<comment><USER46> Content mirror: <http://peg.gd/38G>

</comment></comment><comment><USER47> Ironic that someone who has spent his life working as a trader (i.e. producing _nothing_ ) is so concerned with "debt and honor."

</comment><comment><USER48> <http://en.wikipedia.org/wiki/Prisoners_dilemma>

</comment><comment><USER49> in france, you cant

fuck my life

<comment><USER50> What can't you do? Get paid enough to live very comfortably in one of the world's great and interesting places?

<comment><USER49> getting fucking HIRED.

The left has FINALLY tried to pass a bill here to let companies fire people a little. Many yelled, but in soviet france, it has been a real issue, and the right/sarkozy did not manage to change something about it. It's sad, because this is the #1 cause of unemployment here, it's the total opposite of the US. The minimum wage is also a big issue which adds up to the fact companies almost cannot fire people.

That means companies are too much careful and cannot hire without being the employee will not drag everyone down. It boils down to companies hiring only people they trust, e.g. the friends of employees or their relatives.

It's weird, because for some time now, since 2004 or something, I have been so much interested and obsessed into the american culture in general, without really thinking about working there, or going to canada. I love the US and its issues, since the 2008 crisis I've been fascinated by how an economy works.

"best place in the world" oh boy, well I won't argue with this, but when you live a developed country, wherever you go, there's nothing to work on, because of human nature, and you can't say shit about it.

You either wait for some global conflict to make leaders and big owners react to the problem or force them to, which is really stupid to wish a thing like war, or watch terrorism happen and say "not surprising". You can also wait for the older generation to die out to leave room, but in the end it's just biology.

</comment></comment></comment><comment><USER51> I think of it differently. There are maximizers, satisficers, and doormats. Maximizers are the ones who will go all-out to get the best deal, and sometimes even play the system. They're the ones who know that you can get a box of cereal for $3.79 instead of $5.29 at another store. They'll also come up with excuses to line their job interviews on the same week so the offers roll in at the same time and they can start a "bidding war".

Most people look at maximizers, in the context of negotiation, as being a bit sociopathic. I disagree; I think it's sometimes quite reasonable to take a maximizing strategy. It can be exhausting, but I wouldn't call it sociopathic.

Satisficers have a goal and a sense of "good enough" and, as long as they're north of it, they're happy. Doormats are the ones who take what's given to them. Being a doormat is the worst. You never win by being a doormat.

The problem with "ask for nothing at all", in the workplace, is that it makes you a doormat, not a satisficer.

On the other hand, you have to know when to maximize and when to satisfice (is that a word? It is now.) There's a time for each. Usually, you want to satisfice on salary and maximize on project quality and work culture. But there are exceptions to that rule.

<comment><USER52> The author seems to be recommending that you present as a doormat. You're exposing your jugular as a sign of trust, similar to the practice of shaking our right (weapon) hands as a greeting. If the other party is going to try to take advantage of you in this situation, walk away. You've now seen how they'll behave when they think you're in a weak position.

<comment><USER53> This only works if you are actually in a strong negotiating position (you have or can get equivalent/better offers elsewhere), but you are willing to pretend to put yourself in a weak one, to test the other party's good faith. Risky. If you expose your jugular, you might establish trust, but you also might get your throat slashed.

<comment><USER54> Or, psychologically speaking, it puts you in a strong position.

Think about poker. Do you really know the other player knows all your cards when he/she bluffs?</comment></comment></comment></comment>


Twilio's first support hire joins engineering - <AUTHOR> http://www.twilio.com/engineering/2012/10/01/becoming-an-engineer <comment><USER2> Congrats! I remember seeing posts from you now and then about how you were learning programming. (IIRC, your first contact with programming was for the demo to get your track jacket?) It's great that you kept at it.

 _My first task was to add a dismiss button on a Javascript popup. I thought the task would be easy, but each page actually has dozens of files of code fitting together to make a page work– style sheets, controllers, distributed all around the code base. (…) Instead of being off-put by how long it took, or being overly sympathetic, he just said, "Yup. That's what development is. It's very frustrating until it works."_

I'm currently in a similar situation, working on a project with a guy who uses libraries and frameworks I know very little about and it honestly frustrates me. I've had other things to do on the project so far, so I've postponed digging into it.

But it makes me wonder if that's how things should be. Often you're fine once you're beyond the breaking waves of setting up your environment and getting a grasp on the codebase, but before that, it can be _very_ frustrating… especially, when you want to implement something, that you theoretically know exactly what you want and what you need, and you get slowed down by some problem with library incompatibilities or what not.

<comment><USER3> I think the lecture is broader here. Frustration is really at the core of programming. And whenever you're frustrated, thats a wonderful lession ahead of you in understanding what makes the systems tick that you take for granted.

I've recently had the pleasure to drill down (from C) to single machine instructions in my quest to understand why a conditional branch was seemingly having no effect, on an architecture that I couldn't debug on. As it turns out, the compiler would sometimes use a memory addressing scheme that wasn't supported on this particular architecture. I had to work around this bug by writing assembly that correctly accesses the memory.

It's incredibly frustrating when you end up at a point where the only abstraction (and seemingly faulty) layer below you is nanometer-sized transistors. And all the more rewarding when you reveal the actual problem and get to extend your knowledge.

(Of course, this doesn't really apply to all the ridiculous pain points that annoy us by design. Things like browser compatibility come to mind.)

<comment><USER2> I can certainly enjoy figuring out what's wrong sometimes (and unravel the whole string of events: "oh now that makes sense: this was happening which made this and that behave that way") and I the satisfaction you're referring to; but other times, it's just so far removed from the real task at hand that it's not even funny.

A recent example would be when I was trying to set up my local environment with virtualenv, whose _whole purpose_ is to make that easy. Everything seems fine but pip (Python package manager) was throwing errors. The culprit was that virtualenv creates Python scripts in the local directory with a hashbang for a local version of Python. The thing, it turned out, is that hashbangs don't work when there's a space in the path. And there was a space in my path because I wanted to use Box's sync folder which (stupidly I must say) is called "Box Documents". Now I know.

Long story short, the point is that I wasn't trying to debug virtualenv but had to dig deeper than I wanted into it just to get started on the problems _I_ created. :)

Though you're right: just recalling this, I have a feeling of victory over the problem.

</comment></comment></comment><comment><USER4> I said this elsewhere already, but I've been really proud to see Twilio take steps such as this one to bring more people (and more women in particular) into programming. Not being a part of the web team, I've only watched from the sidelines as Renee, who's consistently been in the office before I arrive in the morning and after I roll out in the evening, has worked to master a whole slew of technologies, and to ship new, non-trivial features for our customers.

I'm really not sure how the two facts we see here -- of people working exceptionally hard to better themselves, and of a company going out of its way to help people do that -- have to do with a bubble. It's hardly a new idea that companies do better financially when they help their employees learn to do work that they couldn't do before, or to do it better.

As the technology community, it's in all our interest to help people learn things they couldn't do before. Twilio's story is one example. Other great ones include RailsBridge, PyLadies, the Boston Python Workshop, and PyStar. Let's do more of this!

</comment><comment><USER5> This makes me love Twilio even more :D I wish more companies would realize the benefit of cultivating talent from within instead of mining other companies for "rockstars"

<comment><USER6> My first job was at a company that did exactly this. Most of the developer staff came in the same way I did: part time college student software tester/tech support.

It was only after the company was purchased by a company with a very different mindset did I realize that this wasn't universal. This makes me just love Twilio a little bit more.

</comment></comment><comment><USER7> Congrats, that's a great move and I'd think a good decision for Twilio. My product manager came from our Customer Service team and is the best PM I've had. I think you nailed it when saying programmers don't need to be brilliant, but rather "it's more important that you're diligent and a methodical problem- solver."

<comment><USER8> Especially when you're working on an existing product. Maybe it took some brilliance to come up with the first version of Google, but once something grows into a bajillion lines of code with tens or hundreds of people all working on little parts of it, brilliance will only get you so far.

</comment></comment><comment><USER9> Congrats Renee. I've only met her a few times, but she's an insanely good listener, which is rare enough in programmers to count as a super power :)

</comment><comment><USER10> I love this. Companies should develop great employees not hire them. It breads loyalty and honor.

</comment><comment><USER11> The company I'm a contractor for originally hired me as a customer support agent. 9 years later, I'm one of the lead developers. Keep up the good work!

</comment><comment><USER12> Renee has handled a good portion of our support tickets over the years and does a fantastic job. It's refreshing to have someone treat even the smallest problem of yours so personally - making sure everything is resolved to your satisfaction. It's huge having someone who's overseen thousands of customer tickets becoming directly involved in the engineering process. Good luck Renee!

</comment><comment><USER13> I consider myself to be a relatively experienced developer, and even still, reading this blog post really lifted my spirits.

I write code for a living, and even though no one has ever told me they weren't happy with my performance, the constant influx of new techniques, languages, algorithms, and systems in the programming world have always made me feel like an inferior developer. I constantly feel like there's so much to learn, that I can't possibly be good, as if the only worthy developers in the world are the top 500 geniuses that work for Google and Facebook and are somehow capable of magically knowing everything.

Knowing that this isn't the case, and that companies like Twilio are finding value in employees with skill sets much narrower than mine, is a good feeling. It's also really nice to know that they're open minded to the point that they respect this guy's talents as a developer just as much as they did as a customer service rep. #thehighroad

<comment><USER14> A more cynical quip I like to use is that the corollary to "you're never the smartest guy in the world" is "you're never the dumbest guy in the world".

The more advanced you get in your field, the more you understand how little you really know. I feel like this every day. It's easy to forget that to a ton of people you're still a guy/gal who works magical wonders with computers.

</comment></comment><comment><USER15> I love reading stories by people getting started. On software dev, and other things too. Keep on hacking !

</comment><comment><USER16> Very cool. I think that stories like this one contradict the often quoted advice to hire only rock star hackers in a good way. People aren't born A,B, or, C players - they learn those skills over time.

Keep up the great work!

</comment><comment><USER17> Congrats! Really awesome that you followed your interests and made the leap.

It says great things about twilio that they are willing to train and grow their employees. Other companies should take note.

</comment><comment><USER18> Congrats! I've always wanted to be an engineer but never have the talent to become one. Great job!!!

<comment><USER19> It doesn't take much talent, just an interest.

<comment><USER20> And persistence. You're absolutely right.

For years I hired developers and told myself I was incapable of doing what they did, never tried to learn. After the job market got hot and I was having to pay good devs $100+/hour I decided I had to finally learn myself. Less than six months later I can now do 80% of what I used to pay people to do for me and 100% understand what they were doing from a high level and why. In another year I think I'll probably be a better developer than most of the people I've hired in the past (mostly because I sucked at hiring good devs because I had no idea how to evaluate their skills).

There's nothing I've had to learn that was especially difficult or that requires someone a lot smarter than me or a lot better at math etc. It just requires persistence and a willingness to put up with frustration until you finally solve problems.

My only regret is that I didn't start learning 5+ years ago.

</comment></comment></comment><comment><USER21> Nice to see you stayed with dev :)

</comment><comment><USER22> Congrats Renee!! Keep calm and carry on.

</comment><comment><USER23> Renee you are such a badass, nice going!

</comment><comment><USER24> And if anyone didn't think the tech sector is in yet another tremendous bubble, this article is all you need.

</comment><comment><USER25> Awesome, Renee!!!!!!

</comment><comment><USER26> Yay Renee!</comment>


What's a great relationship book/guide - <AUTHOR>

I have been very pleased with HN community in book recommendations. I got some great tips on personal finance, time management etc. Can HN suggest an incredible book for relationships? (specifically for marriage and such). <comment><USER2> Feeling Good Together by David D. Burns, which is primarily about the relationships you ask about, but generalizes to all interpersonal relationships, including work and such. My wife and I have both found it helpful for gaining new insight into our twenty-eight-year relationship.

[http://www.amazon.com/Feeling-Good-Together-Troubled- Relatio...](http://www.amazon.com/Feeling-Good-Together-Troubled- Relationships/dp/0767920821/)

</comment><comment><USER3> I believe the Gottmans have done some very good research on marriage - <http://www.gottman.com/>.

[http://www.youtube.com/user/TheGottmanInstitute#p/u/3/LLXX8w...](http://www.youtube.com/user/TheGottmanInstitute#p/u/3/LLXX8wzvT7c)

</comment><comment><USER4> No offense intended, but I don't think reading a book can help you with a relationship. I am not saying that all the relationship coaches are fraudulent but I just prefer to stick to one advice given to me by who knows whom.

 _"Talk"_

It seems in todays culture, especially the busy lives of people in USA, people tend to forget the importance of personal interaction. I know people stay "in contact" using things like facebook, twitter or some other social networking sites, but its just not the same (or _I_ don't know how to use them). The personal presence give it the more human touch. When you are with someone you can hold there hands, smell there perfume, actually hear them laugh (totally different from "lol" or "ha ha ha"), get lost in their beautiful eyes, give them a high five or chase them around if you are feeling childish. I don't know how people tend to forget one of the basic human instincts i.e of interaction.

While on the other hand social networking sites are also a means to stay in touch. Tell them when you were thinking about them and couldn't reach them. Just tweet sweet nothing to them. Or update on your facebook wall telling everyone how lonely you are feeling away.

I do not hold a degree in social interactions, nor do I have a life time of experience in such things (I am just 19), but one thing I am sure of, _talking_ is the best way to manage a relation ship. You can read volumes and volumes of self help guides but when and if you grow tired of it just take the hand of your wife, sit down on your bed and just talk....

<comment><USER5> Wow - a new low on HN. Here we have a never-been-married 19yo who just gave four paragraphs of advice to someone asking for marriage advice.

The fact that you think you should be offering such advice just shows either (a) a complete lack of social skills, (b) a self-belief that is completely whacko, and/or (c) a complete disregard for what life experience brings to the table.

I'd normally have led this with, "No offense..." but since you are 19 and are offering marital advice, you probably should get upset; maybe it will eventually lead to to you objectively look back and say to yourself, "WTF was I thinking responding to that guy? I'm 19 years old and have never been married."

<comment><USER4> Umm... First of all when I say no offense intended, I mean it. Nobody will waste there whole life on a book which is not worth much and those books can never be best sellers like these. And I would just like to clarify on a few things here

1) I wasn't giving specific advice on marriage, as mentioned in my post I am too young to give it. Go through the post again and see its a very general one. It works with any relationship be it with your girl/boyfriend, your mother, you son talking just works I think.

2) It wasn't exactly an advise per se, it was actually an observation (may be my post was wrongly worded).

3) I really don't get how can one be wacko in believing that by talking you can ease out a relationship.

4) In no way I disregarded the life experience of anyone. I just wanted to bring to the table what many of people holding _life experience_ had brought to my attention.

I really didn't see why you had to rip my post apart. A more polite response was possible, and if this is the way you went about talking I can see why talking didn't work for you, some offense intended.

</comment></comment></comment><comment><AUTHOR> thanks for the recommendations, HN. I actually agree that 'talking' is key, but my relationship get's stuck when talking doesn't prove to be enough ;)</comment>


Info Edge Invests $3.5 Million In Fashion Retail Site 99Labels - <AUTHOR> http://thinkiota.com/2011/05/11/info-edge-invests-3-5-million-in-fashion-retail-site-99labels/

<comment><USER2> infoedge invested a huge amount in another firm couple of weeks back, seems like they are heading towards an expansion</comment>


Drakon: a visual language for specifications from the Russian space program - <AUTHOR> http://drakon-editor.sourceforge.net <comment><USER2> This is great work. FYI spacex uses LabView [http://www.ni.com/labview/](http://www.ni.com/labview/) (amongst other stuff)

I wonder if you could use annotations to manage the visuals e.g [http://drakon-editor.sourceforge.net/folder-night.png](http://drakon- editor.sourceforge.net/folder-night.png) You'd have an inline annotation to separate the code blocks and generate the visuals so you don't have to maintain/update two places. Any tool that does that?

Also, integrating different level of complexity using system 1,2,3 (from [https://www.amazon.ca/Software-Requirements-3rd-Karl- Wiegers...](https://www.amazon.ca/Software-Requirements-3rd-Karl- Wiegers/dp/0735679665)) to represent user flow diagram in addition to flow charts.

Flow charts get confusing after some complexity. Useless if you want to represent multiple actors + messages. Systems/sub-systems view.

There is a tendency to think of visual programming as an all or nothing. Either we have all text or all visual. As long as it is "Write once, update everywhere", visual tools can be useful in navigating new code bases, obtaining insights and quickly understanding a piece of code.

The problem though is they often require maitenance and get out of date with reality (even if it is comments/annotations)

</comment><comment><USER3> Couldn't get it to work on OSX (El Capitan) even after installing ActiveState Tcl/Tk. After removing that package following these instructions [http://superuser.com/questions/36567/how-do-i-uninstall- any-...](http://superuser.com/questions/36567/how-do-i-uninstall-any-apple- pkg-package-file)

I installed MacPorts from [https://www.macports.org/](https://www.macports.org/)

sudo port install tk cd ~/Downloads/drakon_editor1.27 tclsh8.6 drakon_editor.tcl

And it works!!! Interesting idea for making the structure visible and presumably, helping find corner cases that are not handled. You could presumably build a library using Drakon, and then build an app using the library so that the detail of the code in the library is hidden behind simple function calls.

This reminds me of the proliferation of graphical workflow systems such as BPMN and this nifty Data Mining app called Orange3 [http://orange.biolab.si/orange3/](http://orange.biolab.si/orange3/)

I think we may finally be figuring out how to apply a visual paradigm to coding in a way that works for real production apps.

</comment><comment><USER4> The whole Buran spacecraft [https://en.wikipedia.org/wiki/Buran_(spacecraft)](https://en.wikipedia.org/wiki/Buran_\(spacecraft\)) was designed using Drakon

</comment><comment><USER5> This is very cool. I like this example which uses diagram for general logic flow, but mixes raw code for details: [http://drakon- editor.sourceforge.net/folder-night.png](http://drakon- editor.sourceforge.net/folder-night.png)

</comment><comment><USER6> Blockly developed by Google is adopted by many educational projects:

[https://developers.google.com/blockly/](https://developers.google.com/blockly/)

Go to "Built with Blockly" which includes BBC MicroBit, MIT App Inventor, code.org, LEGO (3rd party), PBS, Minecraft (3rd party), etc.

<comment><USER7> Blocky…sucks. Way worse than just learning something like Python.

(And this is someone who's spent most of his professional life working on visual programming systems.)

<comment><USER8> I've found the Khan academy way to be very efficient for 9-years olds. The main problem with textual languages is that kids mess up with the syntax easily but once they "get it", it's a bliss.

</comment></comment></comment><comment><USER9> Can the tool generate a diagram from existing source code? Obviously it would likely require additional input for internal 'headings'. And can the diagrams be automatically 'collapsed' into simpler flow charts?

I have two thoughts around this:

1) A lot of 'simple' source code would generate large, complex diagrams - which are likely not very readable, and brings up the same old decries against visual programming.

2) maybe striving for code that works well when converted to a visual language is a good check for code quality.

</comment><comment><USER10> Pretty cool, but one nitpick: when you save as SVG it embeds the font as a base64 encoded url(). Neat trick, but it bloats the file a lot. A simple chart with a few elements ends up being 250kB. Hand-written SVG would be two orders- of-magnitude less than that.

</comment><comment><USER11> This is the first time in a while I've seen an active project on SourceForge.

<comment><USER12> [https://github.com/stepan-mitkin/drakon_editor](https://github.com/stepan- mitkin/drakon_editor) seems to be where development is though.

</comment></comment><comment><USER13> Humm, this looks and awful like flow charts? What am I missing (apart from the 'Insertion' of macro charts)? All the rules about not 'breaking' visual cohesiveness seem like a plus, although not groundbreaking either. Don't want to sound negative, maybe someone can correct me?

<comment><AUTHOR> It is a formal specification for a specific kind of flow charts, yes. The specifics of the implementation, the history, and the tooling around it are what's interesting.

Your comment is a bit analogous to someone commenting "Humm, this looks an awful lot like programming?" on a link documenting a forgotten programming language. Well yes, it's true, but it's a tautological statement.

<comment><USER13> Ah, so this is interesting from a historic perspective. I thought this was being released as a formal method that brought some innovation, as mentionned earlier I had no idea or context other than the slide I went through posted in the link.

</comment></comment></comment><comment><USER14> Is there some overlap between these types of tools and [http://martinfowler.com/bliki/ProjectionalEditing.html](http://martinfowler.com/bliki/ProjectionalEditing.html)

<comment><USER15> Drakon does not seem to be model-based, so I would say no. If you are interested in Projectional Editing, you should look at MPS or Eclipse's Sirius.

</comment></comment><comment><USER16> Visual languages are also often used in industrial applications, usually in the form of ladder logic instead of flow diagrams.

</comment><comment><USER17> I'm really confused as to what exactly this is, but it looks cool. It seems to be some kind of visual programming environment, which I'm usually against on principle (BOO non-standard binary formats! ASCII text is the closest we can get to future-proof, and thus what we should be storing our source code! Down with journald! you should know the drill by now...) But interesting ideas are always interesting, so I'm willing to look into it, even if I don't like the look of it.

<comment><AUTHOR> I don't understand your ideological point. The editable representation has no bearing whatsoever on the storage representation of a program. There is nothing preventing you from having a visual programming environment where everything is just ASCII text under the hood.

<comment><USER18> In theory it would be possible to have a visual programming language that had a readable stored representation with meaningful diff/merge/blame. But in practice I've never seen one.

<comment><USER19> DRAKON represents programs as flowcharts, and there's no reason why the underlying representation couldn't just be C, Python, or some other imperative language, and there's no reason why C or Python originally written in vi couldn't be represented in DRAKON.

I'm not a fan of flowcharts but DRAKON is of historical significance. The same would apply to GRAIL.

Other imperative visual programming languages such as Scratch could also be stored in a form resembling a textual imperative language. In other words, the visual element is largely "syntactic sugar".

Dataflow programs can also be _stored_ as text rather than binary, but due to the nature of dataflow, this would be inconvenient to program directly in. This is because dataflow programs are _graphs_ with only a partial order rather than ordered lists like programs in C or Lisp. This means that visual dataflow languages, such as LabVIEW and my own Full Metal Jacket ([http://web.onetel.com/~hibou/fmj/FMJ.html](http://web.onetel.com/~hibou/fmj/FMJ.html)) aren't simply syntactic sugar.

There are textual dataflow languages such as SISAL, but these require a compilation step before code is actually dataflow.

You should not be surprised to find that version control systems designed for text in which lines of code are executed sequentially by default is less useful for stored visual dataflow programs. You could still use diff/merge on the stored representation at the function level, but not easily at the line level, because the visual representation doesn't have lines of text and the order might change arbitrarily from version to version.

This is why visual dataflow programs need a visual equivalent of diff/merge, e.g. clicking on arrows to show the order in which changes were made to the graph instead of diff. Work is being done on this, e.g. Austin Henley's Yestercode (for LabVIEW), reviewed here: [http://www.felienne.com/archives/5210](http://www.felienne.com/archives/5210)

</comment></comment></comment></comment><comment><USER20> Can anyone explain the advantage of a specification like this over something like UML?

<comment><USER21> Compared to UML Activity Diagrams, DRAKON- _Foo_ (where _Foo_ can be Python, C, C++, Erlang, or any of a bunch of others):

(1) Is constrained in a way designed to enhance understanding of the visual flow, and

(2) Directly includes code (in language _Foo_ ) in the boxes, rather than text; that is, its a programming environment, not a diagramming language with text that gets converted to program code somewhere else that is maintained separately.

The first item is also a feature of DRAKON by itself.

<comment><USER15> About (2): there is a standard action language for UML which can be used to fully describe your algorithm, independently of any language. In that sense, the DRAKON approach seems more practical for software engineers / programmers while the UML approach seems better for the domain experts.

</comment></comment></comment><comment><USER22> Also see PlantUML, which also has experimental code generation tech.

</comment><comment><USER23> Is there something similar to mermaid or graphviz, a DSL of sorts, to generate similar diagrams?

</comment><comment><USER22> I fought like hell to install all the deps before throwing in the towel.

<comment><USER24> > I fought like hell to install all the deps before throwing in the towel.

What? The deps are pretty tame for such a large program.

tcl8.6, tk8.6, tcllib, libsqlite3-tcl, libtk-img

So, for a debian/ubuntu machine:

        sudo apt-get install tcl8.6 tk8.6 tcllib libsqlite3-tcl libtk-img

RHEL/Fedora and friends will be similar, except with yum/dnf.

All of this info is at the top of the downloads section:

[http://drakon-editor.sourceforge.net/editor.html#downloads](http://drakon- editor.sourceforge.net/editor.html#downloads)

</comment></comment><comment><USER25> there should be a common interface to languages that have the same design patterns, why can't a class just be a visual representation of something that contains code, and do the same thing with methods and functions. then inside of visual blocks of code you can then keep the programming languages as simple as possible.</comment>


Tuleap, Free&Open Source Platform for Agile Management and Software Development - <AUTHOR> https://www.tuleap.org/ <comment><USER2> Looks nice.

Btw, your website is not responsive.

<comment><AUTHOR> (I posted it, but I'm not affiliated with the project in any way, not even as a user - I just thought others would be interested. You may wish to report this on their tracker)</comment></comment>


How the first Pascal compiler was written - <AUTHOR> https://raw.github.com/gist/1535291/da3f7f01a2c015cda3901986c6be820c9abd0175/gistfile1.txt <comment><USER2> "After this experience, it was hard to understand that the software engineering community did not recognize the benefits of adopting a high-level, type-safe language instead of C." -- N. Wirth

I suspect that the good programmers did notice the benefits of a strict statically typed language, however the cost was probably deemed to be too high at the time. Because C was a "mid-level language" and stayed close to the metal it could efficiently use the limited resources of pre-LSI (let alone VLSI) computers; effectively C allowed you to break the rules if you wanted or needed to. These days obviously the performance difference is generally less than a few percent and hence can be largely ignored.

<comment><USER3> Pascal's I/O was broken. Strings were broken.

Every Pascal I ever worked with (with the exception of the Pascal I used in school) had extensions to make it work in the Real World. Unextended Pascal was a toy.

Apple was a Pascal shop in the 80s, but they extended it to the point that I just translated (in my head) the C code that I wanted to write into the variant of Pascal they'd implemented. Pascal had a couple of nice things that C didn't (nested procedures, for one), but they weren't used all that much by us.

Strings were still a pain. Str255 stunk, and everyone knew it, but nobody had anything that was dramatically better.

<comment><USER4> I disagree. Unextended Pascal is not a toy: it's a tool to teach computer science and structured programming. In a classroom environment in the 1970's, it's not relevant that strings have to have a defined, fixed length. I'm not 100% sure what you mean by I/O being broken, but I'd wager that's not a big deal in a classroom environment, either. In any case, evaluating unextended Pascal as anything other than a teaching tool is like complaining that a hacksaw isn't very good for screwing in screws. Talk about "wrong tool for the job!" :-)

<comment><USER5> The quote -from Wirth himself- was not about classroom environments, it was about software engineer(s|ing).

<comment><USER4> True. But, "high-level, type-safe language" need not refer to unextended Pascal, and I see no evidence that it was intended to. He could have meant Algol W. Depending on when it was written, he could have meant Modula 2, Modula 3, or Oberon.

<comment><USER3> Serious question: Why is it that we generally see only toy systems being done in these languages.

I don't mean to offend. If I'm unaware of major pieces of software done in Modula-N or Oberon, then feel free to correct me.

I only know of some teaching-level and research OS work, and some GUI work, but little in the way of commercial stuff.

</comment></comment></comment></comment></comment></comment><comment><AUTHOR> Full paper "Good Ideas, Through the Looking Glass" by Niklaus Wirth [PDF]: [http://www.inf.ethz.ch/personal/wirth/Articles/GoodIdeas_ori...](http://www.inf.ethz.ch/personal/wirth/Articles/GoodIdeas_origFig.pdf)

<comment><USER6> I just skimmed through it and there's a really controversial claim in there that the functional paradigm was a bad idea!

I also found it surprising that he disliked Dijkstra's display idea since I've used a variant of that to great effect.

Anyway, there's a lot of fun reading in there so thanks for the link! Here's a discussion on Lambda the Ultimate: <http://lambda-the-ultimate.org/node/1773>

</comment></comment><comment><USER7> I'm always a bit hazy on why people bootstrap languages by writing compilers. I've always imagined it would be easier to write an AST-walking interpreter, write the compiler in the source language, and then interpret the compiler taking its source as input, to produce the first binary.

I guess I've never actually bootstrapped a compiler, but I've always found the interpreters I've written to be easier to reason about than the compilers I've written.

<comment><USER8> Bootstrapping a compiler is a good way to test how the language feels when writing a big project like a compiler. It also helps to find errors in the language/implementation.

<comment><USER7> In my proposed way to bootstrap a compiler, you still write the compiler in the language you wish to compile. You also write an interpreter, rather than another compiler for the same source language, written in some other language for which a compiler already exists. This means that the amount of code you are writing to get the language up and running is smaller, since interpreters are easier to write than a whole second compiler.

So what you say is true--it is a good way to see how the language feels--but not relevant to the facet of language development I was musing about.

</comment></comment></comment><comment><USER9> So they had three tools to choose among. One was broken, one was wildly unsuitable, and one was unpopular. They chose the second for (apparently) purely cultural reasons. I think it's not so surprising that they ran into problems.

Don't discard unsexy solutions out of hand; choose the right tool for the job.

<comment><USER10> Was assembly really the right tool for this either? It seems like the difficulty of translating Fortran to Pascal due to Fortran's lack of many of Pascal's higher-level features would still apply to assembly.

<comment><USER9> I think so. Wirth called out Fortran's lack of pointers, records, and recursion. You have (or can fake) all of these things in assembly. Recursion is particularly important for building a compiler, since much of it involves manipulating trees.

Also, consider the stated goal of the project. They wanted to write a throwaway compiler so that they could bootstrap a Pascal version. In this case, it's a bad choice to use a language (Fortran) that's so different from Pascal. On the other hand, assembly is very flexible, so you can use whatever idioms you think will apply in the Pascal code you later intend to write. This will make the translation much simpler.

</comment></comment></comment><comment><USER11> I'm not a big Lisp fanboy, but I wonder why it wasn't considered an option for at least bootstrapping the compiler? I think even if no Lisp was available on their machines that hand coding one in assembly and then using that would have been much faster than other options (note: it's been 20+ years since my college Programming Languages class (where ironically I built a Lisp-1 in Pascal) so I may be mis-remebering my programming language history here)

</comment><comment><USER12> Shoulda used Forth. It'd be fairly easy to go from assembler to an ultra bare bones Forth, and that could be built up to _work like_ Pascal, until it looks like Pascal-written-backwards. Then write the compiler in that, and the translation and bootstrap would be trivial.

<comment><USER13> My first thought as well, but in 1969 Forth was still busy being born. Based on the notes here[1], many of the core concepts of a modern Forth like defining words and the structure of the dictionary were being actively hammered out.

[1] <http://www.colorforth.com/HOPL.html>

</comment></comment><comment> guard-of-terra I wonder which "high-level" features does Pascal have which C lacks. When I looked into Pascal, literally everything useful there came from C. All things originating in Pascal seemed useless.

<comment><USER14> Pascal has nested functions and supports a limited form of closures.

In Pascal, a function can be passed as an argument to another function, but cannot be stored in a variable or data structure, cannot be returned from a function, and cannot be created without being given a name. However, when a function is passed to another function and later called, it will execute in the lexical context it was defined in, so it is, in some sense, "closed over" that context.

I also liked the I can pass parameters per value or reference without explicitly using pointers.

<comment> guard-of-terra In C a function pointer can be passed around, and usually a pointer to contect structure is passed around. That happens to be more practical.

References are cool. That makes one point for Pascal.

<comment><USER15> Nested routines in classical Pascal support downwards funargs; they are closures lite, i.e. actually more expressive than C functions. But we are talking classical Pascal; every practical commercial Pascal implementation supports function pointers directly, just like C does.

</comment></comment></comment></comment><comment><USER16> I'm confused. He starts off by asserting there were only three options; Assembly, Fortran or Algol. But then later on an essential part of the process turns out to be "a syntax-sugared, low-level language, for which a compiler was available". So why wasn't that apparently anonymous language one of the base options ?

<comment><USER17> I think that was the "compiler for a substantial subset of Pascal using Fortran" that they originally planned to translate to Pascal after implementing it in Fortran.

<comment><USER16> Ok, thanks, I guess that makes sense.

</comment></comment></comment><comment><USER18> _"Never contain programs so few bugs, as when no debugging tools are available!"_

But that's for the initial draft. What of its later evolution?</comment>


Marhaba Beirut Cloudflare's 121st location - <AUTHOR> https://blog.cloudflare.com/marhaba-beirut-cloudflares-121st-pop/ <comment><USER2> Nice to see this here and nice to see Cloudflare moving forward with this initiative.

Lebanon has a bright, entrepreneurial workforce who speak multiple languages. Many new engineering graduates emerge with strong skills from numerous competitive schools. A slow internet has hindered participation in the tech/internet/startup wave we've seen over the last two decades.

After the war ended in 1990, there was a chance to basically start from scratch. Every home could have had fiber right up to their door. Hate to mention it - but tremendous corruption - (which isn't necessarily native to Lebanon) - has thwarted many good projects to bring faster internet to Lebanon.

<comment><USER3> > Lebanon has a bright, entrepreneurial workforce who speak multiple > languages. Many new engineering graduates emerge with strong skills from > numerous competitive schools.

As a Tunisian (ahla w sehla), I agree completely with this statement. It's good to see Cloudflare getting closer to tech hubs such as Lebanon. Let's hope this will convince other large companies to set up shop (directly or indirectly) in the region.</comment></comment>


Achieving Eye Contact in a One-To-Many 3D Video Teleconferencing System (2009) - <AUTHOR> http://gl.ict.usc.edu/Research/3DTeleconferencing/ <comment><USER2> This is so delightfully steampunk, right out of Brazil. The whirring sound is perfect, now it just needs pneumatic tubes!

</comment><comment><USER3> I don't understand why we do not yet have several notebooks on the market with multiple webcams around the sides of the display. That way a video conference with eye contact would be achievable.

<comment><USER4> Because you would look at the person in the video, not the camera.

You want transparent cameras _in the display_.

<comment><USER5> This has existed for TV news cameras for a long time: [https://en.wikipedia.org/wiki/Teleprompter#/media/File:Telep...](https://en.wikipedia.org/wiki/Teleprompter#/media/File:Teleprompter_schematic.svg)

The trick is to put the camera behind a one-way mirror and project onto the other side.

</comment></comment></comment><comment><AUTHOR> video: [https://youtu.be/ypQpWIQ7lFQ](https://youtu.be/ypQpWIQ7lFQ)

3d display details: [http://gl.ict.usc.edu/Research/3DDisplay/](http://gl.ict.usc.edu/Research/3DDisplay/)

</comment><comment><USER6> I had a lecturer who had seen IBM experiment using projections onto manikins placed around a board table shared with 'real' humans, and a mirrored arrangement on the other side of the 'electric' connection, old enough to be an entirely analogue affair, if anyone has an idea what he might have been referring to I would love to know!

</comment><comment><USER2> Check out the other stuff from USC Institute for Creative Technologies and Paul Debevec on their YouTube channel [1]!

Ari Folman's cult-worthy movie "The Congress" [2] is bladerunneresquely based on Stanislaw Lem's psychedelic black humor fiction book "The Futurological Congress" [3].

At the apex of the movie, there's a riveting climactic scene where Robin Wright (playing a fictionalized version of herself) and Harvey Keitel use Paul Debevec's Light Stage [4] to capture her essence [5].

They show it in the trailer [6], but it's best to watch the whole film from start to finish without knowing what to expect. I really enjoyed it, especially the light stage scene, and not just because of the blinking lights -- the actors gave a spectacular performance.

The movie raises a lot of interesting issues, and I highly recommend it! [7] [8] [9] [10]

[1] USC Institute for Creative Technologies Graphics Lab: [https://www.youtube.com/channel/UCOgm-72B_tibAM2I5j-mBiQ](https://www.youtube.com/channel/UCOgm-72B_tibAM2I5j-mBiQ)

[2] The Congress (movie): [https://en.wikipedia.org/wiki/The_Congress_(2013_film)](https://en.wikipedia.org/wiki/The_Congress_\(2013_film\))

[3] The Futurological Congress (book): [https://en.wikipedia.org/wiki/The_Futurological_Congress](https://en.wikipedia.org/wiki/The_Futurological_Congress)

[4] Light Stage 6: Relighting Human Locomotion [https://www.youtube.com/watch?v=xgUW1RN8QNM](https://www.youtube.com/watch?v=xgUW1RN8QNM)

[5] Light Stage 6 Anomaly: [https://www.youtube.com/watch?v=A9gY3C2TeHE](https://www.youtube.com/watch?v=A9gY3C2TeHE)

[6] The Congress trailer: [https://www.youtube.com/watch?v=1rNSTizOsws](https://www.youtube.com/watch?v=1rNSTizOsws)

[7] 'The Congress' Trailer: Is This Live-Action/Animated Hybrid the Wildest Sci-Fi of 2013? [http://www.slashfilm.com/the-congress-trailer-is-this- live-a...](http://www.slashfilm.com/the-congress-trailer-is-this-live- actionanimated-hybrid-the-wildest-sci-fi-of-2013/)

[8] The Congress and the End of Actors: [http://scienceandfilm.org/articles/2496/the-congress-and- the...](http://scienceandfilm.org/articles/2496/the-congress-and-the-end-of- actors)

[9] Pixel Perfect: The scientist behind the digital cloning of actors. [http://www.newyorker.com/magazine/2014/04/28/pixel- perfect-2](http://www.newyorker.com/magazine/2014/04/28/pixel-perfect-2)

[10] Watch: The Future of Acting in the Technological Age: [http://www.indiewire.com/article/watch-the-future-of- acting-...](http://www.indiewire.com/article/watch-the-future-of-acting-in- the-technological-age-20150525)

</comment><comment><USER7> funny how several papers from years ago end up on the HN top page

<comment><USER8> It's great! Historical material is always welcome on Hacker News.

One quality of HN that we should all treasure is its capacity to distribute historical knowledge. We'd like to do more in this area. A video was posted the other day of two authors of a classic paper discussing their work from 30 years ago. We don't see nearly enough of that kind of thing, and we've been thinking about how to sponsor more.</comment></comment>


Mailchimp expands from email to full marketing platform - <AUTHOR> https://techcrunch.com/2019/05/13/mailchimp-expands-from-email-to-full-marketing-platform-says-it-will-make-700m-in-2019/ <comment><AUTHOR> For those that got the email from them today they're being really shady with their language about how they bill for things. See if you can decipher what they're actually saying here about how they calculate their price levels:

[https://mailchimp.com/resources/introducing-your-new- audienc...](https://mailchimp.com/resources/introducing-your-new-audience- dashboard/)

</comment><comment><USER2> I love Mailchimp I really do. And at first glance it sounds exciting. But ya gotta love how an across-the-board price increase is always sold as "added features". Must be some Jetsmarter people jumped ship and went to Mailchimp. :))) ...joke.</comment>


Redesigning the MailChimp App - <AUTHOR> http://blog.mailchimp.com/redesigning-the-mailchimp-app/

<comment><USER2> _We trimmed a lot of code during the pre-design and redesign processes. We hopped on the CSS treadmill and managed to cut about 120kb_

CSS is not my main area of competency... but to _cut_ 120kb strikes me as a LOT? I don't think I've ever worked with a CSS file anywhere close to that size (I realize it might not have all been in one file, but still). Am I off- base here?

<comment><USER3> Link to their css file: <http://us2.admin.mailchimp.com/release/5.5.1/css/screen.css>

Minified. About 215k. Taking a glance, it looks about as clean as it can get, and any more optimization would probably make it much less flexible.

It does appear to have an exorbitant usage of !important, but I won't judge since I don't know any of the ins and outs of what their team has to deal with.

<comment><USER4> _[...] I won't judge since I don't know any of the ins and outs of what their team has to deal with._ Great comment, sometimes people forget this when reading/editing other people's code.</comment></comment></comment>


Viro makes it easy to add VR modes to existing mobile apps - <AUTHOR> https://techcrunch.com/2017/03/22/viro-wants-to-make-mobile-vr-development-a-snap-and-raises-2-5m-to-do-it/ <comment><USER2> Hi, I'm the co-founder of Viro Media, Vik Advani. Our platform is built on top of React Native, allowing for cross platform native development across mobile VR headsets, including Daydream, Oculus Gear VR, Android Cardboard and iOS Cardboard. In the same way you can build powerful mobile apps using React Native, you can do now that for VR.</comment>


Thoughts on the future of programming languages - <AUTHOR> http://concertwindow.com/3443/more-thoughts-on-a-new-programming-language

<comment><USER2> Human language tends to be arbitrary, and I believe that the opposite (specificity) is desirable in programming languages. Many people argue that the future of programming will involve dumbing things down as more and more people become programmers, and one way of dumbing things down is to use natural language. (I shudder at involuntary thoughts of COBOL.) Instead of dumbing languages down, I think it would be much more beneficial to raise the intelligence of the programmers. I hope that the future of programming languages tends toward mathematics, not human language.

Currently, I am often very happy with Haskell syntax for solving problems, when it is possible to define an implementation that is precise, concise, and easy to understand. For solving problems that do not easily map to Haskell syntax, using DSLs (Domain Specific Languages) to map from a representation designed for the problem in question to a Haskell representation still allows Haskell to be a good choice of language.</comment>