This distinction is a more useful one that the article made. I love dockerfiles and immutability, but there are good cases for mutable containers, too.
asciidoc is my favourite too, thanks to Asciidoctor. I agree, asciidoc hits the sweet spots as a format. Been frustrated by the tooling lately though. I can see the huge effort put into Asciidoctor, and am thankful for it, but there are still big downsides i.e. no semantic html 5 output, difficult (or at least more difficult than necessary) integration with image generators, heavyweight (only ruby dependency on my entire machine). I imagine this just needs more time and resources put to it, as all these issues (except the ruby one) are open on GitHub.
I have no expertise, but this is my sleep. It turns out I have sleep apnea. I can "sleep" for 8 hours, but it does very little good. With apnea, you wake up as much as a few times an hour, getting very little REM. It took me years to consider apnea because I'm thin and somewhat fit. But all sorts can have it.
I have to disagree with other responses. I think you could make a career of this for the same reason management consultants can.
You could swoop in and "fix" some stuff and then leave the in-house team not understanding what you've done. That sounds profitable. You might even get called back to fix things a second time.
As with management consulting, I think it would at the system level tend to do more harm than good, even if you do good work and get paid well for it. I agree strongly with feoren that the code needs to reflect the in-house developers' mental models of the domain or everything will fall apart. If you fix things and then give them a bunch of processes and coding standards to follow, they will not do well and you will be thought of as some clueless architecture astronaut by them. But profitably.
I have been getting tired of node dependencies and not knowing what I'm running or when it will break. I make simple things for small number of users and started playing with just writing my own CGI in C++ or bash behind thttpd. This appears to be working very well so far and runs on a vanilla Linux install with deps just on system libs and gcc. With all the pain and unsafety of deps, this might actually make most sense. What new vulnerabilities am I inviting? Why aren't we still doing things this way? It seems... much easier, perhaps not to make it but to secure and sustain it.
I find this pervasive idea that "documenting" things is just a thoughtless dump of facts very troublesome.
Certainly, most "documentation" I read is just a thoughtless dunp of arbitrary facts about some system, design, code, or event or what have you. But it should be better.
There are infinitely many true statements to make about some thing in order to document it. The art is in determining which ideas and facts about it are relevant for an audience, and finding a way to express those ideas and/or facts clearly for.that audience, in a logical order, using good prose, diagrams, etc. I think that's as hard as any other writing task, and arguably more valuable than many. Documentation captures facts for record and makes them accessible to some audience who otherwise would not have known about that thing. What could be a more important kind of knowledge work than that?
I agree with all of this. Submodules aren't easy but they perform a useful job. It's hard to see how they could be made significantly easier. Where else in software is dependency management easy and convenient?
Hmm. I might be a "the internet is altering the course of human evolution" person. But it depends on what you mean by "the course of human evolution".
Do you mean "human evolution" in the typical biological sense, like talking about our genes and our physiology? Or something broader?
I'm pretty convinced that using the Internet has somewhat (not necessarily dramatically, but somewhat) already altered how I think about the world an dhow I see it. Certainly it has altered how I behave and spend much of my time. It also has clearly altered (I'd say dramatically) how we communicate, who we communicate with, and thus also who we consider to be part of our "in-group" (I'm thinking about Peter Singer's expanding circle). That has a huge impact on our moral attitudes, even. Very central changes to what we're like. Some people (I think rightly) consider this to be an evolution, in the broad systems sense of the word.
As for actual biological evolution, I guess that's less obvious to me. But it sure doesn't seem impossible. Yes, the beginning of the Internet is in some sense a consequence of our nature, not a cause. But now that it's here, it can interact with us; it is part of our environment, and could affect our biology. This idea isn't strange to ecologists, who typically refer to it as "top-down" forcing.
So my attitude to this is that, no, the existence of the Internet doesn't only "make our true nature more apparent". Or rather, it makes our true nature apparent in the same way that the elongated shape of some flowers illustrates the nature of hummingbirds (http://www.rubythroat.org/Article860629.html). From that article: "It's obvious that a hummingbird's long narrow beak is an adaptation for feeding on long narrow flowers, but the corollary is also true: There are species of tube-shaped flowers that are adapted for being pollinated by organisms with skinny, tapered mouthparts." I want to say something similar: "Yes, there is an ecological relationship between us and the Internet, and thus the Internet reflects our natures, but it's also its own thing, a part of our environments, alongside which we should expect to evolve."
One interesting advocate of this view is the science historian George Dyson, if you're interested in exploring the idea more.
Someone has made and maintained the app over a few person-months of effort, and can sell millions of copies of it. In order to pay for their time spent making the app, I need to give them one millionth of the cost of their time developing it. When there's lots of competition in the app market, app makers will have to sell their time at competitive prices.
Compare that to coffee. There are three baristas on this street who can make me a coffee, so they're also in a stiffly competitive market. But they have to make me my coffee personally, one at a time. I have to buy a larger portion of their time, since they can only make a few dozen coffees per hour (and they have more physical supply-chain issues to manage, like sourcing beans and managing a property).
It's emotionally easier to pay for the coffee in part because no-one down the street is offering it for half the price, or for free. They can't. An app developer can. And they'll have to, because if they don't, someone else will. Because they can.