jklm

Expecting anyone to stay 4 years in any 1 place is at best unrealistic and at worst sacrificing their potential for the team’s success.

We shouldn’t be surprised when people fly the nest, and for what it’s worth this happens at even the best companies - people leave to start their own businesses.

What we can do is aim to have them do the best work can, build a good rep for our team, and (selfishly) invest in a strong personal relationship with them so that in 10 years maybe they look back and pay back the favor.

Has he considered putting up a portfolio on a personal site or Dribbble and linking to it on his resume or LinkedIn? I’ve found it to be the highest signal thing, above education, work experience, etc.

Isn’t tiktok gaining ground against instagram?

Well...yes. I think we're mostly in agreement that these arguments are meaningless because they can always be created, for every thing.

So the next time you hear an argument that falls into 1 of these 3 buckets, be skeptical both ways (for & against) because the mere presence of criticism can't be evidence of anything.

His arguments are, paraphrased:

1. It hurts nature.

2. It's too expensive and destroys existing jobs.

3. It's unlikely that it's better than the current tech.

And that he won't fall for the "propaganda campaign" that says otherwise.

---

What I find super fascinating here is that the arguments back then and now are...extremely similar.

Look at any cutting-edge tech - EVs, crypto, etc. - and you find the same arguments rehashed in different ways. E.g. EVs hurt nature because of battery disposal issues, crypto uses a ton of energy for a slower database.

Food for thought: are we really all that different from Wendell in 2022?

Just open the default stocks app on your phone, hit nasdaq and set the window to 6m. Who’s really cherry picking?

Marketing advice like this is extremely underrated on HN.

Google had amazingly below-average dev tools when I was there. It was standard in my org to have multi-minute builds, with input/output streamed to/from a remote server. Yes, every keystroke had a small but perceptible delay. I was working on an outlier project that took over 30 minutes to build for a single-character change. I never learned as slowly as I did during my time there. Startups generally have faster tech, bigcos generally have more customized tech with more options and that can operate ‘at scale.’

To offer a different perspective, I was an early engineer at a startup with strong talent that followed this playbook. Things were fine until I realized upon interviewing for fun that I was massively underpaid (2-3x). I was pretty young at the time, and instead of talking with the founders about the gap, gradually grew resentful and left the company.

I’m now on the on the other side of the table, and we pay everyone handsomely but keep the team lean while expecting everyone to operate at a very high level. Not every startup can or should do this, but I feel strongly this is a much better model for retaining talent while balancing cost to the company.

Thanks for being one of the few readers that does a bit of fact checking on news - keeping the old HN alive.

If that seems crazy, wait until you hear about these companies called Stripe and Visa.

Big O is a useful vocabulary for comparing efficiency between different approaches. Binary trees are abstract, yes, but I prefer them to spending an extra 5-10 minutes listening to an interviewer describe a scenario that ultimately still boils down to a binary tree.

From the other side of the table, when I’ve interviewed candidates without a solid understanding of runtimes I’ve seen some very unique code. One candidate wrote a triple-nested for loop and couldn’t understand why it wasn’t an answer we were hoping for. i.e. O(n^3) instead of O(nlgn). Running that code in production honestly would have been a disaster for our oncall.

Interviews being such a hot button topic always struck me as odd. On HN we love evaluating new frameworks of the month, or discussing the intricacies of Elixir fundamentals - all of which also require time investment to learn. Why draw the line at learning Big O? Try looking at it through the lens of a useful skill rather than something to memorize for interviews. Even if you never learned it in school, you can still learn it now and it has real life practical value.

I’ve had this happen to me too. When I had only 2 years of experience, I was asked to code parallel dijkstra's in an interview. That startup shut its doors only 2 years later - guessing a hiring issue.

But at the same time, saying “it happened to me once therefore it’s generally the case” isn’t a strong argument.

I agree with the GP. I’m also a dropout, but am generally pretty good at navigating FANG-style questions, which are leetcode medium at worst. Often it feels like they’re ultimately testing for depth of understanding, flexibility, and creativity when coming up with an answer.

It’s possible to brute-force your way through questions by rote memorization, but that’s going about it in the wrong spirit. And it feels like that's the gap when this topic comes up.

Interviewing is a skill to a certain extent, with maybe a few days/interviews of warmups. But if you believe that your ability to land jobs is directly correlated to regurgitating leetcode hard questions, the outcome is almost predestined.

If I had to sum up from personal experience:

- Not every good leetcoder I know is a top engineer.

- Every top engineer I know is a good (but not necessarily great!) leetcoder.

Extraordinary is subjective though, no?

If I were working at a dot-com company at the turn of century, it would have been extraordinary to me that there were people that didn't believe in the internet and still used white/yellow pages.

Soon after, with the crash, I would have been very wrong. And a few years after that, I would have been very right again.

As soon as any discussion becomes the 'other side' needing to prove something, it's likely already terminal.

My comment was a rearranging of the first paragraph of the GP. To be very clear, I feel souring on someone because of their beliefs is a form of closed-mindedness.

I’m not sure how a productive discussion can happen when both sides pre-judge each other. Skepticism itself is a charged term. /r/ReligionSkepticism and /r/AtheismSkepticism already self-select for audiences - one segment is clearly defending, and another is attacking. A more neutral phrasing would be /r/ReligionChangeMyView. I initially wrote this without opening up the GP's link, but I encourage you to check it out to see if this tracks.

To your point about religion, I’m atheist but have a few very religious friends. Them being religious didn’t sour me on them when we first met, though I’ll likely always disagree with them on that point.

Maybe a little direct, but you don’t see the irony in being soured towards anyone in the space because they’re not open to criticism?

Odd - guessing there was some client-side caching at play in my HN reader app.

Shouldn’t it be reverted to the original title? I remember that was the usual follow up.

The state of web2 in 2005: https://en.m.wikipedia.org/wiki/The_Million_Dollar_Homepage

> First, we lost compatibility with a couple of tools that we really wanted to use. One of them was storybook, that is a super-nice preview system. We had to develop our own frankenstein to do the same.

> Our choice does not need anyone to learn anything, and one can create a widget in no time!

As someone who made the mistake of writing their own internal framework, I tip my hat to you.

You just created your own framework that people now have to learn. And best of all, the documentation is always going to be less detailed than what you'd get with popular frameworks.

Why NameCoin? Why not .eth / ENS that’s already supported in Brave?

Great write-up.

As a natural nerd, took me 5+ years of unintentionally offending people at work to figure out the same lesson. Turns out nerds are somewhat overrepresented in early startups, but the trend doesn’t hold as companies grow!

Another general takeaway from this is “tailor your communication to your audience”. If they’re in marketing, you could talk about a project in terms of the potential conversion lift. If they’re engineers, maybe emphasizing how the same project improves dev speed is more valuable.

One working theory is that emojis increase conversion, retention, etc. [1]

That being said, the reality likely depends on your product and audience.

[1] https://www.leanplum.com/blog/powering-engagement-with-emoji...

To be fully clear - for how they align with the 3 points I raised, Ruby/Node/Python fit into 1 bucket (no, yes, no) and Scala/Elixir/Haskell fit into another (yes, no, yes).

I'm not trying to derail into discussing how Scala is a shade better or worse than Elixir in some aspect - the main point I'm trying to drive home is that they're both in an entirely different class compared to Ruby/Node/Python.

By all means, I encourage everyone to learn Elixir, Scala, Haskell, or other similar, functional, immutable languages for personal growth.

The points I raised earlier in the context of choosing a language for building a company apply to all of those. I don't see why Elixir is exempt - do you mind explaining?

To preface, I share a lot of the same sentiments as the author. My Elixir was Scala - learned it inside and out, then picked up Akka which taught me a lot of neat Erlang-derived principles. My favorite quote is "Make it work, make it right, make it fast," which is very close to the Armstrong comic.

Having said that, I would not recommend Elixir or Scala or anything similar for startups. The 3 main reasons:

1) It's a hiring problem.

There aren't enough qualified people who can fill these roles. Expect a lot of on-the-job training that's more challenging than you'd think since these languages/frameworks are different paradigms. Famously, the complaint I heard in Scala circles was "There are too many ways to shoot yourself in the foot." I worked at a well-known everyday consumer tech company where the payments platform went down for the better part of a day as people scrambled to figure out what went wrong. Noone had read the de-facto Scala bible which warned that catching `Throwable` could break your code.[1]

2) You really, really don't need to get things perfectly right from the get-go.

> My hot take about most dynamic languages is that they are a poor fit for startups who have intentions of being long-term businesses: you’ve created an environment that’s optimized for your founding engineers to build something quickly in the first 7 months, but the price is a set of recurring obstacles which your engineers will pay down over the next 7 years.

With rare exceptions, most companies throw away or rewrite their initial infra once they hit scaling issues. Having these scaling issues means you've likely hit product-market fit, secured more funding, and hired a badass team to solve said scaling issues.

3) The ecosystem is smaller.

Because the language/framework is deeper, it requires more investment to learn. In turn, fewer production-level libraries get built on top of it. That's when you end up needing to build a lot of things yourself. At which point - you've slowed down _even more_ vs. DynamicLang where you can run `dynamic-package add audit-trail` or something and get the 80/20 solution in 5 minutes.

[1] http://www.tzavellas.com/techblog/2010/09/20/catching-throwa...

If we're talking about car phones, which I admittedly know very little about, those were released in 1946[1]. So that would mean it was ~40 years until they became popular for rich executives.

I think it's fair to say that crypto's "release" was in 2009. But the point being, technologies rarely hit "widespread adoption" within 10 years of release. I'd be curious to hear counterexamples.

[1] https://en.wikipedia.org/wiki/Car_phone

By that logic, we should have given up on the idea of cell phones in the late 20th century[1]. FWIW Motorola released the first commercial mobile phone in 1983.

[1] https://ourworldindata.org/exports/mobile-and-fixed-landline...

The image is probably using natively supported font ligatures.

I don't think you can know for sure what exactly they did. Does the crime merit death?

You raise a point that they weren't acting in a purely defensive capacity - for all we know, "did Russia harm" could mean they were a counterintelligence agent that successfully sounded the alarm on a Russian intelligence operation on US soil. From that perspective, wouldn't Russia be the aggressor now?