< Back to the archive

Like what you see? Subscribe here and get it every week in your inbox!

Issue #276 - June 23, 2024

Here are the top threads of the week, happy reading!

Top comment by hn_throwaway_99

I like a lot of the answers, but something else I'd add: lots of "popular" architectures from the late 00s and early 2010s have fallen by the wayside because people realized "You're not Google. Your company will never be Google."

That is, there was a big desire around that time period to "build it how the big successful companies built it." But since then, a lot of us have realized that complexity isn't necessary for 99% of companies. When you couple that with hardware and standard databases getting much better, there are just fewer and fewer companies who need all of these "scalability tricks".

My bar for "Is there a reason we can't just do this all in Postgres?" is much, much higher than it was a decade ago.

Top comment by rsstack

I've been part of the team that sets up this process at a few SaaS's, and I've done SaaS procurement for a while, so I clicked that button often (if I didn't know anyone at the company).

1. It gets added to a list of marketing website leads, which is owned by SDRs/BDRs who are there to filter and qualify leads. These are usually early-career people, with a base salary + quota for qualifying leads. The website is many times their least preferred channel of leads due to the quality, but they can't ignore it because sometimes good customers do come through there.

2. The SDR will either work over email or on a call; their goal is to identify if you're a real potential customer (vs shopping for prices, vs confused about what we sell), write up notes, and identify which customer segment you belong to (geography + business type + business size).

3. You will then speak to a salesperson (with varying titles "Account Executive", "Sales Director", "Regional VP of Enterprise Sales", or whatever inflated title makes sense for that sales organization). Their goal is to confirm they're speaking to the right person in your organization (or wasting their time), if your use case is meaningful enough for the "enterprise plan" (they can't sign too small deals), what your budget is, what your usage will be like, etc.

4. Pricing could be made up by guessing your price point, but it's rare. It is difficult to consistently make up pricing that works over time and doesn't have many lowball deals that harm the company's revenue long-term, and salespeople often don't understand the technical details well enough to make things up that make sense. Usually, there will be a pricing framework and an internal calculator (very often, a spreadsheet with formulae and VLOOKUPs) that will give them a range. They can then choose what number within that range to offer, based on who they think you are and how far off they are from their quarterly quota.

5. They can then negotiate the number, or the included features, or the payment terms (upfront payment, multi-year contract, exit clauses, etc.) which can be translated into discounts if they're favorable to the seller.

Top comment by aurareturn

Yes, it could. It may even surpass the dotcom bubble in size.

But AI hype in 2024 is not even close to dotcom hype in early 2000.

During the dotcom bubble, companies IPOed with no revenue and no profit. In 2024, OpenAI is probably at $2 - $3 billion in revenue right now. All the companies benefiting the most from AI are established companies such as Microsoft, Apple, Nvidia, TSMC. We haven't had any pure AI companies IPO with no revenue in 2024 as far as I know. Heck, I'm not even sure if there is an AI company that IPOed in 2024.

I think AI hype is in the 1996 equivalent of hype - not 1999.

We're at the baby steps of the LLM revolution. There are so many things I want an LLM to do but it hasn't been done yet. I want Slack to be integrated with an LLM so I can ask it business logic discussions that I can't find using its search engine. I want Outlook to summarize long email chains that I just got cc'ed into. I want an powerful but private LLM to ingest all my digital data so it takes into account all those things before doing things for me or answering my requests.

Top comment by throwaway9143

I'll give you a hard-earned tip: expect to fight Apple every step of the way. They will randomly erase all local data (cookies, localstorage, push subscription tokens, etc) in your PWA without warning. They say they don't do this, but I have the receipts. They want PWAs to suffer, and you will go insane trying to make workarounds on iPhone.

Top comment by Brajeshwar

1. (Easy - Lesser Pay) Attach to a Service Company. While I was at Razorfish, I worked with many Freelancers. You have to be one of them. I see them in regular contact and working via these companies in rotation.

2. (Hard - Better Pay) Personal Networked Connections, if you have one from prior jobs, etc. Otherwise, start building this up - a long-tail game that pays off as time passes.

3. (Harder - Awesome Pay) A long-term play is to start building up a following in the niche you are good at. Try to be very good in the sector you want to work. I once started a company and supported it for many years just by the work that came from my blog and public presence. I was focusing only on writing ActionScript topped with the ability to design. If Macromedia (Adobe) had to pick and introduce big clients to a bunch of people doing that, I was one of the ones in the line. I had the opportunity to work with the likes of STARZ, Disney, Pearson, etc. because I was there helping people on forums asking any questions about the topic.

Top comment by marssaxman

In my first marriage we combined our finances, at my wife's insistence. This was simple in that we had only one account, but complex in that we had to negotiate over spending in a tedious fine-grained way. Our priorities and risk tolerances differed greatly; I felt like my wife ended up with all the money, while I ended up with all the responsibility. Unable to resolve this (or any other) conflict peacefully, our partnership foundered.

In my second marriage we kept separate accounts, at my insistence, having learned an incomplete lesson from the first. We divided shared expenses in proportion to our respective incomes, otherwise managing our own affairs. This was simple in that we rarely had to talk about money, but as my income grew, while her career (and mental health) deteriorated, it became awkwardly lopsided; resentments accumulated. Again, being unable to resolve our conflicts peacefully, the marriage failed.

In my third marriage we have both individual and shared accounts, for administrative convenience, though we tend to think of everything we are doing as a joint effort. We have structured our flows of income and expense differently at different times, depending on our circumstances, and we check in every couple of months to make adjustments as needed. This works - and I believe it will continue to work - because we consistently keep each other's interests at heart and resolve our conflicts in a way which draws us closer together.

In summary, I believe that the details of your financial structure are less important than the process of communication and accommodation you establish around it. There's no single right answer, and the right-now answer might not work so well next year. What matters is that you include a periodic check-in about financial state as part of your ongoing expression of care for your partner's well-being, that you maintain flexibility and willingness to adapt as your life changes, and - most of all - that you resolve your differences in a way which leaves you feeling like a team.

Top comment by pedrocr

There's a known buffering issue with YouTube on Firefox. Apparently it's been fixed and will ship in the next point release:

https://bugzilla.mozilla.org/show_bug.cgi?id=1878510#c114

https://www.reddit.com/r/firefox/comments/1djkdql/for_people...

According to the reddit comments it's a broken implementation by Google that doesn't trip up Chrome.

Top comment by rapjr9

I left the electronic warfare industry even though I'd helped build a program from nothing to a product bringing in $100M (probably billions since I left) because I didn't want to be in the war industry any longer where the entire legacy of my lifes work could be measured in destruction. Worked as a software engineer in industry for a while, gradually moving up in salary, then went into contracting. Contracting seemed too uncertain in the rural area I lived in, so though it was bringing in a lot of money I took a job as a software engineer in a college CS department, supporting various research projects. The college job was dead end, there were almost no other people doing anything similar to me, and there was no path to advance (unless I wanted to get a PhD, no thanks, didn't want to be a slave for 4+ years at even lower pay), but the work was very interesting. So I stayed with it for 20 years. Maybe I worked on some things that will change the world, maybe it was all futile. I wasn't happy about the pay, but some of the benefits were great, I have some minor hopes of getting some future income from patents, some of the profs were not great to work with, but some were and the work in general held my interest. I learned a lot, though it was difficult, every single project was very different from the last project and often required learning new skills. I built a Beowulf cluster, electronically herded cows, did a lot of work in wireless sensor systems, help design and build a smart watch for medical applications, and much more.

Top comment by frognumber

I will make a controversial comment:

My experience is that security is a function of simplicity and individuals having a complete understanding of the code and implications of changes.

Implications:

- A smaller team will generally lead to more secure software than a larger team.

- Many security layers are counterproductive.

In studies, bugs per KLOC are relatively consistent. A 100-line program can be fully auditable. One with a JIT in a virtual machine in a sandbox looks, on paper, more secure. In practice:

- There are many more places to introduce bugs.

- Beyond some level of complexity, it's impossible to understand the security model holistically.

- Bugs often cut across layers

- Layers are often used as an excuse ("We'll leave this, since that other layer will catch it).

Layers can be okay if they're well-understood, analyzed, and well-documented (e.g. postfix). However, the vast majority of the time, they're not. People pointing to bigger workforce or sandboxes in Chrome aren't selling me. It only takes one idiot.... And for sandboxes? I've never seen a clean block diagram of the Chrome security model.

To be clear: I'm not arguing which browser is more secure -- simply that the arguments in this thread don't sell me.