4 ms·

I really like the essay but I think there is a form of Stockholm syndrome playing out especially with the following statements: > using a Haskell package for t

by amasad 7y ago

I really like the essay but I think there is a form of Stockholm syndrome playing out especially with the following statements: > using a Haskell package for the first time, and being frustrated by how many annoying snags there were > If you’re a programmer, you might think that the fiddliness of programming is a special feature of programming, but really it’s that everything is fiddly, but you only notice the fiddliness when you’re new, and in programming you do new things more often. I think programmers think that the suckiness of their tools is a fact of the universe, when it's just that they don't know there's a better way. At Repl.it, we built `upm` (Universal Package Manager) to make using packages a breeze with no fiddling. Ever since I started doing most of my scripting on Repl.it I almost never "fiddle" to get a package or a feature of the language to work. upm goes as far as to guess your dependencies when you import them and will install and generate the spec and lock files. It's a truly magical experience. More here: https://repl.it/site/blog/upm https://repl.it/site/blog/upm And we try to do a similar thing with every potential programming workflow. Can you make it "just work"? I think we can, for most things.

ehnto 7y ago
I agree that we can build better tools. I think what is missing in software is wholistic developer tooling and longevity of that tooling, such that we can invest in mastering them. UPM is a great example of a step in the right direction I think. When you go into a carpentry workshop, there are hundreds of tools, all designed to work on wood, and a carpenter will know the majority of their tools quite well. They can invest in a tool knowing they can re-use that knowledge for the rest of their career. When I inherit a software project, it can often have two, three, even four different language ecosystems involved with hundreds of libraries and tools as dependencies. In software we have to accept that we will be surrounded by dozens of tools we need to work with but will never have time to fully master. Most people I meet are only proficient in many of their tools enough to get the job done and no more. Soon enough the status quo will change and the software industry will happily drop thousands of man-hours of learning right into bin. The finer points of library X, framework Y, or tool Z are almost ephemeral. Even a company's core software product could just be thrown away and re-written in the new-hotness at the behest of a PM meeting, often losing nuanced domain knowledge in the process.
- dc443 7y ago
  I have personally stumbled upon this paradigm (value craftsmanship on tools that will have a relevant shelf life), and I credit my ongoing satisfaction with my career to this, at least in part. Without getting into details and specifics, something I highly enjoy doing, I'm referring to things like Vim, tmux, unix utilities and software, various Linux administration knowledge. Various electronics concepts. I now consciously and deeply evaluate a potential skill to learn based on how likely it is going to improve my life in the long term.
Zenbit_UX 7y ago
Despite the tool you work on which solves (maybe) that one very specific problem the author posed, I'd say his point still stands about 99% of other things in this universe.

by amasad 7y ago

ehnto 7y ago

I agree that we can build better tools. I think what is missing in software is wholistic developer tooling and longevity of that tooling, such that we can invest in mastering them. UPM is a great example of a step in the right direction I think. When you go into a carpentry workshop, there are hundreds of tools, all designed to work on wood, and a carpenter will know the majority of their tools quite well. They can invest in a tool knowing they can re-use that knowledge for the rest of their career. When I inherit a software project, it can often have two, three, even four different language ecosystems involved with hundreds of libraries and tools as dependencies. In software we have to accept that we will be surrounded by dozens of tools we need to work with but will never have time to fully master. Most people I meet are only proficient in many of their tools enough to get the job done and no more. Soon enough the status quo will change and the software industry will happily drop thousands of man-hours of learning right into bin. The finer points of library X, framework Y, or tool Z are almost ephemeral. Even a company's core software product could just be thrown away and re-written in the new-hotness at the behest of a PM meeting, often losing nuanced domain knowledge in the process.

dc443 7y ago
I have personally stumbled upon this paradigm (value craftsmanship on tools that will have a relevant shelf life), and I credit my ongoing satisfaction with my career to this, at least in part. Without getting into details and specifics, something I highly enjoy doing, I'm referring to things like Vim, tmux, unix utilities and software, various Linux administration knowledge. Various electronics concepts. I now consciously and deeply evaluate a potential skill to learn based on how likely it is going to improve my life in the long term.

Zenbit_UX 7y ago

Despite the tool you work on which solves (maybe) that one very specific problem the author posed, I'd say his point still stands about 99% of other things in this universe.