There ought to be, if there isn't already, a phase in most peoples' journey with programming where they dig into and experience the fundamentals; the maths, structures, and practical application of theoretical techniques. The reason being that you're not going to get very far in any domain if you don't know how to deal with complexity.
I think there comes a turning point when you've mastered enough of the fundamentals that domain knowledge becomes more useful. Code becomes an artifact of solving problems in your domain. If you've mastered the fundamentals the correct code (for some appropriate definition of correct) becomes easier to develop. Regardless you end up becoming more of a domain specialist and programming is just your _force amplifier_.
Though I think this can get a little dangerous with some folks who might mistake our ability to "learn as you go," as some innate ability to understand and solve problems in any domain. I think this has an effect on our industry where programmers with little experience in a domain think they can write software to solve problems in that domain and iterate until they learn that domain and voila! Disruption!
The problem with that is there are some domains that require mastery due to ethical and legal constraints. There's a reason why you don't just become a civil engineer by following some blog posts and watching Youtube videos.
Still I think that if you are going to be a civil engineer -- if you know a thing or two about programming, like knowing maths, you will be a "10x civil engineer."
>programmers with little experience in a domain...write software to solve problems in that domain and iterate...Disruption!
I don't think that will change much until the overwhelming demand for more software is mostly met with a sufficient number of properly trained Software Engineers. At that point we should start seeing real competition on the quality of the solutions. (and a move towards professional licensing)
It seems likely that the first civil engineers saw a similar pattern. When you have a creek to cross and no one around is qualified to design a bridge, someone gives it a shot anyway. If it collapses they try to build a better one (iterate). Hopefully this can be accomplished without killing anyone.
Now that the world has a decent number of properly trained Civil Engineers though, we don't need to wing it most of the time; especially for the big, consequential projects.
Why I still think we're in a dangerous area with this is that there are established industries with domain experts who simply are not programmers. Inexperienced programmers might come in with solutions to problems that have genuinely good intentions -- a bridge to help people cross the creek; but there are people who already know how to build reliable bridges and you have to be able to either become one of those people or understand enough of their domain to collaborate with them.
I find a lot of great developers become pseudo-civil engineers. If you ask them to switch gears and write a video transcoder they're going to be about as useful as an intermediate programmer with zero-domain knowledge; despite having been writing software for civil engineers for that last 20 years and being in the top of their field... it's the domain knowledge that makes a big difference.
I don't think you understand what domain knowledge means. If the civil engineer is a user of VLC, Youtube, etc. then they do not have "zero domain knowledge" when writing a transcoder.
Not to mention that if they really are a great developer they'll just fork an open source project and be pretty much done.
No matter who you are, the more virgin code you write yourself today, the more immature and vulnerable your application will be.
The notion of a regulated Engineering profession really came about when some very famous bridges started to collapse under load. In response to this, there was public outrage and distrust in governmental projects such as bridges. Thus, the government conceived a program where engineering labor supply is regulated through training and association standards.
Unless software creates such a large loss of life and disruption that the public has a similar outrage. The government will not act to regulate programming. In addition, it's neither in programmers or companies best interests to be regulated (except for programmers that are good at programming and companies that would like to pay a higher price for labor in exchange for quality).
There ought to be, if there isn't already, a phase in most peoples' journey with programming where they dig into and experience the fundamentals; the maths, structures, and practical application of theoretical techniques. The reason being that you're not going to get very far in any domain if you don't know how to deal with complexity.
I think there comes a turning point when you've mastered enough of the fundamentals that domain knowledge becomes more useful. Code becomes an artifact of solving problems in your domain. If you've mastered the fundamentals the correct code (for some appropriate definition of correct) becomes easier to develop. Regardless you end up becoming more of a domain specialist and programming is just your _force amplifier_.
Though I think this can get a little dangerous with some folks who might mistake our ability to "learn as you go," as some innate ability to understand and solve problems in any domain. I think this has an effect on our industry where programmers with little experience in a domain think they can write software to solve problems in that domain and iterate until they learn that domain and voila! Disruption!
The problem with that is there are some domains that require mastery due to ethical and legal constraints. There's a reason why you don't just become a civil engineer by following some blog posts and watching Youtube videos.
Still I think that if you are going to be a civil engineer -- if you know a thing or two about programming, like knowing maths, you will be a "10x civil engineer."