|
It may not be the most ideal example, but it was the best example I could think of.
To err is human. Fortune favors the monsters.
|
|
|
|
|
I understand what you're saying, I was just stating that I believe any kind of craft that requires either building something or solving problems can become 'an art', where you have people whose talent allows them to rise above the mere knowledge they possess. They can teach their knowledge, best practices and tricks but their talent cannot be passed down.
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
You're probably right. I'm just up late.
To err is human. Fortune favors the monsters.
|
|
|
|
|
Structural engineering needs the same level of artistry at the top levels, but is close enough to what we think we understand to believe it's "just" the boring application of simple principles, just as coding is.
Its worth looking at
[1] R. E. Bohn, “Measuring and Managing Technological Knowledge,” in The Economic Impact of Knowledge, Elsevier, 1998, pp. 295–314. doi: 10.1016/B978-0-7506-7009-8.50022-7. Also in HBR and at https://www.researchgate.net/publication/237010832_Measuring_and_Managing_Technological_Knowledge[^]
The paper notes how we have a fading level of understanding as we go further away from our own field of understanding.
Forth Bridge; Golden Gate; Sydney Opera House
|
|
|
|
|
When I have to look at their source code, I strongly curse the artists and enjoy the solid, boring coders.
"In testa che avete, Signor di Ceprano?"
-- Rigoletto
|
|
|
|
|
Absolutely agree!
As someone visiting old code(other people's as well as my own) my one immediate concern is "how easy is this to debug?"
Software developers sometimes have a tendency to write code with the mindset that "nothing will go wrong" rather than "how easy will it be to debug when something does go wrong"?
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
Always strive to write code that is inspectable. In my experience I developed out these few habits:
* One statement per line so debuggers will have an easy time setting breakpoints (work enough in embedded and you will sorely miss VisualStudio 6).
* No implicit use of function values (i.e. if (FunctionCall() == something) . Apart that it's not MISRA compliant so I'd have to do that anyway, it really helps when inspecting the code with watch windows.
* When not counterproductive, always follow the most linear path. It's better tho have two sequential blocks that check different conditions than an absurd boolean expression or a multi-nested if-else block. Madness and unexpected behaviors lie that way. Easy to place breakpoints, easy to lay out watch variables, easy to follow code flow.
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
Agreed.
I also like to inject descriptive variables. One team member would “format”/delete them away:
eg
boolean goodName = complicated not so clear expression;
if goodName …
|
|
|
|
|
I "do" that too except that the meaning of descriptive floats and drifts with time, what's descriptive to me today might not be as descriptive in a month to also me or someone else.
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
When I was part of the team developing OS400 (for the IBM AS/400 and follow on systems) a key goal for me was first failure data capture - so that if a failure occurred there was enough data being logged to find the cause without having to reproduce the error. It didn't always work, but was a worthy goal.
|
|
|
|
|
Yes, yes I do. My personal objective is to code in the most boring possible way. I lost count of the amount of times I cursed my past self for my bright ideas.
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
den2k88 wrote: I cursed my past self for my bright ideas Some times the past is only half an hour; and yesterday is a life time ago
|
|
|
|
|
It definitely happened within the same week.
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
Amen!
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
Spot on! I absolutely respect all those who bring artistry to their craft, but I have also lived through several projects where the "artistry" was applied with zero regard for timelines, TCO, budget, maintainability, or what the client actually asked for.
Some of the artistry, IMHO, comes in knowing when boring and predictable makes more sense.
|
|
|
|
|
whats the point you can't c++ your way though life you need to look for the pointers...
Caveat Emptor.
"Progress doesn't come from early risers – progress is made by lazy men looking for easier ways to do things." Lazarus Long
|
|
|
|
|
Only smart pointers though
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
You use the word 'craft'. I like to think of myself as a craftsman. I enjoy, and take pride in, what I do, I like to make a good job of it and I like it when the code is, in some sense, beautiful (it isn't always!)
Paul Sanders.
If I had more time, I would have written a shorter letter - Blaise Pascal.
Some of my best work is in the undo buffer.
|
|
|
|
|
I think you are conflating "hacks," and "clever solutions "with "art."
Someone at a high-level of competency with the tools and materials in a certain domain can experience aesthetic qualities when they look at something built using those tools and materials.
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
modified 6-Oct-22 8:46am.
|
|
|
|
|
A far more concise and cogent reply than I could muster first thing in the morning, Bill.
Thank you.
Software Zen: delete this;
|
|
|
|
|
Hi, Gary,Gary Wheeler wrote: first thing in the morning Well, I am probably 11 hours ahead of you (GMT + 7).
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
|
|
|
|
|
Yes, plus I don't operate well under caffeine deficit.
Software Zen: delete this;
|
|
|
|
|
I think you make a good point.
I thought he might be saying the same thing Einstein said:
Imagination is more important than knowledge.
|
|
|
|
|
What a wonderful quote !
my favorite Einstein quote:
“A human being is part of a whole, called by us the 'Universe', a part limited in time and space. He experiences himself, his thoughts and feelings, as something separated from the rest ... a kind of optical delusion of his consciousness.
This delusion is a kind of prison for us, restricting us to our personal desires and to affection for a few persons nearest us.
Our task must be to free ourselves from this prison by widening our circles of compassion to embrace all living creatures and the whole of nature in its beauty.”
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
|
|
|
|
|
I agree that higher skill levels of software engineering cannot be taught. I daresay the same thing can be said about e.g. mechanical engineering.
I used to think of it as art, when I was much younger. These days I would mosdef not use the word art to describe it. Just like for example ball-sense cannot be taught (nor be called art).
If forced to pick an expression would just call it exceptional ability, even if there are some art-like properties to it. Like watching Roger Federer playing tennis.
"If we don't change direction, we'll end up where we're going"
|
|
|
|