noop_joe

As others have said, it depends a lot on the product. A lot of the people on PH are other people building stuff, if it makes sense to launch there, join some PH communities on LI. The more you're already engaged on PH, I think the better off you'll be.

I've found it's harder to read signals from ads for early stage releases. You need something to compare to... Then again, maybe a super narrow target with a very clear conversion might yield some useful engagement.

GL!

One of the most difficult challenges with incidents is dispelling the initial conjecture. Something bad happens and a lot of theories flood the discussion. Engineers work to prove or disprove those theories, but the story about one might take on a life of its own outside the dev team. What then ends up happening is post-incident there's a lot of work to not only show that the problem was the result of XYZ, but also it definitely wasn't the result of ABC.

I was responsible for wsj.com for a few years. The homepage, articles and section fronts were considered dial-tone services (cannot under any circumstances go down). My job was to lead the transition from the on-prem site to the redesigned cloud site. As you can imagine there were a few hiccups along that journey.

One particular incident we encountered was when reporters broke the news of a few unrelated industry computer system failures (including finance). Because it was about a financial system, people visited wsj, the spike in traffic was so large it knocked us out. Now other news outlets were reporting wsj down. Unfortunately, there was a perception that these incidents were all related by a coordinated hacking event.

Each minute the site had an interruption of service, I would need to spend hours post-incident making sure the causes were understood, verified and stakeholders knew what they were.

All in all, the on-call experiences were fine. Sure people were tired if they happened in them middle of the night, but the team was supportive and there was a culture of direct problem solving that didn't add _extra_ stress.

Fun stuff.

Heroku and Reclaim are far from the only two options available. The appropriate choice depends entirely on the team's available expertise and the demands of the applications under development.

There's a lot of disagreements pitting one solution against another. Even if one hosting solution were better than another, the problem is there are SO MANY solutions that exist on so many axis of tradeoffs, it's determine an appropriate solution (heroku, reclaim, etc) without consideration to its application and context of use.

Heroku has all sorts of issues: super expensive, limited functionality, but if it happens to be what a developer team knows and works for their needs, heroku could save them lots of money even considering the high cost.

The same is true for reclaim. _If_ you're familiar with all of the tooling, you could host an application with more functionality for less money than heroku.

I agree with the storage example.

> A counter point is that being a professional software developer is more than shipping features, you have to ship something that is profitable in the long run, which requires you have a broader perspective than your desire for a narrow focus.

I think what's more common, particularly in mature companies, is that the responsibilities are getting split between those that manage the complexity of infrastructure and software developers. Software devs might dictate the infrastructure requirements in their own terms like systemA should have access to systemB, but they're not going to be setting up the Amazon security group.

To me, it's about finding the right level of abstraction. At some point we developers have to trust that the underlying system will do what it says it's going to do.

I guess what I'm wondering is more about the opposite of the "cool/neat" where orgs either prohibit development in non-standard langs (and that was good/bad) or allow development in non-standard langs (and that was good/bad).

What criteria is used to determine when it's ok to deviate from in-house langs? What justification is used to prevent deviation at all costs?

This sounds like software development