Live data from Hacker News

The importance of local development

fastpaced.com

81–90 of 94 posts

Re: The importance of local development

#81
post #37
post #23

Earlier quoted context omitted.

I find it irritating when a program's compile time is perceptible. In compiled languages, TCC (Tiny C Compiler) was the only one that came close, though it doesn't seem to be great for production use. This made me switch back to JS and Python. The frictionlessness of "I made this change and I see the result in the same breath" is very compelling to me. Fortunately there are fast TypeScript compilers now, which make t…

I view JS as necessary because of the Web but honestly I don't like doing Python for anything serious because it's a dynamic language and I don't want to write unit tests for spelling mistakes. I realize it's the tool of choice for AI/ML/DS (for good reasons). But I'm with you on fast compilation and at Google this was the case, even with C++. There was a ton of infrastructure made around this that wouldn't be easy t…

Someone asked me today what's my favorite programming language, and I said Python.

I don't use it very often, but even with minimal experience, (and despite my love for static typing,) it's significantly more pleasant and productive than everything else.

It's unfortunately not a great fit for my main niches (small fast binaries with minimal dependencies, and browser games), but in the areas where it shines, it shines.

Re: The importance of local development

#82
post #23

Earlier quoted context omitted.

I find it irritating when a program's compile time is perceptible. In compiled languages, TCC (Tiny C Compiler) was the only one that came close, though it doesn't seem to be great for production use. This made me switch back to JS and Python. The frictionlessness of "I made this change and I see the result in the same breath" is very compelling to me. Fortunately there are fast TypeScript compilers now, which make t…

How long it should take to launch VS or the app through VS? I start it once an update, so any time to start is basically amortised to 0. If anything can be sped up later by doing more processing at startup, I'd totally agree to that.

VS itself, but now you mention it, VS's build system is also very slow (8 seconds last I checked) compared with just running the same compiler on the command line (about 1 second iirc).

I once turned on verbose build output and just started laughing hysterically at all the useless bullshit it was wasting my time doing dozens of times a day.

So I just use a build.bat now.

Re: The importance of local development

#83
post #72

Earlier quoted context omitted.

> 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)

For me it comes down to how often something is holding you back. It’s perfectly reasonable for someone to only use the core Git operations, but if they’re losing work or having trouble collaborating that’s when I start to expect them to recognize that and try to improve.

Re: The importance of local development

#84

At my work senior leads and architects always shoot down being able to develop locally, especially when devs bring up wanting the capability. The critique is some variation of “it would be impossible to run all services locally” or “it would be too expensive.” So we develop the code and deploy into QA, often breaking things. Cycle times are measured in hours to days. Breaking QA is sometimes a fireable offense. Lol.…

I have also seen a prohibition to have a local copy of the code coming from cybersecurity guys worried about laptops being compromised, for example, through an email with a malicious link. "Here is a web-based editor; please develop everything there, and at the bottom, there is a terminal to run your application," they say.

Yes - that’s an indictment of the security group on multiple levels (Kerckhoffs's principle, failure to deploy FDE / MFA, etc.) but depending on the organizational culture the cost might be shifted to the development groups and not everyone has senior technical staff able to challenge it.

Re: The importance of local development

#85
post #13
post #3

You can't run Facebook on a laptop either.

Perhaps it was possible when George Hotz (the quote's source) worked there in 2011?

It's possible. He's comparing Twitter today against Facebook of 2011 though? Surely he might reason that the state of development at Facebook might have changed since then.

Re: The importance of local development

#86
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…

My preference is for test feedback to be subsecond, I quite like the auto runners for automated tests. I want to be able to deploy and run the application in less than 30 seconds ideally a lot faster. I also tend to want things like UIs to be auto load as well so I can do small incremental tweaks and have it auto refresh and show the change so you can rapidly iterate them, UIs especially really benefit from very rapid turn around to build them quickly.

Re: The importance of local development

#87
post #23
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 find it irritating when a program's compile time is perceptible. In compiled languages, TCC (Tiny C Compiler) was the only one that came close, though it doesn't seem to be great for production use. This made me switch back to JS and Python. The frictionlessness of "I made this change and I see the result in the same breath" is very compelling to me. Fortunately there are fast TypeScript compilers now, which make t…

Not even "I made this change".

With JS and Python, I can iterate on code in a REPL. Iteration time is measured in milliseconds.

The somewhat-tested code then goes into the code file to be actually tested as part of the product.

Re: The importance of local development

#88
post #60

If you can't build and run the full environment locally, even in a diminished state, how can you debug the production stack? I'm always advocating for ridiculously fleshed out readmes that describe in detail how to run every part of our stack locally, how to deploy it, and how it's running on the prod servers. If I die I want one of the juniors the next day able to report on how to do anything I do.

So there are at least two of us writing things down in README.md, nice to meet you

Re: The importance of local development

#89
post #64

Earlier quoted context omitted.

In practice, the number one way to bungle a previously-working local environment at many of my past roles has been "brew upgrade". The number two way was to have MacOS and at least one Linux distribution used for local dev on the same team, but one vastly outnumber the other. While I am very pro-containers as a deployment target I am also very resistant to containers in the critical feedback loop of local dev, chiefl…

I firmly believe MacOS and linux should be considered as different as windows and linux from the point of view of platform support. If the only time your software runs on MacOS is during development, you're probably wasting your time supporting another platform, and your developers are never developing against the target. "It's POSIX so it's the same" is a lie in basically all the ways that matter, you'll have a much…

My problems went away the day I decided to run a Linux VM for MacOS. With Parallels (and the others) you can have a good dev setup and still run the other tools (slack, email,...) on MacOS.

Re: The importance of local development

#90
post #4

Local development works great ... until it doesn't. And then getting it to scale past a certain point is excruciating. My favorite argument against local development, however, is that isolation is a bug, not a feature. When I want to show another developer what I've built, or get help debugging an issue, I don't want to have to call them over to my laptop or do a screensharing session. I want them to have access to t…

Local dev doesn’t imply you can’t have deployable PRs.

Or if the team members are good enough with git, send them a patch file, and they can quickly create a new branch to test it out.
Post reply on HN