I've worked in a few teams where some member of the [human] team could be described as "Joe can code, but he can't build software." The difference is what we u

I've worked in a few teams where some member of the [human] team could be described as "Joe can code, but he can't build software." The difference is what we used to call the "ilities": Reliability, inhabitability, understandability, maintainability, securability, scalability, etc. None of these things are about the primary function of the code, i.e. "it seems to work." In coding, "it seems to work" is good enough. In software engineering, it isn't.