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. But they'll be on their way to the next place before it becomes clear how much of a disaster they created at this place, so they'll go cheerfully on their way, basking in their own smartness as they create destruction.
Indeed, I’ve seen the type a couple of times before. They usually show up when an aloof management admits to themselves they have run out of ideas and want to introduce “transformational” thinking into an established team. They’ll typically fanny around for a few weeks, make a few noises that sound like no true Scotsman, annoy everybody, break a few things and then move on to the next thing when they burn out. How do I know this? I have been that guy.
As I mentioned in another post, sometimes it becomes a rite of passage, especially if you are put in a situation where you weren't properly mentored/checked. I've only left one real 'mess', it was a smaller one and mostly because I left the org before we were able to get to the final state. However I gave plenty of notes to make sure they could finish it up.
On the other hand I've managed to build a good career out of being the guy who shows up after a mess is made, and cleans it up. (BTW, this is not a bad spot to be in if you like learning either, you will get good at actually -reading- code, other people's code. And, all the crazy stuff you see, eventually you start to realize there is a -right- way to use some of it. :)
One thing about the software -development- process (be it software engineering or something else) is that there should still be some form check/balance to avoid insanity. As an example, at the moment I'm working on some performance stuff for an open source library. But there's a certain point where I said "I'm stopping here, any work onward is going in a new branch, since it's going to be impure to the rest of the project and IDK if that's what people really want, even if it's a decent gain". Common sense.
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
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. But they'll be on their way to the next place before it becomes clear how much of a disaster they created at this place, so they'll go cheerfully on their way, basking in their own smartness as they create destruction.
Indeed, I’ve seen the type a couple of times before. They usually show up when an aloof management admits to themselves they have run out of ideas and want to introduce “transformational” thinking into an established team. They’ll typically fanny around for a few weeks, make a few noises that sound like no true Scotsman, annoy everybody, break a few things and then move on to the next thing when they burn out. How do I know this? I have been that guy.
Hey at least you've gained the introspection to realize it. That takes effort. I've also been that guy, and hope I am not still.
As I mentioned in another post, sometimes it becomes a rite of passage, especially if you are put in a situation where you weren't properly mentored/checked. I've only left one real 'mess', it was a smaller one and mostly because I left the org before we were able to get to the final state. However I gave plenty of notes to make sure they could finish it up.
On the other hand I've managed to build a good career out of being the guy who shows up after a mess is made, and cleans it up. (BTW, this is not a bad spot to be in if you like learning either, you will get good at actually -reading- code, other people's code. And, all the crazy stuff you see, eventually you start to realize there is a -right- way to use some of it. :)
One thing about the software -development- process (be it software engineering or something else) is that there should still be some form check/balance to avoid insanity. As an example, at the moment I'm working on some performance stuff for an open source library. But there's a certain point where I said "I'm stopping here, any work onward is going in a new branch, since it's going to be impure to the rest of the project and IDK if that's what people really want, even if it's a decent gain". Common sense.
Probably not. In my experience, they usually have zero self-awareness, so your own introspection bodes well.
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.