4 ms·

I think that the issue is around creating and distributing source maps correctly and also about maintaining the correct configurations to match updates in the s

I think that the issue is around creating and distributing source maps correctly and also about maintaining the correct configurations to match updates in the source language. I've worked on many projects for large companies and I have to agree with the previous commenter that it feels like source maps often don't work correctly. You can blame the bundling tools, you can blame the deployment process, you can blame the developers... But ultimately, source maps are not so straight forward and they slow things down because they add a lot of unnecessary complexity to the project. I don't think I've ever worked on a CoffeeScript or TypeScript project without encountering at least a few major recurring issues with the source maps. When you have many developers working on the same code, things will break in unexpected ways and so you want to minimize system complexity.

ehnto 9y ago
Closely matching the experience I have with many support tools for development. Including things like docker, vagrant, dependency managers, build pipelines, CI, migration/setup scripts, compilation, codegen... My intuition is that while these all solve real problems, they are complex enough solutions that they themselves have problems over the course of time. Each tool and configuration of the tool individually understood by whoever put it into the project but never understood by all team members. Two things come out of this: when a tool breaks, it can't be fixed by everyone, and because it can't be fixed by everyone no one feels responsible and it stays broken or gets fixed ad hoc by each team member until a real fix is made by someone who can (doesn't always happen). By the time you are a few years into a project your tooling is a mess, people that built it have left, and dependencies and the ecosystem have well and truly moved on. I loved Vagrant, until it broke, on every single project I touched after it was initially implemented and in a myriad weird and wonderful ways. I know these are complex tools, but they often don't feel worth the trouble. They are not robust, they pass out of fashion quickly, and they are rarely effective enough for long enough to truly reap rewards (in my experience). I want these things to work. But they are broken and in the way so often that I prefer not to rely on them. If a builder had to open his magic drill and learn an unfamiliar skillset to fix it every few months he would probably go back to the regular drill that just worked.

ehnto 9y ago

Closely matching the experience I have with many support tools for development. Including things like docker, vagrant, dependency managers, build pipelines, CI, migration/setup scripts, compilation, codegen... My intuition is that while these all solve real problems, they are complex enough solutions that they themselves have problems over the course of time. Each tool and configuration of the tool individually understood by whoever put it into the project but never understood by all team members. Two things come out of this: when a tool breaks, it can't be fixed by everyone, and because it can't be fixed by everyone no one feels responsible and it stays broken or gets fixed ad hoc by each team member until a real fix is made by someone who can (doesn't always happen). By the time you are a few years into a project your tooling is a mess, people that built it have left, and dependencies and the ecosystem have well and truly moved on. I loved Vagrant, until it broke, on every single project I touched after it was initially implemented and in a myriad weird and wonderful ways. I know these are complex tools, but they often don't feel worth the trouble. They are not robust, they pass out of fashion quickly, and they are rarely effective enough for long enough to truly reap rewards (in my experience). I want these things to work. But they are broken and in the way so often that I prefer not to rely on them. If a builder had to open his magic drill and learn an unfamiliar skillset to fix it every few months he would probably go back to the regular drill that just worked.