[hangonhn]

I really dislike GoDaddy but this is not the best signal to use. A lot of startups are rather low in engineering talent early on when they're trying to find market fit and make a product. A lot of things about startups are just crap early on. People do things that they shouldn't or will have to pay for in the long run. Startups accumulate debt in many ways. Being on GoDaddy might be one of those. And if the DNS resolves just fine, many won't do anything about it except pay the yearly fees. More importantly, startups should ideally improve as they survive from year to year and not using GoDaddy is going to be pretty low on the list of things they need to fix.

[marcosdumay]

> A lot of startups are rather low in engineering talent early on when they're trying to find market fit and make a product.

I imagine that is the class of companies the GP is trying to avoid.

[Cyphus]

It would be worth avoiding at that initial stage, but would be less and less of a factor as the company grows and matures.

I work for a startup with ~60 employees. The DNS was setup through GoDaddy by our CEO over 6 years ago when the company consisted of just founders.

Employee #1 updated GoDaddy to point to AWS for nameservers. We've been managing DNS through Route53 ever since. It's tech debt, sure, but migrating domain ownership to AWS gives us almost no benefits. I guess having more consolidated billing would be nice, but until finance complains at me I'm not bothering to change it.

It would pain me to find out that a candidate would red flag the company based on domain registrar. Then again, I don't know if I'd care to interview someone who makes such large decisions based on small details with no context.

[cellularmitosis]

> gives us almost no benefits.

> until finance complains at me I'm not bothering to change it.

> would pain me to find out that a candidate would red flag the company

You have a good grasp on one perspective, what I would call the purely pragmatic business-owner perspective.

There is another (perhaps flawed) perspective, let's call it the idealistic engineer's perspective. This perspective notices the vestigial godaddy remnants. The flawed DB schema fragments from two refactorings ago which stubbornly survive. The fact that the site goes down for 30 seconds every time someone ships a change to production. The fact that shipping frequently is discouraged because of this. The overly aggressive cache invalidation strategy which causes 30% more DB load. The fact that no one is monitoring the DB load. The API endpoints with 4,000ms of latency. The fact that this will never be fixed because you are way too deep in bed with a poorly chosen framework and ORM.

All of these things can be justified from a business perspective as "not worth the effort to fix". Customers aren't leaving, revenue isn't dipping. It's fine. Just focus on the sprint.

But on every engineer's internal balance scale of "should I stay or should I go", all of these things get noticed. Each one adds a pebble to the "leave" side of the scale. For your talented engineers, two pebbles.

Don't let too many pebbles pile up.

[tazard]

Thanks! That scale/pebbles metaphor very nicely describes something that I have been having a difficult time explaining for some time now.

[quickthrower2]

Leave to where exactly ... the company that writes perfect code? Little or no tech debt? Only possible in rare circumstances, probably when it is business critical that it be that way.

[cellularmitosis]

> the company that writes perfect code?

You are touching on an important point, which I did not state: that there are no companies with zero pebbles on the scale.

The goal is not perfection. The goal is to avoid a pile of pebbles large enough that engineers feel hopeless / "why do I bother" / "this place is a joke anyway". Good people don't stick around long for that.

But the main point was that thinking that a technical blemish has "zero cost" is a trap. The cost is not zero. The cost is having one more pebble on the scale.

[krageon]

From experience, there's very big differences between the amount of terrible decisions the upper management forces upon engineers between various companies. When it's very very bad, you should leave because the odds of it being better somewhere else are very high (they might be only average bad instead of objectively terrible).

Edit: It is also exactly this kind of thinking that keeps people in bad situations. Nobody wins when anyone thinks like that, except of course the people in the exploiting position in the first place.

[selfhoster11]

No company is perfect, but clearly some are better than others from the technical perspective. I know I would enjoy my work more and remain more productive if I felt like I'm struggling a little, rather than a lot, to release anything.

[hnzix]

> It would pain me to find out that a candidate would red flag the company based on domain registrar.

GoDaddy are on my shitlist after the elephant killing incident, their predatory business practices and low quality tooling. And don't ever forget to renew your domain or GoDaddy will squat it.

I would absolutely yellow flag a tech company for using GoDaddy.

[haswell]

It would help to better understand your criteria vs. an arbitrary label like yellow flag.

I was not aware of the elephant killing incident, have not experienced their poor tooling (because I have not used them) and was not aware that GoDaddy squats expired domains.

Does this lack of knowledge yellow flag me as a competent person?

Domain registration often happens in a hurry. After a brainstorm that revealed an aha! In that moment, the only thing that matters is grabbing that domain while it's still available. Someone hurriedly registers the thing, with knowledge that it can always be moved later.

If you want to judge a company based on the early inception of the domain, often before deeply technical/experienced folks get involved, that's obviously your prerogative. But I think you'd be unnecessarily filtering out great opportunities in the process.

Oh, and didn't Google Domains use GoDaddy and others behind the scenes for awhile?

[lostcolony]

Is there greater danger in passing over a possibly competent startup with technical debt such as this, or greater danger in ignoring a potential sign?

Obviously it's not a 100% sign. Just a heuristic. One of many, I'd assume. But I can't fault someone for using one when the cost of a false positive so far outweighs the cost of a false negative.

[bzbz]

Elephant killing incident??

[na85]

https://mashable.com/2011/03/31/bob-parsons-elephant-story/

[quickthrower2]

Looks Like this guy pulls the philosophical train lever to save 5 and gets crushed himself.

[hangonhn]

Wow. That's funny because that's the exact evolution that happened at my current company (GoDaddy points to AWS and AWS does the rest) and we're now a unicorn. Being a unicorn is not a reflection of engineering quality though. That said, the earlier engineers were pretty bad (So bad that someone at one point terminated every line in Python with a semicolon. Those engineers are nearly all gone now) and I like to think that the current groups are decent engineers. But I don't see us ever going back and transferring the domain somewhere else.

[r00fus]

Being a unicorn isn't a reflection of leadership quality either. Again, a particular litmus test that has a quality threshold may work for some and not others, it's still valid for consideration.

[marcosdumay]

> It would be worth avoiding at that initial stage, but would be less and less of a factor as the company grows and matures.

Everything always depends... But the initial team tends to turn into the top management team, and a company managed by people that can do its main work is completely different from one managed by people that can't. It's reasonable for somebody to want to avoid it.

[boomlinde]

> A lot of startups are rather low in engineering talent early on

I.e. "technically incompetent"?