Live data from Hacker News

The importance of local development

fastpaced.com

71–80 of 94 posts

Re: The importance of local development

#71

There are lots of reasons to want a robust local development environment, but a paved path or sometimes even the possibility of "consistency between environments" is not one of them dear sir or madame. The JankStack in which one piles Python environment jank on top of Ubuntu/Darwin jank, and piles Docker jank on top of the previous, and piles Docker Compose jank on the previous, until you finally arrive at Jank-As-A-…

> piles Python environment jank on top of Ubuntu/Darwin jank, and piles Docker jank on top of the previous, and piles Docker Compose jank on the previous, until you finally arrive at Jank-As-A-Service Don’t demand your language do the job of the operating system and come with a package manager. Your distro has packages that are guaranteed to play well together, use them.

> Your distro has packages that are guaranteed to play well together…

I’ve never worked in an org that had all machines 100% unified on a single distro from dev to prod.

Re: The importance of local development

#72
post #15
post #2

I go back and forth on this. On the one hand, maintaining local development environments that work reliably across larger team if developers is a HUGE cost in terms of time and effort. Developers are amazing at breaking their environments in unexpected ways. It’s common for teams to lose many hours a week to problems related to this. So I love the idea of cloud-based development environments where, if something break…

Two thoughts: * in every single case I’ve seen, the developers who broke their local environments that badly had significant skill deficits which affected their general productivity. Investing in training paid dividends far beyond not having to deal with their local environment getting hosed since they also stopped creating massive security and performance problems in production. * building a cloud-based development…

> in every single case I’ve seen, the developers who broke their local environments that badly had significant skill deficits which affected their general productivity. Investing in training paid dividends far beyond not having to deal with their local environment getting hosed since they also stopped creating massive security and performance problems in production.

I mirror this sentiment.

Another one that I've commonly seen: a bit of a yellow flag if a developer is struggling with Git. Becomes a red flag if the issues continue to happen after training. Usually means they don't understand other technical fundamentals.

Re: The importance of local development

#73

For this reason, I strongly recommend Google Firebase. The local emulator suite is one of the best I've seen[0] (would love to see others). Powerful and easy to set up[1]. It includes a top notch emulator for auth which gives you a full SSO flow as if going through Google's OAuth flow and makes it easy to get otherwise complicated auth flows nailed down. The database and Functions runtime emulators are excellent and…

For this reason I strongly recommend AGAINST Google Firebase. The local emulator is a big improvement over not having one, but it still absolutely sucks compared to a stack where you can run the production versions of the tools locally. If you really need a 3rd-party Auth solution then it could be good for that. Otherwise I would recommend to sticking to open source tools on top of a hosting provider that gives you c…

It's easy enough to integrate with Google Cloud Run.

I run a mix; some apps are pure Firebase and Functions. Some run Cloud Run serverless containers connected to Supabase upstream and Pg container locally.

Firebase is quite flexible as a chunk of it is a facade for Google Cloud services (storage, auth API, CDN, Cloud Run).

Very flexible model of upscaling services progressively. Functions -> Cloud Run -> GKE Autopilot -> GKE

Re: The importance of local development

#74
post #9
post #2

I go back and forth on this. On the one hand, maintaining local development environments that work reliably across larger team if developers is a HUGE cost in terms of time and effort. Developers are amazing at breaking their environments in unexpected ways. It’s common for teams to lose many hours a week to problems related to this. So I love the idea of cloud-based development environments where, if something break…

What about local development precludes having a consistent, repeatable development environment? At worst you can distribute an environment the same way you would on the cloud.

With local development the user has an almost unlimited array of other things they can do that might break stuff.

With cloud, they can't. They could drop their laptop out of a window and still be up and running productively a few minutes later (given access to a computer with a keyboard and a web browser).

Re: The importance of local development

#75
post #12
post #2

I go back and forth on this. On the one hand, maintaining local development environments that work reliably across larger team if developers is a HUGE cost in terms of time and effort. Developers are amazing at breaking their environments in unexpected ways. It’s common for teams to lose many hours a week to problems related to this. So I love the idea of cloud-based development environments where, if something break…

> the idea of cloud-based development environments where, if something breaks, a developer can click a button on a website, wait a few minutes and have a fresh working environment ready to go again. Until the cloud development environment inevitably breaks, and your entire development team’s productivity drops to zero.

Right, but you can have a dedicated team working on preventing that from happening - including robust automated tests that exercise the cloud development environment itself, checking that newly launched environments come up and work as they should.

I assert that such a team will be a lot more productive than the exact same sized team dedicated to local development support instead.

Re: The importance of local development

#76
post #6
post #2

I go back and forth on this. On the one hand, maintaining local development environments that work reliably across larger team if developers is a HUGE cost in terms of time and effort. Developers are amazing at breaking their environments in unexpected ways. It’s common for teams to lose many hours a week to problems related to this. So I love the idea of cloud-based development environments where, if something break…

Docker makes it really easy

If only that were true. Source: several years of supporting other developers working with Docker-based local development environments.

It certainly helps, but there's still SO MUCH that can go wrong.

Re: The importance of local development

#77

Earlier quoted context omitted.

> piles Python environment jank on top of Ubuntu/Darwin jank, and piles Docker jank on top of the previous, and piles Docker Compose jank on the previous, until you finally arrive at Jank-As-A-Service Don’t demand your language do the job of the operating system and come with a package manager. Your distro has packages that are guaranteed to play well together, use them.

I use a number of operating systems/distributions/package managers, and they all have their strengths and weaknesses. Most can more or less build most stuff in a way that you can run infrastructure on as long as you're not in a nasty cross-platform setting (MacOS development and Linux deployment comes to mind). Off the top of my head I can't think of any language other than Python that manages to be a constant and pe…

> Pointing this out usually generates a bunch of "pipenv/poetry/uv/whatever works fine for me",

I had to use bundler (Ruby) and got some non-descript “missing dev dependencies”. After installing “dev dependencies” (?) for my Linux distro it still didn’t work. The first StackOverflow answer (for Windows) had over a dozen answers with “this worked for me on macOS”. No logic to it, just a random of assortment of commands that happened to work.

At that point I decided to use devbox. And give up if that didn’t work (but it did).

Re: The importance of local development

#78
post #72
post #15

Earlier quoted context omitted.

Two thoughts: * in every single case I’ve seen, the developers who broke their local environments that badly had significant skill deficits which affected their general productivity. Investing in training paid dividends far beyond not having to deal with their local environment getting hosed since they also stopped creating massive security and performance problems in production. * building a cloud-based development…

> in every single case I’ve seen, the developers who broke their local environments that badly had significant skill deficits which affected their general productivity. Investing in training paid dividends far beyond not having to deal with their local environment getting hosed since they also stopped creating massive security and performance problems in production. I mirror this sentiment. Another one that I've comm…

A lot of developers struggle with Git. The only reason I don’t is because I’m interested in version control (too much according to some people I argue with).

Well I say that I don’t struggle but I’ve never had to use submodules.[1]

[1] Torvalds: people say that submodules is hard to use. True. But it’s gotten better now/it’s getting better. (Google Tech Talk 2007)

Re: The importance of local development

#79

Earlier quoted context omitted.

Or, you know, one of the 1350 dependencies deep in that stack hardcoded something stupid and now you can't update another critical dependency.

I'm a particular fan of how `iconv` is ready to freak out and not link if it happened to doomscroll TikTok that morning and for no other reason more easily discovered than via `pwndbg`.

Hey, I got bitten by iconv writing PHP.

Re: The importance of local development

#80
post #17

I live by this principle: If it takes you more than 30 seconds to test a change, you're going to have a huge productivity drain. That means writing a test should be easy and running it should be fast (including any compilation steps). As soon as something takes more than 30 seconds, you've lost a lot of people. They've switched tabs. They're on HN or reddit or they've pulled out their phone. You've broken the flow. S…

> I live by this principle: If it takes you more than 30 seconds to test a change, you're going to have a huge productivity drain.

> That means writing a test should be easy and running it should be fast (including any compilation steps). As soon as something takes more than 30 seconds, you've lost a lot of people. They've switched tabs. They're on HN or reddit or they've pulled out their phone.

And here I am, compiling tailwind CSS on a blade based template consisting of hundreds of partials. ~30 seconds then refresh. FML.

Post reply on HN