23 ms·

There's an excellent talk by Rich Hickey (I believe it's this one[1]) where he points out an obsession with how quick something is to understand immediately and

There's an excellent talk by Rich Hickey (I believe it's this one[1]) where he points out an obsession with how quick something is to understand immediately and be productive in—he gives the example of building websites in a single day, and contrasts it to musicians learning and mastering instruments over much longer periods of time. While it's very intuitive to see the appeal in low barrier to entry, there's something to be said about tools that optimize for the long-term. Instruments aren't made for beginners, they're made for people who know how to play them. [1] https://www.youtube.com/watch?v=MCZ3YgeEUPg https://www.youtube.com/watch?v=MCZ3YgeEUPg

PaulDavisThe1st 5y ago
Ditto for both power- and hand-tools used for most craft.
eof 5y ago
Some instruments are made for beginners. I think the same correlations would be easy to find in software productivity. C++ :: Saxaphone Wix :: Recorder; or something
- zwieback 5y ago
  I know C++, played some sax in my youth and recorder as a child. If only I knew Wix, then I could connect the two dots in a 2D graph!
- RcouF1uZ4gsC 5y ago
  > I think C++ is more like the French Horn Excerpts from https://houghtonhorns.com/why-is-the-french-horn-so-hard-to-play/ https://houghtonhorns.com/why-is-the-french-horn-so-hard-to-... The French horn is widely considered to be the most difficult brass instrument to play. The modern-day double French horn is actually a combination of two horns (F, Bb) that share a common mouthpipe and bell. Because the partials (available notes in the harmonic series) are so close together in the third octave, the horn’s most comfortable range, it is fairly easy to miss or “crack” a note. Conversely, the partials that occur in the trumpet’s most comfortable range are comparatively more spread out, allowing for a bit better accuracy and more control. Another reason for the horn being difficult to play lies in the fact that it has the widest range of all the brass instruments: nearly as high as a trumpet and almost as low as a tuba. Additionally, the horn mouthpiece is small and deep, requiring fine muscle control and embouchure development. The mouthpipe is long and slender, creating more resistance for the player to overcome. Because the horn faces backwards–as opposed to the other wind instruments–the horn player must work extra hard to balance and blend with the other members of the wind instrument family.
  - deleted 5y ago
    [deleted]
  - helgee 5y ago
    The French horn is a holy instrument. Because if you blow into the mouthpiece, only God knows what will come out of the other end.
sva_ 5y ago
Wouldn't building a website be more equivalent to playing the instrument? Presuming one has learned how to build a website, like a musician learned to play an instrument.
- andkon 5y ago
  Learning to play an instrument is usually about learning many many tiny discrete skills that build on one another and can be combined in creative ways to express what's most important and vital at that moment. You can play an instrument knowing just to pluck a single note. But it's a lot more fun to play if you know a ton of different skills: you can say so much more. I think the same holds true for coding. You can learn more skills all the time, all of which broaden the realm of what you can create when you sit down at a keyboard again (aka the playing the instrument part).
  - deleted 5y ago
    [deleted]
- dv_dt 5y ago
  Learning general website building technology is like learning to play an instrument, but being asked to build a given website is like being asked to give a performance. It might be a quick rendition or it might be a major performance on a stage (with one obviously being much more prep time than another).
  - HomeDeLaPot 5y ago
    Also, do you know the song(s) already, and do you know how to play the particular instrument requested?
    - dhosek 5y ago
      That's a good aspect of the analogy. I can play pretty much anything with strings (not necessarily well, but I can play it), but being able to play a particular song on it is another thing. Likewise, the programming side of my work is generally pretty trivial (as is the case for probably 99% of most programming that happens in the world). It's the domain knowledge that makes things difficult/interesting/challenging.
f0e4c2f7 5y ago
I'm going to watch that talk later it sounds interesting. Thanks for sharing. This may be addressed in the talk but my immediate reaction is that a truly mastercrafted tool should be both. I tend to agree that where you have to make choices lean towards long term (thats what I personally prefer at least). I think I've sometimes romanticized that attitude a little bit though and reveled in complexity for the sake of complexity. Ideally you're building stuff thats easy to learn but takes a lifetime to master (because of depth of the field, hopefully not because of the unnecessary complexity of the tool.)
_peeley 5y ago
Another great Rich Hickey talk is Simple Made Easy, very similar message. So many of these auto-project tools are very easy to use, but in no way simple to understand and end up adding complexity in the long-term. A good example is a tool like `create-react-app` (especially if you add TypeScript support). It's super easy to use and creates the project scaffold and enormous JS build system for you, but good luck trying to fix it if something breaks!
- skinkestek 5y ago
  I don't know what you do but I maintain 3 projects based on create-react-app and have done for 18 months. Together with a couple of senior guys and some younger devs (both guys and gals) I keep them updated, build new features, rewrite stuff to tsx (we got the projects handed down) and with one single exception I never even thought about the build system.
  - aeturnum 5y ago
    I don't think they were saying create-react-app is bad or unusually fragile. It's that there are problems in building increasingly complex 'quick start' setups with the goal of making them accessible to people with less experience. The less you know about how the internals work, the less you'll be able to intuit about what you can and can't change. For many people who just want to make "an app" this doesn't matter, but it also means that a lot of quick start setups optimize for particular approaches that are built on top of particular sub-sets of how apps are built. So people leave the experience knowing more about how a particular component library than they do about the language or the requirements of mobile, or whatever. Or, to put it another way: increased complexity also increases the difficulty of investigation and modification. Making it easier to get an app 'somewhere' can make it harder for someone to understand what the app does to get where it's going.
- 88913527 5y ago
  My actual experience with reporting the "something broke" in a large, popular OSS project was 18+ months until resolution. A crafty engineer thought it was a good idea to run their in-house optimization on third-party JS libraries to squeeze a few extra bytes out of the final bundle size (going above + beyond conventional methods like minification). Turns out that the overly aggressive optimization caused runtime exceptions, and they ended up cleaning up the feature. I've never had a good long-term experience with tools that try to be or solve everything for me, and today I avoid them.
madflame991 5y ago
I come back to this article every now and then http://www.loper-os.org/?p=861 http://www.loper-os.org/?p=861
TeMPOraL 5y ago
> obsession with how quick something is to understand immediately and be productive in—he gives the example of building websites in a single day, and contrasts it to musicians learning and mastering instruments over much longer periods of time. That's an entirely orthogonal concern to what the article is about. I agree that obsessing over the "zero to proficiency" time the way we do nowadays is very much counterproductive, for the reasons you mentioned. But you also want to be quick for a different reason - to make the tool better for the already-proficient user. Rich also talked a lot about essential vs. accidental complexity. I don't know about you, but myself, the more I code, the more I feel 90%+ of my time spent on coding, and even a good chunk of the design/architecting time, is accidental complexity. This is not just a matter of bad APIs and overcomplicated design - the whole process of programming just takes too fucking long. The languages we use are not expressive enough, not succinct enough to capture our solutions. The tooling we use is not powerful enough to allow for an efficient exploration of the solution space. So the other day I was writing some glue between two incompatible systems. I had my data structures well designed, I know how all the operations mapped. I would be able to write you a precise description of everything in an hour. It still took me more than a week to code it up. All the classes, functions, modules, files, syntax issues, gluing different types of error handlers, baah. Midway, I figured I made a mistake in the design. I knew how to correct it in 30 seconds. It would take a single sentence to explain the problem and the solution. It still took me an hour to implement the fix, because I had to change type signatures, move some files around, and update half a dozen places because it turns out you can't just automatically make bulk modifications in languages that aren't Java or C#. And don't get me started on how much time it takes to figure out the structure of a subsystem in a legacy code base... Point being, even if you know your language and problem space inside out, even if you have decades of coding behind you, day-to-day coding still takes way more work than it should. To me, existing tooling feels conceptually too low-level. Writing feels too low-level. One may counter that typing is mechanical, programming happens in the head - that's true, but at least to me, typing (and especially editing) still has enough overhead that I feel my brain slowing down. The feedback loop is too slow. What I'd currently love to have is code editing environment operating on high-level semantic concepts. One keychord to select a function and display all its callers and callees, in a graph. One keychord to select a parameter and display a diagram of how it flows through code. One key to start inserting a class. One key for adding, deleting or editing anything that isn't a name or comment. References, files, folder structures handled automatically. Etc. Because if testing a single design variation will take me 10 minutes instead of half a day, then I might be able to test a bunch of them instead of committing to first one that feels reasonable. </rant>
hikerclimber1 5y ago
everything is subjective. especially laws.
bob229 5y ago
Terrible analogy. Building a website is not the same as learning how to build a website(or an instrument)
fouric 5y ago
This "obsession with how quick something is to understand immediately and be productive in" is a good concept to have around, and it's something that's been tickling the back of my mind for a while. In particular, I believe that this effect is strongly present in the Cult of Text Processing - there's a large group of programmers who believe that Text Must Be The Answer because it's just so easy to write `ls | grep` - never mind that each UNIX text-processing tool actually has its own bespoke input and output formats (it's not actually plain text), and so anything nontrivial quickly becomes a fragile mess riddled with edge-cases and liberal use of sed/awk. What's even more interesting is that because of the perceived ease of immediate understanding, even those that have deep experience with this paradigm (and should understand how inefficient it actually is) still defend it. Although, I don't think that powerful tools necessarily have to have a high barrier to entry. For instance, maybe you could teach new programmers in Racket without type annotations, then introduce typed Racket as a way to allow them to much more easily learn static typing than adopting a whole new language? Such an approach might have made Rust easier to learn - just disable the borrow checker to learn an easier Rust, and then re-enable it gradually (starting with the easiest parts of your code and then moving to the more complex bits) to ease into what is usually the hardest bit for new Rust users. Tool- and language-developers should focus on making things that are both easy to pick up (Python) and scale well (Common Lisp/Rust).
- mpweiher 5y ago
  > Text Must Be The Answer because it's just so easy to write `ls | grep` That's actually not quite it. What's so fantastic about the textual interface in Unix is that it is the same packaging[1] for both use and reuse. This is highly unusual, usually packaging that is optimised for use is unsuitable for reuse (doesn't compose well) and packaging that is good for reuse is unsuitable for direct use (cumbersome/inconvenient). Using text to fill both roles comes with a ton of compromises, as you rightly point out. It's not really great at either function, but sorta/kinda gets by at both. But even with those compromises, pulling off the feat of having the same packaging for use and reuse is just incredibly powerful. There are other ways of achieving the same result, for example Naked Objects[2] bridges the gap by the programmer only providing the reuse packaging (an OO API) and the tooling then automatically generating direct-use packaging (a GUI). Other ways of bridging the gap that can learn from one or both of these approaches clearly seem possible. [1] https://www.cs.cmu.edu/afs/cs.cmu.edu/project/vit/ftp/pdf/Packaging.pdf https://www.cs.cmu.edu/afs/cs.cmu.edu/project/vit/ftp/pdf/Pa... [2] https://en.wikipedia.org/wiki/Naked_objects https://en.wikipedia.org/wiki/Naked_objects
suifbwish 5y ago
More importantly there are dumb as shit C level people out there reading this that are going to think there is something wrong with their developers because they don’t make apps in a day/minutes/(fill in other dumb and obviously false timeframes for a production time allotment here)
- NoGravitas 5y ago
  > "dumb as shit C level people" It is preferred, stylistically, to avoid redundancy in your writing style these days.
  - suifbwish 5y ago
    Good catch
splistud 5y ago
These are excellent points. But what if a musician is hired to compose a song that is to be played on a brand new instrument? Would the musician not want the instrument to be playable rudimentarily very quickly, so he can begin to demonstrate where he is going with the song, so as to get early feedback? While this is a tortured analogy (as a musician, I want no feedback until I'm done). I believe that wanting tools that optimize for the long-term, coupled with needing early feedback is precisely why many use certain technologies for demos, then build in other technologies. The faster the demo can be built the better. The earlier you get feedback on the UI the better. The earlier you show a demo, the sooner you find out what the user really needs as compared to what you've been told (and the sooner the user finds out what they don't need, despite what they thought).
yangikan 5y ago
I guess what would be useful is a "Visual Basic for the web". Back in the day, one could bring up pretty large applications quite quickly using Visual Basic and Delphi.
- TuringTest 5y ago
  What would be useful is an "Excel for web apps". The spreadsheet runtime model is much better adapted to the way non-developers think than what VB6-style visual programming provides. Having code and actual application data allows people without programming experience to build data types and simple to average functions and debug errors in the business logic, whereas with classic code they can't get pass the parser to get their poorly written syntax understood by the compiler. Developers tend to think that writing simple code makes application development easy, but actually learning the syntax and runtime model of classic imperative code is usually the hardest part to newcomers. The functional-reactive execution of the spreadsheet together with the intermixing of data and code provides a simple mental model of instant evaluation and exploration, similar to the benefits a REPL provides to a seasoned developer, minus the syntax errors and deep nested structures. Notebook-style development environments like observablehq.org are almost there (specially those with a spreadsheet-like semantics), though it still keeps too harsh a separation between the code environment and the "runtime values" environment - i.e. its cells are "too large" when compared to spreadsheet cells.
  - ilkan 5y ago
    That's some food for thought. My issue with programming courses is they ask you to memorize the commands then use them; most programming is about creating the logic then QA'ing with some data. Excel is data-first and becomes more like a game, trying different approaches with a clear picture of the end in mind. It's easier to persevere.
    - TuringTest 5y ago
      Quite true, and too often developers are not aware of how important data-first is for their own work in the exploratory part of programming. Programmers have powerful interactive shells and debug environments, yet most courses center the teaching and communication of how a program works around the concepts in the finished product (a working program), more than how you arrive piecewise to the full solution by iterating small parts of the concepts in the domain problem and finding the correct parts of code to handle them.
iainmerrick 5y ago
The musical instrument analogy can be taken the other way, though. After you’ve spent years learning to sight read, you can play almost anything right away if you have the sheet music, even if you’ve never heard it before. Or after you’ve spent years learning to play by ear, you can play any tune you know from memory, or jam along to almost anything.
abetusk 5y ago
Notice that the explosion of rap, hip-hop and punk were because the barrier to entry to music making through sampling and distribution was lowered. The 1980s and 1990s were replete with high profile artists that became famous by using the discarded drum machines and synthesizers of the time [0]. Today, (I believe) most artists use synthesizers and DAWs to create full albums. Eletronica, rap and hip-hop are some of the most popular musical genres [1] [2]. It's not uncommon to see artists that are just one or two people, enabled by a professional grade studio on a PC. [0] https://www.theverge.com/2017/4/3/15162488/roland-tr-808-music-drum-machine-revolutionized-music https://www.theverge.com/2017/4/3/15162488/roland-tr-808-mus... [1] https://ucladatares.medium.com/visualizing-trends-and-patterns-in-pitchfork-reviews-cad1a130869b https://ucladatares.medium.com/visualizing-trends-and-patter... [2] https://www.r-bloggers.com/2017/12/clustering-music-genres-with-r/ https://www.r-bloggers.com/2017/12/clustering-music-genres-w...
- skrebbel 5y ago
  I disagree that this is a good analogy, because you're referring to a financial barrier to entry and the GP is talking about effort, not money. Of the genres you mention, only punk could reasonably be considered a low barrier to entry genre in that some of the biggest punk bands were famous for hardly being able to play their instruments. But it's also the single genre missing from your "Today," paragraph, indicating that yes, indeed, making good hip hop or electronica is hard even with a fantastic computer with fantastic software.
  - teebs 5y ago
    As much as I love hip hop and electronica, and as difficult as it is to make excellent music in those genres, it really is very easy to make okay music. Have you ever used FL Studio (formerly known as FruityLoops)? I remember downloading it freshman year of high school and being able to make a catchy-but-derivative hip-hop beat in minutes. That's not enough to make a hit song, but I think luck is a bigger factor than effort for a lot of underground hits. Today, it's still how a lot of hip-hop and electronica gets made: https://en.wikipedia.org/wiki/FL_Studio#Notable_users https://en.wikipedia.org/wiki/FL_Studio#Notable_users
hardwaregeek 5y ago
Except…are most apps that creative? Let’s face it, a lot of programming is boring variations of CRUD. Yes there’s creative code and I’m sure Rich Hickey does a lot of it, but there’s a lot of boring, banal code that we shouldn’t be real precious about.
- cies 5y ago
  There's always challenges. Let's say we needs some forms. Nothing to fancy. Consider 2 options: React+JS+Redox+formLib+... and Elm. It just some banal forms, I agree. But having to come back to it may months/years later I much rather see back the Elm situation. Typing helps a lot here. Small scope project too. Now it seems this "build in minutes" uses JS and PHP. Sorry, but both are terrible choices for long term maintainability.
- dgb23 5y ago
  I make those. And yes, it’s 90% boring in terms of tech. The exciting part is to make something that my users like to use, that fits them like a glove. And polish. Polish is hard and endless, there is always a tension between pragmatism and perfectionism. Those two parts demand the most seamless and direct expression, and continuous feedback. It’s not quick, it’s deliberate and diligent. That’s what I value and aspire to.
- TillE 5y ago
  The vast, vast majority of playing an instrument well is about deep technical skill, not creativity. That's what we're discussing here.
- iammisc 5y ago
  In my experience, 99% of every app is CRUD. Then there's the 1% that is your differentiation that takes six months to build. To the instrument analogy it's like Beethoven's 5th. Almost anyone can play the beginning on the piano with a few minutes of fooling around (dun dun dun da....). But to actually play the entire thing well will take years of practice because it's the other parts that are hard to get right and must be correct to work.
true_religion 5y ago
People are okay with how long it takes to master computer programming (or science). If they weren’t we wouldn’t have 4 year degrees for it. However unlike music, there are new tools being made constantly because the practice of programming feeds the same skills one needs to make tooling. If musicians had 10,000 instruments to choose from, each with some subtle gotcha that will only make itself known once you get in deep… then maybe they’d want instruments to be easy to play too. A good comparison is songwriting. Lots of artists like songs that are easy to play. Piano pieces that are complicated get put down for later, unless they are classical master pieces. Guitar songs that require too fast a rhythm don’t get as much play time in anyone’s jam session either.
DoreenMichele 5y ago
I don't code. I would love to learn and may still someday and there's an app I would like to build. This article doesn't give me any idea where I would start. At all. I wish it did. I've looked around for quick and dirty ways to try to build the app I want to build. They never seem to do what I want them to do, the "in minutes" part fails to materialize for an outsider without a strong coding background, etc. I think there are some wonderful tools out there and it's always good to lower the barrier to entry so people with other strengths can do their thing, but I read ideas like this and think of a book I saw written by a professional clothing maker who was decrying the shortcomings of off-the-rack clothes and the punchline was to the effect of "Why would you wear that dreck? Life is so much better when you can easily make custom pants in minutes -- like I can because of my many years in the industry!" I didn't buy the book. My mom sews beautifully. I know something about making clothes and, no, you aren't going to replace off-the-rack clothes with teaching the whole world how to make custom clothes "in minutes" because that's so much better and easier.
- pdimitar 5y ago
  Yes, you are very correct. The "build X in minutes" definitely assumes strong background because you know what to look for. Without that you might as well give it blank stares for a year. But then again, I am not sure this article -- and presented technology -- is aimed at you. IMO it's more aimed at jaded programmers who are sick of hand-rolling the ever-almost-the-same 99% identical code for each project. Hopefully such tools can give them a less stressful time. For a programming beginner who would like to build something you'd be much better off looking at something like Airtable.
  - DoreenMichele 5y ago
    I do blogspot blogs and the interface is brilliant in terms of letting anyone of any skill level interact with it. They have precoded templates you can just click on. They have the option to "customize" where you can click on different colors or whatever without knowing any coding. You can also use your own hex codes to change colors to exactly what you want. You can add custom CSS snippets safely without digging around in the code. If you are a serious coder, you can access the code and edit. I do everything but that last because I know some HTML and CSS (and UX etc) but I don't have the programming experience to figure out how to go into the guts of the code. I spent hours and hours learning my way around the blogspot interface. Yes, anyone can just click a template and swap out background photos or whatever but if you don't already have prior experience with their backend and some basic design knowledge and UX knowledge, good luck making it do what you want while looking good and yadda. I spent some time thinking I could sell my skills as a blogspot expert but there doesn't seem to be a market for it. People with money and ambition and so forth don't use blogspot. People who use it don't pay for help with it. They do it themselves. So I have some idea of how much background knowledge someone needs to have to "do X in minutes" though I'm not a serious coder. I'm the computer geek in some circles I hang in though I would never identify that way on HN, just like I don't generally try to tell HN that I'm some mathy person. I am often the "mathy" person in other settings. Just not here. Anyway, thanks to anyone who suggested some entry level options for me.
voidhorse 5y ago
I wish Hickey wasn’t in the programming business and was just a full time philosopher. In a lot of ways his observations on social phenomena, his approach to abstract concepts, and his communication style in general is more interesting than clojure and datatomic (though these technologies are still great). Obsession indeed. Everyone wants to be a master in five minutes. There’s this funny sort of paradox that arose out of the advent of digital technology where, because everything is nearly instantaneous, more people theoretically have more leisure time to plug 10+ years into mastering some hobby, but simultaneously, the instantaneousness and constant rush of digital distractions has lowered the tolerance for temporal investment (i.e. patience) in general, nullifying what would otherwise be a gain in leisure and expertise (e.g. masterclass, whose entire business model is predicated on the ridiculous premise that to be as successful as the stars only requires taking one course of their best tips and tricks and not, idk, thousands of hours of dedicated effort) In my personal experience, I’ve found that most of the shortcuts aren’t actual shortcuts. Everything I know in the realm of computing I’ve taught myself, and, I have to say, I didn’t really progress until about 8 years in I finally buckled down and decided to read actual comp sci papers and really dwell on them and understand them, and by god use a pen and paper when necessary, rather than spend my time coding yet another example todo app from a tutorial on a website somewhere. The fact that many resources around computing are free is both a blessing and a curse. It’s great because it allows people to learn on their own but bad since the crap always bubbles to the top.
- MathYouF 5y ago
  Which papers or educational resources do you recommend?
Too 5y ago
Yes. Almost every single app framework has a shiny hello-world-todo-app pitcher that takes 5 minutes to write. Still, every time, two weeks later when writing your real app, you'll inevitably hit that nasty reactive-router-fluxcapacitor-synchronization dead end inherent limitation (or bug) in the framework, which is world famous and has had an open issue on github for 2 years, where the only workaround is to do things in a much worse way instead, inflicting more pain than the benefit given by the framework. What I'm trying to say is that when choosing a framework, i don't want to see a hello world as example. I want to know how well it will scale for future development.

PaulDavisThe1st 5y ago

Ditto for both power- and hand-tools used for most craft.

eof 5y ago

Some instruments are made for beginners. I think the same correlations would be easy to find in software productivity. C++ :: Saxaphone Wix :: Recorder; or something

zwieback 5y ago
I know C++, played some sax in my youth and recorder as a child. If only I knew Wix, then I could connect the two dots in a 2D graph!
RcouF1uZ4gsC 5y ago
> I think C++ is more like the French Horn Excerpts from https://houghtonhorns.com/why-is-the-french-horn-so-hard-to-play/ https://houghtonhorns.com/why-is-the-french-horn-so-hard-to-... The French horn is widely considered to be the most difficult brass instrument to play. The modern-day double French horn is actually a combination of two horns (F, Bb) that share a common mouthpipe and bell. Because the partials (available notes in the harmonic series) are so close together in the third octave, the horn’s most comfortable range, it is fairly easy to miss or “crack” a note. Conversely, the partials that occur in the trumpet’s most comfortable range are comparatively more spread out, allowing for a bit better accuracy and more control. Another reason for the horn being difficult to play lies in the fact that it has the widest range of all the brass instruments: nearly as high as a trumpet and almost as low as a tuba. Additionally, the horn mouthpiece is small and deep, requiring fine muscle control and embouchure development. The mouthpipe is long and slender, creating more resistance for the player to overcome. Because the horn faces backwards–as opposed to the other wind instruments–the horn player must work extra hard to balance and blend with the other members of the wind instrument family.
- deleted 5y ago
  [deleted]
- helgee 5y ago
  The French horn is a holy instrument. Because if you blow into the mouthpiece, only God knows what will come out of the other end.

sva_ 5y ago

Wouldn't building a website be more equivalent to playing the instrument? Presuming one has learned how to build a website, like a musician learned to play an instrument.

andkon 5y ago
Learning to play an instrument is usually about learning many many tiny discrete skills that build on one another and can be combined in creative ways to express what's most important and vital at that moment. You can play an instrument knowing just to pluck a single note. But it's a lot more fun to play if you know a ton of different skills: you can say so much more. I think the same holds true for coding. You can learn more skills all the time, all of which broaden the realm of what you can create when you sit down at a keyboard again (aka the playing the instrument part).
- deleted 5y ago
  [deleted]
dv_dt 5y ago
Learning general website building technology is like learning to play an instrument, but being asked to build a given website is like being asked to give a performance. It might be a quick rendition or it might be a major performance on a stage (with one obviously being much more prep time than another).
- HomeDeLaPot 5y ago
  Also, do you know the song(s) already, and do you know how to play the particular instrument requested?
  - dhosek 5y ago
    That's a good aspect of the analogy. I can play pretty much anything with strings (not necessarily well, but I can play it), but being able to play a particular song on it is another thing. Likewise, the programming side of my work is generally pretty trivial (as is the case for probably 99% of most programming that happens in the world). It's the domain knowledge that makes things difficult/interesting/challenging.

f0e4c2f7 5y ago

I'm going to watch that talk later it sounds interesting. Thanks for sharing. This may be addressed in the talk but my immediate reaction is that a truly mastercrafted tool should be both. I tend to agree that where you have to make choices lean towards long term (thats what I personally prefer at least). I think I've sometimes romanticized that attitude a little bit though and reveled in complexity for the sake of complexity. Ideally you're building stuff thats easy to learn but takes a lifetime to master (because of depth of the field, hopefully not because of the unnecessary complexity of the tool.)

_peeley 5y ago

Another great Rich Hickey talk is Simple Made Easy, very similar message. So many of these auto-project tools are very easy to use, but in no way simple to understand and end up adding complexity in the long-term. A good example is a tool like `create-react-app` (especially if you add TypeScript support). It's super easy to use and creates the project scaffold and enormous JS build system for you, but good luck trying to fix it if something breaks!

skinkestek 5y ago
I don't know what you do but I maintain 3 projects based on create-react-app and have done for 18 months. Together with a couple of senior guys and some younger devs (both guys and gals) I keep them updated, build new features, rewrite stuff to tsx (we got the projects handed down) and with one single exception I never even thought about the build system.
- aeturnum 5y ago
  I don't think they were saying create-react-app is bad or unusually fragile. It's that there are problems in building increasingly complex 'quick start' setups with the goal of making them accessible to people with less experience. The less you know about how the internals work, the less you'll be able to intuit about what you can and can't change. For many people who just want to make "an app" this doesn't matter, but it also means that a lot of quick start setups optimize for particular approaches that are built on top of particular sub-sets of how apps are built. So people leave the experience knowing more about how a particular component library than they do about the language or the requirements of mobile, or whatever. Or, to put it another way: increased complexity also increases the difficulty of investigation and modification. Making it easier to get an app 'somewhere' can make it harder for someone to understand what the app does to get where it's going.
88913527 5y ago
My actual experience with reporting the "something broke" in a large, popular OSS project was 18+ months until resolution. A crafty engineer thought it was a good idea to run their in-house optimization on third-party JS libraries to squeeze a few extra bytes out of the final bundle size (going above + beyond conventional methods like minification). Turns out that the overly aggressive optimization caused runtime exceptions, and they ended up cleaning up the feature. I've never had a good long-term experience with tools that try to be or solve everything for me, and today I avoid them.

madflame991 5y ago

I come back to this article every now and then http://www.loper-os.org/?p=861 http://www.loper-os.org/?p=861

TeMPOraL 5y ago

> obsession with how quick something is to understand immediately and be productive in—he gives the example of building websites in a single day, and contrasts it to musicians learning and mastering instruments over much longer periods of time. That's an entirely orthogonal concern to what the article is about. I agree that obsessing over the "zero to proficiency" time the way we do nowadays is very much counterproductive, for the reasons you mentioned. But you also want to be quick for a different reason - to make the tool better for the already-proficient user. Rich also talked a lot about essential vs. accidental complexity. I don't know about you, but myself, the more I code, the more I feel 90%+ of my time spent on coding, and even a good chunk of the design/architecting time, is accidental complexity. This is not just a matter of bad APIs and overcomplicated design - the whole process of programming just takes too fucking long. The languages we use are not expressive enough, not succinct enough to capture our solutions. The tooling we use is not powerful enough to allow for an efficient exploration of the solution space. So the other day I was writing some glue between two incompatible systems. I had my data structures well designed, I know how all the operations mapped. I would be able to write you a precise description of everything in an hour. It still took me more than a week to code it up. All the classes, functions, modules, files, syntax issues, gluing different types of error handlers, baah. Midway, I figured I made a mistake in the design. I knew how to correct it in 30 seconds. It would take a single sentence to explain the problem and the solution. It still took me an hour to implement the fix, because I had to change type signatures, move some files around, and update half a dozen places because it turns out you can't just automatically make bulk modifications in languages that aren't Java or C#. And don't get me started on how much time it takes to figure out the structure of a subsystem in a legacy code base... Point being, even if you know your language and problem space inside out, even if you have decades of coding behind you, day-to-day coding still takes way more work than it should. To me, existing tooling feels conceptually too low-level. Writing feels too low-level. One may counter that typing is mechanical, programming happens in the head - that's true, but at least to me, typing (and especially editing) still has enough overhead that I feel my brain slowing down. The feedback loop is too slow. What I'd currently love to have is code editing environment operating on high-level semantic concepts. One keychord to select a function and display all its callers and callees, in a graph. One keychord to select a parameter and display a diagram of how it flows through code. One key to start inserting a class. One key for adding, deleting or editing anything that isn't a name or comment. References, files, folder structures handled automatically. Etc. Because if testing a single design variation will take me 10 minutes instead of half a day, then I might be able to test a bunch of them instead of committing to first one that feels reasonable. </rant>

hikerclimber1 5y ago

everything is subjective. especially laws.

bob229 5y ago

Terrible analogy. Building a website is not the same as learning how to build a website(or an instrument)

fouric 5y ago

This "obsession with how quick something is to understand immediately and be productive in" is a good concept to have around, and it's something that's been tickling the back of my mind for a while. In particular, I believe that this effect is strongly present in the Cult of Text Processing - there's a large group of programmers who believe that Text Must Be The Answer because it's just so easy to write `ls | grep` - never mind that each UNIX text-processing tool actually has its own bespoke input and output formats (it's not actually plain text), and so anything nontrivial quickly becomes a fragile mess riddled with edge-cases and liberal use of sed/awk. What's even more interesting is that because of the perceived ease of immediate understanding, even those that have deep experience with this paradigm (and should understand how inefficient it actually is) still defend it. Although, I don't think that powerful tools necessarily have to have a high barrier to entry. For instance, maybe you could teach new programmers in Racket without type annotations, then introduce typed Racket as a way to allow them to much more easily learn static typing than adopting a whole new language? Such an approach might have made Rust easier to learn - just disable the borrow checker to learn an easier Rust, and then re-enable it gradually (starting with the easiest parts of your code and then moving to the more complex bits) to ease into what is usually the hardest bit for new Rust users. Tool- and language-developers should focus on making things that are both easy to pick up (Python) and scale well (Common Lisp/Rust).

mpweiher 5y ago
> Text Must Be The Answer because it's just so easy to write `ls | grep` That's actually not quite it. What's so fantastic about the textual interface in Unix is that it is the same packaging[1] for both use and reuse. This is highly unusual, usually packaging that is optimised for use is unsuitable for reuse (doesn't compose well) and packaging that is good for reuse is unsuitable for direct use (cumbersome/inconvenient). Using text to fill both roles comes with a ton of compromises, as you rightly point out. It's not really great at either function, but sorta/kinda gets by at both. But even with those compromises, pulling off the feat of having the same packaging for use and reuse is just incredibly powerful. There are other ways of achieving the same result, for example Naked Objects[2] bridges the gap by the programmer only providing the reuse packaging (an OO API) and the tooling then automatically generating direct-use packaging (a GUI). Other ways of bridging the gap that can learn from one or both of these approaches clearly seem possible. [1] https://www.cs.cmu.edu/afs/cs.cmu.edu/project/vit/ftp/pdf/Packaging.pdf https://www.cs.cmu.edu/afs/cs.cmu.edu/project/vit/ftp/pdf/Pa... [2] https://en.wikipedia.org/wiki/Naked_objects https://en.wikipedia.org/wiki/Naked_objects

suifbwish 5y ago

More importantly there are dumb as shit C level people out there reading this that are going to think there is something wrong with their developers because they don’t make apps in a day/minutes/(fill in other dumb and obviously false timeframes for a production time allotment here)

NoGravitas 5y ago
> "dumb as shit C level people" It is preferred, stylistically, to avoid redundancy in your writing style these days.
- suifbwish 5y ago
  Good catch

splistud 5y ago

These are excellent points. But what if a musician is hired to compose a song that is to be played on a brand new instrument? Would the musician not want the instrument to be playable rudimentarily very quickly, so he can begin to demonstrate where he is going with the song, so as to get early feedback? While this is a tortured analogy (as a musician, I want no feedback until I'm done). I believe that wanting tools that optimize for the long-term, coupled with needing early feedback is precisely why many use certain technologies for demos, then build in other technologies. The faster the demo can be built the better. The earlier you get feedback on the UI the better. The earlier you show a demo, the sooner you find out what the user really needs as compared to what you've been told (and the sooner the user finds out what they don't need, despite what they thought).

yangikan 5y ago

I guess what would be useful is a "Visual Basic for the web". Back in the day, one could bring up pretty large applications quite quickly using Visual Basic and Delphi.

TuringTest 5y ago
What would be useful is an "Excel for web apps". The spreadsheet runtime model is much better adapted to the way non-developers think than what VB6-style visual programming provides. Having code and actual application data allows people without programming experience to build data types and simple to average functions and debug errors in the business logic, whereas with classic code they can't get pass the parser to get their poorly written syntax understood by the compiler. Developers tend to think that writing simple code makes application development easy, but actually learning the syntax and runtime model of classic imperative code is usually the hardest part to newcomers. The functional-reactive execution of the spreadsheet together with the intermixing of data and code provides a simple mental model of instant evaluation and exploration, similar to the benefits a REPL provides to a seasoned developer, minus the syntax errors and deep nested structures. Notebook-style development environments like observablehq.org are almost there (specially those with a spreadsheet-like semantics), though it still keeps too harsh a separation between the code environment and the "runtime values" environment - i.e. its cells are "too large" when compared to spreadsheet cells.
- ilkan 5y ago
  That's some food for thought. My issue with programming courses is they ask you to memorize the commands then use them; most programming is about creating the logic then QA'ing with some data. Excel is data-first and becomes more like a game, trying different approaches with a clear picture of the end in mind. It's easier to persevere.
  - TuringTest 5y ago
    Quite true, and too often developers are not aware of how important data-first is for their own work in the exploratory part of programming. Programmers have powerful interactive shells and debug environments, yet most courses center the teaching and communication of how a program works around the concepts in the finished product (a working program), more than how you arrive piecewise to the full solution by iterating small parts of the concepts in the domain problem and finding the correct parts of code to handle them.

iainmerrick 5y ago

The musical instrument analogy can be taken the other way, though. After you’ve spent years learning to sight read, you can play almost anything right away if you have the sheet music, even if you’ve never heard it before. Or after you’ve spent years learning to play by ear, you can play any tune you know from memory, or jam along to almost anything.

abetusk 5y ago

Notice that the explosion of rap, hip-hop and punk were because the barrier to entry to music making through sampling and distribution was lowered. The 1980s and 1990s were replete with high profile artists that became famous by using the discarded drum machines and synthesizers of the time [0]. Today, (I believe) most artists use synthesizers and DAWs to create full albums. Eletronica, rap and hip-hop are some of the most popular musical genres [1] [2]. It's not uncommon to see artists that are just one or two people, enabled by a professional grade studio on a PC. [0] https://www.theverge.com/2017/4/3/15162488/roland-tr-808-music-drum-machine-revolutionized-music https://www.theverge.com/2017/4/3/15162488/roland-tr-808-mus... [1] https://ucladatares.medium.com/visualizing-trends-and-patterns-in-pitchfork-reviews-cad1a130869b https://ucladatares.medium.com/visualizing-trends-and-patter... [2] https://www.r-bloggers.com/2017/12/clustering-music-genres-with-r/ https://www.r-bloggers.com/2017/12/clustering-music-genres-w...

skrebbel 5y ago
I disagree that this is a good analogy, because you're referring to a financial barrier to entry and the GP is talking about effort, not money. Of the genres you mention, only punk could reasonably be considered a low barrier to entry genre in that some of the biggest punk bands were famous for hardly being able to play their instruments. But it's also the single genre missing from your "Today," paragraph, indicating that yes, indeed, making good hip hop or electronica is hard even with a fantastic computer with fantastic software.
- teebs 5y ago
  As much as I love hip hop and electronica, and as difficult as it is to make excellent music in those genres, it really is very easy to make okay music. Have you ever used FL Studio (formerly known as FruityLoops)? I remember downloading it freshman year of high school and being able to make a catchy-but-derivative hip-hop beat in minutes. That's not enough to make a hit song, but I think luck is a bigger factor than effort for a lot of underground hits. Today, it's still how a lot of hip-hop and electronica gets made: https://en.wikipedia.org/wiki/FL_Studio#Notable_users https://en.wikipedia.org/wiki/FL_Studio#Notable_users

hardwaregeek 5y ago

Except…are most apps that creative? Let’s face it, a lot of programming is boring variations of CRUD. Yes there’s creative code and I’m sure Rich Hickey does a lot of it, but there’s a lot of boring, banal code that we shouldn’t be real precious about.

cies 5y ago
There's always challenges. Let's say we needs some forms. Nothing to fancy. Consider 2 options: React+JS+Redox+formLib+... and Elm. It just some banal forms, I agree. But having to come back to it may months/years later I much rather see back the Elm situation. Typing helps a lot here. Small scope project too. Now it seems this "build in minutes" uses JS and PHP. Sorry, but both are terrible choices for long term maintainability.
dgb23 5y ago
I make those. And yes, it’s 90% boring in terms of tech. The exciting part is to make something that my users like to use, that fits them like a glove. And polish. Polish is hard and endless, there is always a tension between pragmatism and perfectionism. Those two parts demand the most seamless and direct expression, and continuous feedback. It’s not quick, it’s deliberate and diligent. That’s what I value and aspire to.
TillE 5y ago
The vast, vast majority of playing an instrument well is about deep technical skill, not creativity. That's what we're discussing here.
iammisc 5y ago
In my experience, 99% of every app is CRUD. Then there's the 1% that is your differentiation that takes six months to build. To the instrument analogy it's like Beethoven's 5th. Almost anyone can play the beginning on the piano with a few minutes of fooling around (dun dun dun da....). But to actually play the entire thing well will take years of practice because it's the other parts that are hard to get right and must be correct to work.

true_religion 5y ago

People are okay with how long it takes to master computer programming (or science). If they weren’t we wouldn’t have 4 year degrees for it. However unlike music, there are new tools being made constantly because the practice of programming feeds the same skills one needs to make tooling. If musicians had 10,000 instruments to choose from, each with some subtle gotcha that will only make itself known once you get in deep… then maybe they’d want instruments to be easy to play too. A good comparison is songwriting. Lots of artists like songs that are easy to play. Piano pieces that are complicated get put down for later, unless they are classical master pieces. Guitar songs that require too fast a rhythm don’t get as much play time in anyone’s jam session either.

DoreenMichele 5y ago

I don't code. I would love to learn and may still someday and there's an app I would like to build. This article doesn't give me any idea where I would start. At all. I wish it did. I've looked around for quick and dirty ways to try to build the app I want to build. They never seem to do what I want them to do, the "in minutes" part fails to materialize for an outsider without a strong coding background, etc. I think there are some wonderful tools out there and it's always good to lower the barrier to entry so people with other strengths can do their thing, but I read ideas like this and think of a book I saw written by a professional clothing maker who was decrying the shortcomings of off-the-rack clothes and the punchline was to the effect of "Why would you wear that dreck? Life is so much better when you can easily make custom pants in minutes -- like I can because of my many years in the industry!" I didn't buy the book. My mom sews beautifully. I know something about making clothes and, no, you aren't going to replace off-the-rack clothes with teaching the whole world how to make custom clothes "in minutes" because that's so much better and easier.

pdimitar 5y ago
Yes, you are very correct. The "build X in minutes" definitely assumes strong background because you know what to look for. Without that you might as well give it blank stares for a year. But then again, I am not sure this article -- and presented technology -- is aimed at you. IMO it's more aimed at jaded programmers who are sick of hand-rolling the ever-almost-the-same 99% identical code for each project. Hopefully such tools can give them a less stressful time. For a programming beginner who would like to build something you'd be much better off looking at something like Airtable.
- DoreenMichele 5y ago
  I do blogspot blogs and the interface is brilliant in terms of letting anyone of any skill level interact with it. They have precoded templates you can just click on. They have the option to "customize" where you can click on different colors or whatever without knowing any coding. You can also use your own hex codes to change colors to exactly what you want. You can add custom CSS snippets safely without digging around in the code. If you are a serious coder, you can access the code and edit. I do everything but that last because I know some HTML and CSS (and UX etc) but I don't have the programming experience to figure out how to go into the guts of the code. I spent hours and hours learning my way around the blogspot interface. Yes, anyone can just click a template and swap out background photos or whatever but if you don't already have prior experience with their backend and some basic design knowledge and UX knowledge, good luck making it do what you want while looking good and yadda. I spent some time thinking I could sell my skills as a blogspot expert but there doesn't seem to be a market for it. People with money and ambition and so forth don't use blogspot. People who use it don't pay for help with it. They do it themselves. So I have some idea of how much background knowledge someone needs to have to "do X in minutes" though I'm not a serious coder. I'm the computer geek in some circles I hang in though I would never identify that way on HN, just like I don't generally try to tell HN that I'm some mathy person. I am often the "mathy" person in other settings. Just not here. Anyway, thanks to anyone who suggested some entry level options for me.

voidhorse 5y ago

I wish Hickey wasn’t in the programming business and was just a full time philosopher. In a lot of ways his observations on social phenomena, his approach to abstract concepts, and his communication style in general is more interesting than clojure and datatomic (though these technologies are still great). Obsession indeed. Everyone wants to be a master in five minutes. There’s this funny sort of paradox that arose out of the advent of digital technology where, because everything is nearly instantaneous, more people theoretically have more leisure time to plug 10+ years into mastering some hobby, but simultaneously, the instantaneousness and constant rush of digital distractions has lowered the tolerance for temporal investment (i.e. patience) in general, nullifying what would otherwise be a gain in leisure and expertise (e.g. masterclass, whose entire business model is predicated on the ridiculous premise that to be as successful as the stars only requires taking one course of their best tips and tricks and not, idk, thousands of hours of dedicated effort) In my personal experience, I’ve found that most of the shortcuts aren’t actual shortcuts. Everything I know in the realm of computing I’ve taught myself, and, I have to say, I didn’t really progress until about 8 years in I finally buckled down and decided to read actual comp sci papers and really dwell on them and understand them, and by god use a pen and paper when necessary, rather than spend my time coding yet another example todo app from a tutorial on a website somewhere. The fact that many resources around computing are free is both a blessing and a curse. It’s great because it allows people to learn on their own but bad since the crap always bubbles to the top.

MathYouF 5y ago
Which papers or educational resources do you recommend?

Too 5y ago

Yes. Almost every single app framework has a shiny hello-world-todo-app pitcher that takes 5 minutes to write. Still, every time, two weeks later when writing your real app, you'll inevitably hit that nasty reactive-router-fluxcapacitor-synchronization dead end inherent limitation (or bug) in the framework, which is world famous and has had an open issue on github for 2 years, where the only workaround is to do things in a much worse way instead, inflicting more pain than the benefit given by the framework. What I'm trying to say is that when choosing a framework, i don't want to see a hello world as example. I want to know how well it will scale for future development.