> it’s easier to build your own than to gain an understanding of React.

And, in today’s corporate how many story points did you complete this sprint “what have you done for me lately” panopticon culture, building your own looks like productivity, gaining an understanding looks like slacking - a fireable offense. Supposed tech labor shortage or not, few of us have the luxury of looking unproductive regardless of what we’re actually accomplishing.

Oh, come on... Is React really that hard to understand? It's one of the simplest libraries I know. I was a self-taught web dev with only about a year (though, quite an extensive year) of JS/jQuery experience when I switched to React. I had never worked with a JS framework before and I knew I was going to need one for my next project, and for some reason I chose the new (at that time - early 2014) React, rather than the established Angular. And after going through the official tutorial everything went so smooth I was amazed by the power of React.

> Is React really that hard to understand?

Beats me, I've never tried to learn it - it was the author's example of a framework that's harder (or appears to be harder) to learn than to just reimplement from first principles. Replace "React" with something that does fit that description if you like. Unless you think there is no such thing?

Well, I guess there sure must be something hard to learn, but is rolling your own easier? I really doubt that. Or why then we don't see a thousand of frameworks in other languages? Are there no hard to learn frameworks written in them? I believe people set out to write a new framework because those that exist do not meet some certain criteria of theirs.

And just to imagine somebody lacking ability to comprehend something while having an ability to implement their own... Sounds weird.

I've rewritten fairly large systems and re-integrated them faster than I could ever have understood the original code.

I don't think React is in that category though, I think the concepts are understandable, the documentation is good, and StackOverflow is helpful.

I implemented a small React app while learning it which is in production and running just fine.

Yeah, that’s definitely true of established, in-house, undocumented, partly-working code bases.

Well, that's what I (and the author, I believe) are getting at. In the long term, it's almost definitely better to reuse what's already there and is tried, true and tested. But that's in the long term. When you're giving daily (!) status reports and trying to justify your existence, you're better off pointing to something that you programmed than at time you spent learning something. Organizations are shooting themselves in the foot by holding learning in such low regard.

Oh, I see, but I haven't seen that in my experience. At our company it's fairly normal to have a task that sounds like "Investigate..." or "Research..." especially at the beginning of a project, with an expected result being zero lines of code, understanding of some important concept and a decision made that will govern which way the project will move from that point on. I personally had to explain to our PM that we can't just take whatever tools we used in a project that has been just completed and lasted over a year, because lots of things could have changed during that period, and taking time to research for better alternatives is always worth it. He agreed.

I get what you're saying, but it's easy to decompose "gaining an understanding" into grains useful to task-accounting methodologies like those you're lamenting.

I think the pressure towards "just write code" comes from somewhere else.

I mean a real connection between the history of opera and programming is the conflict between opera as a courtly art (Eric Raymond’s “cathedral”) and its life as a public spectacle (“the bazaar”). There is an excellent essay by Richard Taruskin title “the history of opera from Monteverdi to Monteverdi” in his Oxford History of Western Music. Even if you aren’t a musicologist a read of the intro might reveal some analogies...

I think the article is mistaken about the meaning of the word 'descant'. It's primary meaning is 'an independent treble melody usually sung or played above a basic melody', which would make sense for a renowned singer to reference!

Side note: the audio-course mentioned in the article (https://www.audible.com/pd/How-to-Listen-to-and-Understand-G...) is probably the best Teaching Company courses I've ever heard (and I heard a bunch) and is highly recommended to anyone. I wasn't a big aficionado of classical music and opera before, and I am still not an opera regular now, but it expanded my education about what happened in that world and where things come from immensely. And Robert Greenberg's presentation is just excellent.

I read all these nice articles, but the fact is most companies couldn't care less specially if their business area isn't selling software.

All these years after the agile manifesto, and the ideas are still the exception, not the rule.

>> All these years after the agile manifesto, and the ideas are still the exception, not the rule.

Are you saying agile is the exception?

Yes, in many companies it degenerates into some kind of cherry picked items from talks that looks agile on the surface, but it is as waterfall as ever.

Maybe management just feels that waterfall is more tractable and easier to control. I feel like a good scrum-master has to subside their ego a bit to let the programmers write and bid tasks without intervening.

Could be that doing Agile is the rule; being agile is the exception.