3 ms·

One of the most damaging things for productivity is not being able to run the stack locally. This generally happens due to laziness and corner cutting. If deve

by cedws 3y ago

One of the most damaging things for productivity is not being able to run the stack locally. This generally happens due to laziness and corner cutting. If developers have to commit and wait for a build + test + deploy pipeline to see if their code works, that should be priority #1 to fix.

pyjarrett 3y ago
> laziness and corner cutting My experience is that it just isn't prioritized, and you have to do it early to enforce good engineering solutions to keep it this way. It's much easier to keep something locally runnable than try to set it up that way six months into a project. If you can't run the stack locally, it makes it harder to set up performance and acceptance testing later. Running locally also makes long build times more noticeable and it's easier to address these issues earlier. Being able to run locally looks low value at first, but if you do it, and sustain it, you get extremely large project-wide benefits later.
- icedchai 3y ago
  I took a job at a place that was into "serverless". That's fine, but there was no way to run anything locally due to how the application was built (wrong framework, no framework, etc.) Also, they failed to give each developer their own environment, so we had people editing the same code in the AWS console. I've never seen anything like it. Everywhere else I worked prioritized local first.
- PH95VuimJjqBqy 3y ago
  > My experience is that it just isn't prioritized my experience as well and it blows my fucking mind every time I see it. It tells me developers have _no clue_ what it is they're doing that is helping or hindering them.
mrkeen 3y ago
"Can you actually run your software on your laptop?" has become one of my interview questions for that reason. I think a lot of dev shops just genuinely don't realise it can be done. I've never been in a startup right at the beginning, but I don't understand how a stack would ever be allowed to transition away from being locally-runnable.
- xxpor 3y ago
  Just start writing firmware.
- swader999 3y ago
  That's a good question to ask. I've always assumed nobody would ever develop without local. Been lucky I guess.
- physicles 3y ago
  As soon as you choose to use any SaaS that doesn’t have a local equivalent, it’s over. We were fine until we started using Snowflake. The SQL doesn’t quite transpile to Postgres, and anyway we’re using some Python functions where the equivalent SQL would be nightmarishly complicated. I hate that we can’t iterate fast on that part of the stack. Could we build something that works nearly identically, but locally? Yes, but we’d need to submit some patches to sqlglot, which nobody has time for. Could we avoid using Snowflake altogether? Only with a lot more work. It solves a few real problems for us.
lhamil64 3y ago
At my job it's a weird situation where it isn't really possible to even compile the code locally so we end up editing locally and then uploading the code to another system to compile it. Then we can remote into a hypervisor to spin up a VM with the code. So in a way it's "local" because we have private environments to build & test the code (and don't need to go through a build system) but it is still a relatively slow code-compile-test loop.
- xxpor 3y ago
  VSCode remote-ssh (or emacs TRAMP) solves the remote issue.
ActionHank 3y ago
This so much. Current project I work on, everyone looked at me like I was made of cheese when I asked how I spin up the project locally. They only do unit and component tests locally, the rest is assumed to work when deployed. Another killer is no contribution guide as a living doc for the team. "Code reviews" end up being a weird gate-keeping mechanism to exercise your authority over others by pointing out things they haven't done "correctly" when there is no shared consensus on what is correct and why.
phpisthebest 3y ago
I have had it were devs could run locally, but their machine was not setup like production and they included some library, dll, or other dependency that was on their laptop into the project and then it blows up in prod.... fun times... even more fun when that project is a GUI app installed on lots of computers and now you have a new dependency to roll out to every system because it would be too hard for the dev to revert and fix it where the code did not need that dependency... Even more fun when that dependency comes from licensed software that you only have a limited number of licenses for
harshalizee 3y ago
With the advent of microservices, it has exacerbated the situation where many dev shops only build, unit test their own little service and call it a day without verifying the end to end functionality -- the "works in my microservice" effect. You can see the effect in many large SaaS/tech products in the form of latency in the double digits to forever looping redirects of their service to Narnia and back.
- Pet_Ant 3y ago
  > unit test their own little service and call it a day without verifying the end to end functionality -- the "works in my microservice" effect. You really shouldn't have to do more if the contracts are strong-enough. If you really are that fragile you have a micro-monolith not micro-services. If you have to run everything, what is micro? The individual deployable binaries (but their sum is now even bigger...)?!!
pptr 3y ago
With proper instrumentation, the main speed difference between running your binary locally or in the cloud is the additional scheduling delay. You still need to build your code and start it. Startup time is the main productivity issue in our stack. We load lots of datasets into memory on startup, which can take minutes.

by cedws 3y ago

pyjarrett 3y ago

> laziness and corner cutting My experience is that it just isn't prioritized, and you have to do it early to enforce good engineering solutions to keep it this way. It's much easier to keep something locally runnable than try to set it up that way six months into a project. If you can't run the stack locally, it makes it harder to set up performance and acceptance testing later. Running locally also makes long build times more noticeable and it's easier to address these issues earlier. Being able to run locally looks low value at first, but if you do it, and sustain it, you get extremely large project-wide benefits later.

icedchai 3y ago
I took a job at a place that was into "serverless". That's fine, but there was no way to run anything locally due to how the application was built (wrong framework, no framework, etc.) Also, they failed to give each developer their own environment, so we had people editing the same code in the AWS console. I've never seen anything like it. Everywhere else I worked prioritized local first.
PH95VuimJjqBqy 3y ago
> My experience is that it just isn't prioritized my experience as well and it blows my fucking mind every time I see it. It tells me developers have _no clue_ what it is they're doing that is helping or hindering them.

mrkeen 3y ago

"Can you actually run your software on your laptop?" has become one of my interview questions for that reason. I think a lot of dev shops just genuinely don't realise it can be done. I've never been in a startup right at the beginning, but I don't understand how a stack would ever be allowed to transition away from being locally-runnable.

xxpor 3y ago
Just start writing firmware.
swader999 3y ago
That's a good question to ask. I've always assumed nobody would ever develop without local. Been lucky I guess.
physicles 3y ago
As soon as you choose to use any SaaS that doesn’t have a local equivalent, it’s over. We were fine until we started using Snowflake. The SQL doesn’t quite transpile to Postgres, and anyway we’re using some Python functions where the equivalent SQL would be nightmarishly complicated. I hate that we can’t iterate fast on that part of the stack. Could we build something that works nearly identically, but locally? Yes, but we’d need to submit some patches to sqlglot, which nobody has time for. Could we avoid using Snowflake altogether? Only with a lot more work. It solves a few real problems for us.

lhamil64 3y ago

At my job it's a weird situation where it isn't really possible to even compile the code locally so we end up editing locally and then uploading the code to another system to compile it. Then we can remote into a hypervisor to spin up a VM with the code. So in a way it's "local" because we have private environments to build & test the code (and don't need to go through a build system) but it is still a relatively slow code-compile-test loop.

xxpor 3y ago
VSCode remote-ssh (or emacs TRAMP) solves the remote issue.

ActionHank 3y ago

This so much. Current project I work on, everyone looked at me like I was made of cheese when I asked how I spin up the project locally. They only do unit and component tests locally, the rest is assumed to work when deployed. Another killer is no contribution guide as a living doc for the team. "Code reviews" end up being a weird gate-keeping mechanism to exercise your authority over others by pointing out things they haven't done "correctly" when there is no shared consensus on what is correct and why.

phpisthebest 3y ago

I have had it were devs could run locally, but their machine was not setup like production and they included some library, dll, or other dependency that was on their laptop into the project and then it blows up in prod.... fun times... even more fun when that project is a GUI app installed on lots of computers and now you have a new dependency to roll out to every system because it would be too hard for the dev to revert and fix it where the code did not need that dependency... Even more fun when that dependency comes from licensed software that you only have a limited number of licenses for

harshalizee 3y ago

With the advent of microservices, it has exacerbated the situation where many dev shops only build, unit test their own little service and call it a day without verifying the end to end functionality -- the "works in my microservice" effect. You can see the effect in many large SaaS/tech products in the form of latency in the double digits to forever looping redirects of their service to Narnia and back.

Pet_Ant 3y ago
> unit test their own little service and call it a day without verifying the end to end functionality -- the "works in my microservice" effect. You really shouldn't have to do more if the contracts are strong-enough. If you really are that fragile you have a micro-monolith not micro-services. If you have to run everything, what is micro? The individual deployable binaries (but their sum is now even bigger...)?!!

pptr 3y ago

With proper instrumentation, the main speed difference between running your binary locally or in the cloud is the additional scheduling delay. You still need to build your code and start it. Startup time is the main productivity issue in our stack. We load lots of datasets into memory on startup, which can take minutes.