1. 38
  1.  

  2. 19

    This is one of the real reasons why I’m pretty disenchanted with mainstream tech. The preoccupation and network effects surrounding what are, at best, tools that promote easy over simple are really depressing. It’s like we don’t, collectively, understand the value of composition at all. We’d rather pore over half-baked docs of a Weird Framework With a God Complex than sit down and actually use the host language. Hype trumps substance, because hype looks like a startup with a clever domain name and marketing.

    We call ourselves rational, but we’re just making easy choices to cover our own asses, and blending in with the crowd. We succumb to the same vapid marketing used in the commercial world. We continually defer to social proof over actual technical excellence, which we’re reluctant to assess. Frankly, we deserve whatever problems we fall into by these attitudes.

    I’m sick of ridiculous groupthink labeled ‘best practices’. I’m sick of a complete lack of intellectual humility, and ignorance of history that came before. I’m sick of self-promotion for it’s own sake, and “GitHub is your resume” and a culture of entitlement that emerges from tons of people viewing open source as a bunch of free stuff.

    P.S. this story has a happy ending: I’m a lot more careful about where & who I listen to now about tech. I prefer communities of people who aspire to simplicity & minimalism in their software over the mega bells and whistles-style of development. It makes a big difference.

    1. 3

      If I’m interested in simplicity and minimalism, which resources could you recommend?

      I’ve had minimalism as a goal in my recent projects (e.g. no ORM, simple APIs, avoiding frameworks where possible, preferring small semi-independent subsystems), but it mostly came out of my own experience and stumbling on interesting links on Lobste.rs.

      It would be great to learn more about other people’s thinking, particularly in the area of JavaScript, Node.js and web apps more generally.

      1. 5

        It’s not quite minimalist-oriented, but first thing that comes to mind is reading through Growing Object-Oriented Software Guided By Tests. I’m thinking specifically of working through what it takes to architect and design great software, which is a prereq for minimalism, as you don’t have the guard rails in place. Learning to build just enough structure (aka architecture) to grow your app is a very powerful idea.

        I think I tend more towards simplicity than minimalism, mostly for ease maintaining said software. I extract a ton of benefit from using the ideas of the IO monad in imperative code; that is, isolating side effects (such as databases/UIs) into their own module, and only calling them from a certain place. Watch Gary Bernhardt’s Boundaries talk to get an example of this.

        FP, to me, is very simple once you learn it. Understand why FP encourages pure code, and how it interoperates with impure code.

        1. 1

          Thank you, I’ll check these out. I’m on board with FP (I’ve been experimenting with Haskell a bit), however, I haven’t worked out how to inject a substantial dose of FP into my JavaScript projects. Everything is geared towards OOP and mutable state so it’s an uphill struggle. Looks like the Boundaries talk may give me some pointers for that.

          1. 3

            Brian Lonsdorf has some interesting suggestions for writing JS in a FP style. The talk “Hey Underscore, You’re Doing It Wrong” is a good starting place for his work. His other talks are also good, and I’ve been enjoying his new project Loop School.

            And +1 for Boundaries, and the work of Gary Bernhardt in general. Destroy All Software did a wonderful job showing me a good way to write in a gradually-more-functional style in an imperative language.

            1. 1

              Great, this is exactly what I was looking for.

        2. 4

          You could join the #lesscode channel @ freenode (the author of this article hangs out there, and people who share similar preferences too).

          Edit: There is also a collection of links on the r/lesscode subreddit.

          1. 3

            Also, check out the suckless-project (http://suckless.org). If you strive for the unix-philosophy, many things will just fall right into place, and in numerous cases, you end up more flexible and efficient than with the popular kitchen-sink solutions.

          2. 3

            Quoting from the article,

            1. Cuba itself is extremely easy to work with because it barely does anything. You can read the entire source in 5 minutes and understand it completely. I’m confident future teams could pick it up.

            This.

          3. 8

            Popularity is the best trait for becoming more popular.

            While this is certainly true, it glosses over what helps a given library/framework become popular in the first place. I tend to think that the best trait (besides popularity) for becoming popular is ease, particularly ease of getting started.

            Think about what made Rails popular. Was it the architecture or the code quality? No. It was the Build a Blog in 15 Minutes video.

            Some developers look down on this sort of thing. “Why are you using #{framework}? Just use these 15 simple high quality modules instead!” But there is something to be said for ease.

            First, knowing how to wire up those 15 modules is the fruit of experience which many developers lack. More importantly, sometimes* a complex, but easy system is the right approach to developing a given application because you happen to hit a framework/library’s sweet spot.

            * I would guess that it’s quite often, actually. Consider how many websites need a datepicker widget. jQuery plus a datepicker plugin is probably the right choice even though it’s technically more complex than finding the perfect datepicker that doesn’t have any jQuery dependencies.

            1. 4

              I think this is short-selling the impact of the 15-Minutes video. Just a reminder, that back then, there was a culture where installing a new module into a framework (in a loose term, e.g. Typo 3 was considered one) was a work of hours by hand and very error-prone. It was very usual to not use frameworks at all. A colleague of mine even got complaints about creating a fast generator for new Typo 3 modules - it would hurt the bottom line, as people charged by hours. PHP frameworks were very unwieldy if there were any, e.g. I used Mojavi back than and it wasn’t any way better than Rails.

              Now, Rails implemented MVC in a fashion that it still fundamentally uses today (!), made sure you can get it up an running for development quickly (deployment was a different thing for a while), soon after popularized REST, integrated Javascript beyond simple effects into the modern web page workflow and turned out to be the prototype for many larger framework that came out in the years after.

              It’s too easy to say “they did show, with nothing behind”. No, they did show with a lot behind. Rails, with all its issues, fundamentally moved web development forward on a technical basis.

              Suddenly, a full blog prototype with development setup was something of 15 minutes.

              1. 1

                I agree with everything you wrote here. I certainly didn’t intend to undersell the importance of developer ease, and the massive improvements Rails made in that area (and many others).

            2. 5

              If I find too many people adopting a certain software tool, I’d probably think it’s bad. It would require an in depth analysis to convince me otherwise, because the mechanics at work are well established.

              The mechanics the author described, of a tool becoming popular just because of a feedback loop, don’t suggest that popular software is usually bad. Rather, they suggest merely that popular software is no better than randomly-picked software. If many people are adopting a certain software tool, that doesn’t mean it’s bad, that means it’s probably average.

              In fact, it’s probably better than average. The article suggests that a tool’s popularity is purely a feedback loop, regardless of the tool’s quality. But when a tool grows in popularity, that can actually improve its quality. The project may draw more core contributors, who catch more bugs, or who bring expertise in competing software and apply it when designing changes to the tool.

              The quality intrinsic to a tool is also not the only thing that matters (though of course it does matter). If two tools are basically identical, but one of them has a bigger community that can answer my questions better and that has already published plugins to integrate with the libraries I need, then the project with the bigger community is a better choice.

              1. 3

                If two tools are basically identical, but one of them has a bigger community that can answer my questions better and that has already published plugins to integrate with the libraries I need, then the project with the bigger community is a better choice.

                Wholeheartedly agree. Not to mention, some projects are started with the intent to collaborate (think open source, or even growing startups). If you want to get the most reach, you need to think about what languages/frameworks are popular so that you can maximize your chances for acquiring talent.

                While I do agree that all languages and frameworks have their strengths and and you can’t label one as genuinely superior to another, making decisions based on community size isn’t a bad idea.

                1. 1

                  But when a tool grows in popularity, that can actually improve its quality. The project may draw more core contributors, who catch more bugs, or who bring expertise in competing software and apply it when designing changes to the tool.

                  It’s hard to tell if popularity improves the quality or not. I’ve been thinking a lot about it, and I hope I can write an analysis soon. You mentioned why popularity may increase the quality, but think about the inverse: what aspects of popularity can decrease the software quality? Sorry for the short reply and the lack of clarifications, I still need more time to wrap up my ideas on this subject.