Thus speaks someone who doesn't know anything about the difference between computer programming and software engineering. They may be able to program circles around everyone else, but they can't software engineer their way out of a wet paper bag, and they're going to produce a disaster.
That's at least a bit of an assumption. Perhaps it hits close to home from my days in a Lisp shop, but some of the most brilliant Lisp programs I've seen weren't even written by programmers or software engineers; they were written by drafters who were clever at math. And while I know I'm waxing poetic, I do consider that a credit to Lisp's purity.
Hell, in the drafting industry I would say this story is (or certainly was) absolutely true. I wrote a whole bunch of LISP that I believe is still in use today, 8-12 years later alongside a number of small C#/VBA applications. Amazingly what was put together was not only a 'non-disaster', but done thoughtfully enough that the team was able to take that code and evolve it over that same time period since I've left (I keep in touch with some of that team, specifically the guy who got 5 days of me offboarding 6 years of work...)
On the other hand, I've seen the opposite as well. In the C# world, writing one's ORM is often seen as a trial of passage where one should hopefully by the end realize the difference between programming and engineering.
BUT, but... I've seen things blown the other way as well. I've seen PDD (Presentation Driven Development) in it's worst form; where engineering principles are so overvalued that nobody actually does anything. It wasn't even bikeshedding the architecture; it was bikeshedding the project itself.
I think we also sometimes forget differences in engineering philosophies. A Youtube channel called Regular Car Reviews did a great video once upon a time discussing the failure of the Chrysler-Mercedes merger from the late 90s. One of the things touched on was differences in engineering philosophy. The way a High performance 'european' car used to get made was often a measure of precision, lots of fancy pieces working in unison (and, as anyone who had a late 90s BMW with VANOS can say, expensive to fix.) American Engineering? Just make it bigger!
We see some of this difference in engineering philosophy today; consider folks who prefer ground iron or cloud iron vs functions as a service.
The first lesson I learned about programming versus engineering was about disasters left behind.
The second lesson was that sometimes the disasters had a good reason.
... some of the most brilliant Lisp programs I've seen weren't even written by programmers or software engineers; they were written by drafters who were clever at math.
Sure. But those drafters probably weren't on a "we're so much smarter than everyone else, strong typing is for people with weak memories" ego trip. People who know they aren't programming experts tend to be conservative and careful in what they write. People who want to throw away all the guardrails so that they can show what great coders they are... look out.
Comments
That's at least a bit of an assumption. Perhaps it hits close to home from my days in a Lisp shop, but some of the most brilliant Lisp programs I've seen weren't even written by programmers or software engineers; they were written by drafters who were clever at math. And while I know I'm waxing poetic, I do consider that a credit to Lisp's purity.
Hell, in the drafting industry I would say this story is (or certainly was) absolutely true. I wrote a whole bunch of LISP that I believe is still in use today, 8-12 years later alongside a number of small C#/VBA applications. Amazingly what was put together was not only a 'non-disaster', but done thoughtfully enough that the team was able to take that code and evolve it over that same time period since I've left (I keep in touch with some of that team, specifically the guy who got 5 days of me offboarding 6 years of work...)
On the other hand, I've seen the opposite as well. In the C# world, writing one's ORM is often seen as a trial of passage where one should hopefully by the end realize the difference between programming and engineering.
BUT, but... I've seen things blown the other way as well. I've seen PDD (Presentation Driven Development) in it's worst form; where engineering principles are so overvalued that nobody actually does anything. It wasn't even bikeshedding the architecture; it was bikeshedding the project itself.
I think we also sometimes forget differences in engineering philosophies. A Youtube channel called Regular Car Reviews did a great video once upon a time discussing the failure of the Chrysler-Mercedes merger from the late 90s. One of the things touched on was differences in engineering philosophy. The way a High performance 'european' car used to get made was often a measure of precision, lots of fancy pieces working in unison (and, as anyone who had a late 90s BMW with VANOS can say, expensive to fix.) American Engineering? Just make it bigger!
We see some of this difference in engineering philosophy today; consider folks who prefer ground iron or cloud iron vs functions as a service.
The first lesson I learned about programming versus engineering was about disasters left behind.
The second lesson was that sometimes the disasters had a good reason.
Sure. But those drafters probably weren't on a "we're so much smarter than everyone else, strong typing is for people with weak memories" ego trip. People who know they aren't programming experts tend to be conservative and careful in what they write. People who want to throw away all the guardrails so that they can show what great coders they are... look out.