I could be less enthused. There's some ok caution here, in two points:

1. Don't be emotionally attached to your work. Itself obviously horrifically bad advice for everyone: we should be building with passion, in tech the group has fervently picked up and can be excited to roll with. But emotionlessness and removing oneself is a fact of professionalism (to save oneself) and the mired compromise-oriented culture of professional life and business (where historically business plans have always trumped the everloving fuck out of passion and belief).

The linked article? #1 rule of programming, leave emotions at the door? It's not about emotions. It's about pride and hubris, being unable to let go, as the junior developer in the article is, as he is silently unfeelingly antipathically checked without discourse or camraderie from coworkers that simply hit "mute" on him.

2. Design and process is indeed a great caution, something we need to burn cycles on- but the author flat out says junior people don't even think about what they are saying they want to build.

Envisioning and end goal and hacking out some code can be a way of life, can be remotely possible, if your company can parcel up responsibilities in neat little independent units where you don't have to interact with anyone. As soon as you have to work on a project of >1 person, design first immediately becomes mandatory to some very minimal extent. This is a company problem, a danger if you really are leaving everyone running wild and hoping they see the virtues of designing for themselves.

Last, I'd contend the green-horns, with their fancy notions of "what-if," have usually spent more time considering combinations and ways to lay things out than the experienced. If you really do exhibit the well-invested-techie syndrome and you have any self respect, your plan isn't "use redis and node.js and win," there's some kind of data-model, spoken or unspoken and it's up to a company to determine what kind of design proposal process it wants to run for pulling in these ideas and formulating a plan and direction.

The author hits themselves in the forehead by the end: they finally get to process, where they discuss lifecycle. Lifecycle which needs to be the company's lifecycle, which needs to entail design. If a developer is off coding without a plan and there's no process in place where they had to think before hand, yeah, bad news, bad programmer, but how did that happen and why did the inexperienced person not have a standard of work from their workplace they drew from to get in such a bad spot? Did they not see the corporate wiki full of UML diagrams? Did they really forge ahead without filing any tickets for their work?

Honestly some of the best programmers are young ones, because they are humble and they don't purport to know. Experienced ones are the ones coding from the seat of their pants, because they've seen it, they know it, they have assurances and confidence from the past and they're repeating it, day in and day out, and it's not exciting for adventurous for them, it's what they already know. It takes a certain moral rectitude in the junior class to exhibit this, but more than that, it takes a culture that supports discourse and process, it takes a workplace culture that can relish getting into it and understanding what they are doing, and executing first prototypes and then well to plan, and if that idea is hinted at and space is made where a junior programmer can cycle themselves through that and not be looked down upon, they have every chance of being as good today as they will in ten, twenty, thirty, or three hundred years.