A thread on HN about bad code in legacy projects both makes me think how little we've learned as a discipline over the years and, honestly, how little credit we give ourselves for some pretty major

Fun going down this list and thinking: "Hmm, plausible at a well-run modern software shop", "Hmm, possible, but requires implausible tradeoffs", "Literally disallowed by languages", and "If you were to attempt doing that our test suite wouldn't let you merge."
I think we as an industry celebrate (not quite the right word) failure too much and don't celebrate success nearly enough. There is no DailyWTF for competent execution, word of which generally stays pretty local to the source while incompetence passes into legend.
Alrighty let me try to thread the needle on being the change I want to see in the world while not giving away anything that will get me in trouble:
Ruby has wonderful developer ergonomics. Typed languages are easier for machines to guarantee the correctness of. We built a type checker for Ruby (and I believe it is slated for OSS release sometime).

c.f. https://t.co/S5XIDxFUrH
We have an infrastructure at work which allows one to specify an invariant about not just code but e.g. objects or the environment and then have a range of response options if that invariant changes.

(Parallel evolution of code: I wrote a less-well-specified one at last gig.)
Git, continuous integration, and workflow-driven mandatory code reviews are all younger that the Joel Test, at least insofar as them being common features of median-sophistication engineering shops.
It is not astonishing to start a new engineering job in 2018 and have a developer environment which reasonably approximates the production environment available on one's laptop or tested, repeatable ways to spin up and spin down a new server w/o "build it by hand."
It is highly likely that a service which is hard down learns of that fact faster than Twitter can apprise them of it, assuming that service is operated in a professional fashion.

At risk of stating the obvious: this is a relatively novel development.
The industry has decisively adopted:

* a single, common encoding for almost all human languages
* a single, parseable, human-readable data interchange format
* a default protocol for information transport
You can round to "Any new application talking to any application written by a competent team in last 10 years will be talking to it over an encrypted link which neither side had to think deeply about because the technology is reliable, ubiquitous, and uncontroversially legal."
While it's not literally the case that you could replicate an entire modern software company's deployment for zero dollars in software licenses, that can almost round to true, due to the pervasive use of OSS.

This is very good for learners.
You can get a full development environment capable of doing Hello World spun up in your well-supported language of choice in, almost certainly, less than ten minutes of effort (contingent on you using a Mac, sadly).
The majority case for libraries, APIs, and file formats of interest to you will overwhelmingly be "If you Google the thing you want you get exactly what you need very, very quickly."

More from Patrick McKenzie

I like this heuristic, and have a few which are similar in intent to it:


Hiring efficiency:

How long does it take, measured from initial expression of interest through offer of employment signed, for a typical candidate cold inbounding to the company?

What is the *theoretical minimum* for *any* candidate?

How long does it take, as a developer newly hired at the company:

* To get a fully credentialed machine issued to you
* To get a fully functional development environment on that machine which could push code to production immediately
* To solo ship one material quanta of work

How long does it take, from first idea floated to "It's on the Internet", to create a piece of marketing collateral.

(For bonus points: break down by ambitiousness / form factor.)

How many people have to say yes to do something which is clearly worth doing which costs $5,000 / $15,000 / $250,000 and has never been done before.
There are a *lot* of software shops in the world that would far rather have one more technical dependency than they'd like to pay for one of their 20 engineers to become the company's SPOF expert on the joys of e.g. HTTP file uploads, CSV parsing bugs, PDF generation, etc.


Every year at MicroConf I get surprised-not-surprised by the number of people I meet who are running "Does one thing reasonably well, ranks well for it, pulls down a full-time dev salary" out of a fun side project which obviates a frequent 1~5 engineer-day sprint horizontally.

"Who is the prototypical client here?"

A consulting shop delivering a $X00k engagement for an internal system, a SaaS company doing something custom for a large client or internally facing or deeply non-core to their business, etc.

(I feel like many of these businesses are good answers to the "how would you monetize OSS to make it sustainable?" fashion, since they often wrap a core OSS offering in the assorted infrastructure which makes it easily consumable.)

"But don't the customers get subscription fatigue?"

I think subscription fatigue is far more reported by people who are embarrassed to charge money for software than it is experienced by for-profit businesses, who don't seem to have gotten pay-biweekly-for-services fatigue.

More from Tech

There has been a lot of discussion about negative emissions technologies (NETs) lately. While we need to be skeptical of assumed planetary-scale engineering and wary of moral hazard, we also need much greater RD&D funding to keep our options open. A quick thread: 1/10

Energy system models love NETs, particularly for very rapid mitigation scenarios like 1.5C (where the alternative is zero global emissions by 2040)! More problematically, they also like tons of NETs in 2C scenarios where NETs are less essential.
https://t.co/M3ACyD4cv7 2/10


In model world the math is simple: very rapid mitigation is expensive today, particularly once you get outside the power sector, and technological advancement may make later NETs cheaper than near-term mitigation after a point. 3/10

This is, of course, problematic if the aim is to ensure that particular targets (such as well-below 2C) are met; betting that a "backstop" technology that does not exist today at any meaningful scale will save the day is a hell of a moral hazard. 4/10

Many models go completely overboard with CCS, seeing a future resurgence of coal and a large part of global primary energy occurring with carbon capture. For example, here is what the MESSAGE SSP2-1.9 scenario shows: 5/10

You May Also Like

IMPORTANCE, ADVANTAGES AND CHARACTERISTICS OF BHAGWAT PURAN

It was Ved Vyas who edited the eighteen thousand shlokas of Bhagwat. This book destroys all your sins. It has twelve parts which are like kalpvraksh.

In the first skandh, the importance of Vedvyas


and characters of Pandavas are described by the dialogues between Suutji and Shaunakji. Then there is the story of Parikshit.
Next there is a Brahm Narad dialogue describing the avtaar of Bhagwan. Then the characteristics of Puraan are mentioned.

It also discusses the evolution of universe.(
https://t.co/2aK1AZSC79 )

Next is the portrayal of Vidur and his dialogue with Maitreyji. Then there is a mention of Creation of universe by Brahma and the preachings of Sankhya by Kapil Muni.


In the next section we find the portrayal of Sati, Dhruv, Pruthu, and the story of ancient King, Bahirshi.
In the next section we find the character of King Priyavrat and his sons, different types of loks in this universe, and description of Narak. ( https://t.co/gmDTkLktKS )


In the sixth part we find the portrayal of Ajaamil ( https://t.co/LdVSSNspa2 ), Daksh and the birth of Marudgans( https://t.co/tecNidVckj )

In the seventh section we find the story of Prahlad and the description of Varnashram dharma. This section is based on karma vaasna.