|
I like this method of revealing the answer.
I’ve given up trying to be calm. However, I am open to feeling slightly less agitated.
|
|
|
|
|
Aaarrrggg!  Not being British and also not one to follow the royal family very closely I thought he was King Charles II. Had I bothered to look it up I probably would have solved it. 
I don't know why a digit in the answer would be invalid, but I'm certainly no expert. So, in my opinion, nice clue! 
|
|
|
|
|
I think any creative process can rise to the level of art when you can't teach someone how to be great at it.
I think you can teach any structural engineer how to be a great structural engineer, IMO. If you have the skillset, experience will carry you to greatness.
I do not think you can teach any engineer to be a great software developer. The skillset alone isn't enough to foment greatness.
Software development in some respects is like cooking, acting, painting, or dancing rather than like blueprinting.
Some people just have a knack, but most people will always plateau after a point because raw skillset only carries you so far, no matter how well you know C++ for example.
It doesn't mean that most coders can't code. they will just never be what I consider great. You have to have some artist in you, I think.
I don't say that to discourage anyone. I routinely code with someone who will never be an artist at the craft, but it's not to say he's not intelligent, or capable. There's nothing wrong with the code he produces. It's a solid average, and easy to understand, so it has that going for it. I can work with that. Very utilitarian.
But then there's great code. Code that makes you go "wow, I wish I would have thought of that"
He's not going to produce that code, and that's okay.
But there's an art to doing so.
To err is human. Fortune favors the monsters.
modified 5-Oct-22 3:14am.
|
|
|
|
|
honey the codewitch wrote: I think you can teach any structural engineer how to be a great structural engineer,
I don't know enough about structural engineering but I know enough about engineering as a whole that while I understand the gist of what you are saying and I partially agree, I'm fairly sure we could both be surprised by the actual practice of any field of engineering.
Knowing is all weel and good, experience is paramount but some people just have or have developed an innate knowledge of their craft, a forma mentis that makes them particularly brilliant and allow them to find creative, original or groundbreaking solutions. In my years of working in highly multidisciplinary environment I learnt to never underestimate the level of brilliance people can attain in any field.
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
|
|
|
|
|
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
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
