Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Startup Anti-Patterns

itamarnovick.com

Post reply on HN
Print view View original

31–40 of 102 posts

Re: Startup Anti-Patterns

#31

Post by tikhonj »

brinepot wrote: post #28

Yep, seen too many startups jump straight to Kubernetes and microservices before they even have a validated product. Ouch.

I worked at a startup that did this and it was... totally fine? Like, we hired a guy who knew how to set Kubernetes up, he spent like a week or two setting it up, and then it was totally solid and the development experience was great. I was building some of the core product-specific logic and it only made my life easier.

Which really just goes to show that the "legible" aspects matter far less than the illegible aspects. It's easy to say "hey, this startup is using boring technology and deploying a monolith, great!" or "Kubernetes and a bunch of services, over-complicated!". It's hard to say "hey, this startup's codebase is awful and it's an unforced error slowing them down" vs "hey, these guys are taking some shortcuts but it makes sense in context".

But a mess built on "boring", simple tech is going to derail you far more than a needlessly complex but well-executed setup.

Re: Startup Anti-Patterns

#32

Post by elendilm »

Validation is shorthand for saying "I don't have deterministic skills or knowledge hence I will rely on user behaviour to drive the product".

Works out for many people and usually ideal for beginners. But post a couple of years, if validation is still your primary model, your model tells you how clueless you are in your domain.

Make logical derivations. Build. Determinism is a luxury only affordable for the ones who put in the effort. Others are doomed to chase validation for eternity.

Re: Startup Anti-Patterns

#33

Post by strken »

1saadcodes wrote: post #30

Some seem to treat microservices as a sign of good engineering when it's often just premature complexity. You can always split a monolith later, but you're stuck maintaining that complexity from day one

Big companies mostly seem to use the microservice(s) per team model. If your whole company is two founders, one account manager, and an engineer, you only have one team.

It can make sense to have more than one service for purely technical reasons. I once worked on a friend's startup where we built a separate ingress microservice so we could scale it independently from our monolith. There's no organisational benefit to doing so, however. The technical founder and the one engineer are hardly going to block each other.

Re: Startup Anti-Patterns

#34

Post by dtnm »

threethirtytwo wrote: post #7

Python is an anti pattern. Nodejs + typescript is superior across almost every dimension other than data science and familiarity. People think it’s apples and oranges but it’s not. Also don’t forget golang too. If your app is Python in the beginning then you’re pretty much locked in. It’s doable, but you’re going to be dealing with a lot of Python specific warts.

>locked in

Every tech choice is a lock in.

Re: Startup Anti-Patterns

#35

Post by jagged-chisel »

awithrow wrote: post #14
threethirtytwo wrote: post #7

Python is an anti pattern. Nodejs + typescript is superior across almost every dimension other than data science and familiarity. People think it’s apples and oranges but it’s not. Also don’t forget golang too. If your app is Python in the beginning then you’re pretty much locked in. It’s doable, but you’re going to be dealing with a lot of Python specific warts.

Python is a perfectly fine choice for a tech stack. Just because you don't like something doesn't make it an anti-pattern. NodeJs + TypeScript have tons of warts of their own that you have to deal with as well. Every language does.

There are two types of programming languages: those people complain about, and those no one uses.

Re: Startup Anti-Patterns

#36

Post by threethirtytwo »

q8zd3 wrote: post #17
threethirtytwo wrote: post #7

Python is an anti pattern. Nodejs + typescript is superior across almost every dimension other than data science and familiarity. People think it’s apples and oranges but it’s not. Also don’t forget golang too. If your app is Python in the beginning then you’re pretty much locked in. It’s doable, but you’re going to be dealing with a lot of Python specific warts.

Any stack has its own warts.

The Python stack is a huge wart. First performance is shit. Second type checking is shit.

The only benefit is familiarity and data science. That’s literally it. No one in this thread has stated any benefit Python brings to the table on top of other popular web application languages.

I guess ruby is a worse choice.

Re: Startup Anti-Patterns

#37

Post by threethirtytwo »

awithrow wrote: post #14
threethirtytwo wrote: post #7

Python is an anti pattern. Nodejs + typescript is superior across almost every dimension other than data science and familiarity. People think it’s apples and oranges but it’s not. Also don’t forget golang too. If your app is Python in the beginning then you’re pretty much locked in. It’s doable, but you’re going to be dealing with a lot of Python specific warts.

Python is a perfectly fine choice for a tech stack. Just because you don't like something doesn't make it an anti-pattern. NodeJs + TypeScript have tons of warts of their own that you have to deal with as well. Every language does.

Nah but the warts are minor compared with other languages. Python is guaranteed to hold you back.

First it’s the worst performing language for the application stack (only among the most languages for that area). Second type checking on Python is raw garbage.

Third you’re going to have to use TS for the frontend anyway. You can’t escape ts. Choosing Python(or any other language) forces you to have redundant code in two languages. Ts is the overall best startup stack and a huge part of it is because the frontend requires ts anyway.

Also sqlalchemy is pretty garbage.

Re: Startup Anti-Patterns

#38

Post by threethirtytwo »

jagged-chisel wrote: post #35
awithrow wrote: post #14

Earlier quoted context omitted.

Python is a perfectly fine choice for a tech stack. Just because you don't like something doesn't make it an anti-pattern. NodeJs + TypeScript have tons of warts of their own that you have to deal with as well. Every language does.

There are two types of programming languages: those people complain about, and those no one uses.

There’s a third type of language: Python. Actual poor choice for a startup, independent of complaints.

You’ll note my complaint here is actually remarkably unique. You will rarely hear a person who is an expert in both TS and Python say definitively TS is better.

Many people who know both stacks well always maintains some kind of apples and oranges opinion about it. It’s like agnosticism.

Re: Startup Anti-Patterns

#39

Post by threethirtytwo »

nojs wrote: post #22
threethirtytwo wrote: post #7

Python is an anti pattern. Nodejs + typescript is superior across almost every dimension other than data science and familiarity. People think it’s apples and oranges but it’s not. Also don’t forget golang too. If your app is Python in the beginning then you’re pretty much locked in. It’s doable, but you’re going to be dealing with a lot of Python specific warts.

No, caring too much about the language and not the problem is the anti pattern

Thinking that the stack/language is not intrinsically tied to the problem and smart ass quotations define reality is the bigger problem.

Go use Python for your triple A next gen game rendering engine.

Re: Startup Anti-Patterns

#40

Post by threethirtytwo »

dtnm wrote: post #34
threethirtytwo wrote: post #7

Python is an anti pattern. Nodejs + typescript is superior across almost every dimension other than data science and familiarity. People think it’s apples and oranges but it’s not. Also don’t forget golang too. If your app is Python in the beginning then you’re pretty much locked in. It’s doable, but you’re going to be dealing with a lot of Python specific warts.

>locked in Every tech choice is a lock in.

This is true. I guess I’m saying if you locked yourself into Python you’re locking yourself into a lot of pain. Much more pain than other choices.

It’s like php. Facebook got locked into php and had to develop a whole new language around it.

Post reply on HN