If you want to start a startup, go work for someone else - <AUTHOR> http://philosophyforprogrammers.blogspot.com/2014/09/if-you-want-to-start-startup-go-work.html <comment><USER2> I've done both - worked for 2 other people's startups, founded my own, worked 5+ years at Google, now founding another. My experience is that you learn something from both, but you learn _different things_ from each, and which will teach you more depends on what skills you need to learn.

Working for someone else's startup, I learned how to quickly cobble solutions together. I learned about uncertainty and picking a direction regardless of whether you're sure it'll work. I learned that most startups fail, and that when they fail, the people who end up doing well are the ones who were looking out for their own interests all along. I learned a lot of basic technical skills, how to write code quickly and learn new APIs quickly and deploy software to multiple machines. I learned how quickly problems of scaling a development team crop up, and how early you should start investing in automation.

Working for Google, I learned how to fix problems once and for all and build that culture into the organization. I learned that even in successful companies, everything is temporary, and that great products are usually built through a lot of hard work by many people rather than great ah-ha insights. I learned how to architect systems for scale, and a lot of practices used for robust, high-availability, frequently-deployed systems. I learned the value of research and of spending a lot of time on a single important problem: many startups take a scattershot approach, trying one weekend hackathon after another and finding nobody wants any of them, while oftentimes there are opportunities that nobody has solved because nobody wants to put in the work. I learned how to work in teams and try to understand what other people want. I learned what problems are really painful for big organizations. I learned how to rigorously research the market and use data to make product decisions, rather than making decisions based on what seems best to one person.

Founding a startup, I learned the limitations of all of the above, and that even if you know in theory what can go wrong, it's quite a different matter to avoid committing those mistakes too. I learned a lot _more_ technical skills; it turns out that no matter how well you prepared in your job, finding a workable startup opportunity requires that you do things that you don't know how to do. I learned how to talk to other people and gather information about the market from ordinary conversations. I learned to make decisions in the absence of firm information, _knowing_ that I may be wrong but that I can't make any forward progress without trying something out that is almost certainly wrong. I learned how to take expedient shortcuts, and to un-learn many of the rigorous engineering practices that I learned working for people because they don't apply in this environment.

I've found many of these self-reinforce as well - I got farther on the first startup because I'd learned many of the basic technical skills from the two startup jobs I'd had before, then got into Google from the skills I taught myself founding that startup, then have a different perspective on what's possible for the second startup because of the work I did at Google. The overlap is less than I (or most people) would like, but one of the unfortunate facts of life you learn as you get older is that life is not a linear path of one move reliably preparing you for the next, and there are often twists of pure luck that throw a monkey wrench into all your plans.

<comment><USER3> This is a great comment, thank you!

> I learned that most startups fail, and that when they fail, the people who > end up doing well are the ones who were looking out for their own interests > all along.

Can you elaborate on this? How were people "looking out for their own interests", and how did it end up helping them? Could the founders have done things differently to make the outcome more equitable?

Thanks!

<comment><USER4> Also not the person you are replying to, but I have my own experience with this.

Basically the people who leave a failing firm early do better than those who stick around until the money runs out. They find better jobs faster because they're not competing with a bunch of their former coworkers, they don't have a gap in their employment to explain, and they don't have to answer the question of why they stayed when they should have known the company was failing. If you find yourself in this situation and you think that loyalty has any value, think again.

</comment></comment></comment><comment><USER5> The path I took (founded four startups previously, two exits, currently working on fifth) was to first have a go at consulting.

Working for yourself is not much different from running a startup. You have a product (yourself). You have sales (winning contracts). You have accounting (for your invoices and for your expenses) and have to keep books. You have legal (your contracts). It's a great way to learn how to run a (hopefully) profitable business and build the foundation you'll need to run a startup.

</comment><comment><USER6> Very informative and amusing post. My favorite statistic was the 18% of entrepreneurs succeed the first time, and only 20% succeed the second time.

> The sort of person who jumps in and gives advice to the masses without doing > a lot of research first generally believes that you should jump in and do > things without doing a lot of research first.

Like most good polemics, this one probably overstates the case. It seems to me that if you want to pursue an idea when you're young and inexperienced then go for it; but don't go for "it" because doing so is intrinsically better than getting a job.

In my thirties I left a pretty promising career to pursue the dream of designing games and running a games company. I failed (in the ways I cared about -- we didn't lose money or go broke). I _think_ I learned a lot. One thing I learned is that sometimes there are advantages to being young, and poor, and hungry (in the "stay hungry" sense) and sometimes there are advantages to being older, comfortably well-off, and experienced.

<comment><USER7> >My favorite statistic was the 18% of entrepreneurs succeed the first time, and only 20% succeed the second time.

This is a potentially misleading stat. The second cohort only includes the failures. So clearly at least some of them learned something.

It's a 36% total success rate for entrepreneurs who try twice.

(Though I guess that number is missing those that try once and don't try again)

<comment><USER6> There is nothing to suggest that the second cohort _only_ includes failures, and bear in mind that many people -- having failed -- won't try a second time -- and if they've learned anything, it will be the people who figure out they're never going to succeed who drop out. Without knowing the probability that someone who succeeds vs. fails will try again there's simply no way to tell.

Anecdotally, it's very common for entrepreneurs to start a business, wait until it's up and running, sell it, and start over. This applies both in high- tech and more prosaic areas like restaurants and gas stations. I imagine that first-time successes are _very_ likely to try again.

<comment><USER8> Actually, the post says it explicitly that this 20% includes only failures. --> "... entrepreneurs who previously failed have a 20% chance of succeeding."

<comment><USER6> But what chance of success do entrepreneurs who previously succeeded have?

<comment><USER8> This statistic wasn't there but one could imagine that it would be higher than 20%. Also, keep in mind that success is a subjective term -- for some people it's when you make $1M, break-even or get acquihired, for others it's at least $100M or $1B.

</comment></comment></comment></comment></comment></comment><comment><USER9> > It's unclear whether the average person learns anything from a startup.

> Entrepreneurs don't seem to learn much from their failures

There is a difference between not learning anything at all and not learning something from failures that will help in a future startup venture. I have learned a tremendous amount working at startups. I am closer to everything, nothing is in a silo and I have gotten exposure to all parts of the architecture whereas at an employer I would have been barred from infrastructure and operation tasks. There is also much more freedom to use whatever technology you want to try out, and thus you learn a lot about new programming languages and new libraries and new ways of doing things without having to get approval from layers of management and architects. You learn about your self too, your limits, you have to become independent, and self- reliant.

> Our most important finding is that the reward to the entrepreneurs who > provide the ideas and long hours of hard work in these startups is zero.

Maybe if you only consider money. If you are into startups for the money alone, I feel like I would agree, stay away. If you're in a start up for the small team size, for controlling your own destiny, for being close to the customer, close to the product, and don't want to see your life's days waste away in meetings and products that never see the light of day then the value is actually immeasurable.

</comment><comment><USER10> Analysis like this is interesting because it assesses entrepreneurship like a career choice. Most entrepreneurs arise out of an idea. They aren't sitting on HN dreaming of becoming an entrepreneur(not that there is anything wrong with that). You see an unfulfilled need in the marketplace, believe you have the solution and can smell the money.

The thought, "is this a good long-term career choice?" isn't in the equation. That's for people looking to build a career. This is your one great idea that will make you rich, fuck a career. You are your boss from now on.

If your thought process doesn't look like that than maybe you just haven't stumbled upon that great idea. The idea that strips every rational bone out of your body, that keeps you up at night. Or may you just don't have the risk tolerance for entrepreneurship.

It's a fairly cavalier mindset, but you have to have that kind of naivete to outlive the struggles of starting a business.

<comment><AUTHOR> > Most entrepreneurs arise out of an idea.

And how did you get that idea? How did you get the experience to see that there was an unfilled need in the marketplace?

People who have experience in a field perceive their risks as lower (correctly!) and are therefore more likely to start a company. It is a perfectly rational decision and is unrelated to risk tolerance.

<comment><USER10> Exactly my point actually. You work in an industry, might even have a cozy corporate job and great benefits. You're on a solid career trajectory. Leaving that to start a company rarely makes financial sense. But most people aren't assessing it through that lens. They know their industry, have a great idea, and they HAVE TO DO IT. Even if financially it seems nuts!

<comment><AUTHOR> Entrepreneurs are, in general, not motivated by money. This may be what you are saying - in which case I agree! What I object to is this statement:

> Or may you just don't have the risk tolerance for entrepreneurship.

Risk tolerance is at best weakly related to the likelihood that you will become an entrepreneur, and risk-tolerant entrepreneurs [perform worse]([http://hal.archives- ouvertes.fr/docs/00/85/66/06/PDF/PEER_st...](http://hal.archives- ouvertes.fr/docs/00/85/66/06/PDF/PEER_stage2_10.1016%252Fj.jebo.2010.02.012.pdf)) than average.

</comment></comment></comment></comment><comment><USER11> The general idea is the same in education and almost every other aspect of life: learning enough, then applied practice. You do a programming language tutorial then work on your own programs to really grasp it. If you skip the first step you'll make needless mistakes and pick up bad habits, if you skip the second you'll rarely be of much use in the real world.

Here, working at another company can be considered the first step in learning about building businesses, and I'm sure it's beneficial, but in startups I've found you can quickly learn and practice whatever you're intending or supposed to do. Let me give an example form personal experience. At one point in my life I had never sold anything before and probably would have been a lot better if I had worked in another company and observed the sales department, however, when my time came, I had to start contacting customers. I spent a while reading about sales then just went for it. I improved a lot in a short space of time... now I consider this an accelerated experience gain because I researched exactly what I needed for a particular task and applied it to a problem. In the same way I'd only learn about some particular aspect of programming because I've discovered it's what I need.

</comment><comment><USER12> Article is confusing "startup" with "small business", if your field and your methods are old enough to be tried-and-true then, yes, by all means, apprentice yourself and learn the ropes. After spending the 7 or so years working in a social-networking company, you too can create another stable small-business in social-networking that (for example) staggers users' twitter posts or sells slightly ridiculous shirts to facebook hipsters. If you balance your books and keep at it, you'll probably make a handsome chunk of money and maybe even make it really big one day.

If your field / technology / process is dangerously new and untested because you just invented it (e.g. you're mining titanium from the moon using gravity fields, you're desalinating sea water, you're selling a headset that streams movies into your right eye checks your social feed in your left eye and sucks your dick), there's going to be preciously little other people and books can teach you. You've entered the realm of vague opinions, uncertain grey zones, and questionable futures. In that case, you're only choice is to either not do it and wait for more tests to return, or do it blindly in hopes of learning on the job.

PG and his cronies recommend the "just do it" path for startups in the second category because if you succeed, you'll find yourself in a temporary market monopoly where you'll be entitled to make astronomical amounts of money. PG and his cronies then invest maybe 1% or so of their utility while you invest around 99% of your utility. If your business succeeds, PG and friends get a 1.5x boost to their utilities, while you get maybe a 2x boost to yours. If your business fails, PG and friends shrug it off and offer you some words of encouragement as you pick up the splattered mess of your life off the floor and write a book about how the world wasn't ready for the movie-streaming-eye- sucking machine.

<comment><USER13> "e.g. you're mining titanium from the moon using gravity fields, you're desalinating sea water"

The fundamental disconnect here is that while there are some "startups" that actually do novel things, most are more like "build some ruby on rails app that does XYZ thing that has always been done, but do it on computers, and maybe cheaper than the big guy can by just ignoring existing regulations until we get big enough that anyone cares".

And then you wind up with a startup company probably full of 20 year olds who are smart and driven but haven't yet seen the hundreds of ways in which they can paint themselves into a corner with bad software practices which creates this negative feedback loop where everyone is working 80-120 hours spinning their wheels trying to get shit to "just work" whereas if they had more experienced technical talent (say people who have worked on highly scalable software at google or microsoft or whoever for 5 years) who have already "seen some shit", they would likely have much higher quality at a fraction of the development time.

(And while the salaries for experienced folks would have to be higher per employee, they could get by with a lot less of them and still have better code).

</comment></comment><comment><USER14> I would agree that if you don't intend to utterly disrupt some industry, that some experience working in another company can be helpful.

I would argue that as much good knowledge may be gained that the equal number of bad habits may be learned and turn you into an "inside the box thinker".

Working in a hardware startup is a great example of this duality, however. Old engineers know that planning, testing, and quality debugging lead to a great product and that no amount of research can beat a good test program. Young engineers are willing to try stuff because they don't know what they don't know. Some huge innovations have come from younguns trying stuff that "shouldn't" work, and become industry shaping product innovations.

Who's right in the end? Both have been.

Last, I think I am pretty sick of people saying "what the formula is". Just shut up, because there isn't one!

</comment><comment><USER8> After working for a big multinational pay company, an investment bank, and a year-long internship at a VC firm, and now starting my own business, I really appreciate the experiences that I got from BigCo, especially when it comes to operations, managing customer service, and doing lots of manual work.

Here are my lessons: 1\. MVP should be very minimal. Do not bloat it with lots of automation. Just let a human deal with it. That's when you get real user feedback, which you can later automate.

2\. Track your interactions with customers (investors, angels, partners) via "Saleforce"-like software. There are cleaner and easier versions out there, which can integrate with the web or mobile apps, and the customer will not even know he or she submitted a ticket or has some reference number.

3\. At startup things go really fast, however the tech is being slow to release.

</comment><comment><USER15> I've been doing my startup and have been working in companies on and off on the side and to be honest I have a quite strong opinion towards the point of view that people need to collect experience in a company before starting their company. I think this is really bad. More specifically, every single day that you work at a company

1\. The likelihood of you starting a company and the final size of your company decreases, because every day you learn more about what's not possible. Your mind becomes more restricted and corporate experience will certainly not encourage you to invent Snapchat, Facebook, Twitter, Uber. These ideas can only be done by people who have NO restrictions whatsoever in their minds, who think everything is possible. Corporate life will prevent you from having these ideas and that is why I want to prevent working in a company by all means as long as I can. Which brings us to our second point.

2\. You get more used to corporate life, which includes receiving a pay-check, which is mostly not based on how much money you made the company, adapting your personality so that you are good in company politics, so that you look good, so that you get promoted, but that's actually not good for the company. These learnings are very bad for starting a company.

3\. You come closer to having kids. I think having kids is probably the biggest factor preventing people from starting companies. Having kids is almost like starting a company, they are your own startup, so having 2 startups is near to impossible.

There is some merit in working at a company, to learn about how politics are weaved into corporate life. This helps you to understand that when you need to sell to a larger company that the person you are selling to care much more about how they look by buying your product than how good your product actually is for his/her company.

This is why working 6 months does have value, which is how long it usually takes to understand how company politics work. However everything more than 6 months will reduce your capability in starting your own startup, every single day.

</comment><comment><USER16> It kind of drives me nuts that I've read a lot of this research elsewhere, and all of my experiences have either flew in the face of them, or there were major asterisks. It makes me wonder, who were the people being studied, because I can see all of this being true in the general population, and you can even see it in most of the valley.

There is something about the results that I don't trust, much like the way that I don't trust anything I read about what's good or bad for you. Years ago, they said fat was bad for you. Turns out, it's complicated. Then they said carbs were bad. All I can tell is that my parent's immigrant diet was healthier in ways that could not be assessed by "research."

<comment><USER17> I think it has something to do with the idea that 3% of YC applicants have a 100% chance of getting an interview.

If you follow PG's ethos perfectly maybe you choose to work at a great startup that is going to succeed and then you start your own. Work at Justin.tv, and then start Twitch/ZeroCater

<comment><AUTHOR> I would disagree with the causality. The sort of person who can get an influential job in a top-tier startup is probably also the sort of person who can start a good company.

<comment><USER17> Sure. And that person would benefit from working at the top tier startup before starting his own.

</comment></comment></comment></comment><comment><USER18> I found that starting a startup taught me quickly what I didn't know. In my case, it led me to search for a place where I could learn what I needed.

It's hard to know what to look for, what to learn, when you have not ran against any walls. Starting a startup forces you to find solutions you don't have, for problems you weren't aware off. You might have many solutions when employed, but you're unaware whether those will help you with your startup and what problems you might encounter.

</comment><comment><USER19> While I am not the first person to defend Paul Graham's writing, I must admit that the author of this article has zero understanding of what is _actually_ meant by the phrase "just do it."

All that statement relays is this: there is _no_ secret formula to having a successful startup! So, the only way to figure things out is to actually be out there doing it.

It is very true that you _can_ learn things working for someone else that would contribute to your future startup. But that is highly dependent on who you are working for and what you are doing for them.

As in regards to the cited studies. The first study actually lists a total of _8_ important factors for startups that lasted longer than 5 years and were started between 1991-2000. Interestingly, startups during those years had a 1 in 5 chance of survival. (Sidepoint: Does anyone know if the survival rate for startups today is anywhere close to this rate?) In other words, industry experience is only _one_ of many factors ... and industry experience means _having worked in the same industry as your startup_ , it doesn't mean working in any industry for any employer.

To list the 8 important factors for everyone (and I have a feeling that these are in order of importance):

1\. supply chain integration 2\. market scope 3\. firm age 4\. size of founding team 5\. financial resources 6\. founders' marketing experience 7\. founders' industry experience 8\. existence of patent protection

[0] [http://onlinelibrary.wiley.com/doi/10.1111/j.1540-5885.2007....](http://onlinelibrary.wiley.com/doi/10.1111/j.1540-5885.2007.00280.x/full)

</comment><comment><USER20> Companies are like babies, if you wait to be 100% ready to have one, you'll never have one. You will never know everything, you will never be prepared for everything. Being fully in control (specially through means of statistical modeling) is just an illusion, it might be true for big enough samples, but means nothing for your particular case... and that is why Paul Graham's advice is actually a very good one.

</comment><comment><USER21> Not that I have heaps of experience to base this on, but here's my general thoughts on a good strategy:

        while(0 == ideas.good_ideas.count ||
            FAIL == start_company(&ideas, &experience)) {

            // no ideas, or failed startup
            while(THRESHOLD > experience.why_failed.confidence ||
                0 == ideas.good_ideas.count) {

                // no ideas, and/or not sure why startup failed
                work_in_leadership_for_young_but_successful_company(&experience, &ideas);
            }
        }

        // would be interested to read more articles on
        // what goes here
        end_game();

I think employment for the sake of being a better entrepreneur is a great strategy, but only if you can find the right role, and only if you approach it with the correct frame of mind.

</comment><comment><USER22> According to the author: \- 18% success rate for time founders \- 20% success rate after that

Implying previous experience almost doesn't matter that much... so just trying 5 times should assure 1 success.

In that view, starting your company as soon as you can would still be the best way to get to your first success faster.

<comment><USER23> > _So trying 5 times should assure 1 success_

That's NOT how probability works. Just because you have a 50-50 chance of flipping heads does not mean it only takes two try's to get heads. On AVERAGE it does.

<comment><USER24> Yea, I think even if people know this they don't intuitively grasp _how far off_ they are. Five tries at 20% success rate is only 67% overall. That's about the same odds you have to win two rounds of russian roulette.

To have an overall 99% chance (what we might conversationally say is a guarantee), it'd take 21 tries.

</comment></comment></comment><comment><USER25> I've got a full time job, and I've done startups - both are obviously valuable. A friend of mine approached me recently with the idea of doing a startup - but he didn't have any ideas. He wanted to do consulting in his chosen space to find that idea.

My problem with this is that, in my mind, it doubles the risk - you have go into consulting (which is not risk free), then hope you find an idea. There is then additional risk of starting the company and finding out if the idea is a scalable product - I've had it happen twice that we thought we had a product, but it turned out we had a product that required so much consulting to launch we were essentially a consulting company.

<comment><USER26> Consulting isn't all that risky depending. I never made as much money as when I was part of a consulting partnership. But the work was less glamorous/interesting. Mostly solving legacy system problems (where by definition companies might have lost their expertise and have to call in an outsider).

At least a startup is always new and fresh, at least with a good product. That's why I gave up on consulting (that and the other partners had a falling- out) and have been in startups every since.

<comment><USER25> Did you find any ideas while consulting that you could use in spinning up a startup? I agree with you about consulting.

<comment><USER26> Sure ideas are a dime a dozen. Getting a team, funding, traction are all more important.

</comment></comment></comment></comment><comment><USER27> The self-employment study says that when people who are self-employed switch to dependent employment their wages are at least as high as their dependent employment counterparts.

From an earnings perspective, that makes start ups more appealing. You can take a shot at starting your own company. If it fails, you can still make at least as much money as if you had not started your own company.

The other thing is this blog post is looking at the average outcome. If you are starting a company, you are already starting from the assumption that you are not average.

</comment><comment><USER28> Glaring logical conclusion that is omitted: if there even is the slight bump in the likelihood of success having worked for someone else vs. not, it's still clear that simply the number of attempts at starting a company is still the overwhelmingly more important factor in overall success.

It doesn't dismiss the point as the author is refuting a specific claim made by PG and others (that you will be better off in your second startup having learned from doing another startup vs. having a job) but it's still worth noting.

</comment><comment><USER29> I get the "link-bait" virtues of your title(and it worked on me), but the title contradicts itself, literally.

If you want to start a start up, start a start up.

The body of your text also contradicts itself. One of your premises speaks to the luck nature of success. Conceding your premise, the supporting text that follows amounts to advising people to study to win the lottery.

A more interesting treatment would consider time cost, iterative or serial entrepreneurship vs. whatever your win condition is, etc.

<comment><USER30> there is no contradiction. what _you want to do_ and what _this article suggests you do instead_ are not mutually exclusive.

consider the (perhaps poorly guided) advice "if you want to go to Florida [i think you should] go to Hawaii [instead]".

</comment></comment><comment><USER31> Bootstrapping my start-ups while working 9 to 5 on site consulting jobs has proved frustrating!

All those who brought me on knew explicitly of my start-ups and yet my consulting gigs never lasted more then a year. Which has been frustrating because my bosses and I befriend each other during the course of the year, but end up turning on me due to office politics. Sigh!

Well im starting a remote consulting gig, which is great, as I will turn in solid work and be far away from office politics.

<comment><USER32> > be far away from office politics.

heh. it may actually be _worse_ , because being remote adds a new dynamic to all the politics.

Good luck.

<comment><USER31> It's a work as many hours as I like and need to and they don't own or have rights to my start-up companies nor can later profit from them.

I made it clear to them I am working towards raising money for my start-up and will be able to work a few days a week (weekends included).

My focus is turn in solid/perfect work and rinse and repeat. Not try and worry about trying to create friendships/getting the right people to like me.

I am likable and have a good amount of friends, but when your doing more then just the 9 to 5 and getting visible attention for it, it seems to effect people negatively towards me. So goodbye office politics and thankfully their office is 4 hours away from home.

</comment></comment></comment><comment><USER33> I don't understand this. If you want to do a startup, just do it. Do it before you have a bunch of excuses for why you shouldn't.

<comment><USER13> "Just do it"... but have a fallback plan for when you will, statistically, almost inevitably fail.

Granted, if you're on the technical side (and in SV or another "tech hub") then the fallback plan is usually "get a job with someone else within a couple of days of starting to look", but for that to be a reasonable fallback plan you still need to be careful during your startup time to not take on lots of personal debt, etc.

</comment></comment><comment><USER34> Yeah, but then there is good research and bad research. Hey should have done a bayesian analysis and iterated through all the people who've been successful with startups. What percentage of them were likely successful because of previous employment and those that weren't. How many of these guys are your zucks and gates and andreesens of the world?

</comment><comment><USER35> The number one rule in startups, just like any other endeavor is just do it and unleash the potentials you never knew you got. TRY is key. Very often we read a lot of rules, dos and donts from successful people and finally just get confused. A lot of them won't tell you they learned their mistakes early on, made corrective adjustments and moved along.

</comment><comment><USER36> All research are "on average" and given a set of conditions. So, shouting "anecdata!" is not a as strong as it sounds. There are many circumstances to consider.

[Disclaimer: I am person who regrets not "just doing it" while waiting for better times - and motivation for a particular project evaporates in years.]

</comment><comment><USER37> I pretty sure in one of the essays PG says you should finish collage and go work for 2-3 years (or maybe it wasn't him)

I think there is no simple answer. Try defaulting to work for a few years, but if you are hacking a project while you are studying and you are convinced that you are on to something, take a year break to try it.

<comment><USER38> work for 2-3 years, yes; college, maybe later.

If I could write a note to my high-school counterpart, it'd say 'learn javascript, screw college, start working right after school'.

</comment></comment><comment><USER39> you can definitely learn more by working with/for someone else than by simply striking out on your own (too early) _IF_ those people actually care about mentoring and have the ability to communicate their knowledge and experiences.

Sometimes working on your own ideas vs someone elses is very appealing regardless of how efficient the learning might be. So, sometimes I have to remind myself and others -- doing this is not just about efficiency.

I chuckle at the "Academics joke that "a month in the lab can save you an hour in the library." line in the post. What immediately came to my mind was something Click and Clack said : "reality often astonishes theory" ..which is why spending time in the dirty reality of building and experimenting (or even reproducing something you found in the library) is the yin to the library's yang.

</comment><comment><USER40> Out of curiosity, does anyone know how academic positions are counted in these numbers? Are the Google founders counted as having been previously employed in tech, for example? (They had paid PhD research positions at Stanford CS, but never worked in "regular" tech jobs in industry.)

<comment><USER41> In my observation, academic research shares a lot in common with entrepreneurship. Stealing from nostrademons above:

>>>> Working for someone else's startup, I learned how to quickly cobble solutions together. I learned about uncertainty and picking a direction regardless of whether you're sure it'll work. I learned that most startups fail, and that when they fail, the people who end up doing well are the ones who were looking out for their own interests all along. I learned a lot of basic technical skills, how to write code quickly and learn new APIs quickly and deploy software to multiple machines. I learned how quickly problems of scaling a development team crop up, and how early you should start investing in automation. <<<<

I pretty much experienced all of those things in the course of my PhD research, with the exception of forming teams.

</comment></comment><comment><USER42> If you want to be a cobbler, go work at a cobbler's shop. If you want to be a luthier, go work at a luthiers. If you want to start a startup, go work at a startup for a while.

Why is this news?

</comment><comment><USER28> Also is [http://www.paulgraham.com/](http://www.paulgraham.com/) down for anyone else?

</comment><comment><USER43> I worked for two startups. One startup was fairly large 100+, it sure didn't feel like a startup except for when it asked people to come on weekends and work or stay behind until 11pm and have the manager call at 1am about work. It also played the startup card when it came to pay. I learned that if you screw people over, they will still stay if it means they can keep a job.

Another startup I joined was small, 20 people. CEO was very caring guy. Paid people better and no crazy hours. Learned some things from the boss.

Overall, I've learned more from the second startup, but it probably won't matter in helping my own. I learned so much more about just bootstrapping my own product.

</comment><comment><USER44> Finding which startups to work for is the trick

</comment><comment><USER45> These venture-funded startups make a mockery of the concept. After all, if you're a true entrepreneur, are you _really_ going to waste 6 months of your life asking a fucking venture capitalist for permission to be a founder? The VC-funded game is just the same private-sector social climbing that a previous generation called "the corporate ladder".

The real problem, the 9500-pound chain-smoking and belching elephant in the room, is that almost no one can bootstrap because the U.S. middle class is nearly gone and _almost no one has any fucking money_. In the 1960s, with strong unions and low housing costs and cheap health insurance that covered everything, worker bees actually _could_ save up and have starting capital. The Satanic Trinity (housing, healthcare, and tuition) that is now killing the middle class wasn't even on the horizon, so people of average means had a real shot at starting their own ventures-- without having to get permission from a bunch of effete Sand Hill Road bureaucrats.

Add to this the obscene cost of living in Silicon Valley. Even the people with supposedly well-paid corporate jobs can't afford to buy houses. The only real way to make money in the Valley: _be a landlord._ Whenever entrepreneurship revives on the North American continent, it will be far from the tapped-out, overpriced, landlord's paradise wasteland of California.

Ok, so on to the finding itself... I agree. Most people who launch successful businesses had to learn on someone else's dime and risk before they had the capital, skills, and domain knowledge necessary to go on their own. It's pretty rare that a 22-year-old, fresh out of college, has (a) the leadership skill to create a business from scratch, and (b) insight into a real-world problem that can actually be made into a business. These VC darlings aren't true entrepreneurs and shouldn't be taken as typical; instead, they're rich kids whose parents are laundering family connections so it looks like their underachieving spawn are "startup wunderkinds" instead of well-placed halfwits that Wall Street didn't want.

<comment><USER46> That's just, like, your opinion man. You seem to be focusing on the glitzy veneer of the Sand Hill VCs and ignoring the fact that new capital intensive businesses almost always involve seed investment, be it from friends and family, or venture capitalists.

In either case, it's almost always a good idea to use other peoples' money instead of your own. Particularly in environments like the current one where you can get money without giving up ridiculous amounts of equity. You're undermining your ability to have a few failures to learn from if you put all of your personal assets on the line in one venture.

If your main complaint isn't VCs per se, but _access_ to VCs, then sure, that's a fair argument. But arguing that somehow we'd be better of if people were risking massive amounts of their personal capital on their startups (vs what we have now where the risk is split between them and others who can afford it) seems wrong. Even the founders who _do_ have money aren't so dumb as to turn away VCs out of pride of being a "true entrepreneur" if the terms are favorable.

<comment><USER45> _In either case, it 's almost always a good idea to use other peoples' money instead of your own._

I agree. You used to be able to get bank loans on co-investment (i.e. you put up some of the capital). Now they require personal liability. Things have gone to the worse.

 _You 're undermining your ability to have a few failures to learn from if you put all of your personal assets on the line in one venture._

True. But in a time when (a) bank loans were available with co-investment alone (not you're-insane-if-you-take-it personal liability) and (b) people in the middle class actually had money, it was possible to get going while only putting up 5% of the seed money (and getting a larger equity disbursement, because you actually are doing the work on a low salary).

 _But arguing that somehow we 'd be better of if people were risking massive amounts of their personal capital on their startups (vs what we have now where the risk is split between them and others who can afford it) seems wrong._

I agree. My point is that, before the VC era, people didn't have to risk massive amounts of personal capital. A 5% co-investment, and a willingness to work on a lower-than-market salary for a while, was enough to get you in the game.

 _Even the founders who do have money aren 't so dumb as to turn away VCs out of pride of being a "true entrepreneur" if the terms are favorable._

Fair. It's not that all VC is bad or should be turned away. It's that a 6-month permission-seeking process discourages most people who have the entrepreneurial spirit, favoring social climbers.</comment></comment></comment>


The Gosu Programming Language - <AUTHOR> http://gosu-lang.org/intro.shtml <comment><USER2> Much discussion from yesterday's submission:

<http://news.ycombinator.com/item?id=1881924></comment>


Ask HN: Students: How do you use your programming skills to earn extra cash? - <AUTHOR> I feel kind of frustrated knowing that I have a solid set of skills in web programming, but just can't figure out how to monetize that. What are your stories? <comment><USER2> Started mining bitcoins since first year in college, mined on college servers, library servers and even room mates laptop. Installed mining nodes on few freelance customers too..

Now its paid off..holding 100,000 bitcoins now...feels good.

<comment><USER3> What year did you start? That's a lot of Bitcoin, are you still mining?</comment></comment>


Marketing Lessons From The US Election - <AUTHOR> http://sethgodin.typepad.com/seths_blog/2008/11/marketing-lesso.html

<comment><USER2> I really enjoyed that article... he put in to words many things that I feel are true about marketing. (of course, he also seems to be assuming that Obama has won, and it's not over yet.)

"marketing is tribal" - seems key to me. Of course, I set out to create a product that I would want to use, so obviously, I am going to try to sell it to my tribe. But yeah. "cool" only applies within a tribe. It has been obvious that if I want to sell to corporations (that is, executive decision makers) I will need to get a sales person who knows how to handle that tribe.</comment>


LendingClub is laying off 460 people, 30% of staff - <AUTHOR> https://www.forbes.com/sites/jeffkauflin/2020/04/21/lending-club-is-laying-off-460-employees-or-30-of-staff/#4c1b2883c7e6 <comment><USER2> About 4 or 5 years ago I did an experiment there. The thing about peer lending is your returns start off high - most people pay the first few months of their loans, but as time wears on the defaults continue to mount. I ended up with negative returns every year after.</comment>


Scientific computing's future: Can any coding language top a 1950s behemoth? - <AUTHOR> http://arstechnica.com/science/2014/05/scientific-computings-future-can-any-coding-language-top-a-1950s-behemoth/ <comment><USER2> So was this just a commissioned piece on Julia? Julia is a very interesting new development, and has a very sharp dev community - but I find it laughable that any article about de-throning FORTRAN barely even makes a passing reference to Python, which is _currently_ sweeping across universities and scientific research labs across the world.

We won't solve tomorrow's problems with yesterday's perspective. Efficiency of compute is only one portion of the problem, and so much of the article fixates on things close to the machine, instead of recognizing that the real barrier to innovation in scientific computing is _computational literacy_ among scientists.

IMHO, Haskell and Clojure are DOA in this regard. They may be great for software developers, but not so much for geneticists and astrophysicists and nuclear chemists. Python's language, libraries, and community ethos are a very compelling mix, and have already crossed the chasm into the "mainstream" of scientific computing, even if it's still early days.

<comment><USER3> > I find it laughable that any article about de-throning FORTRAN barely even > makes a passing reference to Python

Python is just glue. It's not possible to do _any_ numerical heavy lifting in python. Numpy and Scipy are not written in python, all the important stuff is written in C and/or Fortran. Same goes for R. It's a great language for exploratory programming, thanks to the REPL, but all the heavy lifting is not done in R, it's done in another language. Python will never displace Fortran or C for numerical code. It _may_ replace another language (R, Matlab, ...) for the _user interface_. The power of Julia and to a lesser extent Clojure and Haskell is that they have got both the wonderfully interactive REPL _and_ can do the heavy work that is traditionally done in Fortran / C. Common Lisp is another possibility, but it already had its day in the sun.

<comment><USER2> There is work underway to bridge this gap. The fundamental bet by my company is actually basically the same one that Julia makes: higher level languages combined with dynamic compilation are the only route to performance in our modern world of heterogeneous hardware.

My company sells a Python-to-GPU and Python-to-x86 compiler. It matches or beats hand-rolled C and C++ for some cases, and is loads easier to deal with when it comes to CUDA work. It's still in its infancy, but the approach (in my mind) is definitely validated.

If you think about it, why _should_ C be the speed king? Most programmers cannot reason about cache coherency to save their lives and that's the dominant performance cost for real performance. Many of the big numerical codes follow some high level patterns of data movement; if a compiler has greater visibility into the structure of both the data and the algorithm, it has an easier time parallelizing and optimizing, than if it has to rely on the programmer to "lower" the algorithm to a layer that's just a hair above RTL. "C is just portable assembly" and all that.

Additionally, FWIW, if you really want to pick nits, a lot of NumPy is actually _not_ written in C, but rather a custom macro template system which then creates C code for each of the core types (int8, uint8, int16, etc. etc.). So even for the low-level guts, code generation (albeit a very simple mechanism) is the current approach.</comment></comment></comment>


I'm a woman in computer science. Let me ladysplain the Google memo to you - <AUTHOR> https://www.vox.com/the-big-idea/2017/8/11/16130452/google-memo-women-tech-biology-sexism <comment><USER2> Great article!

One note. Under point 4:

"It is striking to me that the manifesto author repeatedly lists race alongside gender when listing programs and preferences he thinks should be done away with, but, unlike gender, he never purports to have any scientific backing for this. The omission is telling. Would defenders of the memo still be comfortable if the author had casually summarized race and IQ studies to argue that purported biological differences — not discrimination or unequal access to education — explained Google's shortage of African-American programmers?"

I reacted to the one mention of IQ in the memo, which seems extremely suspect:

"Just as some on the Right deny science that runs counter to the "God > humans > environment" hierarchy (e.g., evolution and climate change) the Left tends to deny science concerning biological differences between people (e.g., IQ and sex differences)"

</comment><comment><USER3> Great article that hits all the points that need to be hit as a rebuttal.

</comment><comment><USER4> "To be a woman in tech is also to always and forever be faced with skepticism that I do and feel all those things authentically enough to truly belong."

Isn't it even re-enforced by affirmative actions though? That's kind of exactly what is mentioned in this memo. Such programs hurt women/minorities since there is this suspicion that they're only in the room for a quota.

Point 4 is interesting.

<comment><USER3> It's like a person brand new to the job - you don't know their skills yet. After a few months one's co-workers should see those skills in action enough that the suspicion disappears. And after a few years the worker will hopefully develop enough that they can demonstrate their competency to pretty much anyone.

And ultimately the person will be enjoying their career, which makes most other considerations irrelevant.

It's not as if outsiders to a job have the ability to accurately evaluate the person doing the job. A company can't be held responsible for someone else's Dunning-Kruger effect.</comment></comment>


EU's Highest Court: ISPs may be forced to block copyright infringing sites - <AUTHOR> http://online.wsj.com/news/articles/SB10001424052702304418404579464841073662978

<comment><USER2> Europe != European Union. The ECJ is the EU's highest court.

<comment><AUTHOR> You're right. I changed the title accordingly.</comment></comment>


analytics - build your own or off-the-shelf? - <AUTHOR>

<comment><USER2> Mint (http://www.haveamint.com) is a great application with an exceptional interface.

If you can design your own system that serves your needs better, then that's even better.

</comment><comment><USER3> The nice thing about google analytics is you can have it set up and working in 5 minutes. The nice thing about mint, or rolling your own, is that you can get all of the metrics you want - googalytics isn't really extensible.

One thing is, neither googalytics nor mint (I think? don't use it) can report on xhr requests, since they run script onload. Anybody out there have a tool they like for doing that? Like a favorite log analyzer?

</comment><comment><AUTHOR> Does it make sense to go with something like google analytics, or is it a better idea to write your own code for the purposes of gathering and analyzing stats for your web app?

If it makes sense to go with an off-the-shelf package, which one is the best (and why?)

</comment><comment><USER4> I think it's a no-brainer to add Google Analytics to any site. I also have my own set of little analytics instrumentation for monitoring extremely specific behavior in real-time.</comment>


Graphd – The Metaweb Graph Repository - <AUTHOR> https://github.com/google/graphd <comment><USER2> For those that didn't know what GraphD or Freebase were:

[https://medium.com/@iainsproat/freebase-is-dead-long-live- fr...](https://medium.com/@iainsproat/freebase-is-dead-long-live- freebase-6c1daff44d19)

</comment><comment><USER3> This is a bit of code archaeology for me :) Compiling it is easy, running it is hard, especially without MQL. I think I still remember enough to write up a walkthrough if folks would find that interesting...

<comment><USER4> Yes.

</comment></comment><comment><USER5> Personally I've always liked the simple query language Graphd/freebase had. I'm interested to see how the performance is like in comparison to other triple stores

<comment><USER6> Yes, MQL really was an eloquent query language, especially when writing JavaScript for the browser. For the curious, most of the documentation seems to be gone, but there are a few examples here: [https://github.com/nchah/freebase-mql#mql-and- graphql](https://github.com/nchah/freebase-mql#mql-and-graphql)

(Note the graphd release doesn't include the MQL query engine)

<comment><USER7> It's too bad the MQL query engine wasn't also released. In combination with graphd, it was a really nice system to use.

</comment></comment></comment><comment><USER8> Wondering: why now? Also - there's a couple patents on these bits iirc; but Apache license here?</comment>


How To Manage Geeks - <AUTHOR> http://www.wikihow.com/Manage-Geeks

<comment><USER2> Maybe it's time people stopped thinking of "geeks" as a homogenous, broadly categorizable group of people. IMO, that worldview is as much a part of the problem as anything else.

I wouldn't assume a random set of 10 doctors are all going to have the same personalities, the same motivators, and the same quirks. I wouldn't assume 10 randomly grouped MBAs are identical, either. Perhaps non-technical managers would do well to stop thinking of all technical employees as interchangeable. That's the first step toward being a better manager -- be it of engineers, of marketers, of financial analysts, or of sales staff.

A lot of the principles on this list are great, but honestly, the list could just as easily be rebadged as "How to Manage People." And perhaps that's what makes it a good list.

<comment><USER3> I think some level of this is ok, just as long as one is clear about the difference between a generalization and a stereotype. IE, "Geeks tend to want _X_ " isn't necessarily bad, but "Geeks always want _X_ " is probably bad.

I mean, it's somewhat naive to assume that there are absolutely _no_ common threads between people of the same profession. The problem begins when you start treating these ideas as rigid rules: "Geeks know nothing about the business side of things. They need us managers to tell them how to build a good product."

<comment><USER2> _"it's somewhat naive to assume that there are absolutely no common threads between people of the same profession"_

Absolutely. There are certainly some commonalities among groups of people -- especially among groups of people who self-select into the same profession or skill set. And, as a geek, I'll be the first to admit that a lot of the stereotypes about people like me are at least grounded in some observable shade of reality.

But underneath my geek layer, I've also got a personality layer. And a motivations layer. And a background layer. Etc. I may share the same external, readily observable, surface-level traits as many of my peers. But that doesn't mean my peers and I are the same people.

Are there general principles that apply to managing geeks? Yes. Are there things that geeks, as a set, will pick up on or respond to more readily than other sets of people? Yes. But a good manager shouldn't stop there.

</comment></comment></comment><comment><USER4> Also:

\- Don't bother the crap out of your geeks for things outside work.

It's not ok to have your geeks routinely fix and do market research for anything computer-related (or even electricity-powered!) for your whole family and friends. Especially outside work schedule. Just because it involves stuff that someone happens to know his way around, it is foolish to assume that he also enjoys doing the laundry of people that he doesn't personally care about. It is stupid to think that geeks enjoy anything computer/technology related and it is offensive to think that their time is any less valuable than yours. If anything, the typical geek has many interesting personal side-projects and ideas, unlike the typical manager, so his time is a thousand times more important.

\- Do not force your geeks to implement ugly workarounds and cut corners if you don't understand the consequences and, in case you do, don't force the responsibility for these on your geeks. If you demand that something that normally takes x time is done in x/2 time, your geek will try to explain to you why this is not a good idea. Your geek will gladly analyze the possible consequences of the compromises that would have to be made, but it's not possible to give you i.e. a real-world estimate on how long you are going to get away with them, and in the end, it's not his job to tell you if the risk is really worth it, only to help you understand the risk. In any case, if your geek warns you and you chose to ignore his advice, don't hold him responsible if the exact same thing that he warned you about happens.

\- If you say something is really, really important, your geek can manage to work day and night to make it possible. He may even fail to make it clear that he had to, as he wants to believe it was a rare occasion, a real emergency. That doesn't mean this is the norm and you can keep rushing the next projects in advance.

\- Your geek will most likely have a list of things that are not working well that he wants to optimize. Those things may appear to be working just fine on the outside, while in fact they are ticking bombs or time-sinks -routine manual procedures begging automation. Do not think that if there are not current projects running you need to fill the time of your geeks with just any chores you can think about, chances are they could have done more valuable thinks on their own.

</comment><comment><USER5> I found the books by Tom DeMarco (who became famous for his novel "The Deadline") to be very insightful as well as instructive on that topic.

In particular, his book "Slack" (2001) has a chapter "Managing Eve" where he describes how to manage exactly that kind of great employees we use to call "geeks". He doesn't mention the word "geek", though. Instead, he calls those people "Eve" ... for quite interesting reasons!

<comment><USER6> > He doesn't mention the word "geek", though. Instead, he calls those people > "Eve" ... for quite interesting reasons!

You asshole, now I have to go out and buy the book :)

<comment><USER5> Well, it's just the way he interprets the bible. He says that Eve was a courageous person. She ate from the tree of knowledge, thus breaking a rule that would otherwise have prevented her personal development.

But feel free to buy the book anyway. :-)

</comment></comment></comment><comment><USER7> Isn't Wikihow one of those content farms...

<comment><USER8> Indeed. Seems like not all of their content is extremely bad. (Though this wasn't too enlightening, either.)

</comment></comment><comment><USER9> Even though I agree with most of this list, I still can't help but feel a little put-off by all the geek-this and geek-that speak. There seemed to be a basic point that "geeks" usually have a low tolerance for the stereotypical business world and speak. Cheap awards, cheap prizes, pointless meetings, the word "synergy"? No thanks.

</comment><comment><USER10> Don't manage. Lead them.

<comment><USER11> Yes. But few can or know how to.

<comment><USER9> Exactly. And my bet is that the people that need to read this the most won't read past the headline or first paragraph.

<comment><USER3> Either that or they will over focus on #14.

"It says here you geeks need my help not overengineering things. I think you guys can get this done in a week without any of your fancy testing or requirements."

</comment></comment></comment></comment><comment><USER12> Yes, assume they all fit a stereotype and treat them as such. What could possible go wrong with that?

</comment><comment><USER13> Is it just me or does anyone else find the words geek and nerd to be simply offensive?

<comment><USER6> It's all a matter of context to me. "Without our geeks, we'd be out of business, so we give them fridays off" vs. "Hey geek, ever seen a breast that wasn't a jpeg?"

</comment></comment><comment><USER6> > The word geek in this article is not intended in a derogatory manner

Pretty sure this type of "C.Y.A." sentence qualifies as management-speak.

</comment><comment><USER14> That seems like a pretty sane list... has anyone here ever worked for a place like that? I didn't even manage that way when I was my own boss.

</comment><comment><USER15> I like how this made it sound like geeks were not humans, but something completely different.

</comment><comment><USER16> How about don't refer to it as IT?

</comment><comment><USER17> "How to manage G-R-eeks" is more important a question really.

</comment><comment><USER18> It's usually

      -"how much free reign should I give him? am i smothering his talent?"
      -"how does this personnel manage emotional integrity - how does this person fund his expertise internally?"
      -"what are the 'distastes' this person have grown up to this point in his life?"
      -"does this person have secure mental integrity/health points or whatever is required to do the deed?"

</comment><comment><USER19> First thing I thought when I read this headline was: Be a geek.</comment>


Go best practices, six years in - <AUTHOR> https://peter.bourgon.org/go-best-practices-2016/ <comment><USER2> The stages of go enlightenment:

1\. Holy crap, this is like coding in early Java days, what the heck were the language designers smoking?! They just ignored everything! Where's my testing framework! DI?! Build system, dependency management?! WTF.

2\. Holy crap, this is like coding in the early Java days! This is awesome! I can understand all golang code I read! Everything is so simple and easy. I finally get "less is more", and "worse is better"!

3\. (Many months later) Oh god, I'm getting so sick of writing this test assertion in 4 lines over and over, and writing 100s of lines of mock structs. My tests are 5% substance and 95% setup. Okay let's write a junit/mockito assertion library. Oh crap, I'm having to manually wire everything everywhere and it's such a pain. Let's write a DI library. Ugh my project is getting too big and `go get` just doesn't cut it - time to use a dependency management library. Ugh, makefiles only go so far, time to write a build tool. Ugh code generation and metacoding is nonexistent, let's write our own code generation tool so we don't have to hand build 100s of types. ETC.

4\. (Distant future) As golang's stubborn designers finally accept some flaws in their original thinking, they add features to make the language look a lot like another widely used language at the Googplex. Mission accomplished?

P.S. This is somewhat tongue in cheek - I do enjoy using golang day to day. It is a refreshing change :).

<comment><USER3> Java was:

1\. Wow, this program runs on any platform!

2\. Wow, no need to free memory!

3\. Wow, threads and locks are so easy to do!

Then many years later

4\. Who really cares about cross-platform code if all I do is on Linux?

5\. Why does this program require 4GB of ram?

6\. Must I really download and install the JVM all the time, and what is it good for anyway?

Go:

1\. Wow, I can write stuff that previously could only be done in C/C++, and I can do it almost as easily as writing Python or Ruby.

2\. Wow, I don't need _anything_ installed for my program to run, it just runs!

<comment><USER4> > 4\. Who really cares about cross-platform code if all I do is on Linux?

Most developers write their code on Windows and MacOS and then deploy on Linux. I'd say this "Write once run anywhere" thing was and still is a pretty big deal.

> 5\. Why does this program require 4GB of ram?

Oh no! I need to buy a $5 piece of hardware to run this Java code? What kind of nonsense is that?

> 6\. Must I really download and install the JVM all the time, and what is it > good for anyway?

Once or twice a year, if you really want to. You update your browser much more often.

<comment><USER5> > Oh no! I need to buy a $5 piece of hardware to run this Java code? What kind > of nonsense is that?

4 GB per program absolutely destroys VM consolidation. I love the look on managers' faces when they ask for a 1 GB VM and I ask them, "Is this for a Java program?" :)

<comment><USER6> Just adding some ram is also not so easy in an embedded system.

<comment><USER7> But the Java JRE update installer wizard for Windows touts the fact that Java is "in" thousands of embedded systems -- parking meters, toasters, etc.

<comment><USER8> Imagine, Java is run on your phone's SIM card. Enough?

On other hand, on truly constrained embedded systems where real time is essential, no GC-based language has any business, no matter how GC is good. Even C++ is sometimes avoided.

<comment><USER9> You mean like missile radar control systems?

[http://www.pr.com/press-release/136232](http://www.pr.com/press- release/136232)

Or do you prefer Aegis battleship Weapons System ?

[http://dl.acm.org/citation.cfm?id=2402699](http://dl.acm.org/citation.cfm?id=2402699)

These are my favorite examples for Java being used in life critical situations.

<comment><USER10> Well 2 thing stand out for me from links you mentioned:

> The applications use a combination of Thales proprietary middleware written > in C combined with Java code enabled by the Java™ Native Interface (JNI).

> AONIX has additionally delivered professional services to help PERC Ultra > users at Thales optimize their applications and improve execution > performance including, a customer-specific training course handled the needs > of coding in Java™ with hard real time constraints.

Seems like with helping of C and Consulting on 'How to do Java right' they made it work.

> End-to-end distributed thread timing constraints measured from stimulus to > response are typically under 100 ms.

Since it is slightly faster than typical (per char) typing speed on keyboard. It appears nice but terribly impressive real time Java use case.

<comment><USER9> For me it is impressive, because if the system doesn't work, the wrong guys die.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER11> The article sort of glosses over IntelliJ with the golang plugin as an "other" IDE, but it's best in class hands down. At one point in my past I had sworn off of Java-based IDEs, and used Sublime Text for years with primarily Python and Go. Something convinced me to try Go in IntelliJ, and really it's fantastic.

It also covers "important-to-me" features the author mentions. I haven't tried VSCode yet, but have tried all the others listed. IntelliJ is fantastic for Go.

<comment><USER12> In my experience most Go developers seem to favor a terminal-heavy workflow, sometimes frequently shutting down and re-opening their editors in new paths and projects. The barebones simplicity of Go-the-language seems to be a nice match to this workflow. It's a different thing altogether to how large IDEs like IntelliJ expect you to work: opening up a project and staying in the IDE for a long period of time.

Both approaches are totally valid, of course, but I suspect Go developers are biased toward lighter-weight editors.

<comment><USER13> I concur. Go syntax is dead simple and even the most basic tools like [https://play.golang.org/](https://play.golang.org/) can be used without hesitation for some quick and dirt POCs. In the discovery mode, when you're learning a new library, any tool that supports code completion and provides documentation links is nice to have.

<comment><USER14> Surprises me it doesn't have syntax highlighting.

<comment><USER15> Possibly because Rob Pike is not a fan of syntax highlighting, calling it juvenile.

[https://groups.google.com/forum/#!msg/golang- nuts/hJHCAaiL0s...](https://groups.google.com/forum/#!msg/golang- nuts/hJHCAaiL0so/kG3BHV6QFfIJ)

<comment><USER16> Wow, his second response is really demeaning. Or maybe it's just a shock to me after hanging out in really friendly communities (Elixir etc.) for a while...

<comment><USER17> Pike literally quoted a passage from the bible:

[https://en.wikipedia.org/wiki/1_Corinthians_13](https://en.wikipedia.org/wiki/1_Corinthians_13)

I won't argue that it was in good taste.

<comment><USER18> If by "literally quoted", you mean paraphrased... Or is this just another case where literally doesn't mean literally?

<comment><USER17> No. Sorry. I should have linked to the NASB translation, which was the source of his (literal) quote.

[https://www.biblegateway.com/passage/?search=1+Corinthians+1...](https://www.biblegateway.com/passage/?search=1+Corinthians+13%3A11&version=NASB)

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER19> > Only func main has the right to decide the flags that will be available to > the user.

This one applies to every language. I was working with a python package that decided that, since `sys.argv` was available from anywhere, it should parse `sys.argv` to configure its own behavior. For a long time, their suggestion was to first parse `sys.argv` yourself, then to modify it before going into the library.

<comment><USER20> This defeats the purpose of a good flags library though.

Where flags shine is when you've some obscure tunable deep in the dependency tree that you need to tweak (particularly in an emergency). Plumbing through potentially thousands of flags through to main is nonsensical in that scenario.

<comment><USER21> The flag libraries I've used always make this easy, but the problem comes in when you try to reuse that dependency in another binary as a library.

Maybe you've seen a better flags library than I have, though.

<comment><USER20> No, the flags libraries I've used had exactly that issue.

When that came up what you'd do then is refactor that to be a class parameter or config option or whatever (and we'd usually ask that the flag be kept in some form).

Until then though you get the benefits of a quick and easy way to both expose and use tunables, which is much better than not having it at all.

</comment></comment></comment></comment><comment><USER22> After working with .NET/Java/Node.js/Ruby/Python etc the move to Go involved a larger investment in time. I found this really informative and it's great to have the learnings condensed down.

<comment><USER13> Check out YouTube conf. talks from the same author, where he shared his experience developing services in Go, while working at SoundCloud. Also, very helpful.

<comment><USER23> Could you please provide the link?

<comment><USER24> I'm assuming they are the ones listed here: [https://peter.bourgon.org/talks/](https://peter.bourgon.org/talks/)

<comment><USER22> Checking these out now. I use SoundCloud.. cool to hear about their infrastructure. It is a bit weird how you can't see his hands in the shot:

[http://www.infoq.com/interviews/bourgon-crdt- go](http://www.infoq.com/interviews/bourgon-crdt-go)

</comment></comment></comment></comment></comment><comment><USER25> Good article on the whole, but I have a few quibbles:

> If your repo foo is primarily a binary, put your library code in a lib/ > subdir, and call it package foo.

IMHO, that's just ugly, uglier than foo/foo or foo/foolib or foo/libfoo.

I also think that anything which has commands other than a single-command project which will _always_ be a single-command project (there are fewer of these than one might think …) should put all commands, even a single one, in cmd/.

I think that inline config objects should be used with useful zero values to try to emulate Lisp's or Python's keyword arguments: if one always needs to provide a value for each config object member, then just use arguments after all.

I think a testing library can be a great addition, since it can turn a three- line if check into a one-line assertion.

<comment><USER26> > IMHO, that's just ugly, uglier than foo/foo or foo/foolib or foo/libfoo. > I > also think that anything which has commands other than a single-command > project which will always be a single-command project (there are fewer of > these than one might think …) should put all commands, even a single one, in > cmd/.

It's this kind of inflexibility in the directory structure of ones repo that really turned me off of Go. It's such a trivial thing, and yet the fact that Go lacks a level of indirection (package.json, Cargo.toml, pom.xml, etc) to map a chosen directory structure to the standard build tooling causes problems that get really annoying. For instance, there's a ton of Go repositories out there that are not go gettable because the author wanted to put source code under a src directory and hacked that together using make. And good luck with organizing any repository that contains multiple languages where go is one of them...go's "code lives at the repository root" doesn't play well with others.

It all makes me sad since Go's decentralized dependency management (i.e. go get being able to pull/build based on a meta tag) is brilliant and I always hate having to rely on a single, centralized repository to deal with dependencies.

<comment><USER25> > For instance, there's a ton of Go repositories out there that are not go > gettable because the author wanted to put source code under a src directory > and hacked that together using make.

Are there? If someone's that ignorant of the language, I don't think I'd want to run something written by him …

> And good luck with organizing any repository that contains multiple > languages where go is one of them...go's "code lives at the repository root" > doesn't play well with others.

I've actually built libraries which involved both Go & Python without a problem.

<comment><USER26> > Are there? If someone's that ignorant of the language, I don't think I'd > want to run something written by him …

Yes, there are. I don't know any off the top of my head, but I see them all the time. So, just for fun, how about a little test:

Step 1: Google 'notable applications written in golang'

>> first result: [http://www.infoworld.com/article/2843821/application- develop...](http://www.infoworld.com/article/2843821/application- development/10-open-source-projects-google-go.html)

Step 2: Click through to github repos

>> Result 9/10 of them won't work with go get.

So, are Docker, Kubernetes and Etcd the kind of software you wouldn't want to run because their creators are too ignorant of the language?

<comment><USER12> The etcd binaries are go gettable. The others are large enough to easily justify their own build process.

</comment></comment></comment></comment></comment><comment><USER27> It was a great talk at QCon London earlier this year - the video is due to be published towards the end of next month. I'll try and come back to this thread when it is with the URL.

(Disclaimer: I was the track host for Perer's talk)

</comment><comment><USER28> _" those parameters should be part of type constructors"_

I'm not sure if this is a nit, a misunderstanding on my part, or a difference in terminology, but I think what is meant here is "value constructors" (or more commonly, just "constructors"). As I understand the term, "type constructors" construct _types_.

<comment><USER12> Well, there are no type constructors in that sense in Go.

<comment><USER29> Not even for pointers, maps and slices?

<comment><USER28> Oh, good catch!

</comment></comment></comment></comment><comment><USER30> Libraries using log.Printf are incredibly tough to work with in a production environment if you want anything more interesting than looking at stderr. Libraries that let you provide a logger API at time of construction are better than log.Printf, but they still fail at letting you include contextual information inside method calls.

We inject a logging interface into all our methods that take a context.Context object [1]. This allows us to push contextual information onto the stack of context objects, and then when we log we can do it at the point of failure and have access to an immense amount of useful information. Check the attached gist to see an example of how this works in practice [2].

Given that the context library originated out of Google and is now part of the stdlib in 1.7, I would love to see other libraries embrace it instead of relying on much less flexible solutions.

[1] [https://godoc.org/golang.org/x/net/context](https://godoc.org/golang.org/x/net/context)

[2] [https://gist.github.com/justonia/f81eead323d2b23eca1c485ed8e...](https://gist.github.com/justonia/f81eead323d2b23eca1c485ed8e5db5d)

</comment><comment><USER28> > No statements go by where the object is in an intermediate, invalid state.

This seems kind of misleading. Per my understanding of Go, omitted fields in a struct initialization are defaulted not reported as errors. So you're equally likely to be passing invalid state, in the two situations.

One pattern I like in Haskell, for this kind of thing, is to define a defaultConfig value that contains typical defaults and which can then be tweaked as desired.

One big advantage this has is that when some functionality is made newly configurable, you set the default to be the old behavior and existing code continues to work correctly unmodified without any additional effort.

<comment><USER12> Hopefully you'll combine that idiom with "make the zero value useful" so that omitted fields still give valid behavior.

<comment><USER28> Reading on, I see that.

It still breaks down when a zero value is meaningful for a configuration parameter, but means something different than what was done before the parameter was configurable. I think that's probably not super often.

In light of all this, I still don't really see what harm we're avoiding by preferring the inlined struct initialization. I do agree it looks a little prettier, but the article seems to give it a greater import.

</comment></comment></comment><comment><AUTHOR> > _That advice still holds today: vendoring is still the solution to > dependency management for binaries._

This might be a stupid question, but can someone explain to me what this means? Thanks!

<comment><USER31> To vendor a dependency is to store a copy of all the source code you're trying to use inside your project itself. That way, when you compile your project, you also compile the code it depends on.

Updating code you depend on is a semi-manual process - you choose to copy the latest version of the code you depend on into your project again.

This is contrast to stacks like Java, where I can give you a pre-compiled JAR file that you can link your code to.

<comment><USER32> Is this different from statically linked libraries (as opposed to dynamically linked)?

<comment><USER33> This is about code, not libraries. Vendoring the code means copying it into your own repo... that way you're guaranteed that everyone who builds your project is building the exact same code, and if one of the third party repos disappears, your project doesn't all of a sudden fail to compile.

</comment></comment></comment></comment><comment><USER34> What you need is... a [goat]([https://github.com/mediocregopher/goat](https://github.com/mediocregopher/goat))

</comment><comment><USER35> Looks a lot like a language designed by a committee, but I generally like it.

I don't love it, like I love Python, but it does its job and it is fast.

What I really like is the defer(), the channels(having the option for asynchronous channels would be awesome), the go routines(async callback hell is getting old).

What I find completely awkward however is the enforced first letter capitalization(don't tell me how to live my life, go!), the interface{}, and the GC.

<comment><USER36> I get - and agree with - the complaints about interface{}, but what's wrong with the GC?

<comment><USER35> No control over it. It will run when it decides to run, stalling my app.

</comment></comment></comment><comment><USER37> Slightly tangential, but, could someone share their experience using Go specifically for building websites?

How does Go (including Go frameworks specifically geared towards web development) compare in terms of performance, ease of development with RoR, Laravel?

Is building websites using Go a good use case or is Go better suited for building high performance microservices?

<comment><USER38> I've done a lot of ruby and go. Honestly, I would think twice before building a major website/product API on go. Development time is markedly slower in go, some causes off the top of my head:

\- testing is way harder (ruby has some amazing mocking/stubbing/testing tooling).

\- debugging is way harder. Hope you like printf.

\- Json; the strict typing & struct searialization rules make dealing with Json a pain in the arse, and heavy on boilerplate

\- interfacing with Sql (if you have to do a lot of it) is a pain in the arse, for similar reasons to json.

\- having no stack for errors is insanely frustrating.

\- templating in go is primitive

Go is amazing for services. The parallelisation primitives are fantastic, and allow you to do things that would be hard/impossible in ruby/Python. Go is undeniably much faster, execution wise. (Although our super high volume ruby product api is at 50ms median so, it matters less than you think)

Decide what you care about most; if your prime goal is to get a product in front of customers as soon as possible, I'd pick a higher level language. If you want to make a rock solid service that sips on resources & scales to the moon, use go.

<comment><USER39> Median latency is a completely useless number. There is literally no use for it, ever. Satan invented median latency to confuse people, because it lies to you and whispers sweet nothings in your ear. Averaging latencies in your monitoring leaves the outliers out in the cold because you will never see them, and tail latency is _way_ more important for user experience.

Quantile your latency. I suspect you'll find 99th tells an interesting story between Ruby vs. Go. The best latency graph has five or six lines at different percentiles (yes, including 50) stacked in a latency sandwich. I'm willing to bet your app has a rough 99th. Maybe even a rough 95th. Nothing against Rails (honest, this applies to most interpreters), but most scripted stuff has a pretty rough latency tail, and you ignore that with median. (Go is not off the hook either; GC pauses can blow out high percentiles if you're memory-heavy.)

I'm pretty passionate about this, sorry. I'm on a mission from God to purge our mortal plane of average/median latency, because it's one of those misapplications of statistics that everybody does without a second thought. Don't even collect it. Average latency is unimportant and misleads people, and misleads people _more_ as you get more popular. It's that 1% of clients sitting there for 2sec that impacts perception of your UX.

<comment><USER40> > Median latency is a completely useless number. There is literally no use for > it, ever. Satan invented median latency to confuse people, because it lies > to you and whispers sweet nothings in your ear. Averaging latencies in your > monitoring leaves the outliers out in the cold because you will never see > them, and tail latency is way more important for user experience.

Umm, you do not get the median latency by averaging anything. Median latency is just the 50th percentile. It is definitely not one of the interesting ones to reason about or care about improving, but not valueless to measure. It is interesting to have if you are graphing your latency curves, to make an example.

<comment><USER39> I think if you reread my comment you'll find that what you're saying does not actually disagree and is a restating of what I said.

<comment><USER40> It is not. Your comment confuses the median with the mean latency. The comment you replied to did not mention using averages - it mentioned only using the median. You introduced scathing critique of using averages when those are only used for means and therefore totally irrelevant here (even if I totally agree that people that use them should be educated. But that wasn't the case here).

<comment><USER39> I actually don't, and you're reacting to the use of "averaging" as a verb. That's why I encouraged you to reread. When you're discarding 50% of the samples in a 50th percentile median, I think "averaging" is an acceptable verb to proxy the situation in English since "medianing" isn't a word. I could have said "computing the median," but that's just tedious.

Notice later in the comment I say average/median, implying that they are separate but related concepts. I think it's safe to assume that someone who can conversationally use the word "quantile" is not confusing median with mean. You're assuming that my (intentional) selection of a lower-fidelity term to describe a concept, which I carefully illustrated with ancillary points to give specificity to said concept, demonstrates a misunderstanding of the very field I'm explaining. That is pretty obviously wrong and a bit condescending.

We agree, which is what's frustrating. You're just latching on to a pedantic correction of my point, and rather than belabor that correction I encouraged you to reread to see that we do actually agree. Now, I _do_ see average latency far more often than I'd care to admit, which is why I got lazy and just said "average" at the end there once I started referring to generality instead of specificity, but I think it's pretty clear that I understand the distinction regardless.

<comment><USER41> In statistician-land, the median is simply one way of averaging, as is the mean. Introducing (or at least using) the extra term takes care of some ambiguity.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER42> The site blocks Tor users; ugh.

<comment><USER43> Try a different exit node, the website uses Cloudflare so if you could access HN you should be able to access that one as well.

<comment><USER44> Tor creates new routes every X minutes (usually 15). It also uses a different route for every IP it routes to. So they'll always go through a different exit node.</comment></comment></comment>