[danjac]

Hiring is just like any other kind of marketing: an employer is going to paint a rosy picture to get you to join, and you are going to paint a rosy picture to get hired.

At the end of the day ignore the rosy picture and look at the fundamentals - whether it's a big organization or a tiny startup. Will this job be good for my career? What's the feedback from ex-employees or customers? (Glassdoor etc). What's the salary like? What are their coding practices? Are they nice people?

Look for the warning signs: negative reviews, over-convoluted and time-wasting interview processes, asshole behavior at interviews (turning up late, rudeness etc), blank stares at the phrases "continuous integration" and "testing practices", low salary offers, and so on. If you are going to dedicate a chunk of your valuable lifespan to a company it's on you to do due diligence and adopt a healthy attitude of scepticism.

[arwhatever]

“Continuous integration and testing practices? We think those things are great, but we’ve been too busy to get to that, because we’re a startup ...”

[danjac]

It's kind of like trying to save time on a marathon by not stopping to tie your shoelaces.

I mean it takes maybe a day or two at most to set up a CI/CD pipeline with Github actions or something similar. It takes maybe a day to set up test runners, and you can just sprinkle in small tests as you go. There are plenty of templates you can find depending on your language/platform that do most of this out of the box.

You don't need a perfect pipeline or test coverage, just something you can improve on incrementally. It's much, much harder to do all this on top of a bloated legacy codebase and infrastructure and that's when "adding CI/CD" becomes a Big Project that we'll get to real soon now.

[arwhatever]

I love your shoelaces analogy.

I’ve expressed it as sprinting forward as fast as you can while looking straight down at your feet - which is basically the exact same sentiment.

Of course there’s always “stopping to sharpen one’s saw”

A new I came up with myself “removing the stoplights hoping it will end rush hour sooner ...”

[brudgers]

A startup doesn’t have a known course with a finish line and competing forces defined by rules.

A startup is running from a grizzly bear and tying your shoe laces is an engineering decision. There are important tradeoffs and potential bad outcomes either way.

[nabla9]

“Continuous integration and testing practices" are useless when you are going to rewrite the software from ground up every year or two years. You just patch the software until it's time to throw it away.

Many startups write something that they can sell, get experience, realize what they should have been doing instead, then do that.

[arwhatever]

Your team’s velocity will be faster from week 2 through the end of the 2nd year if you build the rapid feedback cycles provided by automated testing and CI/CD into your progress from the beginning

UNLESS your team lacks the experience to build and maintain a test suite with a high benefit-to-cost ratio, which is unfortunately the case for most teams.

In this case I don’t have any good solutions, other than choosing one’s team and teammates carefully, before starting the project.

[danjac]

“Continuous integration and testing practices" are not exactly a great burden, and you don't know when the thing you are working on is going to snowball and become the thing you need to nurture and grow. Even if you pivot, you will likely want to re-use code written for earlier attempts.

I suspect the reason startups don't do the bare minimum here is because their developers tend to be cheaper and less experienced (at least until they get funding), and "we move fast and break things" is just a lame justification for incompetence.

[rchaves]

Actually you are more likely to rewrite and migrate away from that legacy codebase once you succeed/pivot

I recommend watching Kent Back’s 3X talk for that, I also wrote a blogpost about it: https://rchavesferna.medium.com/designed-v-evolutionary-code...

[danjac]

In theory yes, you're supposed to migrate away from the legacy codebase.

In practice I've never, ever, ever seen that happen: it's too much upfront cost to start over, especially when you have real customers and real data on top of it and you need to keep pumping out new features.

[nabla9]

It's not that. For a startup figuring out what the product is and making it happens in parallel.

Product and product research are the same.