Ask HN: How did your startup change after an exit? - <AUTHOR> Hi HN
I'm an engineering VP in a (maybe) unicorn looking seriously at an exit and the vibe has ... already changed.
Looking at the current climate, I am probably going to be able to pay off my mortgage and send my partner to grad school, but financial independence or FYM isn't on the cards. I like it here, and am not planning to move on yet.
I've been wondering where the stories about what happens (what goes wrong/right) after an exit, like an IPO.
What should I be looking out for after the exit? Any experiences from senior engineering staff? Or even good blog posts or books?
Thanks <comment><USER2> People spent a lot less time working and a lot more time checking the stock price and estimating their net worth. As the stock headed south, and the press started writing mean articles about us, morale went south.

Lunchtime talk started to focus on money. Some people nursed unrealistic fantasies about an upward turn in the stock. Those of us who were more cynical sold our shares earlier and were happier in the long run. Eventually most of us moved on to other companies. The company is headed down the drain, but many of us are still friends. I bought a condo.

<comment><USER3> I'm pretty sure that people who say things like, "if I'd have invested $10k in Apple in 2008 I'd be a millionaire" are so far from right that they aren't even wrong.

Nobody holds on to a winning lottery ticket that long. You cannot exit at the top and trying to do so will drive you crazy.

I think you and your friends were right. I had a coworker that was selling his stock as fast as he could and it finally dawned on me that he was doing the right thing. When you work at a place, you are investing your time an energy into an idea. If you hold stock in that place, you aren't diversified.

If the stock tanks, layoffs are more likely to happen. And then you are broke and jobless. There are very few companies you can work for where your own stock is the best bet on the stock market, and second best is often pretty darn good. Gamble on a different income stream.

<comment><USER4> There is no right or wrong, it also comes down to personal preferences. Many seriously rich people probably havent been diversifying that much.

Also, a middle ground is possible. Sell some of the stock for safety, and take risk with the rest.

<comment><USER5> Tech stocks outperformed market even when market was on a historical bull run. This might not (and probably won't) hold true in the future but it does bias all our current anecdotal samples.

I think the FAANG people I know who supposedly make 500k/yr only got to those numbers by never selling a single share and then reporting total net worth including appreciation divided by time worked. Their base salary isn't actually that crazy. People who sell all their shares for index funds didn't do as well.

<comment><USER6> I am guessing this isn't what you wanna hear but, They don't do a post hoc calculation.

It is usually the salary + stock award that will vest over 4 years. For most companies with a flat vest, the total will come to 500k/yr for certain levels.

The appreciation is all yours. Future perf bonuses which will be each 6 months or a year are on top of this. Some companies do adjust for what you're making in that year and cut down the perf bonus (In a previous company I once got a promotion without any stock because our stock had tripled in the time...) - but these companies have a serious growth outlook. Once the stock flattens, there will be a major drain and they know this.

</comment></comment></comment></comment></comment><comment><USER7> Was part of a startup (250 employees) acquired by a huge company (300k+). The megacorp had bought up about two dozen companies as they moved into this market.

It reminded me a lot of how someone goes about restoring a car. You buy three old cars. You restore one. The other two cars are parts cars for the first.

We were a parts car. We existed for a year as people were transferred to a different are or left entirely. There was nothing left but maintenance work in our group.

<comment><USER8> This is a good analogy

<comment><USER7> The analogy would be better if car enthusiasts would take the half restored car, drive it in a ditch and leave it there.

</comment></comment></comment><comment><USER9> One thing to look out for is that until you're wholely absorbed in, expect your parent company to offer high powered but disgruntled or burnt out managers and individuals from elsewhere in the company positions in your department. They'll do this in an attempt to retain these folks by offering them an interesting new challenge, but in the vast majority of cases, they'll spend a few months to a year half-heartedly trying you out and then leaving anyway.

<comment><USER10> The only exception to this is if your company actually is a different atmosphere from the parent company and the people coming in have some reason they'd fit better there than in the rest of the company. I had good luck collecting dissatisfied high performers from a parent company, but they always went through an interview process, and I always started by having them take two weeks of vacation and only then come back for on-boarding, as though they were new hires I had just successfully poached.

</comment></comment><comment><USER11> We had a bizarre experience. Our acquisition was motivated by the value of our contracts and came with a number of earn out goals to ensure that management kept these going for a year. All of the money for the acquisition was held in escrow for this time period, with payouts at the end of the year.

Our executive management was very savvy and negotiated that the acquiring company couldn't interfere with our operations for the first year in any way that could threaten our meeting the earn out goals.

The net effect was just weird. In many ways, nothing really changed for a year. In other ways, everything kind of ground to a halt because there was no motivation to do anything and no new management to steer.

I left at the end of the year.

<comment><USER12> How much you got out of it?

<comment><USER11> Enough that I don't technically have to work, not so much that I won't keep working.

</comment></comment></comment><comment><USER13> It all depends on the acquiring party. Whatever you decide to do, do not put too much stock into promises by management (either of the company being acquired or the one doing the acquiring) about the situation post acquisition. History has shown over and over again that those promises are worth absolutely nothing.

<comment><USER14> Also, don't put too much stock in stock if you don't get an immediate & liquid payout. Stock you can't sell is worth exactly 'nil'.

<comment><USER15> If anyone has any post-exit but not yet liquid stock that they would like to sell me for $0.01, my contact info is in my HN profile.

<comment><USER16> > not yet liquid stock that they would like to sell me

That's... isn't that impossible by definition?

<comment><USER17> You can't transfer the stock, but you can sell a contract promising to sell at a specific price once it's liquid.

<comment><USER18> Isn't that essentially shorting the stock?

<comment><USER19> It's a put option.

</comment></comment></comment></comment></comment></comment></comment><comment><USER20> I don't have experience with an IPO, but I did work for a startup that was acquired by a publicly traded Fortune 500 compnay. Short version is that it wasn't a pleasant transition.

The startup had a niche product in higher ed and had done a really good job cultivating their relationships with customers through top notch customer support and rapid iteration on the engineering side. Typical startup strategies for the most part.

Post-acquisition, the support team was essentially goaded into quitting by management, only to realize that the product was far more sophisticated to support than the other products in their portfolio, so they wound up having to rebuild the support team. This was when we realized upper management was a bunch of morons.

On the engineering side, they shifted our product development focus to making the entire app a bunch of SPAs because reasons. The core engineering leadership left, and the new hires that were brought in weren't as good. Apathy set in, the company started stiffing us out of promised bonuses, and I left.

What I imagine is true for both IPOs and acquisitions is that most publicly traded companies usually care a whole lot more about the bottom line than well-funded startups. Getting rid of the crazy retreats and in-house chef is one thing, but when companies start getting squirrely about compensation, it's a good time to think about what's next.

</comment><comment><USER21> I joined a startup 9 years ago that was bought and sold three times since I joined. The first two sales were overall improvements. I didn't get rich, but I got paid well for a job that I enjoy.

I won't comment on the current owner, because international politics forced their hand more than the typical horror story. What I will say is that they ran us very well for a long time.

All I can say is, if you like your job, like the product, and the pay is enough, stay as long as you're happy. Always give new owners a chance to fix a mistake.

A warning sign is when the parent company screws with your whatever you did to be successful. This can be as mundane as moving from git to perforce; or bypassing critical decision makers in your business critical processes. (IE, you lose control of hiring or product management.)

So enter into the process with an open mind, and keep the payout as a buffer in case you decide to give your two weeks notice and leave.

</comment><comment><USER22> It was incredibly odd. They paid a good about for our company, then just scuttled it. Didn't use the source code, sold the hardware, neglected the remaining employees until we left one by one.

They absorbed a few employees who are still there and are just as confused as none of the tech they spent so much money on ever got used.

Maybe it was somehow a giant tax write off, or just buying out the competition?

<comment><USER23> This same exact thing happened with my startup. I was surprisingly the second engineer to trickle out, which is only surprising since I didn't expect someone to leave before me. The clash of cultures made it difficult to integrate; different geographies, age brackets, experience, practices, tech stacks, you name it.

Overall, I agree with the theories proposed in response to your post — either incompetence of their leadership or favor to an investor. In our case, it was a bit of both and the latter part was clear beforehand. Their crudely constructed plan was to take our industry data to improve their models, but they were not privy to any of it so effectively all they bought was a bunch of tech they couldn't manage to integrate since all of our tech leads left in the first two months. That's what they get for not providing an incentive to stay at all, which again hints at both incompetence and a favor.

</comment></comment><comment><USER24> I got brought-out by an organisation who purchased me to fill a hole in their main software product. Their plan was to take my 800 clients, deprecate my software, and force everyone to move to their platform. Problem was a) my clients liked my software, b) their platform was 3x more expensive, c) their platform was a nightmare to configure.

I was tasked to sell their monstrosity and it was hell. To see the faces of my clients as they looked at this 'new' platform was very demoralising for all concerned. We ended up with about 20 clients who stayed and eventually the organisation just got out of the industry segment all together, and they gave me a redundancy package.

<comment><USER3> This sort of situation is one it the pillars of my thinking that the sale is and always has been about the founders getting rich, and everyone else gets a pittance compared to what is asked of them.

But it sounds like sometimes the founder is fucked too.

They buy your product out from under you. They are never, ever going to be as emotionally invested in it as you were. To you it was a pet, possibly even a child. To them it's just an asset.

How often has the product really gotten better after a purchase? Investment, sure. Bank loan, all the time. But how often to mergers result in good news for the customers? Maybe, possibly, if the products complement each other. But even Bitbucket was better off before, from a customer standpoint.

<comment><USER24> That's right. They imposed their will on the customers and they responded.

It's always about the culture. They were just corporate.

</comment></comment></comment><comment><USER25> I will tell my experience of being the guy who works for the company that acquired others, AKA "the others" or "the enemy."

First, we are paired with the "legacy team" AKA --> You, in this case.

And mainly two things happen with the _" tribal minds"_ of the two companies collide:

1\. My peers will feel that you are X or Y and will start to be condescending with you and make your life harder;

2\. Your peers will feel that we are "cheap," "foreign," and ignorant labor that will undo all the good work you did.

Because of my personal history, I can feel and see both side's views. And then I like to work with Americans and Natives more than I like my culture. (teamwork spirit is better)

Then I start to cut of the backstabbing and politics from my side, BUT I will ask and audit if you are playing fairly with us and consider and talk about the changes that will come and How can I make it easier for you[1].

If you don't play fair, I will have to enforce legal contracts and protect my company from you. If my side is not being fair, I will ask to "rotate" the team.

All the people who played fair were granted more work and more time and are right now earning more money and happier on my company or another. And I still really like them.

Conclusion: You got your badges, your war stories, and nice/elegant solutions. It was fun, but the owners need money. Nothing personal You need more challenges, and you Can Teach/Mentor better in other places. Thank you, soldier. I do hope we keep in touch because I love the way you did your terraform or scripts.

[1] - Telling management to keep you more time, more or fewer hours, Helping you dealing with backstabbing, insulating you from things and doing referrals for another jobs and whatever I can do.

</comment><comment><USER26> Been through both IPO and acquisition, but not life changing money.

The IPO was a lot of fun. We were still in charge of our own company culture. I wasn't privy to all the financial information, but we were told the company was skirting profitability and it would've been just a small push to get there. People worked harder afterwards to try to get to profitability. You also realize stock price has nothing to do with your day-to-day work - it's not in your control.

The acquisition was... well, a lot of us didn't stay. For one, a lot of people's RSU's had already vested. The acquisition meant a company cultural change. 1/3 of us left initially, some people were waiting for their RSU's to vest. I think in all, 2.5 years after acquisition, only 1/3 of the original staff is still there.

So depending on the exit, really understand what your yourself want out of life and career. It's ok to be selfish in this scenario, as not everything will be in your control, as others are also considering if they want to take large sums of money, even if it's not FYM. For being higher up on the corporate ladder, be honest and truthful to your reports. Don't make promises you can't keep.

</comment><comment><USER27> First time, we all got our options exercised immediately (worth pretty much nothing for non-founders/investors) and retention+severance plan based on how critical to company you were. Just about all the "strategic" execs bounced and it had pretty much zero impact on the company. Most of the people responsible for the company's success stuck around for several years after. The parent company invested a lot into us, which lead to significant rapid expansion in both staff and technical projects and investments which let to record company financial growth and pretty much exceeded projections and expectations constantly. At the same time, they let us be almost completely independent since they didn't quite understand the formula to our success and didn't want to mess with a good thing; we could use parent company resources whenever it was beneficial or sensible, or not when it wasn't. Some of the things we used to outsource got transferred to our parent company to do in-house (payroll, legal, HR), some of their relevant business divisions got transferred under our operational management. Our compensation and benefits were adjusted to be more market competitive than startup pay. Morale was mostly good and most people settled down, had kids, bought property or very expensive toys. Biggest cultural change was that we had to actually do our job well and make money instead of constantly throwing parties on VC money.

Then our parent company got acquired and by extension we did too. Not even a remotely half-baked idea on what to do with us or our parent company. Grandparent company started meddling immediately without remotely understanding how the business functioned. Significant layoffs at both the parent and grandparent company. Multi-year hiring, compensation, and promotion freezes. Most of the founders were forced out. Forced down changes to core business technology to match their technology. Not a thought given to employee retention or business continuation. We pretty much had half the staff voluntarily leave in the following half year, which might be more attrition than the entire decade of company lifetime combined. Morale is pretty much in the gutter and the bleedout doesn't seem to to be stopping anytime soon. We pretty much flipped from a healthily profitable and growing division to one that's on the verge of collapse overnight. Plus side is our parent company negotiated an excellent severance clause for their employees, which lead to borderline sabotage by people in the parent company in hopes of getting severance instead of being forced to stay under the grandparent company.

Pretty much best case scenario and worst case scenario of what you'd want after an exit.

</comment><comment><USER28> There are a lot of variables and these events don't happen that often so rules are hard to come by. That said being, I've been through three acquisitions and it really depends. How valuable are you personally to their strategy? If you're not, you're likely not going to enjoy it. IE: if you're in accounting and it was an engineering talent acquisition, then it's probably not good. If you are valuable to their strategy, then expect things for you personally to stay the same or improve. The big thing that happens is the company will likely become unbundled and they'll take the parts they like.

My latest has substantially improved the company. We're still very independent, employees made great money and now we have a strategic rudder and a patient investor that we didn't have before. In this case, our tech is very critical to their long term strategy.

</comment><comment><USER29> I went through an exit. There are a lot of ways it can go wrong, but if it goes right, it can be good.

If the deal is structured in such a way that there is mutual incentive for the company being acquired to continue growing, the results can be good. The necessary ingredients are to incentivize the acquired company to grow and the acquiring company to invest. If it's structured as a one-time cash-out for the founders or a financial engineering acquisition for the acquirer, it's likely a net negative.

Lets throw out some real numbers. Suppose "Small Startup" has $1M/year in revenue, is breaking even as far as expenses/profit, and is growing 30%/year.

Bad Acquisition: Pay the Small Startup founders $3M for the company.

Good Acquisition: Pay the founders $2M, and promise them 30% of revenue above $1M/year for the next 5 years. Also promise to invest an additional $3M over the next 5 years.

</comment><comment><USER30> If you are a vp it is very important to develop a relationship quickly after merging because your position is usually the type that get absorbed.

Usually it's a process where the company tries to push what you have into an existing product. The remaining staff support that product until the switch over happens. Some are forced to stay with option vesting deals. But usually happens over two years.

</comment><comment><USER31> My company got acquired by a larger, public company. 80-90% of us are still here after 3 years. Acquiring company was also a technology company, saw that our product filled a gap that they needed, and believed that acquiring a company was worthless if the people left. The worst thing that happened was that after two years they took away our lunches (you think I'm kidding, but all my lunch conversations are now dedicated meetings which is a massive drag on productivity). I speak as an individual contributor, not a VP.

<comment><USER32> So during your lunch...you have a meeting? Every day?

<comment><USER33> There is also the "lunch and learn" events. These things come when your company does not want to be called out for their lip service that is "employee training".

<comment><USER34> Honest question: are there companies that do "employee training" in tech? What does that look like?

<comment><USER35> In my experience, there is never enough time to complete the existing projects comfortably before the deadline. (If there is enough time, it means some team member should be moved to another project, or a new project should be created. Otherwise the managers are not doing their job.) So the actual problem with employee training is usually time, not money.

If you could learn a new work-related skill in literally zero time, most companies would be happy to pay the expenses. It wouldn't be different from buying a new chair, or a larger monitor. But if learning the skill takes a few days (forget about weeks!), in short term it means that a project that is already late would become even more late. Which is why the company totes supports investing in their human resources, but sorry, you can't get the training right now, because there are higher priorities. (Spoiler: there will always be higher priorities.)

Which is sad, because in many cases what is needed is time, not extra money. There are free tutorials, free online courses; the employees have skills they could teach their colleagues. In theory, the company totes supports employees with initiative to offer internal trainings, until they realize that this actually requires some time, too. Then you get the usual "yes, but not anytime soon". (Translation: it means "no".)

I have also seen it from the other side. At some point of my life, I was providing courses for companies.

Generally, there are companies willing to pay you for lessons of MS Word, or MS Excel. (Also Photoshop etc., but I wasn't doing those.) But with anything more complicated, time became an issue. Like, there would be a market for e.g. Enterprise Java lessons, assuming you could teach the whole thing from scratch in one day. Two days, maybe. But three days is definitely too long.

Literally, I once had a potential client asking me whether I could teach their new employees, who had zero programming skills (in any programming language, ever), make Java Enterprise applications. They gave me the checklist with dozen required topics, like web services etc. How quickly can I get my students from zero to expert? I thought about it, and concluded that perhaps in one week, I could at least tell them something about each topic; with no hope that they would remember it all, but perhaps if I also gave them detailed written notes, they would be able to reconstruct parts of it later. When I made a schedule and showed it to the potential client, they were horrified why should it take so much time; there were expecting at most three days, preferably two. At that moment I understood how much the complexity of technical knowledge is underestimated by those who make the decisions.

tl;dr - you are supposed to learn in your free time (and sometimes the company is willing to pay for it)

<comment><USER34> Yeah that's my experience too, which is why I asked. As you say, sending a secretary to an 'advanced Excel' course is common enough, but for real tech topics, there isn't anything you can really teach in a few days that you can't learn yourself from a book and some websites in the same time. And getting some budget for going to a conference a few isn't usually too hard, but it's still completely self-directed learning.

I'm not complaining, I was just wondering what is 'normal'.

</comment></comment></comment></comment></comment></comment><comment><USER33> From my current experience, I closely monitor these things:

\- loss of agility in finance, HR, product development as you have to check back with the corresponding divisions of the new parent company to get aligment/green light for any kind of investment.

Worse: not being able to make independent strategic decision in these areas, but only follow orders

\- restructuring of upper management that creates disquiet/uncertainty with in teams -> productivity sinks

\- Parent company's sales force/marketing does not know how to integrate your product into their current portfolio/process. (Example, when a manufacturing company wants to "go digital", buys other company but their Sales has no idea how to sale digital products)

\- focus shifts from "working on your product for your customers" to "integrate with their system/ their other divisions" who have no idea of your customer base.

\- corporate politics takes over the decision making process

\- general much more "process" creaping in, make you develop much slower. (but that does not have to always be a bad thing)

</comment><comment><USER36> I imagine it widely varies depending on a multitude of factors; how many employees are equitably compensated, whether it's an acqui-hire or a tech/business value acquisition, if the acquiring company/organization plans to take over any leadership duties, etc etc.

Generally though, most of not all were just thankful to not have to depend on VC. Revenue wasn't high enough to keep the company afloat, and the value in us was largely in our established brand within the market combined with a rather active user base.

Fortunately, most everyone who was in the company pre-acquisition are still around over a year and a half later.

</comment><comment><USER37> Rest and vest... rest and vest...

[https://www.youtube.com/watch?v=6BaoxI75TRs](https://www.youtube.com/watch?v=6BaoxI75TRs)

I couldn't watch that clip when it first came out. Too close to home.

<comment><USER38> He got a contract and nothing to do? Perfect, it's free money on the table and he can also take another paid job at the same time! <3

<comment><USER39> It's soul destroying, I've worked on contracts where it took 3 weeks just to get an account before I could start work. I hated it.

</comment></comment></comment><comment><USER40> I worked at a startup that was acquired. No one was able to retire and almost everyone continued working for the new company. We were put on a 3 year retention bonus plan. We got more financial resources but never really got the human resources we needed. Things were largely stable for the first year or so, then we started getting more influence from the new management team - things that were not productive. My job became exclusively about my daily turn over of 'story points', didn't matter if I was doing something useful just that I did something. By the third year the business had all but dried up and we had no clear direction. When the bonuses stopped I left. From my perspective, you need to make sure there is a valid business model and a clear vision to continue to be successful. Everyone one new and old needs to share the vision.

</comment><comment><USER41> The book "before the exit" seems pretty relevant for your scenario

</comment><comment><USER42> Most people left within 2 years. Founders phoned it in immediately after the acquisition. We were a small, nimble company and were acquired by a HUGE corporation, which ran us to the ground.

</comment><comment><USER43> If the stock starts tanking after an IPO, and the company is in upheaval, there might be blackout periods where you cannot sell your stock and can only watch as the price plummets.

</comment><comment><USER44> Our founding team left or were made to leave by the acquirer. For one year everyone kind of relaxed because we all made money. After that our management team left had no vision because they were bunch of execs hired recently. They lacked innovation and kept beating around the bush and left in 2 years of the acquisition. At this point most of old timers left the company because of lack of innovation or anything to do. I becomes like a graveyard.

</comment><comment><USER45> Looking through the comments, has anyone has a mundane or positive experience? Or is it always bad? Not anywhere near having this kind of problem, but fascinated

<comment><USER46> I've been part of two buyouts, have joined recently bought out teams, a recently IPOed team, and part of four teams looking for a buyer.

I'm talking for personal experience from someone mid-career that moves around a lot in the industry.

The best buyout experiences are the slow embraces instead of a big bear hug. A slow embrace allows both sides to grow while they learn how to support each other. A big bear hug will suffocate the purchased company while all energy is spent assimilating instead of helping customers.

<comment><USER45> When you say slow embrace, do you mean the acquisition happened slowly and with transparency or the acquirer handled it well? This is a problem I'd love to have to deal with tbh

<comment><USER47> Post-acquisition example: Acquirer has a VP that's pushing the deal. VP makes promises to make the deal seem as attractive as possible (eg: X will improve in Y time). New team is pressured to move quickly. New team uses the honeymoon period to flex all of their political capital. Existing teams get frustrated as their work is de-prioritized/marginalized. Culture clashes happen if new team isn't silo'd from existing teams. And so on...

</comment></comment></comment></comment><comment><USER48> The last company I was at had an exit and it was great for the company's growth. There were some culture changes but for the better.

@after_the_exit can you give us a hint of this unicorn so we have more context?

</comment><comment><USER49> Depends on the exit, I watched an amazing culture be crushed after an acquisition. So sad

</comment><comment><USER50> I joined a biotech as employee ~70, and after 5 years of growth (up to ~800 people) we went public. Nothing really changed. It's interesting how the large amount of private capital has removed the need to go public very early on in the life-cycle of a biotech. The biggest difference is that people spend more time worrying about the stock price, but there are a number of catalytic events in our future that everyone is kind of holding their breath for so it's still kind of funny money. Compared to a tech start-up, where growth is smoother (i.e., number of active users going up), biotech lurches/jerks forward after key clinical events. Be it actual data or governmental decisions on the data. The other thing that changed was the incorporate of more rigid corporate practices like HR stuff. Everything got more serious.

</comment><comment><USER51> It's been 18 months since my company (non-founding engineer) was acquired, and in that time I've watched the majority of the team I spent the last 5 years around depart. I was engineer #10, and today only 2 of that original 10 remain (besides myself).

Of the team we had at the time of being acquired, 2/3 have left. Some of those departures were voluntary, others because their roles were eliminated (replaced with different skill sets).

The monolith we built over 6 years continues to live, but its days are numbered, as we're shifting new development off of the project in favor of an updated stack.

The P/E firm that acquired us implemented a different type of equity system going forward: much like death, you can't take it with you if you leave before the next exit.

</comment><comment><USER52> I found this article valuable when going through an acquisition:

[https://www.saastr.com/if-youre-acquired-you-need-to- learn-t...](https://www.saastr.com/if-youre-acquired-you-need-to-learn-to- move-from-persuasion-to-alignment/)

</comment><comment><USER53> I didn't get life changing money but got good money. I like the new position, I've had some amazing opportunities. But it's high stress. The market segment is hot and the buyer is betting on us. It's great in the way a huge messy challenge is great. It's hard problems. For me, I got stock buyout from sale and on hire stock grant that I have to stay for some years to earn out. I plan to stay. Altogether maybe 700K. Maybe more. Not sure. I feel pretty good but it's intense. For our size startup it's hard to imagine how it could be better than this. Nothing is easy.

</comment><comment><USER54> I was an engineering director at a company that went public. It was a moderate IPO, nothing special either way.

Maybe because of that not much changed afterwards. There were a bit more compliance issues to deal with. We got a bit more money to spend. Recruiting became both a bit easier (known value of offer) and a bit harder (can't sell the IPO dream anymore).

After IPO my total comp became about where it would be if I joined a large public company to begin with, so nothing especially good or bad there either.

So I guess for me all in all not much changed, just something became more explicit and known.

</comment><comment><USER55> $100M to $1B+: Non-obvious Lessons Learned Selling to Yahoo! - [https://link.medium.com/ru5Ku7a8J0](https://link.medium.com/ru5Ku7a8J0)

</comment><comment><USER56> Be ready for non stop politics and a survivor like atmosphere. The first thing that happens after a merger is they look for people they can fire to save money.

<comment><USER57> Those are called "synergies."

</comment></comment><comment><USER58> I would imagine an IPO is a lot different than another type of exit, like an acquisition. I've been through two acquisitions and both went terribly for just about everyone but the founders.

For an IPO I haven't been through one of those but all of my friends just basically stare at the stock price all day every day and brag to their friends about how much money their stocks are worth.

<comment><USER3> One acquisition in particular really gave me the vibe that I'd been sold like cattle. From what I hear that is frequently enough exactly what has happened.

Founders sometimes have part of their pay structure tied up in retention numbers. They have an incentive to stretch the truth until those milestones are met.

The first time I was in a sale, a bunch of us had options that were worth $40k+ On paper, which isn't amazing but for your first one out it's pretty cool. But they couldn't take in our culture like they said they wanted to, so it started to unravel almost immediately.

What I found out later is that there's a kind of merger where the buyer swaps stock for your liquid assets. The founder got payed less cash than the company had in cash and accounts receivable. All that money went into payroll as the combined company cratered in slow motion. Ten months later our options were underwater, and all of that imaginary money we were going to get was lost.

By the time I had another set of options worth anything, it didn't take much for a coworker to talk me into selling them the moment I could. Bought my first MacBook for starters, and started a love affair with a bag company. Ultimately I made more money off of the annual bonus than the stock, and got out three weeks after the bonus was paid. I put part of that money into Apple stock, which quintupled within the next couple years. And I'm still not rich.

</comment></comment><comment><USER59> I joined a startup that was acquired by a large company. Once the original founders left it went straight to hell. Upper management changed three times, then we got merged with other acquisitions, layoffs followed. It went from engaged, smart staff working long hours to unmotivated 9-5 cover-your-ass corporate environment within one year.

</comment><comment><USER60> It is always an interesting time. You didn't say "what kind" of exit, that is important.

In one, people go from owning options in their company which is private to owning options in another company that is also private. In the two companies where I have seen that happen things didn't change a whole lot but the "new way to do things" which is to say the way the acquiring company did things was sufficiently different than the way the acquired company did that there was churn.

In one the "exit" is really sort of an aquihire with no value transferred, rather the employees are all given some form of retention package depending on their perceived necessity to the success of merging in the acquired company. In those, people are typically both happy to still be working and conflicted because they now feel "trapped" as the only way to get value out of their previous investment of time into the startup is by working through their retention.

The rare, but happier version, is the one where stock options become "tradable" at some future date for non-zero amounts of money depending on the current stock price of either the acquiring (and already public) company, or the rarest where the company itself goes public.

A lot here varies by scale. At Sun I watched[1] a number of people become "overnight" multi-millionaires. Some people it didn't change at all, others became insufferable prima donas, and a number basically scaled back their work while they 'rested and vested.' A number of folks left to start their own companies (some as groups like Legato) now that they had enough money to self fund. Some, like John Gilmore, went off to do advocacy because of all the crazy stuff going on in the Crypto wars.

Bottom line is that if its a big uptick in wealth for a number of people they will all respond a bit differently. Life will be different.

For me, I came to recognize that there are many levels of "wealth"

Perhaps the first is when you have enough extra to insure your kids can go to the college of their choice (within reason I suppose). This can empower one to take some riskier bets and reap potentially some bigger rewards.

The next is when you have enough to send your kids to college and you can pay off your mortgage so that your "burn rate" is manageable regardless of your salary. This often empowers people to speak 'truth to power' since they don't really care if their truth makes those in power so uncomfortable they are asked to leave.

The third is when you own your living space outright, your kid's college is taken care of, and you have diversified the surplus into an investment strategy that is kicking off enough returns to cover your nominal burn rate (taxes, insurance, food, gas, car maintenance, home maintenance, etc). I used to talk about as being 'raman rich' much like a startup talks about being 'raman profitable' meaning that you don't _have_ to work but not working means you might not get to take vacations or invest in other interesting endeavors.

So how your life changes will be based on both how you respond and how those around you respond to the way you respond :-).

In the first decade of the 2000's one of those Sun people who had turned into an insufferable prima dona came by looking for a job. They had mistaken (or over estimated) how much of their new wealth was because of what _they_ did and how much of it was just luck. As a result they embarked on a number of risky startup ideas and I suspect never took anyone's advice on solving the hard problems. As a result, a string of failed startups and a trail of people who would listen to their pitch, nod politely and decline to participate. They ended up selling their house, moving to the midwest near their ex-wife's parents so that they could visit with their kids. Not a happy story.

[1] Not me though since I had started on the Monday _after_ they went public.

<comment><USER61> Love the term "ramen rich". Sums it up well, happened to me.

<comment><USER62> How is the experience of being "ramen rich"? Care to expand how it changes your day to day work or relationship with work?

<comment><USER63> I would identify myself as "ramen rich". Specifically, my post-tax living expenses (rent, food, gas, entertainment, ...) are ~30X my liquid portfolio, all invested in a bunch of diversified index funds that throw dividends/interest income, as well as increasing their NAV.

It improved my life in the sense that I don't feel the pressure of having to keep a job I don't like: I can quit and not work for several months and nothing will happen. Even if I don't actually quit, just the thought of me being able to do it gives me a lot of comfort. I suffered significantly from this in the past, where I was stuck in non-ideal work situations for financial/immigration reasons.

But it's far from being truly liberating: I constantly think that a significant drop in the market could jeopardize my position (and I can't move more than 30% to fixed income investments, since I am young enough that inflation is otherwise going to eat all my capital away), or a crazy medical emergency force me to go bankrupt (and I say this as I have a pretty good health insurance plan covered by my employer).

And, I think it would be nice to have more money for discretionary (e.g. more traveling) or unforeseen expenses.

<comment><USER64> The source of the 3.5-4% "safe withdrawal rate" theory suggests that that is designed with historical market declines in mind, so you might be better immunized against that than you think.

Side note: You have the ratio inverted and probably should be thinking of the portfolio income as pre-tax.

<comment><USER63> I am familiar with the Trinity study. Even if that is going to be true going forward (which I am very skeptical, as I think global warming is going to have a major impact on market returns over the next few decades), I am young enough (32) that I really can't trust these level of frugal expenses to be maintained for the rest of my life.

</comment></comment></comment></comment></comment></comment><comment><USER65> Imposter Syndrome is a phenomenon I've observed post-exit. With sudden success some people believe they'll be exposed as a "fraud", despite evidence of their competence.

The longer the vesting period, the more they have to lose with each decision. So they simply stop taking risks.

</comment><comment><USER66> An exit is not always bad. Big companies have vast resources and established sales channels. Acquired companies can offload peripheral corporate functionality to their new parent and focus their efforts on core competencies such as research and development.

</comment><comment><USER67> Be ready for a career change.

Within 2 years, the vast majority of the ~300 person startup I worked for had found new jobs, and if they are still there they're likely not in the same role.

</comment><comment><USER68> Out of curiosity, How much dollars worth of stock do people vp/manager/ic in those situations get? I know it depends on the worth of the company, say < unicorn more than a couple of hundred million

</comment><comment><USER69> I sold my bootstrapped company last year.

We had new branding in the works, new products and a recruitment initiative that had been key to finding us very capable & motivated staff. I asked several times during the due diligence if they actually wanted all of that to continue, as they seemed a more conservative kind of shop.

Yes yes, business as usual please, came the response, who knows where it could lead. They still insisted on an earn-out clause that hinged on profitability alone.

After we signed, my whole experience of the (public) parent company was about quarter-to-quarter profitability - there was no visible technical leadership, everyone was fighting their own fires, just generally scrambling around hoping to save money or land a sale. If anything got delivered it seemed to be down to heroism, bullying or both.

After several weeks failing to meet up with other leaders in the company, I concluded that they didn't want any of my company's current developments. I emailed the CEO to say that I'd be firing about 50% of the team to save a huge number on the salary bill, and best meet the earn-out criteria, i.e. that we'd just be a cash cow and nothing more. I'd manage the transition, take the personal flak for it, and get a bonus on my way out.

These were people I liked, most lived locally and many I'd personally recruited. But I wasn't going to be naive about what the new parent company would want.

Immediately - a call from their CFO, pearls a-clutched. He was shocked, SHOCKED by my idea and emphasised it was not how things were done at the parent company. Despite the clause promising no interference in my running of the company, he was ready to veto me from doing it, with an EGM and everything. He offered to settle the earn-out early if I left early. And that was fine by me.

Two months later, they _did_ fire everyone I'd suggested, saving 2-4x what they might have paid me.

My old company is now a landing page for a vaporware product based on tech they have no expertise in.

There's not even any staff left who could debug the old platform if it broke - so they're crossing their fingers that 1/3 of the revenue doesn't disappear with a novel systems failure.

From the people who left, it sounds like a depressing, ambitionless place to work - i.e. perfectly integrated into the parent company.

Any change of control is an opportunity for some types of people, and a death knell for others, so I'm sure it's a better company for some people. Just nobody I'd respect :)

</comment><comment><USER70> That's the kind of posts they should show students at business school

So valuable comments it's insane

</comment><comment><USER71> If you're acquired it depends on how the integration works. Sometimes it turns out that they can't make the incentives align.

</comment><comment><USER72> I worked for a legal startup as the lead dev. When written like this is sounds cool, but in reality I was a fresh dev out of university thrust into a top job with no idea what to do, and with a similarly skilled team we bullshitted our way towards a product that got acquired by a large multinational company (again, non-tech). It wasn't a huge acquisition, but enough to make the directors rich.

I left just after the acquisition went through, because I wanted to work for a company where I could be mentored instead of swimming on my own, but I'm still friends with a lot of the people I worked with, so most of this is from an outsider looking in, but with stories from those still in the company.

The parent company swallowed the whole company, and while the product was still under the original startup name, it was built with the whole parent companies resources. While the product sadly no longer exists, they invested heavily in making sure it was a top resource, and fed into their main business.

Culturally, the place changed considerably. They went from penny pinching to giving generous budgets and perks to their employees. They were still to date the only company I've known that gave software engineers full flexitime - allowing people to work extra hours to build up extra holiday, and allowing people to take holiday whenever they wanted, with a day of notice. It all sounded amazing, but the biggest problems many of their faced was that the dev team didn't really improve. The company itself didn't have any other developers, so the same group of recent grads worked together for years. They've all left the team now, but many of them spent years working on a product without any other input. In this time, I had worked at three different companies with dozens of other talented developers, and I had learned a ton from them. Would you trade in mentorship and peer learning over insane company perks?

The last one is a negative one. The startup had several "divisions", and while the product is what got us acquired, the main money-bringer for several months was a call centre used to cold-call companies to pass on leads. They also dabbled in PPI, and other schemes from that time. We all knew that it was the product we had built that the company had wanted, and although everyone had been given new contracts at our new parent company, it became pretty clear that it was "only" the product. After a year, the owner had left the parent company to start a new venture, and mere weeks later everyone outside of the core product team that hadn't moved into other roles were made redundant. Our core product team consisted of about 8 people, in a company of around 50. A year after the acquisition was complete, only around a dozen remained.

</comment><comment><USER73> Probably, almost every dollar you receive from IPO will go into paying taxes.

</comment><comment><USER74> The things I would look out for:

\- First, you need to find out if your department is not going to be axed immediately. A lot of functions will become redundant depending on your size (sales, HR, finance, IT are the most likely to go).

\- Next, you need to find out what the org structure of the acquiring company is and how you integrate there. Each function that the acquiring company has will be replicated on your site in many cases. One example: You currently might not have a separation of product owners and project managers. If your acquirer sees these roles as different, then you will have to follow suit and people need to pick sides. Another example: If you have a regulatory department that currently reports to you as VP engineering, but the acquiring company has regulatory report into the GM/CEO whatever, then you will lose this team.

\- If you can negotiate part of the post-acquisition plan, please make sure that the acquiring party agrees to grow you / your site at least to double the size. This means budget and head count (easy to forget the latter) must be allocated for the next 5 years. Otherwise you will not likely be able to hire anybody over the next 2 years, because you are not aligned to the budgetting season and head count is frozen. You need the growth just to handle all the new communication overhead you have with the acquirer.

\- Resist the temptation to realign salaries and job grades too fast to the acquiring party. I have been in an acquisition where this was not handeled well. You can end up with overpayed employees who were just in the start-up for a long time and underpaid new hires. This can seriously mess things up and cause conflict among employees. Take your time and align with the new organization when everybody understands their new roles.

\- Don't expect founders to stick around. They were used to running the ship and getting told what to do rarely works out unless for the vesting.

\- Distance yourself quickly emotionally from "your" start-up. The likelyhood is large that the acquisition will break everything even though everyone has best intentions (compare most comments here). Don't be sad if it does.

\- If you are an engineering VP now, you will likely end up as a senior manager or director. Put all your effort into being put into a director grade. Even if this is not justified normally (you need a team of 30-100 reports and/or 30-100m in sales normally to be called a director), it is much better to negotiate higher positions at the start. As many acquisitions are not allowed to scale, it might be very tough to ever be promoted for the next 5 years otherwise.

\- If you can fight it, make sure that you retain on-site IT people. Corporate function are usually hell, but corporate IT is the worst.

</comment><comment><USER75> nice. i think it very good idea

</comment><comment><USER12> Why do you have to pay for your partner's grad school? Isn't there NsF scholarship? And it it's not STEM what's the point of a 200k grad school when you earn 50k/year after?

<comment><USER64> Business, law, and medicine are possible examples of not general grant funded but still possibly good financial prospects.</comment></comment>


Show HN: Tradely – buy and sell with friends and friends of friends - <AUTHOR> Introducing Tradely: https://play.google.com/store/apps/details?id=com.newbuysell... - A new way to buy and sell used or unused stuff with friends & friends of friends because buying & selling with strangers is too mainstream. <comment><USER2> How does the app get to know who are your friends? Why not friends of friends of friends?

Anyway, this seems like a good use-case for [https://debtmoney.xyz/](https://debtmoney.xyz/)

<comment><AUTHOR> App gets to know about friends using Facebook.</comment></comment>


Lyft has been quietly pitching investors on a new funding round - <AUTHOR> https://www.wsj.com/articles/lyft-seeking-at-least-500-million-in-new-funding-1488418612 <comment><USER2> They've been trying to sell the company earlier without any success: [https://www.nytimes.com/2016/08/20/technology/lyft-is- said-t...](https://www.nytimes.com/2016/08/20/technology/lyft-is-said-to-fail- to-find-a-buyer-despite-talks-with-several-companies.html)</comment>


Avoid getters and setters whenever possible - <AUTHOR> https://dev.to/scottshipp/avoid-getters-and-setters-whenever-possible-c8m <comment><USER2> I have trouble articulating this point, but I never understood the argument why you'd want getters or setters at all.

From my point of view, your data structures _are_ your API. Attempting to hide them behind methods so that you can do something clever doesn't work when it's not always you that constructs the data (I'm thinking of things like json deserialization and accepting data from outside your control.).

All the arguments behind getters and setters seem rooted in this fear that maybe you'll change your mind later about your data, but somehow you won't have to change the function signatures of your getters/setters when that happens... this seems so contrived to me it's insane to design entire frameworks and paradigms with this as a central idea.

Maybe I've been using Go for a bit too long now but I really think the mixing of data and logic is a fundamental mistake.

<comment><USER3> I'm inclined to this position as well but consider cases where you need values to be restricted or linked. A setter would allow that to happen reliably every time without changing your API to require validation calls before doing anything else.

Getters definitely seem less likely to have cases like that unless there's some sort of ordering contract you need to enforce.

How valuable this is will come down to audience: if it's a small team which is very familiar with the app, there's considerably less value than a large app with a huge team or a library intended for other people, especially non- experts.

<comment><USER2> I guess I don't think that way.

Having classes where values are "restricted" doesn't make many sense in my mind. It's a flaw in your type system if invalid values are possible... proper algebraic typing with pattern matching would do an infinitely better job at this.

And linked values are more smell to me... it's a sign you have a bad abstraction if two properties have to be set in tandem or your object becomes invalid. Can you think of a good example for purposes of discussion?

<comment><USER3> A somewhat contrived example but say you had a user address with state and zip code values and you wanted to prevent setting a zip code outside of that state. Or with any kind of state change - e.g. certain statuses are only valid for paid accounts, you can only archive verified files, etc.

That's not saying you couldn't have an API which is set, set, set, validate() but there's an aesthetic argument for early enforcement so invalid values can never be set.

Type systems can't solve everything but I'd agree that it's not surprising that you see these design patterns most in languages like Java which didn't have a better way.

<comment><USER2> I love this response because it's helping me formulate my objections a little better.

I don't think a User class should be directly validating the zip lives inside the state in some sort of setter method... which one do I set first to make it work? It looks like once I change one I can't change the other any more... I'd need to have a method that changes both at once. And this is a perfect example of your data not matching your encapsulation: your encapsulation would want to express that you need to provide a zip/state pair via some setLocation(zip, state) method, which does not correspond to any private property you actually have.

But I definitely would prefer the set,set,set,validate approach more, and I would even say the validate() belongs in a different class altogether, ideally as a side-effect-free standalone method. (Basically, I should be able to set an invalid state and zip property in a vacuum, it's only when I go to validate it that it returns invalid.)

Going further I would implement any form submission system as taking some Validatable interface, where the Validatable object in this case would store your Address object via composition, and would represent the specific logic for validation for these purposes... but it would all live separately from a User struct, which would just be a dumb struct.

<comment><USER3> > I don't think a User class should be directly validating the zip lives > inside the state in some sort of setter method... which one do I set first > to make it work? It looks like once I change one I can't change the other > any more... I'd need to have a method that changes both at once.

The idea I had in mind for that admittedly contrived example was roughly that you'd have an address class and some logic along the lines of setting a field automatically clears the lower-level fields, but that's not really a practical design as much as an illustration of the pattern of having complex logic in a setter.

I should note that this isn't my preference, either – either set,set,set,validate or updateLotsOfFields(dataStructure) – but I've seen people who felt otherwise and had reasonable arguments for this kind of behaviour.

</comment></comment></comment></comment></comment></comment><comment><USER4> This is strange advice. There's no real drawback from using getter/setter and there are obvious benefits.

And even if you mostly use public properties, there will still be cases where you'll need getter/setter so you'll end up with a messy mix of getter/setter and public properties. Better be consistent and always use getter/setter.

<comment><USER5> Getters, yes.

I would argue that everything that can be immutable should be immutable though unless you have good reason for it to be mutable.

<comment><USER6> Agreed but immutability can lead to builders and builders lead to lots of code bloat. Plus, from what I've experienced lots of frameworks depend on java bean conventions (i.e. getters/setters for everything).

There's really two missing features of java that could solve 90+% of the use cases for getters/setters.

\- Attributes: annotation or keyword based directives for the compiler to generate getters/setters for a given instance variables

\- Default + named parameters which would reduce a lot of the pain of multiple constructors and constructors with a tremendous number of parameters.

<comment><USER7> Instead of attributes that lead to creation of getters/setters, how about the simple notion of private or public access to members? I'm not sure which should be the default, but it sounds like Java programmers would like them private unless otherwise specified. Why add code when all you want is to restrict access?

</comment></comment></comment></comment><comment><USER8> For Java exists the Project Lombok, it works pretty well for this purpose, you can use getters and setters without polluting the code with auto-generated stuff. Have some other cool features like fluent accessors, builders, auto cleanups for close() and plugins for IDEs. IMHO every Java programmer should check it out.

<comment><USER9> My favorite is immutables ([https://immutables.github.io/](https://immutables.github.io/)). It's really frictionless and at this point it feels like an extension of the language to me. It also lets you fall back to mutable types when you need them, despite the name.

</comment></comment><comment><USER10> I disagree with the author, getters and setters are a good tool to have and used in the right place.

Setters are great when you want to do some validation and add an entry in a log when the setter is used.

There are rules what not to do in getters or in setters so if you use does practices you are ok.

<comment><USER11> I try to avoid setters whenever possible in favor of constructors taking the dependency as parameter. That way, reasoning about the lifecycle of dependencies is much easier.

<comment><USER10> I agree, if you can make the object imutable by setting all it's fields at construction time then it is great, if you have to update the object then is good to use setters or functions that can perform validation, it makes it easy to catch errors earlier.

</comment></comment></comment><comment><USER12> Overlooked is how they became so ubiquitous: JavaBeans. It was well-meant, but it's left a lot of unintended pain in its wake (I'm looking at _you_ , JPA constructors). Without that standard, Java code might feel quite differently today.

While you can avoid making it worse with idioms like only using constructor injection, you can't unwrite the billions of lines written to date.

Kotlin makes a great effort to atone for the sins of the past.

<comment><USER13> > While you can avoid making it worse with idioms like only using constructor > injection, you can't unwrite the billions of lines written to date.

But you can fix them. One line at a time. So many years of atonement still to do ...

</comment></comment><comment><USER14> To me, objects is a data abstraction technique which is about abstracting the said data under a set of operations known as the interface; You are no more thinking about the data but about the operations which then allows all kind of interface abstraction techniques known as design patterns. Once you break that abstraction, you break everything which is relying on.

Even for small classes where there is no design pattern involved, it is important to think about the interface first then the data. take for example, a rectangle, you may think (g/s)etters would be pointless and be tempted to do

      class Rectangle:
        public x, y, w, h;

        public Rectangle(x, y, w, h):
          this.x = x;
          ...

Then you need the area

      class Rectangle:
        ...
        public area():
          return w * h;

Then you need to cache the area

      class Rectangle:
        public x, y, w, h, cached_area;

        public Rectangle(w, h):
          this.w = w;
          this.h = h;
          cached_area = w * h;

        public area():
          return cached_area;

Problem here is that w and h being public, user can corrupt the area, you now need to rely on (s/g)etters.

      class rectangle
        ...
        private w;

        public setWidth(w):
          this.w = w;
          updateArea();

        private updateArea():
          cached_area = w * h;

If you had start with an interface only having operations, you would never had that problem.

      interface Rectangle:
        getX();
        setX(x);
        getWidth();
        setWidth(w);
        area();
        ...

      // implementations are irrelevant to the user.
      class RectangleCached implements Rectangle:
        ...

      class RectangleLazy implements Rectangle:
        ...

      class RectangleWhatever implements Rectangle:
        ...

_One of the great leaps in OO is to be able to answer the question "How does this work?" with "I don't care"_ (Alan Knight)

Note that another solution in this case would be immutability but this is another discussion.

</comment><comment><USER15> The argument for getters and setters is much stronger when you're writing libraries that are dependencies for projects you don't control.

If you own all consumers of your code, and it's all part of the same project, then you can safely refactor from field access to getters and setters if and when you need to add extra semantics. If you own the consumers but they're not all part of the same project, you can refactor but it will take longer and be a multi-step exercise.

If you don't own the consumers, then you need to break compatibility, which means major version bumps, which will leave some downstream consumers on older versions, and will probably increase version divergence in your userbase, fragmenting the ecosystem and increasing your support load.

<comment><USER16> I think it is kind of insane not to recompile when your downstream dependencies change and the recompilation fixes this problem. Like presumably it makes sense to run your tests again when you change downstream dependencies and it is extra work to run tests independently of recompilation so I think most people's process would be update dependency -> recompile -> run tests. I just remember Java having lots of gotchas with binary compatibility and I assume C# has similar issues. It's just easier to not depend on binary compatibility and always recompile.

I'm guessing this is a result of 'insane' processes where you have people upgrading dependencies in deployed applications without properly going through a test process.

(EDIT: oops i thought this was a c# post. but this change in java breaks source compatibility as well as binary compatibility)

<comment><USER12> My understanding is that C#'s properties were designed pretty much exactly for this situation.

</comment></comment></comment><comment><USER13> The first point:

> (...) My question is how often has the working programmer ever had to do > that? I don't remember ever doing this in all my years of software.

has that hollow ring of "I write my software the way it doesn't allow easy changes, so I don't do them, so there's no reason to do it." ... there probably would've been reason to do it more than once, the author just didn't want to do it because it would've been painful.

Anyway: If you can make your class work without exposing anything then go ahead. That's great. But if you have to allow external access a getter will always be better than direct access.

p.s.: Setter means mutable class. Mutable classes are a performance hack. Sometimes you have to do it, most of the time it's premature optimization.

<comment><USER17> > Mutable classes are a performance hack.

Could you please clarify this point? I have no idea what you're trying to say.

<comment><USER12> It's often much faster to modify something in place than to create a modified copy.

Suppose I have:

        Point point = new Point(50, 50);
        int x = 100;
        int y = 200;
        Point translatedPoint = point.plus(x, y); // new Point(this.x + x, this.y + y)

This code suggests that Point is immutable. Once defined, a point never changes. This makes a lot of sense -- if you change the values of x and y, you have a _different_ point, in a mathematical sense.

But newing up an object is _tremendously_ slower than integer arithmetic. Suppose I can do this:

        Point point = new Point(50, 50);
        point.translateX(100); // this.x += x
        point.translateY(200); // this.y += y
        Point translatedPoint = point;

This is going to lead to translatedPoint much more quickly than the first code. But it's riddled with troublesome outcomes. Who else was relying on point? What happens if I change it again? Why am I able to mutate something that, mathematically, isn't mutable?

The basic reason mutability improves performance is that you can change things in-place without making a new copy. Most of the stuff being done during the copy construction is overhead compared to the thing you're changing. The price might be too high in a performance-sensitive situation.

There are workarounds based on using copy-on-write datastructures with clever shared bits, but they're not native idioms in Java-land or in most languages without a strong functional heritage.

</comment></comment></comment><comment><USER18> I prefer getters setters over Car1 example especially for large classes. I am quite used to use prefix to filter for methods in IDE - get<thing>, add<thing>, set<thing>, create<thing>, is<thing>, to<thing>, etc. Often you know which one of those subgroups you are interested in and can do ctrl-o or ctrl-space and filter irrelevant options out. The worst option of all is when there are both getters/setters and public fields.

But most importantly, the real practical differences between these styles are minimal for all practical purposes. It is all mostly matter of habit. You might as well argue about which shade of blue is best for syntax highlighting.

</comment><comment><USER19> Some Java frameworks let class and interface authors use decorators on getters / setters to control how particular class/interface fields are used in some contexts ... e.g., one might have a field (due to an algorithmic consideration) in an entity that's useful when constructing POJOs (plain-old Java objects) that eventually are written to a database, but that particular field should should not be persisted to the database -- one can use decorators to control whether field goes to database, or the data type used to persist the field in the database, etc. It's sometimes useful to treat the getter and setter asymmetrically.

</comment><comment><USER20> IMHO getters & setters can be a bad smell, symptomatic of classes that are just dumb aggregations of data that have no significant behaviour. I've seen them most often in Java - a single paradigm lang that forces every method or data item to be a class member. And then, because our data item is a class member, it must be encapsulated. Multi paradigm langs offer better approaches to data aggregations. Python, for instance, gives us dictionaries and named tuples as well as classes.

<comment><USER21> Generic data types aren't necessarily a better approach. My primary language for many years has been PHP, where the default approach used to be just to pass generic maps around for all data, and it was hell.

You cannot tell if a map passed to you has any of the members you expect, hasn't had additional unexpected members added, or anything else about it without parsing it, it's a mystery bag. There are times when a mystery bag is fine and you're going to be inspecting it anyway, but most of the time your code has at least some expectations about the structure of your data, and for that you need real specific types to maintain any kind of sanity. Otherwise, you're re-validating data over and over or writing code that relies on hope and faith instead of correctness.

<comment><USER22> Why use actual objects and rely on static anlysis when you can write tens of unit tests that ensure the maps/tuples passed around always contain the correct data structures? _And_ you get the added benefit of 100% test coverage.

<comment><USER23> now you have to add (manual) type checks in your tests instead of your compiler doing it for you

<comment><USER22> You probably didn't get the sarcasm :).

</comment></comment></comment></comment></comment><comment><USER24> I have sometimes wondered why none of the mainstream OO languages implemented an access class of publicly readable but only privately modifiable.

<comment><USER25> Does Swift count?

private(set) is a thing

<comment><USER24> Sure, Swift counts - thanks for the correction. Maybe those with experience of it could comment on whether they found this feature useful in practice.

</comment></comment></comment><comment><USER26> I prefer actions over getter and setters. The object should take care of itself (ddd style).

But xml and db to object mapper often need them :(

</comment><comment><USER27> tl;dr: "Don't use getters and setters" shouldn't be a goal to strive for. Good OO design should be the goal, and the reduction of getters and setters ( _and_ of public data members) is a consequence of that.

I fundamentally agree with the author: Getters and setters often break _Tell, don't ask_ , increase the public interface of a class (and expose implementation details), and add mutable state, which makes reasoning about the program's state harder — for getters, this is often mitigated by defensive copying, which has its own set of issues (it can introduce _glaring_ inefficiencies in the code base, which, in many cases, could have been entirely avoided).

The extreme case is when getters and setters lead to quasi-classes [1]. All this is uncontroversial when you think about it (and is backed by a vast consensus in the literature and by what little evidence we have in evidence- based software engineering). On the other hand, I agree with the author that accessors are sometimes a practical solution and shouldn't be banned entirely.

 _But_ I don't think the author states the case well at all. There's too much talk about _feelings_ , which is a poor substitute for arguments. This starts with the first example that's provided: Contrary to what the article claims, there's of course a difference between `Car1` and `Car2`. Namely, `Car2` can add logic to its accessors without creating introducing API changes. `Car1` cannot do this: If I for instance need to ensure that `engine` is never set to `null` by the user, or I need to add logging, or I need to add deferred loading, etc, I need to make `engine` `private` and add public accessors.

Future-proofing isn't always relevant but it unfortunately tends to become relevant unexpectedly. Anyway, neither example is probably very good code and, conversely, either piece of code can be appropriate. But they're emphatically not the same.

I also don't think the "list of options" at the end is particularly useful because it seems to be a substitute for properly thinking about the architectural design of the code (which doesn't need to happen up-front, it can happen iteratively): Many accessors are simply never necessary and were instead added "just in case", or because the programmer thinks about objects as "bags of data" instead of, more appropriately, "[black] boxes with a specific observable behaviour". This simple change of perspective will drastically reduce the number of public accessors in a code base; but this happens as a side-effect of better OO design, rather than a goal in itself.

[1] [http://www.idinews.com/quasiClass.pdf](http://www.idinews.com/quasiClass.pdf)</comment>


Luakit – fast, extensible, and customizable web browser - <AUTHOR> https://luakit.github.io/ <comment><USER2> Another alternative that I use as a daily browser is qutebrowser. Basically the same idea, but with Python instead. Also comes with nice vim-bindings for navigation: [https://qutebrowser.org/](https://qutebrowser.org/)

<comment><USER3> Qutebrowser is nice, but it uses the same webengine (QtWebengine) that chrome uses. This is a concern for some

<comment><USER4> > _This is a concern for some_

I don't think so. Why would it be a concern? It's not like the web rendering engine will "phone home" under your nose or something...

<comment><USER5> I don't use any of these alternative browsers because I don't want to increase the Blink/Webkit marketshare even further.

<comment><USER3> This ^

</comment></comment></comment></comment></comment><comment><USER6> The new website looks great! And it seems new maintainers have stepped up. Is Luakit on an upswing?

This project could have immense value to the web. Having multiple language communities working on the same types of problems, and in cross-cultural collaboration, gives the best approach, ie with [Model-driven engineering] ([example below]).

I have reviewed Luakit's codebase, trying to figure out the extent of its DOM scripting capabilities (notes elsewhere atm). If anyone else is interested in this, pls message me on Discord, @naturallymitchell via [The Programmers Hangout] or [Luvit].

A good example issue for DOM scripting would be something like [scrolling screenshots],

[https://github.com/luakit/luakit/issues/763](https://github.com/luakit/luakit/issues/763)

[https://en.wikipedia.org/wiki/Model- driven_architecture](https://en.wikipedia.org/wiki/Model-driven_architecture)

[http://luvit.io/](http://luvit.io/)

[https://discord.gg/BQN6BYE](https://discord.gg/BQN6BYE)

<comment><USER7> Sometime back I was looking for alternative browsers and came across your comment (dated 2015)[0]:

> The code itself works very well. Mason, founder of Luakit and most generous > contributor, got hit by a bus so new maintainership roles have yet to get > filled by existing and new users and developers. All current development > takes place outside of "central" repo, and it needs organizing and > compiling. Once this takes place, development and merge requests can > continue full course.

I actually saved the comment as a placeholder in ZIM[1] - in a section where I keep programs to try in the future. You seem to keep up with the project pretty well and it also looks like the project itself has been moving forward. Going to give it a try this time ("This project could have immense value to the web." \- I agree).

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

[1] [https://zim-wiki.org/](https://zim-wiki.org/)

</comment></comment><comment><USER8> I wish that there was a way for Luakit / Qutebrowser to support extensions from the major browsers.

Every time I use one I love it initially but then find myself desperately wishing for uBlock Origin and my password manager extension.

<comment><USER9> Well qutebrowser already has a built in host-based adblocker. There are also a number of password manager scripts available.

</comment></comment><comment><USER10> I really liked Luakit, but one problem I was having was with videos not loading I believe. I _could_ have hacked it up with an external player I believe, but I couldn't get it to work. Has this been sorted?

Big fan of the project though, can't say that enough. It was a nice, lite and zippy browser with nice key bindings + Lua scripting. A lot to like about it, just hope some of the issues get resolved.

<comment><USER11> Try looking at the settings page to see if it could be disabled. There are settings relating to video playback and hardware acceleration. There was a bug in hardware acceleration that caused the browse to use a lot of cpu, maybe it has been fixed at this point.

</comment></comment><comment><USER12> I really liked using this web browser. I like qutebrowser too but luakit has some things it doesn't have. One was making your own luakit:// pages.

I tried to get a flatpak working for it but was unable to get one of the dependencies luafilesysyem to work. I think the author was going to remove it so once that's done installing the latest version should get much easier.

<comment><USER13> > One was making your own luakit:// pages would you min expanding or leaving a > link on that

</comment></comment><comment><USER14> How does it compare with uzbl? ([https://www.uzbl.org/](https://www.uzbl.org/))

<comment><USER11> I quite liked uzbl when it was being more actively developed, seemed like a very promising project. Unfortunately development stalled some time ago and it doesn't seem like it's going to start again any time soon. So I migrated to luakit. Luakit and uzbl are pretty much on par with each other feature wise and both are pretty scriptable.

</comment></comment><comment><USER15> I wish the latest release wasn't from two years ago. And that it wasn't based on webkit.

<comment><USER12> Looks like the latest release was Nov 2018.

<comment><USER15> Then it's misleading that the site prominently says "Latest release — Luakit 2017-08-10"

</comment></comment></comment><comment><USER16> Can this do basic functions such as play a video, post a form or run advanced JavaScript? If it can't then it is broken today's web technologies are just too advanced for some of these small browsers

</comment><comment><USER17> The page says the latest release was 2017-08, that seems tremendously outdated. Am I missing something? Is it updating in the background?

<comment><USER18> Page is indeed outdated. Check the project GitHub repo, last release (e.g. git tag) was on Nov 2018, version 2.1.

Since then just the "develop" branch has received new code, but GitHub Insights shows stable activity on the last month.

I'm not involved in the project, they're probably low on contributors and taking things slow. The documentation does point to compiling from code, so you should be good by using the develop branch and even bumping some dependencies if concerned with security issues and etc

</comment></comment><comment><USER19> Anyone know of something like this but with web technologies rather than a different stack? Vivaldi is the closest I can think of and while it is built with a similar concept it's structured in a way that makes it near impossible for you to modify substantially as a user (and you have to reapply your edits after every update).

<comment><USER20> What are you looking to do that can't be done with local chrome/firefox extensions?

<comment><USER19> E.g. in Vivaldi I blend the URL bar into the top-of-window space where tabs are.

Also while there are many things web extensions can do in page their interactions with the browser as a whole or OS are extremely limited. This is good for security, bad for customization. Even in cases where web extensions are appropriate it can make implementation much more difficult (again, good for general user security, bad for running your own code).

</comment></comment></comment><comment><USER21> Could someone who uses it say what this is really for? What can one do with it?

For instance: does it make automating interactions with web sites easier than using other tools?

</comment><comment><USER22> Instructions for Arch Linux are broken.

<comment><USER23> Some dependencies have the package "luarocks-5.1" as a build dependency, and that package has been removed. Apparently, it's been replaced by "luarocks", so you can install in Archlinux by fixing these dependencies (tested on my own system):

      set -e # halts if there's an error in the following
      # move to a directory for building modified dependencies
      mkdir -p build
      cd build
      for aurpkg in lua51-{say,luacheck,luassert}; do
        # downloads the aur-package building script and files
        cower -d "$aurpkg"
        (
          cd "$aurpkg"
          # replace dependency
          sed -ri 's/luarocks-?5\.1/luarocks/' PKGBUILD
          # install dependencies, build package, and install
          makepkg -si
        )
      done
      # install luakit-git from aur
      pacaur -y luakit-git

Of course, these things being in the AUR, it's preferable if one gives the PKGBUILDs a read before deciding to build and install each of them, but if you've judged it's OK, you can just run the above.

If luakit is really on an upswing, maybe the package will be moved back to one of the official repos.

</comment></comment><comment><USER24> What can you do with this that you can't do with chrome/firefox extensions?

<comment><USER25> You can extend it using lua.

<comment><USER26> If Firefox is generalized to be extended with wasm - which could run a lua VM - what would be the benefit of a single language specific browser?

<comment><USER27> The lua api in luakit ([https://luakit.github.io/docs/](https://luakit.github.io/docs/)) is trusted, meaning it has similar capabilities to pre-57 Firefox, as opposed to webextensions (in modern FF and Chrome), which are treated as untrusted and thus are somewhat more limited in what they can do.

</comment></comment></comment></comment><comment><USER28> Silly observation: The logo shows the Earth visible through a crescent moon. In reality the moon is always round, it's never transparent. :)

<comment><USER23> Well, maybe the Earth is just smiling. Maybe, it's laying down and having a nice dream. :)

</comment></comment><comment><USER29> Is Luakit a web browser or a web view component?

<comment><USER25> Read the very first paragraph of the page linked above.

<comment><USER29> Not helpful. The reason why I asked this was that the page claimed that Luakit was a web browser but then immediately started talking about it being a "web browser framework", and the screenshots showed nothing except for what looked like a web view (there's no browser chrome, for instance).</comment></comment></comment>


Scheme: Procedures that return another inner procedure - <AUTHOR> http://stackoverflow.com/questions/12496482/scheme-procedures-that-return-another-inner-procedure/12496867 <comment><USER2> This is the "closure/object isomorphism", basically.

The outer function (cons) is a class constructor. It returns an object, which is a function of one argument, where the argument is equivalent to the name of a method. In this case, the methods are getters, so they evaluate to values. You could just as easily have stored more procedures in the object returned by the constructor.

In this case, numbers where chosen as method names and sugary procedures defined outside the object itself. You could have used symbols:

        (define (cons x y)
          (lambda (method)
            (cond ((eq? method 'car) x)
                  ((eq? method 'cdr) y)
                  (else (error "unknown method")))))

In which case what you have more closely resembles OO:

        # (define p (cons 1 2))
        # (p 'car)
        1
        # (p 'cdr)
        2

<comment><USER3> Nice. Or you can use the procedural representation. E.g. in Clojure:

        (defn pcons [x y] (fn [m] (m x y)))
        (defn pcar [z] (z (fn [p q] p)))
        (defn pcdr [z] (z (fn [p q] q)))

        (pcar (pcons 2 3)) ==> 2
        (pcdr (pcons 2 3)) ==> 3

<comment><USER4> I still look at this, and the whole LC encoded structures, with amazement. I love how things are mutually molded together and almost empty. Most of the LC felt that way, accumulation of lots of nothingness that achieve something.

</comment></comment></comment><comment><USER5> Ah, this is like closures or decorators in python.

<comment><USER6> Those _are_ closures (btw, did you mean generators instead of decorators?). Until nonlocal ([https://www.python.org/dev/peps/pep-3104/](https://www.python.org/dev/peps/pep-3104/)), python closures were limited ([http://stackoverflow.com/questions/141642/what- limitations-h...](http://stackoverflow.com/questions/141642/what-limitations- have-closures-in-python-compared-to-language-x-closures)). Even though nonlocal solves the problems, the resulting scoping rules are messy: global, local, nonlocal, ...</comment></comment>


How a 48h hackathon led to a pivot - <AUTHOR> http://blog.swypeout.me/hackton-to-pivot/

<comment><USER2> This is too thick on startup buzzwords such that it makes it difficult to understand any argument.

<comment><AUTHOR> There's no argument or lesson learned from it. Its simply a story. The backstory is that I got so frustrated at Facebook's api changes that I had almost lost hope on anything working with beepl. And just when i was abwt to give up, i said 'fuck it' and did a mobile version for a change. And this happened.

</comment></comment><comment><USER3> as much as I love seeing this startup spinoff like that, I feel bad for the one you're leaving behind. But anyways, good luck!</comment>


TSA Doing Random Truck Searches On Tennessee Highway - <AUTHOR> http://www.newschannel5.com/story/15725035/officials-claim-tennessee-becomes-first-state-to-deploy-vipr-statewide

<comment><USER2> As any other Governmental agency, they'll keep trying to expand and finding new reasons to get an increased budget.

"Sure, we check every plane, but that's what - 5% of the travelling population? We need to check them at the subway, buses, trains, trucks and cars, too. Then we'll consider malls and Walmarts. Anything to protect the country against "terrorism"."

</comment><comment><USER3> Misleading headline. Commercial vehicles have different standards than non- commercial vehicles. The article makes it seem that they were running standard weigh station inspections but adding a Big Brother "report your neighbor" aspect to it.

<comment><AUTHOR> the first picture is of an agent on his back under a truck inspecting it. Is that standard weigh station behavior? And if not, won't those kind of inspections slow everything down more?

</comment></comment><comment><USER4> Why are they bothering to do this? They're not getting to grope beautiful women - truckers are notoriously male, and they're not getting to see shiny, blue nudes. Isn't this sort of work highly demoralizing to the average TSA "officer"?</comment>


Quake on an oscilloscope - <AUTHOR> http://www.lofibucket.com/articles/oscilloscope_quake.html?source=twitter <comment><USER2> There have been several postings about this already: [https://hn.algolia.com/?q=oscilloscope+#!/story/past_week/0/...](https://hn.algolia.com/?q=oscilloscope+#!/story/past_week/0/oscilloscope) .</comment>


Show HN: GifBook – Animated GIFs as paper flip books - <AUTHOR> https://gifbook.io/?hn

<comment><USER2> This looks awesome! I love following what you're up to. Can't wait to see a blog post about it later :)

FYI: I think your ?hn querysting is still rendering "Welcome Product Hunters!" O_o

</comment><comment><USER3> You might want to filter the GIFs being shown on the front page, guys.

<comment><USER4> Yup, that didn't take long to become an issue!

</comment></comment><comment><USER5> Do you loop them to a standard page size?

<comment><AUTHOR> Yes 50 pages

</comment></comment><comment><USER6> Really cool !</comment>