Since the comments are closed I'd like to add that this terminology completely focused on "building" explains why some people think that programmers a.k.a "builders" are interchangeable, like lego bricks. So if you need to replace programmer A in team X because he or she quit all you have to do is call upon programmer B. Then team X will be complete again like nothing had happened.
Related to this is the fact that teams that work well and manage to produce value during a project are usually "disbanded" at the end of that project with all the knowledge gathered during the team's retrospectives, etc lost or at least scattered in documents or wikis that no one will read.
When did you see a good football team that won Champions League being "disbanded"? Never, of course, because it doesn't make sense. The sensible thing is to keep the team together for another project and another...you don't want to let go off your good team...or you shouldn't...
Clearly, we (software developers) are failing to communicate as a group that there's value in keeping good teams together, that there's value in the experience of seasoned developers, that there's value in good design, that it's not just about "building", that knowledge work is not about Lego, and so on.
The ones making the big decisions (but of course there are exceptions!) are not seeing the value in all the above which is surprising since:
Software-dependent businesses can only evolve as fast as their ability to write and evolve their software allows them to (Gorman's Law Of Software-Dependent Business Evolution)
Maybe we need to raise our game.