Ask yourself: When’s the last time you used an app, or visited a website, that was made by an actual individual person? How many of the tools you use at work, or apps you spend time on for fun, come from a community that you're part of? If you’re a coder, when’s the last time you just quickly built something to solve a problem for yourself or simply because it was a fun idea? https://www.linkedin.com/pulse/code-great-heres-why-we-need-yes-anil-dash

Last time I visited a Web site made by an individual? Right now, 15 minutes ago (reading a blog post). Rarely more than a few hours during the day. Tools made by individuals are a different story. I use a few at work, but those are very specialized research tools.

Thanks for sharing @Mariano Guerra, this got me super excited since I am working on this exact problem 🙂 (with DSL approach at the moment)! I agree that a lot of web is already there (medium, wordpress, shopify, wix, bubble, ...), but as @Konrad Hinsen said, if we want to build a tool / actual app, that is different story. That is in part due to tools/apps just inherently being more complex, that is something that we can't avoid, but there is certainly still a lot of space to make it simpler than it is right now (removing accidental complexity).

One of the great mysteries about computers is why so few programmers write programs to speed up their own workflows? Sure, Emacs is a thing, and a lot of people do a bit of customization with their shell. But the vast majority of programmers I've met and worked with, do not do this, and effectively write zero code to help with their own workflows. You can see this in the numbers by looking at the meteoric success of Visual Studio Code (arguably the most popular GUI programming tool in history), which is much harder to customize than say, Emacs, Vim, or Atom.

@robenkleene hm, well the answer regarding writing programs for our own workflows might be pretty simple - it is always lower priority compared to the project we are working on, and it provides long term benefits compared to short term benefits of solving the immediate task (and we naturally go for short term).

I don't disagree that that's a factor, but it feels incomplete to me. For example, you could say the same about learning new programming languages or new frameworks. But I don't find programmers particularly adverse to doing that, and they often actually find that exciting. If I were to rank programmer preference for how invest in longer-term gains, I'd put them in this order: Learn a new language or framework > Learn a new tool (e.g., IDE or text editor) > Write code to solve their own problems The first thing I'd say that ordering reveals is that branding works: languages, frameworks, and tools all have branding, while writing a script doesn't.

This article is how I feel generally about programming and programming languages. What "no code" offers is ready-made components that are easy to compose. But that can be done with (well disciplined) code and libraries all the same. The difference is that you typically have to do that composition in the midst of a lot of programming and language boilerplate / noise. But if that were cleaned up (e.g. provide a clean interface or declarative view) for the components you want, then you can have that "no code" feel on top, but still have all the power to customize and program what goes into it. It's like creating a collection of functions (a library) that give you all the basic tools you need for something simple, except nothing stopping you from also writing new functions or selectively mixing some of those with your own code.

@robenkleene That is a good point, I would also say people prefer learning new stuff to writing their own helper tools. But except for branding, I think there is another big factor: learning is easier then creating something. While learning I read the materials, follow the instructions and play with the tech. No hard decisions, and I know I am doing something good, I am improving myself and I am following instructions, I am making myself more valuable on the job market. Creating a tool / writing a script, on the other hand, means I have to make a lot of decisions (how will it work, how will I do it), I have to do research on my own without clear guidance, and finally, I don't know what the outcome will be, I might fail in building it, and I am not really sure what will the impact on my value on the job market be. Not to mention that if you are working in well developed ecosystem, the "easy" tools are usually already there and present, so you feel the need to build tools less, and what is left to be done is harder and more complex, maybe so much that you don't think it can/should be solved.

Great points about learning and the career-boosting potential of learning languages and frameworks. I definitely agree those are major factors, I'd say you're right and the career boosting potential is probably the #1 reason developers learn new languages and frameworks. About "creating a tool / writing a script", I'm not really talking about projects that are the size and scope of what you're talking about. E.g., there's pretty clear progression for learning to automate: 1. You might learn about Bash aliases, customizable keyboard shortcuts in an IDE/text editor, using a macro utility like Keyboard Maestro on macOS, install a shell utility like ripgrep or rupa z. 2. You start writing your own Bash scripts and functions, maybe write something with AppleScript or Automator on macOS. 3. You write your own text editor extension, browser extension, or shell program. The problems you're talking about only start to show up in #3, whereas in my experience, the majority of developers never even do #1.

Ah I see what you mean @robenkleene! You are right, I was actually thinking more about #3 as you nicely analyzed it. I actually thought that many/most devs do stuff from #1 and #2, but now that I think about it I realize my examples are from a limited circle of people and probably not representative. One thing I did notice with people I worked with is they are not using advanced keybinding system like those that emacs or especially vim offer, which I always feel is a shame since they are so fun/cool/productive, but ok, I assume that is due to the learning curve + perception that vim and emacs are old and so are the keybindings hm.

Yeah, I'm definitely basing my points anecdotally on my particular circle of colleagues as well.

Interesting discussion! I mainly avoid scripting or customization for this weird reason: it feels like tight coupling to me, which is what I try to avoid in programming and system design as well. If I use certain configuration or scripting mechanisms, it initially feels like I have much more control over the system than I have over a system that doesn’t provide these. You don’t notice that it’s an illusion until the system changes dramatically or goes away. In a way I could also describe it as “I want to use a product that has been well designed in the first place, not a mediocre system that only becomes a great one after I put the effort in to customize it.” There are things I want to be involved in building, but there are also things I just want to work without me having to make them work first. That’s why I value good defaults over configurability and extendablity. I’ll rather use a product that is somewhat limited in features, if it chose good defaults over a product that is more configurable but starts with poorly chosen defaults and I have to spend time to set it up the way I want it first. I don’t know exactly where this comes from, and I know way more people — especially in our community — who value configurability more and don’t care about defaults that much. So I know I’m closer to the weird end of the spectrum — is it just me, or are there others who know what I’m talking about? I’m still trying to get to the core of this weird feeling, and it still feels too hard to describe, but it seems obvious to me that it plays a large role in the platform and tool choices we make.

@Stefan I can back this up from my side for sure! Although I love programming/engineering and tinkering, when I need something to work, I will certainly prefer opinionated solution with good defaults then configuring stuff myself. One part is certainly the time I would need to spend on configuring, however I enjoy that sometimes - but the biggest thing is certainly maintainance! Yes, if I configured it myself, it might work exactly as I want it, but what when it stops working? And at that moment, I might not have the luxury of choosing the time when I will fix it, it might be urgent and critical. So for me, to put it simply, it is the cost of maintainance - the less I am responsible for, the more I can focus on what I want.

I like when a system/tool allows you to configure things. But now I also value a lot those with good defaults. And in the end I find myself seeking configurable tools with nice defaults. For example, I use zsh as my interactive shell, with which one can configure lots of things, and I chose it for that. But after having installed it, I found the defaults was good enough for me, and I didn't have to to tweak it much.

To add to this, I wouldnt be so sure that majority of people prefer customisation/extensibility Vs good defaults/ease of usage - it is just that most experts prefer customization/extensibility, due to them being experts who need more power/control, and experts are also much louder in the community since they have more to say, are building tools and so on. It is hard to say to which degree this goes, but I am pretty sure these is some bias there / skewed perception. I remember Haskellers discussing smth similar, about Haskell appearing harder than it is because most of the stuff discussed online is happening between senior Haskellers, so it is rather complex concepts, and if you read Reddit posts for example, you quickly get feeling you will never be productive. But, allegedly we are seeing just the top of the pyramid of Haskellers.

@Martin Not sure if that was in response to my comment, but just to clarify: what I meant and according to my anecdotal experience is that I would assume more people in this particular community and probably among programmers in general to prefer customization, while I also firmly believe that end-users prefer good defaults. Although I’d also argue that many end-users are not making that choice as consciously as programmers/people here do.