Working for a startup makes less sense - <AUTHOR> https://zainamro.com/notes/working-for-a-startup-makes-less-sense <comment><USER2> I've had a related discussion with a few VCs in recent months. Some kinds of startups are effectively impossible to build given current structural constraints on financing them, creating an adverse selection for startups that fit the classic model rather than startups with the highest expected ROI.

Broadly speaking, engineers will work at a discount to market-clearing wages of maybe 20% if they really like the startup. This is not necessarily an issue if you are well-funded and require ordinary levels of skill from your engineering team, which is most startups. Some types of software startups can't be built without a team of engineers where the market-clearing wages are typically more like $500k-1M. Even at a 20% discount to market, the amount of capital involved just for headcount is far too large for early stage investors, and startups that try to fit within the capital they can raise by getting by with less qualified engineers always fail at technical execution. Consequently, startups that have this property are effectively un-investable because there is not enough capital available in the early stages to achieve technical viability even though they may be great investments in the abstract. This wasn't a serious issue a decade ago, but it is spreading to a larger set of startups as wages rapidly escalate.

Given a long-term glut of capital, this could be addressed in principle by designing a model that modifies the distribution of capital/equity over time to accommodate startups that have difficulty financing the initial wage gap. As the startups grow, one would expect the average wages to start reverting toward the mean, but these startups won't get out of the gate without that initial investment in capable and very expensive engineers.

I've had interesting and productive discussions around this, it is seen as a way to bring fresh blood into an early stage pipeline that is drying up. It is obvious to almost everyone that the classic model of how you finance and build a startup team is breaking down in the current market environment, with an adverse impact on expected returns.

<comment><USER3> This is a good summation of the current challenges with startups that are attempting to compete on technical merit. I know this first hand as I started a computer vision company right around 2012 when the "AI" boom was really picking up steam. I would never dream today of starting a very technical company because every major will poach your talent (happened to me), invest in your competitors or attempt to acquire you (some people don't want to be acquired).

Contrary to your points, I don't see any way this will change until some big technology revolution happens that puts power back into the hands of creators - though that might be a pipedream.

Note, that doesn't mean you can't start and be successful with a company. What I'm trying to point out is that the days of a scrappy upstart coming along to "unseat the leaders" doesn't seem anywhere near realistic.

The only counter to this might be worldwide competition - so for example I could see Tencent getting bigger than Facebook in total user numbers. I'm not sure if these are comparable because they are in segmented markets.

<comment><USER4> > I would never dream today of starting a very technical company because every > major will poach your talent (happened to me), invest in your competitors or > attempt to acquire you (some people don't want to be acquired).

Damn, this is exactly what I want to do. Computer vision too.

Do you have any advice other than "don't"?

Would basing the company on the East coast near a tier-1 research university help with talent?

Could you have strong software engineers support the research roles? Does that pattern work effectively?

Another thing I really want to do is offer a 4-day work week with the promise of sabbaticals and/or remote work. That might not be attractive to everyone, but it's something that would speak to me and that I would want in addition to equity and salary.

Are you still interested in computer vision? Want to chat sometime?

<comment><USER5> >Another thing I really want to do is offer a 4-day work week with the promise of sabbaticals and/or remote work. That might not be attractive to everyone, but it's something that would speak to me and that I would want in addition to equity and salary.

I think this would be a very strong advantage in the hiring market (assuming you can raise money from investors who're okay with it).

I'm not your target market (I'm just an in-demand software engineer who happens to be learning ML, not a top computer vision researcher), but this is something I'd be willing to accept substantially lower comp for.

Unfortunately most startups seem to require even higher work output than big tech.

<comment><USER6> Well, that's his big bet isn't it. There are a lot of studies that claim 4 day work week will keep productivity more or less the same.

The catch here is this will potentially enable you to hire those 10x people. Even at reduced productivity, 80% of 10x is more than double productivity for 100% of 3-4x people, and perhaps this work environment will foster other people to increase their productivity as well.

With the right people and product, I see this as the ultimate weapon against big tech, most of which will have shareholders that will act a lot more conservatively when it comes to risks compared to startups.

This is not something big tech will be able to accommodate in the current macro-economic environment, no board will approve basically a 20% salary bump to all employees and while risking a potential drop in productivity.

</comment></comment></comment></comment></comment><comment><USER7> My experience: engineering at Startup #1 for 2 years, then Google for 3 years, then Startup #2 for 4 years, and now I've been working with seed stage companies as a VC for the last 7 years. The amount I earned as an engineer was highest at Startup #1 (got lucky!), significantly lower at Google, and a little lower than that at Startup #2. Startup #2 is still chugging along, which could eventually make it on par with or a little superior to working at Google.

But money isn't everything. Startup #2 was the place where I learned the most. I was senior enough to be single-handedly responsible for large projects like a distributed search engine and a logging and analytics service. Sure, my search engine was a POS compared to Google's, but at Google I would've worked on a part of a feature of a component of the search engine whereas at a startup I got to build the whole thing from scratch. I'm almost 40 now, and that search engine is still by far the most fun and educational engineering project I've ever worked on.

Aside from learning potential and financial comp, there are other factors like team camaraderie, independence, etc. I keep in touch with way more people from the two small startups than I do with Google colleagues. Google had a good culture, but the startups were much tighter knit.

Finally, I think articles advocating for startups vs. big companies are a little like trying to convert someone to atheism or Christianity with a blog post. It doesn't really work that way. Some people are wired for startups: they love them and spend their careers at small companies and don't understand why big companies are attractive. Other people are more drawn to big companies where the company itself has a huge impact, the teams are well-staffed and have lots of resources, and the employees get higher salaries and lots of other benefits. When these people try working at a startup, they often hate it and quickly go back to another large company.

Neither big nor small companies are objectively the best, but if you factor in personal happiness then often one type of company is the best _for you._

<comment><USER8> I've noticed the same thing in biotech startups. Some people are meant to be part of smaller, bootstrapping companies and others are meant to be part of more established, good business corporations. The most interesting people are the ones who get in early and stick with it, growing along with the company.

<comment><USER9> _The most interesting people are the ones who get in early and stick with it, growing along with the company_

It's pretty rare for this to actually happen in my experience. Generally an early engineer will grow and be ready to take up the role of VP Engineering or even CTO and instead the VC's will parachute in one of their cronies once the hard work has already been done.

<comment><USER8> Completely agree. The issue I see is that at that higher levels, opex is more important for success than familiarity with the specific science. So the people who "grew-up" with the company, who would have detailed understanding of the science, would not necessarily have opex skills commensurate with the requirements the larger organization now requires.

</comment></comment></comment></comment><comment><USER10> Here's where I've been:

\- worked at a startup out of college for 85k max plus significant equity (never amounted to anything). Stayed too long.

\- worked at a later-stage startup starting at 120k, peaking at 130k. Got some stock options there (haven't amounted to anything yet)

\- took a job at FAANG starting at 400k, plus some stock options. Currently at this job for > 600k base. Plus stock options.

While at FAANG, I created a tool that we open-sourced. I've had several VCs contact me to see if I want to try turning that into a company, but by my math it would be a lot of work for no gain over what my salary already is. I already get paid to work on this OSS thing, but I also get to work on other things - and on the OSS thing it's pretty clear cut what I need to prioritize, since my priority user base works with me at FAANG.

For me, startups have a 0/2 track record of delivering value. Being able to net more than I make as an IC seems pretty unlikely, and trying would be a whole lot of pain and sacrifice. The "faster growth as a founder" idea seems to be conditioned on the assumption that you'll succeed enough to pay yourself more than you make now, and/or be able to exit at an amount that will make up for the opportunity cost of getting paid well in the meantime while having a sane work/life balance. YMMV.

<comment> wh-uws > "faster growth as a founder" idea seems to be conditioned on the assumption > that you'll succeed enough to pay yourself more than you make now, and/or be > able to exit at an amount that will make up for the opportunity cost of > getting paid well in the meantime while having a sane work/life balance....

I posit its even more than that. It's a meme / propaganda by the survivors with their bias and those who hope to follow in their footsteps.

Also what's also interesting is you posted your comment to a throwaway while the others parroting that talking point were happy to reveal themselves at least pseudonomusly.

I'm pretty sure why. You don't want to burn your shot if you want to have another go at the startup thing and have people be able to read you saying you wouldn't be fully committed.

I fully respect that.

The only reason I point it out is to show how Silicon Valley the larger VC ecosystem is an echo chamber around this ethos.

My guess as to why is how would they recruit the next generation without that?

</comment></comment><comment><USER11> Yes you will probably make more at an established company, but your rate of growth can be much higher at a startup.

I worked at a large tech company for 3 years before joining a startup, and learned more in the first month at the startup than the full 3 years at the large tech company. I was able to design and implement a service in a matter of days, whereas at the large tech company those 3 days would easily spent convincing people that the service is needed in the first place. Direct exposure to customers also is really interesting and changes you as an engineer.

It's definitely a no guardrail environment, in the early days we had a bug that directly cost us a large customer pilot. No better teacher than experience, we did not make that mistake twice.

<comment> yoz-y I've had kind of the opposite experience. At the startup we were really sluggish it was hard to learn anything because we were jumping into any possible business opportunity before even thinking about ROI because money was always tight. 80% of the time was wasted supporting clients and fixing bugs that were due to the fact that the product was shipped too early.

I think the biggest difference is money. A well funded startup might be a boon but a struggling one will be a bane.

<comment><USER12> The difference is whether you see learning to do meaningful things on a shoestring budget to be itself a useful skill.

Boeing won't care if you save the project $5k by spending a week of your time coming up with a clever workaround. The week was more important than the $5k. Same for a high level role generally. But not getting work done for a week because your boss won't approve a $500 purchase... that would be frustrating and get old fast.

<comment><USER13> On the other hand, it seems like a savvy engineer could work that into a story to tell a Boeing interviewer about how they took the initiative to think outside the box and develop a solution that saved the day when the team was under a time constraint.

<comment><USER12> If they solved a time constraint by being clever and working hard then clearly Boeing would care about that, I agree.

Saving $$ per unit and saving $$ total are so different. If all you're doing is saving $500 total, I wouldn't even care in most cases... but if you managed to use clever techniques to save $0.30 off the manufacturing cost for a toy that gets sold in the millions...

I most strongly agree with the ethical part of the article, in any event. I'm sick of companies trying to take advantage of their employees, it's just sad and gross to see it done by startups that could be better than big companies in at least this one way. But instead they take it even further somehow because their finances are far more opaque. I don't think it should be up to noblesse oblige to determine whether distribution of profits and salaries are fair, it should be assumed to be the rule even if there may be exceptions.

It's a sad day when you look at employment agreements from Intel and a shiny startup and find that Intel is more up front and transparent about how things will work and what you'll get paid.

<comment><USER14> >noblesse oblige

I think the course of events in the USA in the decades since the 50s has essentially answered the question of what happens if you leave it up to the most fortunate to decide how to treat the least fortunate.

</comment></comment></comment></comment></comment></comment><comment><USER15> I've been out of startups for a few years now, but it always struck me that there is _plenty_ of room in the cap table for employees, if founders and VCs realize they have to cut back.

If founders and VCs gave a third to half of their companies to employees, instead of crushingly small option pools, this math would almost certainly shift. And the returns wouldn't be much worse for founders or VCs.

<comment><USER16> The reason they don't is because they already gave 50% to the investors. And it isn't uncommon for companies with $30M or $1B exits for the founders to get nothing. I heard about a company recently where the company sold for $40M and the founders only owned 4% after years of raises. I doubt the founders got anything. Most of the time these companies are having trouble scaling sales.

<comment><USER15> That's why I included investors. One could imagine a regime change where, given the market for talent, both founders and investors realize the need to carve out more for hiring equity, and value companies accordingly, especially in the BS early rounds where it's not based upon any real financial metrics.

</comment></comment></comment><comment><USER17> I worked at software startups in the Boston area from 1988 through 2013, so perhaps my comments are not relevant to this day and age. But what I read in that note sounded awfully familiar.

In the mid 90s, Microsoft was buying up talent left and right, in whatever area they wanted to go into. My field is databases, and I developed expertise in the integration of query languages with programming languages. I got an obscenely lucrative offer from Microsoft, and decided to turn it down. It was a dumb decision, financially, but actually worked out fine on that front. However, I'm sure that Microsoft enticed many promising software developers to work for them instead of startups. (A few names do come to mind.)

This problem was completely solvable then, and the same technique would work now. The problem is that VCs don't want to solve it. They want software developers cheap. They give miniscule amounts of equity, and bias the terms so that those tiny stock option grants almost never pay off very well, (e.g. liquidation preferences). Except, perhaps, for the chief architect, and one or two very senior developers, we are viewed as disposable, interchangeable cogs.

There are great reasons to work for a startup, other than equity. I am very happy with my 25 years doing just that. But equity is definitely a factor. Contrary to what they would have you believe, VCs are _extremely_ risk-averse, certainly compared to the developers who are sacrificing the best years of their lives for their companies and the chance of a financial win.

</comment><comment><USER18> It has always been mindboggling to me that startups are still so all in on the Bay Area. Most problems mentioned in the article go away if/when you are willing to staff developers in an area that is not as ridiculous in terms of cost of living as the Bay area. According to StackExchange data, the 50th percentile pay for a Full Stack Developer with a Bachelors degree and 3 years experience (a profile that would seem reasonable for a startup hire) in the Bay area is $140k, whereas in the St Louis and Minneapolis it is $89k. Not sure why for many startups Bay area seems to be the only option. If they staffed their developers in a place like St Louis they'd be able to avoid the SF salaries and still pay in the 75th percentile for the market and the developers would have more purchasing power making $115k in the midwest or Raleigh than they do in the bay area making $145k.

<comment><USER19> The Bay Area offers software engineers a career growth trajectory that other places simply don't.

That $140k number might be a reasonable 50th percentile for what a junior engineer would make at a startup in the Bay Area, but compensation can increase quite a bit after several years in the industry, especially for engineers who move to large companies which give stock compensation. They will far outpace the earnings growth of engineers elsewhere.

It's much easier to achieve that kind of career trajectory in places with high concentrations of tech companies, e.g. the Bay Area and Seattle.

<comment><USER20> That makes things look even better for St Louis and Minneapolis type places. Startups in BA can't even hire juniors for $140k while if they pay $100k in St Louis they will have people jumping at a chance.

Now I'm sure the BA people average better but somebody in the top 5% from St Louis is going to be pretty good.

Note: I'm from Auckland, New Zealand and $US 100k would be a very good salary.

</comment></comment></comment><comment><USER21> There is a lot of capital out there, what needs to happen is the number of startups shrink and the well funded ones pay more money - even more than google or FB pay. Simple as that! If you are sad that you can't get a professional team on a $1mil seed, I have absolutely no empathy for you because I'm an employee and this is the free market.

Now, if you really want to make it more enticing, some things that would move the needle for me other than comparable salaries (although more cash is #1):

\- Larger equity that automatically ups if it will be diluted, and the moment any shares vest I can sell them in the private market.

\- Transparent cap table.

\- If the founders take cash off the table, I can as well, and no preference for founders.

\- 10 years after leaving to exercise my shares. I don't want to have a 3 month trigger that handcuffs me to prevent a giant cap gains bill on "paper money" when the fair market value is way higher.

\- Reasonable working hours.

\- Flexible work from home policy.

But overall, go raise more and start offering more cash, because I assume 95% of startups are total failures.

</comment><comment><USER22> I've said this before and I'll say it again. Never accept a lower salary in exchange for equity. Salary is your market rate for providing labor. Equity is what you get for taking on the risk of being out of a job sooner than later.

So with that in mind, if the equity and bonuses in BigTechCo are a sure deal, then it may be worth negotiating for more when you join a startup.

Don't sell yourself short.

</comment><comment><USER23> I believe this post does a very good job of bringing the elephant in the room into the discussion. The current structure of equity compensation for early- stage startup companies is simply not enticing enough to get people to choose that over the salary and predictable path of BigTechCos. I love working in startups and even I, when presented with the choice, pad the salary knowing that throughout the funding rounds, if the startup is lucky, any fractional percent that I have will be so diluted that I'm likely to walk away with nothing to show for the work I put in beside the cash I opted for, hopefully, some new connections and some learnings. While some of the more successful startups can compete with those companies on base salary it is just not enough necessarily to convince the top talent that you are the right move for their career. That said there are ways to improve this such as the increased transparency OP wrote about in their post. We should also give more equity to early employees and have favorable terms around vesting for these employees and better timing around the loss of options after leaving a company. Of course this negatively impacts founder equity and potentially investors as well. But to me, worrying about that negative impact to founders and investors comes off as short sighted on part of the investors and founders. Ensuring your early employees will be taken care of means they'll work harder for your company and this will increase the chance you'll survive long enough to see an event that makes _anyone_ a return on their investment. The numbers are so overwhelmingly stacked against startups that worrying about the couple million less you'll have because you gave out 1-1.5% equity to your early employees is really silly, very much chicken before the egg. Instead we currently have the weird known but unspoken fact that your early employees will likely get nothing in a liquidity event while still asking them to put their all into your company which is unethical at best and downright manipulative and harmful at worst. So yeah startups are in a weird place. This doesn't even touch on companies that just stay private forever which is another issue all together.

</comment><comment><USER24> The tricks that companies have used to dilute engineers' equity and to have different classes of stock are coming back to bite those companies.

<comment><USER25> To be fair it's mostly been the VCs learning how to extract more value and forcing that on the companies.

The VCs have naturally gotten better at what they do, which is bring returns to their LPs. The consequence is that they get more value from exits than they used to which comes at the expense of the employees and founders.

<comment><USER26> The founders agree to those terms though

<comment><USER25> They don't really have a choice if they want funding. Also that's why the terms are usually good for founders and it employees.

</comment></comment></comment></comment><comment><USER27> 1) People say you learn a lot more in a startup than in a BigTechCo. I don't think this is true: I've gotten far more skills during BigTechCo stints than at startups. YMMV.

2) A new grad at a startup gets, what, $100k in salary and some equity? If we're talking a three year stint at a startup, you're effectively asking a worker to invest ~$500k in exchange for that hypothetical equity. In the broadest strokes (obviously everything depends on the deal), what kind of equity does an angel get for half a million dollars, and how does it compare to the amount of equity the new grad gets? And it bears pointing out that that new grad equity is subject to all kinds of games and deception. Of course, the usual response is "you just have to be smart enough not to be scammed!" Perhaps, but I know tons of people (including myself) who are apparently just too dumb not to be scammed but are still smart enough to be gainfully employed at a safe job.

<comment><USER13> How do you come to $500k? Wouldn't that require that the new grad would be able to get a $266k job at a larger company? That doesn't seem particularly realistic.

<comment><USER27> Rough numbers, but I'm thinking roughly $200k, $230k, $260k. It's an order of magnitude estimate, take that for what it's worth. If the new grad is instead investing $300k, the calculus remains about the same.

<comment><USER13> I think it's fair to say that someone who can get that sort of job right out of college probably should. However, I'm not sure that the vast majority of engineers can do that.

<comment><USER28> When I started at Google my first three full years were $213k, $233k, $287k ([https://www.jefftk.com/money](https://www.jefftk.com/money)). Some of this was stock growth (which is not guaranteed and I was lucky there) but I think this sort of pay is reasonably typical for people who are considering a FAANG offer.

<comment><USER29> You didn't join straight out of school.

<comment><USER28> Whoops, thanks! I'd missed that!

I don't think that had a large effect on my compensation, if any: I joined at L3, which is what most new grads are hired at, and my salary before Google was low enough that I don't think it pushed up my offer at all. I also didn't get offers from multiple places, which is the sort of thing that (a) results in higher offers and (b) is the sort of thing new grads usually do.

But ideally someone hired right out of school would be up for sharing their comp?

<comment><USER30> Mind sharing what your rent was during those 3 years? The best figure would actually be comp minus taxes and rent.

edit: Oh, I see you were in Boston -- that's a great deal then. I still wouldn't want to work for Google for idealogical reasons, but I can see why the money would attract others. You also had ~9 YEARS of full time experience at that point, which makes it a lot less impressive.

<comment><USER28> I'm in Boston, and our rent was about $1100/month for a couple. Rents are higher now ([https://www.jefftk.com/p/boston-rents-over- time](https://www.jefftk.com/p/boston-rents-over-time)) and we have kids now.

Taxes would be higher but we donate 50% of our income ([https://www.jefftk.com/donations](https://www.jefftk.com/donations)) so I'm not sure how you'd count that?

Also, I didn't have ~9 years of full time work when I started at Google, I had 3.5. My first full time programming job started fall 2008, and this was Spring 2012.

<comment><USER30> If you were making 60k+ through your college "internships," I would put them at the same level as full-time work. My first college internship was $9/hour with no benefits, and it lasted 6 weeks...

Also, donations are discretionary, so you wouldn't count them at all -- you would just count your salary minus your tax rate (not counting deductions, so that the average Joe can get some context).

<comment><USER28> If you look back at [https://www.jefftk.com/money](https://www.jefftk.com/money) you'll see I wasn't earning more than $12/hr until my first programming job in fall 2008.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER31> You can be compensated in other ways, but often I've found much of the work at startups can be no more interesting than their Big N counterparts. It might not even be faster paced. Your career growth might also be similar. In theory, for startups, you sacrifice pay for other facets. The reality is quite different.

The work might be similar but you're paid 50-75% of your peers. That was my experience in startup land, at least. Few good challenges or career growth and half of what I felt like I was worth. Completely personal anecdote, but I felt I was sold some half truth, where I was promised career growth, interesting problems and flexibility, but got nothing that I couldn't have found at many Big N companies.

</comment><comment><USER32> > I think startups' best bet is to make the most of the variables they can > control outside of money and perks (if you lack the appropriate resources). > This means being transparent and honest with candidates about all risks > involved when joining a startup and factoring all this into the amount of > equity they offer which should be something considerable.

Even if the original founders have the best intentions, large equity up front is unlikely to give you a big payday.

Since, in the traditional VC model the drive is to move toward bigger rounds (A, B, C, etc) and investors get paid back first.

So even if you do start with 10%, you'll probably only end up with a low % percent after 3-4 rounds.

The important thing to note is that this whole thing bamboozles our brains because of unicorn survivor bias. We feel like unicorns and $100m dollar companies are the norm but nothing could be further from the truth.

The chance of being part of unicorn is about 0.006% last I checked. The chance of being part of a $100m+ company is in low single digits (of all startups).

If it ends up just making a few million revenue investors will drop it (because not 10x enough) and you're 2-3% will be worth very little.

If ends up stagnating at $5m for a few years investors will drop it (because not 10x enough).

The overwhelmingly most likely outcome of you getting a large chunk like 10% up front is, when all is said and done, after 5-7 years you'll walk away with a few hundred thousand (before tax) if you are lucky.

In my case I was on founding team. Started out with 10% equity. Co. is now 7 years old. After a merger (diluted by 40%), $10m investment (diluted more), $4m strategic investment (diluted more), then investors taking money off the table first for an exit event - I stand to make $100k if we sell at $20m and $600k if we sell at $40m (currently valued at $20mish and has been for 2 years). That's pre tax.

<comment><USER33> Ditto to that, and add that this can happen at a larger scale even if you happen to find yourself working for one of those lucky unicorns, where late- stage VC will swoop in, inflate the valuation, and dilute the hell out of everybody holding ordinary shares.

</comment></comment><comment><USER34> "To make the situation worse, the very good engineers, the ones who could truly help build a tech company from the ground up from day 1, were getting offers so exorbitant they could not possibly fathom to turn them down."

Ok I have seen this written every now and then.

What does this person look like and how do I become one given a willing to sacrifice everything else?

I can not find a good answer to this question. Everybody seems to have their own opinion.

<comment><USER35> First, be smart. Very very smart. And be able to demonstrate your smartness at the drop of a hat under stressful conditions.

Second, attend a top tier "name" university like MIT, Stanford or Carnegie Mellon and major in a related discipline.

Third, do some side work in your chosen field that can be shown off to prospective employers.

Fourth, learn how to present yourself well (for interviews and such).

That's generally speaking, of course. Exceptions exist.

<comment><USER36> Eh, I really don't think this is representative. I'm a self-taught iOS dev who has only ever been self-employed and I just got a $420k / job from a public company. And I'm smart, but not some unfathomable genius.

I think every engineer should at least do some mock interviews on data structures, algos, and system design (there are TONS) of free study resources and then do a round of interviews. You only need one yes.

<comment><USER37> Congrats dude! All salary or salary and equity?

<comment><USER36> $220k cash, $200k equity (or whatever it's worth in 12 months!)

<comment><USER38> where is this? also, how many years of experience?

<comment><USER36> Not going to disclose the company. Smaller public tech company. 10+ yoe.

<comment><USER38> right, wasn't looking for the company actually, by "where" I meant the location, which I think is NYC based on your handle! Congrats, that's a great gig!

<comment><USER36> Ah yes, NYC. Thanks! I seriously couldn't be more excited :)

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER39> I love how the article ranked right above this one is titled "Downsides to working at a tech giant".

<comment><USER40> LOL, I noticed as well.

As I was reading "Downsides to working at a tech giant" it occurred to me that the alternative to working for a tech giant is not necessarily a start-up: I would probably work for myself — freelance.

So, in fact the two articles can both be right. ;-)

<comment><USER41> You can also work in tech, for a company, but for something that is neither a giant nor a startup. There's plenty of such jobs out there. In fact, the majority of tech jobs probably fit that category

</comment></comment></comment><comment><USER42> > Equity agreements should not be intentionally confusing or designed to screw > over employees.

Totally agree with this. Unfortunately I think there might be about 5 startups left if this idea were widely implemented.

<comment><USER43> Your odds of making money are much better with a young-ish but publicly traded company than with a startup. Even if a startup is successful, you won't see much money unless you were one of the founders or early investors. There's a million ways the stock options that early employees get can be made worthless (or worth-little).

<comment><USER44> I have BEEN one of the founders, and still didn't make any money off the ultimate sale. There are far too many games with share classes, VC-funded bridge loans, and preferred investor incentives. The only way to win is to not play the game.

</comment></comment></comment><comment><USER45> There were a few recent Ask HNs on the subject:

[https://news.ycombinator.com/item?id=21709724](https://news.ycombinator.com/item?id=21709724)

[https://news.ycombinator.com/item?id=21641864](https://news.ycombinator.com/item?id=21641864)

[https://news.ycombinator.com/item?id=21645117](https://news.ycombinator.com/item?id=21645117)

a larger question is : why can't startups make money

<comment><USER46> For a lot of them that's just not the primary goal. Honestly, I expect the next big success stories to break from this pattern of the silicon valley sickness of trying to grow a company at all costs by conning VC firms until they've got enough users and then sell the company or get another round of funding to try and figure out the whole "revenue" thing later.

I think some old school thinking of more organic growth of a good idea with immediate revenue will see a resurgence.

</comment></comment><comment><USER47> It seems like start-ups _could_ catch up, at least somewhat, by offering more stock. Right now founders are still ending up with an order of magnitude or more stock than the first few employees.

There are certainly situations where that makes sense but if the founders are adding extreme value compared to the first few employees perhaps they should only end up with twice as much stock. That would free up a lot of equity for early employees.

<comment><USER48> > if the founders are adding extreme value compared to the first few employees > perhaps they should only end up with twice as much stock

Why would this be the case? If they're adding relatively extreme value, why should they only get 2x the equity?

</comment></comment><comment><USER49> I think another reason that people are wary of joining start ups, is they've realised that:

a) The market is now incredibly saturated, and being an early equity owner in a start up that will be worth billions is very rare now. Gone are the days of a unicorn every month or two.

b) People have noticed the trend of FAANG companies buying up start ups, and that this is the goal of many (most?) start ups today. Reach critical mass, get a good valuation and customer reviews, get bought out by tech giant. If you want to work on the most viable new products, just join a tech giant and work on one of the projects they've acquired. (Or wait till the company is bought and join them if they are still independantly run at which point they're not really a start up anymore)

<comment><USER50> > Gone are the days of a unicorn every month or two.

My friend, I've been building software professionally for big companies and small since 2001.

There were __never __days where there was a unicorn every month or two.

<comment><USER49> I didn't mean that a company became a unicorn every month or two, but it seemed that companies were founded quite frequently that later went on to become unicorns.

</comment></comment></comment><comment><USER51> The problem is getting paid in common stock. A pay cut is money that, instead of making, the employee is investing in the early-stage startup. That's no different than the money the investor is putting in.

Employees should get preferred stock in the amount of their pay cut.

</comment><comment><USER52> I think the questions/issues around this topic don't really make sense:

A. Why are we comparing an employee situation at a FAANG company with what should be a co-founder situation? If someone is an engineer that can make something happen at a startup, they should probably be a co-founder rather than an employee.

B. Why are tech center startups trying to hire coders of a certain skill level that will be incredibly expensive due to local competition? If a startup is looking for skilled coders to implement the vision of the co-founding engineers that can make things happen, then there are plenty of remote coders in non-tech-center areas that will do a bang up job for a reasonable price. Note that many of these remote coders don't want to or cannot come to a tech center. I assume that this is an issue because many/most startups are not good at hiring, on-boarding, managing people, managing remote workers, etc.

C. Related to issue B, why play the micro-equity game with coders at all when they should either be co-founders or they (as remote workers) can be paid a satisfactory wage without equity bait?

D. Why is this conversation comparing a job with (relatively speaking) a lot of hierarchy and politics at a FAANG with a job that should have a flat structure and a great deal of autonomy? These jobs cater to two different groups of people — the ones who like the former probably won't like the latter, and the opposite is true as well. There are subtle sides to this (e.g., do your time at a FAANG to develop a network), but many people who succeed at startups are not folks you want working at a large company — they will go nuts, and they will drive the people around them crazy.

This whole conversation is bizarre to me. I think there are three relatively simple choices:

1\. Take a company job if you're a company person — that is, someone who likes structure and hierarchy. It might not be trendy to admit it, but many/most elite school grads fall into this category.

2\. If you prefer things like autonomy, being close to the customer, and being a generalist, then go to a startup. Plan on leaving once it hits a certain size.

3\. If you have a plan for an alternate path that includes both, then go for it — specialist work at FAANG, FAANG then startup founder, startup employee then startup founder, etc. Just know what you're getting into, because it can be awfully tough to walk away from $300k annual comp as a 25 yo.

Most people I've known clearly fall into one of these categories barring some sort of life-changing event.

</comment><comment><USER25> My career path has been startup, public tech, startup, public tech, startup.

I got lucky that the public techs both had the largest stock growth in their history while I worked there.

All the money I ever made was at the public companies. I also learned a lot of cool, very specialized skills and got to do a lot of "ohhh so cool" type stuff.

Almost all of the knowledge I learned that allowed me to be successful at the big companies I learned at the startups, and most of the friends I made at work that I still talk to were at startups.

Both environments offer something unique.

I usually tell young people to start at a big company with a well known mentorship program and then quickly move to a startup to learn a bunch of practical skills.

But YMMV.

</comment><comment><USER53> I have a very straightforward suggestion for startups: Focus on the engineers who've put in a decade or more at the big companies.

They are, given the exorbitant salaries, financially set enough to afford the startup risk, and there's a good chance they'd like to see some more agility again.

But 1) you'll need to stop lowballing equity for hires, and 2) you need to get used to the idea that it's not going to be an extension of university life - these people have all better things in their spare time than playing beer pong.

Bonus points: Offer an office instead of cubicle mania. Bonus bonus points: Make sure you hire a diverse workforce from the get-go.

</comment><comment><USER54> I've worked at 3 big tech companies and 3 startups. 2 got bought out, the other is going strong. I made more money off 1 year of bonus at Google than I did with any of the successful startups. It's not because I did anything wrong (I was Eng #1 at one, First iOS Lead at another and Lead for the 3rd) It's because I was building someone else's vision for the promise that that my stock will be worth something. When a company gets bought even if you have a high % when it gets funding, it will be diluted. If the company doesn't do refreshers often enough you will be working long hours for close to free. The charming CEOs will talk about how they plan to change the world, the sleazy ones will tell you they are a sure thing (and what will you do with your millions). That makes no difference, it's just a lottery ticket. You have to decide how much of your career to put on that ticket.

Startups are a wild ride, and a thrill to join, you'll learn a lot, and have a great chance of coming out learning more than you'd learn as a entry level at a big company. Don't for a second think you have the winning lottery ticket, because if your number doesn't come up you'll left with memories and the paper it wasn't written on.

PS I'd argue if you have a group / team, build your own vision. Go big, we have enough insta-wecha-snapple sauce out there. Build something that will have real impact. And if you don't have the Team / Vision / Risk tolerance go somewhere they'll pay you what you are worth. Maybe you'll be even meet some of those you want to build a team for whats next.

</comment><comment><USER55> Maybe startups should try cities like Pittsburgh, Columbus, Atlanta, Knoxville, etc. Lots of talent that will work for less for the simple reason that the cost of living is not so stupidly high. Hell even SoCal, Portland, Austin, and Chicago are bargains compared to NYC or worse SF.

Problem is that all the capital is in NYC and SF, and they still prefer to invest locally. At this point VCs should just skip the middle man and cut checks directly to landlords and property speculators.

</comment><comment><USER56> Isn't this also a function of the limited runway VC's give to startups. If they 10x'd the amount of funding for seed and series A, startups could afford to hire the best.

It would add a lot more risk, but given the outsized rewards, it would still be profitable for some VC's.

Otherwise, there will be lots of ideas left un-persued because many experienced engineers will not want themselves or their employees to live (in relative terms) an ascetic lifestyle while perusing their dream.

</comment><comment><USER57> It's VCs' and founders' fault for always diluting employees on the big exits. If they want to gain back trust we need iron-clad poison-pill provisions that prevent employees from getting screwed out of their equity.

</comment><comment><USER58> I work at a startup and have for 2 years since graduating college. Its quite hard to gauge my true value. I know that for the area (according to Stackoverflow's salary numbers) it seems competitive, but big N companies are moving in to Culver City which may be changing that.

Since starting, I've seen engineers who can't hack it leave or get fired. I've been the one engineer who has been productive and seen our projects to completion. Our team has gotten stronger over the past 2 years however and I feel that we are in a good position. In this way, I feel that I am valuable, but I have nothing to compare myself to.

Working at a startup I've also learned an extremely broad area of knowledge, much of this completely on my own. I'm often worried that that may hurt me if I apply at a larger company and that hiring managers would question my fit.

</comment><comment><USER59> It's worth mentioning that this post is focused on USA and (unsurprisingly) highlights Bay Area.

I'm sure the points exposed apply there but there are many other places in the USA and the rest of the world where this doesn't apply and you can find good talent without needing to offer an exorbitant paycheck.

</comment><comment><USER60> How about you just start giving your first engineers a bit more equity?

</comment><comment><USER61> Well said. Startups can't really compete with MGAFA those days. Not the people, not the resources. For domain like ML, it is hard to imagine what you can realistically achieve outside of working in those companies.

</comment><comment><USER62> A few years ago I decided to start working for a startup because I wanted to try out the experience. It was a late-stage startup with no VC money and they had good prospects for a possible acquisition.

I did the math and I figured that it might work out for me. 2 years later it turned out that they have been talking about a possible acquisition for the last 3 years, but nothing happened. I also checked the company's public information and it turned out that they weren't that transparent about the shares. I was told that I get 0.5% worth of shares (they refused to tell me the total amount of shares) and what I saw is that it was true: I had 0.5% of the _outstanding shares_. But in case of an acquisition, they are free to dilute them 5-fold because the authorized shares are 5 times as much as the outstanding ones.

So I decided to join a big company which is paying almost 2 times more right off the bat and I also get additional shares each year. I made a calculation and even if the old company gets acquired I get less money (it is just a rough estimation) than I get at the new company. And that's still a big _if_. I think that I still started from a much better situation than most of the other folks working for startups. This company produces profit, they have a business model I believe in and there is no VC to please. Most of the startups are in a much worse situation.

I will never work for a startup again.

</comment><comment><USER63> Captable slots for early employees range anywhere from 5 to 40% (collectively, not individually), depending on who the partners are and what the company does it might make sense to join a start-up. But it's better to be a founder and if you are risk averse then it is better to work for a big company with long term viability.

This definitely isn't one size fits all and there are a lot of people that will happily try to sell you on their version of the story because 'it worked for them'.

</comment><comment><USER64> It's fun to watch the Bay losing its startup spirit and becoming a land of mega corporates. It might resemble Atlanta in 20-30 years. There are so many other places where joining a startup is the best option you have (excluding remote gigs). I guess most startups will become remote-first and lure people who care either about the team or the problem being solved. Building a startup employer brand will be of paramount importance.

<comment><USER65> > It might resemble Atlanta in 20-30 years.

Or it might indicate a lower probability of creating another company that produces FAANGM levels of cash flow.

</comment></comment><comment><USER66> Use your brain, when offered a role, do you like the product ?

Do you believe in it ?

Are they paying you a nice amount of money ?

If you can only answer 1/3 please continue to the purgatory state.

</comment><comment><USER67> I like this piece and I agree that startups can be great. But the first half of the essay, the hook of the essay, was contingent upon the author declining a $70k check from Thiel and noting that he walked away from $200 million; and the end of the essay suggested that one shouldn't work at a startup for the money (and you really shouldn't, it's unlikely it'll make you much).

</comment><comment><USER68> Agreed, if you're living in SF or NYC I don't see the point in working at a startup unless you're just really passionate/optimistic about the work/company or are getting some other perks you wouldn't get at a FAANG.

Personally I work for startups, but only because they let me work remotely, something I wouldn't be able to do at any FAANG. I would only go back to an office job to work at a FAANG, since compared to a startup the money, "exit ops", work life balance, and job security are probably going to be way better.

If startups want to be more competitive and have access to more talent, then they'd be wise to open to hiring remote workers. Otherwise they're going to struggle to compete with FAANG type companies. Remote is the one perk that FAANG companies don't offer, and unfortunately probably won't for the foreseeable future short of some serious cultural change.

</comment><comment><USER69> If the cost of housing was substantially lower, perhaps these great engineers would work for startups that could really use their talent, as they might not care as much to being millionaires so they can afford what's considered a middle class home for their family in most other places besides SF/Bay Area.

</comment><comment><USER70> It seems to me that most companies start to gain a tedious/conventional/corporate atmosphere once they get to more than, I don't know exactly, somewhere in 100-400 employees. At that point the company has acquired, in addition to those who care purely about building companies and building software and building hardware and physical processes, a middle layer of conventional auxiliary staff, and nice though everybody may be, the company just becomes a standard corporate office environment. Many people (especially those who have enjoyed academic environments) strongly don't like such atmospheres, and for those many people this is a pretty strong incentive to work at small companies.

</comment><comment><USER71> > _And, to be clear, I'm not saying that one should or should not place money > or perks above everything_

Why not?

The whole premise of venture _capitalism_ is that money is an appropriate common denominator for what is valuable in the world, that the best way to change the world is through establishing a legal entity whose goal is to make money, that once you have lots of money the best thing you can do is to put that money to further use instead of directly engaging your own technical skills.

Why do we tell potential employees at startups "money isn't everything" but potential founders "you'll make more money this way" and potential funders "please, sir, some money"?

The startup ecosystem is a way for venture capitalists to get richer, and to incentivize the people who can directly help them get richer. Evidently it's not enough - so maybe they should incentivize the people who help them indirectly get richer. If money isn't everything, don't join a startup _or_ a big company, go to grad school, where you can actually work on whatever you want. Or go work for a big company for several years and retire, or find a half-time consulting gig, or something.

</comment><comment><USER72> I have worked at 3 startups for 3 years of my career. At one, I was a founder and seed-venture investor; that one lasted 8 years. It was the only company NOT run by criminals. Total out-of-pocket costs to me (in 2019 dollars) : $45,000 in 2 startups for shares and for options. Total return : $0. Total discount to market salary that I worked for : 33%. In 2 out of 3 startups, the CEOs (1) stole all the money and fled the country, or (2) conned the VCs out of $2.5m and shut down the business the next day after the final funding round (all monies went directly into CEO bank accounts.) Ask me what I think about startups .... Fuck startups.

</comment><comment><USER73> I agree that the game is clearly rigged in favor of corporations at this stage.

If money is what you're after then joining a big company is by far the most rational choice. Eventually, big tech companies will realize this and start significantly lowering wages until new engineers are paid the same as blue collar workers.

The reality is that new startups do not disrupt corporations; they feed them.

The only way I can see to end corporate dominance is with blockchain tech because it can disrupt the incentive structures that feed corporarions. The new generation of developers can build a new financial system using cryptocurrency as the decentralized foundation in which to store value.

</comment><comment><USER74> While I understand your sentiment, there is a 2015 Dan Luu article which goes into far more depth saying basically the same thing: [https://danluu.com/startup-tradeoffs/](https://danluu.com/startup-tradeoffs/)

I can see you just started writing on this blog so I don't want to discourage you, but I was struck by the formatting of your notes page and this post being so similar to Dan's along with the topic and content of this post. Keep writing but I would maybe suggest something with more of an original spin.

<comment><USER75> I've always thought this problem to be overstated. It doesn't make financial sense to work for a startup, but the upside is that you get to work on something you care about (and even the startup salaries aren't that bad in the grand scheme).

<comment><USER76> > the upside is that you get to work on something you care about

As a counter example, I found this is far more true at big companies, where you can switch teams until you find one that fits your interest, then at a startup where you are expected to work on basic infra that the company doesn't handle. For the data/ML related jobs that I was looking for and the industry is moving towards, big companies have tons of valuable data that startups could only dream of acquiring.

<comment><USER75> I like the Elad Gil take on this issue: at big companies, you can have more /impact/, for the reasons you state.

At small companies, you have more control. That's in the high-growth handbook. :)

</comment></comment></comment></comment><comment><USER77> A few things developers are waking up to...

burnout, working evenings and weekends, a life outside of code, having children or families, master in a specific field vs jack of all trades (master of none), money is more important than free snacks, working your butt off to watch all the credit go to the founders (as well as the money), long term stability, benefits and retirement is much less risky than hoping for an equity payout

I feel the startup founders should enjoy reaping what they have sown.

</comment><comment> Bella-Xiang I really agree with your opinion, especially the words in the last paragraph. I am working in a startup now for half a year, in which all the rules you mentioned is done well, so as a fresh graduate, I never regret working for a startup. There, I have learned a lot of different skills that definitely will be my great treasures in the future. So, for the fresh graduates, I think working for a startup makes great sense that helps them find their true value.

</comment><comment><USER78> i'd say if a start-up is hiring outside of founders / stock offerings then they are no longer a startup and should offer somewhat realistic wages. before that time, people accept to get paid less with prospect of their stock options exploding and that compensating for the lack of initial wages.

that being said, if a person wants to work at a startup, i'd say they already accept that the wage will be much lower than at some big corporate or company who is making good income already. it seems a bit if not a lot silly to me that someone would join a startup in the early phases but then demand a corporate salary. startups are kind of a popular term, but think about it... people used to actually build stuff and then get funded / success, instead of wanting funding upfront without any actual effort put in (thats exaggerating i know). A lot of startups these days though really ask for ALOT of money from investors without having even an MVP or viable product yet. I can't see why someone would pay for just an idea ... it seems a lazy way to make a startup. Building something, prove it works, and investors will have no issue to invest?

</comment><comment><USER56> > The two things I really like about working for smaller places or starting a > company is you get very direct access to users and customers and their > problems

I don't understand this at all. Big companies have lots of individual projects, where engineers get direct access to customers. At my big co, we all watch every App Store review come in, conduct thousands of interviews with customers and have a direct say on what gets built.

</comment><comment><USER79> YC has been saying that for a while, but great & early employee need way more equity; they're the one who change the game.

</comment><comment><USER80> Better solution is to make do with as little staff as possible. Lower headcount makes management overhead and friction inefficiencies lower and saves you money big time. And this is something big companies can't replicate. This is how a startup was supposed to be: do one thing and do it perfectly, with as few people as possible.

</comment><comment><USER81> Sounds like wealth inequality doesn't just affect private individuals- it's affecting corporations themselves!

</comment><comment><USER82> The blog post echoes sentiments in TechLead's video last month about the same topic: [https://www.youtube.com/watch?v=Btbvv9kfLqo](https://www.youtube.com/watch?v=Btbvv9kfLqo) "Software Engineer Salaries in 2020. How much do programmers make?"

</comment><comment><USER83> Working for a startup makes sense if you think it has good odds of making it, and you are in for a share of it.

<comment><USER84> Also - outside of the bay (I live in Chicago) you actually make more money working for a startup (at least I do) than for a larger company (as a senior engineer with a lot of early stage experience). I think it might be the nature of the market here.

</comment></comment><comment><USER85> My main question is how do you attract developers to join your open source project? Wordpress and RoR and all those other projects?

Instead of startups I want to attract people to a project to change the world just like the OP is saying. But where to find the first few developers who would do it not for the money?

</comment><comment><USER86> I work for startups because generally there's not useless word docs and red tape. You can have a fully reproducible engineering cycle without all the nasty forms.

I can't find the link but a while ago hacker news how to link to an article about useless jobs at large companies. Reminds me a lot of this.

</comment><comment><USER87> The consensus on HN is pretty clearly towards being a founder or working at Bigtech Co vs being an employee at a startup.

So, if you're a founder, how do you tip the equation to make working at your startup attractive to talent who presumably also read HN?

What would make you interested in joining a startup as an employee?

</comment><comment><USER88> Frequently in the UK I'm seeing options that are clawed back if you leave the company at any point. EMI options that can only be exercised under certain conditions such as an exit.

</comment><comment><USER89> Actually, my observation over the last 20 years of being a venture investor, bigco acquirer and startup CEO (including at a unicorn) is that the risk- adjusted $ compensation is the same at a startup and at bigco. Startups just have more beta in the comp. You learn a _lot_ more at a startup and hence it's the experience you want if you hope to do your own startup. If you just care about short-term $ then absolutely stay at bigco. If you want experiences unavailable at bigcos and are willing to take the chance of making less, but also the chance of making 10X+ more, do startups.

<comment><USER36> Show your work, because I flat out do not believe you. Just the fact that you were investing in these startups, acquiring them, and working as a CEO at a unicorn indicates that you have a vastly skewed perception of the typical startup.

</comment></comment><comment><USER90> Just hire abroad. Working in a completely remote environment is entirely feasible, and it's actually in many, many ways, more comfortable and productive.

</comment><comment><USER91> A solution could be to let engineers work for multiple companies at once and laws to prevent employers from penalizing such behaviour.

</comment><comment><USER92> Awesome post! Also this is where nailing PMF is so Important too before hiring

</comment><comment><USER93> Many new startups (with massive VC backing), aren't really startups

</comment><comment><USER36> Strongly agree with this. I just did about seven weeks of interviewing in NYC for senior iOS roles, at both startups and big tech companies.

To be frank, it was a total shitshow. Especially on the startup side.

Here's some of the bullshit I faced interviewing at early stage companies before accepting an offer literally 2.5x as high as the (multiple) offers that startups made.

1\. Shitty equity: one startup wanted me to be engineer #7 and completely own the mobile app and strategy, which is the single point of interaction for their customers. They offered me 0.1% and spun some story about how much it would be worth when they were worth $800mm. Their last valuation was about $35mm. Even if their numbers were real, I'd still make more at a big tech company in equity alone. They also made it clear they wouldn't budge.

2\. Bad work/life balance: the big tech company where I accepted apparently has no issue with people taking off whatever time they need (avg is about 25 days per year), working normal 40 hour weeks, and working from home if needed. By contrast, the startups felt way more restrictive here.

3\. Terrible interview process: almost all these startups had pretty disorganized process. Worse: they did the standard whiteboard algorithms interviews, whereas multiple bigger tech companies had more iOS-specific interview loops. Even worse, the startups tended to have a _higher_ bar for hiring than the bigger tech companies. This one is subjective and could be random or misperception on my part too.

4\. Most infuriating of all, all of these startups (except coinbase) had a 60-90 day option exercise window for employees who left before a liquidity window. Let me be clear: fuck you if you think this is fair. IPO might be 7-10 years out and if I stay and add value for anything short of that, you're going to ask me to take a huge risk to exercise my options (and pay the taxes) on your probably worthless stock, otherwise you'll just keep it? Fuck you.

The entire thing left a bad taste in my mouth. It's pretty clear that these founders and investors don't give much of a fuck about their talent, and watching them get squeezed by big tech companies offering sky high comp fills me with glee.

Be a founder, investor, or big co employee. Fuck being an employee for a startup so they can bleed you dry.

<comment><USER94> From your post, it sounds like you value:

1) Safety and predictability in compensation

2) Ownership over your company's strategy (e.g. mobile) only if you're paid highly for doing it (not a bad thing, but many other people exist who would willingly take a pay cut for the ability to have an actual impact on company strategy)

3) A highly organized and logical hiring process and qualification evaluation

4) Custom negotiated options contract outside of industry norms OR BigCo stock that has value today

5) 5 weeks of paid vacation

It definitely sounds like you made the correct decision by choosing BigCo over startup.

<comment><USER95> I think the point is more that startups are really overestimating what they're offering, or hoping their employees are too stupid to realize the disparity. So far as I can tell the only thing most startups offer anymore is ownership, lack of large company culture/bureaucracy, and more opportunities to switch roles.

Equity is basically always monopoly, you generally can't even evaluate its value because no one will show you the cap table. _Highly_ profitable startups still regularly manage to deliver a pittance to early employees on exit. Even if the exit _does_ deliver oftentimes the yearly compensations disparity is so large that if they'd just stayed at BigCo and invested the bulk of their earnings they would have earned as much or more. This is all while working _significantly_ more hours per year.

The list of upsides is _really_ small relative to the risk. If startups want talent the industry norms are going to have to change.

<comment><USER96> I've always thought that the shitty startup practices when it comes to equity is due to insufficient competition for talent. Looks like this is about to change, since startups now obviously struggle to get the best people.

Not showing the relevant details of the cap table is _ridiculous_ , companies that do this are banking on a pool of candidates that are either morons or don't care what they're paid.

Imagine the following situation: You're in a foreign market, and a vendor tries to sell you a fancy-looking machine. You know he's legally bound not to lie, so you ask what the machine is worth. He says "it's worth 2 billion Magic Moneys!!" but refuses to give you any information that would help you suss out whether that's 20 cents or 20 million dollars.

</comment></comment></comment></comment><comment><USER97> I feel like it is hard for people to say what they truly love before they have at least $1M in their bank account. If you have FU money, your view on working at a FAANG vs building a startup can change. You will find it easier to know what you truly LOVE.

<comment><USER98> I'm glad all the great artists, musicians, writers, theorists, scientists, teachers, and inventors throughout history didn't read this post.

<comment><USER99> A remarkably large number of the most notable of those people came from wealthy families - that's what allowed them the single-minded focus, instead of worrying about food and healthcare.

<comment><USER100> And a lot of them suffered in poverty to pursue what they loved. Is there survivorship bias there? Sure. You don't become great without taking some chances though.

</comment></comment></comment></comment><comment><USER101> Dunning and Kruger explained how people drastically overestimate their value. The author won't be earning what he thinks he deserves, isn't working on projects he thinks he deserves, and doesn't get the promotions he thinks he deserves wherever he goes. His reality may never change for him and that's his cross to carry.</comment>


Design and Build Your Next Home in Minecraft - <AUTHOR> http://luisquintanilla.herokuapp.com/2017/12/15/build-your-house-minecraft/ <comment><USER2> It feels like this article just kinda left off the end.</comment>


SeaweedFS – A simple and highly scalable distributed file system - <AUTHOR> https://github.com/chrislusf/seaweedfs <comment><USER2> I am Chris the author. btw: This is not a new project. It has been around since 2011. Many people tested it and contributed on it. It may not be the tool for everyone. But I guess many companies will need a key~file store.

There is also a "Filer" component.

This is a side project. Welcome any VC to invest in this.

</comment><comment><USER3> I was wondering why so many distributed file systems - all claiming high performance / availability / scalability - are being implemented from scratch, when mature ones like Gluster and Ceph have been around from years. Why start new ones instead of improving existing ones? My guess is that these new infra software like SeaweedFS and LeoFS are created mainly to implement them in new languages like Go, Rust and Erlang. I'm not saying it's a bad thing, just that it's one possible reason so many alternatives are being implemented from scratch.

<comment><USER4> I'm reading between the lines here, and I'd love for Chris Lu (the SeaweedFS author) to chime in here and correct me, but it _seems_ like Chris read Facebook's Haystack paper and decided to implement it himself in Go. Kind of how Riak started as "let's take the DynamoDB paper and implement it in Erlang."

The README mentions that Seaweed is much easier to set up than Ceph. The more apt comparison would be the RADOS component of Ceph--both Seaweed and RADOS are key/value oriented. I've now set up both, and for sure Seaweed is easier to get going.

I have a fair bit of experience with RADOS (all quite positive) but I really do appreciate the ease of use Seaweed presents. I've only been using it for an hour or so, just doing benchmarks and walking through fault scenarios, and so far Seaweed looks quite good!

FWIW, I don't think this should be called a filesystem at all. Seaweed isn't a filesystem which forsakes some aspects of POSIX, it's nothing like a filesystem. The more proper term would be "distributed object store."

<comment><USER5> You are correct, it is not really a file system. It is used with the HTTP API (upload, download, etc.).

</comment></comment></comment><comment><USER5> I've been using SeaweedFS (previously WeedFS) in production for a couple of years. I needed to share files on a LAN, including small VPS, so distributed file systems(like GlusterFS) that require a kernel module did not work for me.

I store small files. Random access with WeedFS is very constant and fast. If you use multiple volume servers, the ID is unique across all servers. You get redirected to the right volume if you try to access an ID on the wrong server, which does add latency.

My biggest complain is about replication. You can define rules, like replicate on the same rack or different rack, how many copies, etc. But it SeaweedFS fails to replicate a file, it does not store it at all. I would prefer a best- effort duplication rather than a guarantee. This is a big issue when master synchronization fails for some reason and only 1 volume is "visible" for some period of time.

<comment><USER4> Can you tell us more about your production environment? Like how much data, average IOPS, and uptime requirements? I've been poking around and I can't find any real info on who's using this or how. The project's interesting and I'd love to hear more.

<comment><USER5> I use it to store many small files (JSON and images). My requirements were:

1\. predictable read time 2\. read/write access through LAN 3\. server easily installable on VPS 4\. simple API

The main downsides I found so far:

1\. Master splitting are very hard to recover from. They happen rarely but when it does, be ready to restart master many times in random order. Latest version seems to have fixed it 2\. No easy way to list the content of a volume. You need to use the command line on the volume files 3\. Cleanup is hard (compacting the volume files), I fee that the GarbageThreshold is not working well 4\. Hard to resize the volumes (i.e. set lower limits) after it has been started 5\. Replication, as I mentionned in another comment

Overall it works fine for me. The potential alternative (not fully tested) was Cassandar (the 64MB limit per object when I checked is fine with me).

</comment></comment></comment><comment><USER6> Call me skeptical:

>When testing read performance on SeaweedFS, it basically becomes performance test your hard drive's random read speed. Hard Drive usually get 100MB/s~200MB/s.

There are no modern hard drives that get 100-200MB/sec on _RANDOM_ reads. Random ends up being an exercise in IOPS not throughput, and there's absolutely no way you're pulling enough IOPS out of a SAS or SATA hard drive to get anywhere NEAR 100-200MB/sec on random workloads. I get the "it's the software dummy" thing everyone is so hyped about, but if you know _THAT_ little about the underlying hardware and how it functions, you shouldn't be writing filesystems.

Also - what's the protection mechanism for files? If there is none, I literally have no idea what the purpose of this FS is. Under what circumstances would I need a giant slow data storage tier that has no redundancy to speak of?

<comment><USER2> Sorry for my wording, if it is misleading. I am only saying the SeaweedFS code does not try to do anything unnecessary, so you can extract most of the performance juice out of your hard drive or SSD.

</comment></comment><comment><USER7> Distributed KV blob database seems more apt. I don't see anything here resembling a filesystem.

</comment><comment><USER8> How does this compare with the already popular distributed file systems IPFS?

<comment><USER9> This isn't truly distributed in that sense:

        "Instead of managing chunks, SeaweedFS manages data
        volumes in the master server. Each data volume is size
        32GB, and can hold a lot of files. And each storage node
        can have many data volumes. So the master node only needs
        to store the metadata about the volumes, which is fairly
        small amount of data and is generally stable."

<comment><USER10> So there's no replication?

<comment><USER2> There is. I am not following your reasoning.

<comment><USER9> i think he's asking if there's replication for the data stored on the master in case the master goes down, i.e. can there be multiple masters?

<comment><USER5> You can (should) have multiple masters. But each volume has a primary master. I did see other masters loose the volume state information after the primary master has gone down and been taken out of the cluster.

<comment><USER2> Good observation. I will make the recovery much faster with gRPC calls, which can detect broken network much faster than http heartbeats.

</comment></comment></comment></comment></comment></comment></comment><comment><USER11> Seems to gloss over the details. Who is grooming the replication in case a volume replica disappears? What happens when a client is writing a replicated file and crashes in the middle?

<comment><USER2> If one volume replica disappears, the whole set of volume will become read- only. There are no magic to auto correct things, which I personally think is where problems start.

If the client crashes, the writes would fail.

</comment></comment><comment><USER12> Can you compare it to MogileFS, which seems very similar in design assumptions? (Also, Mogile has been around for > 10 years!)

<comment><USER5> I've just looked at it. The concept seem to be the same. SeaweedFS is much simpler. You have only 2 services: master and volume, both speak HTTP only. MogileFS seems to offer more control and more tools (rebalancing, for example).</comment></comment>


DNA GPS Maps Where Your Ancestors Lived - <AUTHOR> http://www.iflscience.com/health-and-medicine/dna-gps-maps-where-your-ancestors-lived

<comment><USER2> I was this close signing up to _prosapiagenetics.com_ and providing them my 23andMe data. But after seeing

# too many typos,

# a weird terms of use clause (" _Licensor charges fees for use of the Software under this Agreement._ ", without stating how high these fees are),

# and further small nits such as a Facebook page going to nowhere and non- working links for TOU and privacy policy on the landing page,

I don't feel comfortable to provide them with personal genetics data.</comment>


Sensible Software Engineering - <AUTHOR> https://www.scriptcrafty.com/2019/02/sensible-software-engineering/ <comment><USER2> > Bugs are correlated with lines of code and TDD forces writing more code so > how can it reduce bug counts? If the test code has no bugs then just write > the rest of the code in the same style

Nobody has pointed out the fault in this reasoning yet, so I will.

The linear relationship lines-of-code vs. total-bug-count is based on independence of bug introduction in different parts of the code. That is, introducing a bug in line 10000 is more-or-less independent of adding line 20000. For product code that is arguably the case, but adding test code into the mix, this basic assumption doesn't just not hold, but it's turned upside down.

Test code is not customer-visible, but only dev-visible, with the sole purpose of finding bugs. Thus, adding test code to a code base _decreases_ the average probability of a bug for lines of product code. More formally, if you have N lines of product code and thus c * N bugs for some fraction c, then adding M lines of test code does _not_ increase the number of customer-visible bugs to c * (N + M). Instead, it reduces that number to c' * N with c'<c and the difference being caused by your test coverage. (A 100% test coverage, i.e., an exhaustive test without bugs or, equivalently, a formal verification, would bring c' to 0.) Sure, the M lines of test code may well have bugs on their own, but that only increases c' slightly while keeping it below c, and more importantly, those test bugs are not customer-visible. They only annoy developers.

I agree with the rest of the post though.

<comment><USER3> Agree. Consider the situation of data entry professionals, those people who transcribe audio recordings or enter data into databases.

If you have one person entering data into a computer, then the odds of them introducing an error and failing to spot it are fairly high.

If you have twice as many people entering twice as much data data, then the odds of an error getting introduced are roughly doubled.

However, if you have those two people entering _the same_ data, then their mistakes cancel each other out. If person A and person B both entered the same thing, it's extremely unlikely that it's incorrect. If they differ though, the a problem has been identified, and can now be fixed.

The odds of both of those people entering the same piece of data incorrectly is tiny. Likewise, _accidentally_ introducing a bug into both the production code _and_ the test is pretty unlikely.

That said though, if those two theoretical data entry people above are given the wrong data to enter, then they the system cannot protect them. They will both correctly enter incorrect data. "Garbage in, garbage out".

Likewise, if the requirements of a piece of software are poorly understood, then it is quite likely that both the test and the production code will implement the same "bug". Writing tests won't fix a failure to understand the problem you're trying to solve. And they're not supposed to.

<comment><USER4> > The odds of both of those people entering the same piece of data incorrectly > is tiny.

This is just not correct. There may be a systematic reason why they are making a mistake (e.g. a miss-pronounced word) in which case increasing the confidence intervals does not increase the accuracy. Check out the concepts of accuracy, precision etc from physical sciences.

</comment></comment></comment><comment><USER5> _> Bugs are correlated with lines of code and TDD forces writing more code so how can it reduce bug counts? If the test code has no bugs then just write the rest of the code in the same style_

I'm not advocating for TDD (the programmer methodology in the IDE) but the author's explanation about "test code" isn't correct. Code written for explicit purposes of a _test_ to exercise other code has been shown to increase correctness. E.g. SQLite database has 711x more test code than the core engine code.[1] (I made a previous comment why this is possible: [https://news.ycombinator.com/item?id=15593121](https://news.ycombinator.com/item?id=15593121))

Low-level infrastructure code like database engines, string manipulation libraries, crypto libraries, math libraries, network protocol routines, etc can benefit from a suite of regression tests.

It's the high-level stuff like GUIs in webpages being tested with Selenium or LoadRunner that has conflicting business value because altering one pixel can have a cascading effect of breaking a bunch of fragile UI test scripts.

[1] [https://www.sqlite.org/testing.html](https://www.sqlite.org/testing.html)

<comment><USER6> The question that always comes to mind whenever testing is discussed is "how do you know the test code is itself free of bugs?"

I distinctively remember once posing that question in a meeting about testing, and a manager replying --- seriously --- with "then perhaps the test code should itself have tests." Someone else must've come up with that before too, because (at a different job) I've also worked on a codebase where a surprising number of tests were basically testing the function of another test.

<comment><USER7> You don't know that the test code is free of bugs. You don't need to.

Case 0: No bugs in the test code. All is well.

Case 1: Bug in the test code that causes some bugs in the real code not to get caught. That's bad, but you're no worse off than if you didn't have the test at all.

Case 2: Bug in the test code that causes _correct_ real code to look buggy. Result: the test fails, you look for problems, most likely you find that the problem is in the test code and fix it. Going forward, you have a working test.

Case 3: Bug in the test code that makes something _else_ break. This can happen and is genuinely bad, but (1) it only affects testing, not your actual product, and (2) most bugs don't behave that way.

The test code is a net win if the bugs it catches in your real code are worth the effort of writing and debugging the test code. That's no less true on account of the possibility of bugs in the test code. It just means that when you estimate the benefit you have to be aware that sometimes the tests might be less effective because of bugs, and when you estimate the cost you have to be aware that you have to debug the code, not just write it the first time. And then you just ... decide what's the best tradeoff, just like everything else in engineering.

(And no, you don't need tests for your test code. The test code is a test for itself as well as for the code it's testing.)

<comment><USER8> I see 5 cases:

        Code  | Test  | Result
        </comment></comment></comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment>--
        fine  | fine  | a) We have a regression test, yay!
        fine  | buggy | b) Someone breaks the code to make
                           the test work. Oops.
                        c) Someone fixes the test, we have
                           a regression test, yay!
        buggy | fine  | d) We'll fix the code, and we have
                           a regression test, yay!
        buggy | buggy | e) Bug remains in code. Oops.

If the probability of introducing an error is p,

        Code  | Test  | Probabilities      | p = .01 (one in ten)
        </comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment>--
        fine  | fine  | a) (1-p) * (1-p)   | .9801
        fine  | buggy | b) (1-p) * p * .5  | .00495
                        c) (1-p) * p * .5  | .00495
        buggy | fine  | d) p * (1-p)       | .0099
        buggy | buggy | e) p * p           | .0001

So we see, probability for:

        no harm done                 .9801  (a)
        bugs found + fixed           .01485 (c,d)
        bugs introduced / not found  .00505 (b,e)

The above completely ignores the fact, that depending on the code base there will be significantly more test code than production code. But then test code is quite often highly redundant, and might actually have a lower defect rate itself.

Also the probability on introducing an error in the production code and the test code, might actually not be statistically independent, which I assumes here. So take with a grain of salt.

[Edit] Actually d) could also end negatively. Guess a working model would have to take into account that on failing test cases, a sensible developer should take a step back and reason about why this happened. So the negative outcomes would be (hopefully) less likely than the positive ones here.

<comment><USER9> Top notch explanation here. P = 0.01 is 1 in 100 though right?

<comment><USER8> Oops, yes.

</comment></comment></comment><comment><USER10> >So here's the punchline: if you want to be a good programmer then learn a technology and language agnostic formalism. Logic, statistics, and game theory are probably good bets.

I think in an abstract sense control theory is a reasonably good bet.

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

I can't say I know it deeply, but a lot of the ideas resonate when I think about software engineering. If you think of everything as basically an n-dimensional vehicle with an interface to control it and the control mechanism is used to set all the parameters relevant to the system then a few things follow:

      every system has a safe operating envelope
      parameters are usually linked to eachother such that turning one up turns another down

I find there is a lot of mileage to be had about thinking about which parameters are linked to eachother and when you get excited about turning one of them up (ie you bring in TDD or a Kubernetes type solution) what is the effect you are having on the other parameters? That's where a new source of pain is going to come from. The biggest mistake I see in reasoning about these kind of things is being blind to the negative side of the trade-off due to the overwhelming excitement of finally being able to jump on the bandwagon and join the cargo cult. You have to train yourself to hunt for the parameter that is being affected indirectly as that's the most important side of the trade- off. You need to reason about whether or not the indirectly affected parameter's new value would take you outside of the safe operating envelope.

With every decision we make about systems we build and run we are essentially trying to steer them, albeit clumsily, in this manner.

<comment><USER11> good recommendation, if the author understood control theory he'd understand that code that feedbacks on code is quite different than code with no feedback loop.

while I find it hard to find anything I'd recommend about the authors article as most of the reasoning seems a little off, I can understand the sentiment of the article .

Agile and TDD are really recognition of control theories ideas of feedback loops keep things in better control and can adapt faster vs long feedback loops going out of control far easier. This is more targeted at the human side of creating software. Nothing to say there aren't better strategies than TDD and Agile techniques, however I think that principle of feedback loops to give confidence will stay in some form. I think there is a LOT more to be said about engineering / designing correct, robust, and secure software.

<comment><USER10> >This is more targeted at the human side of creating software

This in my experience is the most important factor.

</comment></comment></comment><comment><USER12> Really buried the lede here. I get that it was acknowledged as a rant / opinion piece but there's not a lot of really actionable advice for the general population of programmers, IMO. The article has good points, for sure, but the ending has the best part, IMO.

> So here's the punchline: if you want to be a good programmer then learn a > technology and language agnostic formalism. Logic, statistics, and game > theory are probably good bets. As things stand that kind of skill is > probably the only thing that is going to survive the coming automation > apocalypse because so far no one has figured out a way around rigorous and > heuristic thinking.

I think there's a lot of support there.

I don't think using Kubernetes as an example of "sequestering the complexity behind a distributed control system" was a good follow up to TDD generating more lines of code. Containers are a step in the right direction and Kubernetes _is not_ the best option for using containers in production but it _is_ the most popular option and so if you want community mindshare and support then it probably is the best choice if you can manage it or use a managed service.

"Serverless" is real, it's here, and containers / k8s are just a step along the way.

<comment><USER13> I agree that Kubernetes is not the best technology out there, but I'm not 100% on which I would call the best. Did you have a winner in mind (it sounded like it)? If so why that one?

Also it may not really matter as you said Kubernetes is the most popular and is only getting more so at this point and the network affect is so strong in tech like this that the "technically best" most likely will become a moot point.

<comment><USER12> I am a big fan of Nomad's scheduler and the code is easy to pull in to an existing Go project. It doesn't have everything Kubernetes has but I don't think it needs it, either.

Kubernetes has for sure won the popularity contest but the overhead involved in running it The Right Way™ on your own is a lot. Given what I've seen I would advocate for OpenShift if you like RedHat products / projects or sticking with Kubernetes from one of the well-known cloud providers.

<comment><USER14> I have a sneaking suspicion that Kubernetes is another Ruby on Rails waiting to happen:

[https://trends.google.com/trends/explore?date=all&geo=US&q=r...](https://trends.google.com/trends/explore?date=all&geo=US&q=ruby%20on%20rails)

<comment><USER15> Good for me, I must made about 500,000 from moving Rails to other more modern stacks... I'll learn Kubernetes just as it dies off and start moving people's shit to whatever's next.

<comment><USER10> That has to be one of the best strategies out there. So long as you just read the trends right.

<comment><USER15> Best of both worlds, I can paid to learn the new tech and the old tech...

</comment></comment></comment></comment></comment></comment></comment><comment><USER16> The only part I tend to disagree with is regarding TDD. There is a study from Microsoft Research showing that TDD results in greater quality -- although you pay a price for it [0]. I believe this applies as a general rule, although I recognize I'm not aware of further studies.

However I agree with the article's general idea. In the aviation industry there already are languages abstracting computers' internals and allowing programmers to reason about safety-critical programs using more high level constructs.

Due to its nature, I think there won't be such a technology for general purpose languages -- in order to be general enough, you can't have too much things abstracted away. Maybe we couldn't go much farther than what languages like Basic allows us.

On the other hand, I wish we had such languages for more specific tasks like ERP-like software, business web applications and so on. It's worth noticing that many of the biggest ERP companies in the world have their proprietary domain specific languages.

[0] [https://www.microsoft.com/en-us/research/blog/exploding- soft...](https://www.microsoft.com/en-us/research/blog/exploding-software- engineering-myths/)

</comment><comment><USER17> From the article:

      So here's the punchline: if you want to be
      a good programmer then learn a technology
      and language agnostic formalism.

No.

If you want to be "a good programmer", then learn how to define the problem for which you are tasked to solve. The technology is irrelevant. The "language agnostic formalism" is irrelevant.

Unless a person/team knows what must be done, then the rest really doesn't matter. Techniques which help to elicit repeatable delivery certainly are worthy to learn, even to advocate for. But without understanding what is needed, what use are they?

</comment><comment><USER18> Basically, the author suggested a "back to basic" approach, which is of course not totally wrong. But ignore the very real challenge of the software industry is not going to help either. We can not sit down to plan and wait for the so- called "global optimal" design and then and only then proceed to implement. Because to achieve a "global optimal" design one has to consider _each and every_ details and aspects of the problem, which is simply impossible in the software industry because so many are unknown. The Waterfall model is long dead. History has proven it does more harm than good. Don't dig it up.

PS: I don't disagree that in some cases, academics can use the formal methods to find a (near) global optimal solution. But I don't think it's practical in a daily context, nor necessary. Our evolution is the best proof that local optima can lead over time to fantastic solutions.

</comment><comment><USER19> > The bottleneck has always been in understanding all the implicit assumptions > baked into the system that for one reason or another are essential to its > correctness.

> It takes a particular kind of masochist to enjoy reverse engineering a black > box from just poking at it with simple linear impulses.

These are great observations and brilliantly put. In particular the second one I think rightly explains why some very smart people definitely do not take to programming as a profession.

</comment><comment><USER20> I agree with the part that says Agile (and Scrum in particular) is drinking the koolaid. Managers who don't themselves write any code, but micromanage their workers with their version of Scrum, are the worst.

<comment><USER21> The majority of issues I see with Agile and Scrum is that it's a process added by people external to the teams and it's treated as a rigid process to be followed.

I've worked with teams who have had to suffer through a 45-minute standup every morning that was immensely painful. They were just following the process as best as they understood it from a couple of days with an "agile coach" and didn't really understand what being agile really meant.

> Managers who don't themselves write any code, but micromanage their workers > with their version of Scrum, are the worst.

I don't think anyone would disagree on the evils of micromanaging, but as a manager that doesn't code, I think that managers who do code are depriving their teams of the most valuable thing they have to offer--their support. If you take on a coding task and put yourself on the critical path of that sprint's work, you have to commit to putting the hours in to get it done. This is not a good use of your time.

This is the difference between a manager and a Tech Lead.

<comment><USER22> Just the fact that a manager doesn't code doesn't mean they're providing their teams with any support.

</comment></comment></comment><comment><USER23> ..and I came here thinking I would see an article about an amazing indie games studio from the 90s :-(

<comment><USER24> I thought exactly the same!

</comment></comment><comment><USER25> I enjoyed reading it and agree on many points. One thing that does not seem right is the claim that introduction of formal specification will increase the number of programmers. Yes, it takes a special kind of a person to be interested in fiddling with the code, but I believe the threshold for enjoying creation of formal specifications is even higher.

</comment><comment><USER26> "Whenever I've approached a new system the bottleneck has never been writing more code. The bottleneck has always been in understanding all the implicit assumptions baked into the system that for one reason or another are essential to its correctness". Well.... I know the feels... Assumptions without "understanding" is like the sword of damocles. As you sway into the program itself, there's always this notion that "something" is not right. Or maybe our assumption is not good enough. Most of the time, unplanned assumptions make it harder to integrate "more" code in the long run.

</comment><comment><USER27> This was really quite lovely to read.

Like the others, I think the thoughts on TDD are somewhat fallacious but I certainly can't fault the conclusion.</comment>


Oh, you snarky developers! - <AUTHOR> http://blog.logicalrand.com/2008/9/11/oh-you-snarky-developers

<comment><USER2> But Chris, you left us hanging at the end your your blog entry. What was your reply? It was snarky, right?

<comment><AUTHOR> Haha :) I ended up writing the blog entry, and by the time I was done, my snarky inspiration had somehow transformed into something resembling diplomacy.

</comment></comment><comment><USER3> I enjoyed that article, and its important to note that "snark" has a long and generally successful history. They used to call it "wit" and many writers built a career around it. In the workplace, wit is often a way to rail against pointless mind-numbing hierarchies without actually assaulting anyone ;-)

<comment><USER4> snark ≠ wit

snark includes a snide/smug element; wit rarely does

<comment><USER3> Well, rarely ≠ never, but I just thought I'd go look for some examples - decided Oscar Wilde quotes would be a good place to start

 _A man can be happy with any woman, as long as he does not love her._

 _A true friend stabs you in the front._

 _All bad poetry springs from genuine feeling._

 _Ambition is the last refuge of the failure._

Just as examples. Admittedly I'm cherry-picking, but I'm 100% convinced that smugness or a sense of self-superiority is integral to "wit."

<comment><USER4> Whether any of those quotes are _snide_ depends on the context: especially whether they were directed against someone in particular.

Further: wit is often self-deprecating (and some of those Wildisms may have been offered in that spirit), while snark hardly ever is.</comment></comment></comment></comment>