|
I'm not too proud to say it. I pretty much always start with naive implementations of code while I work out how I really want it to be laid out. If you see "clever" code from me, that was never my first pass at it. There's always been a lot of playing around with it beforehand as I refactor and tidy it up.
We need to get better at telling new coders that this is okay. Or perhaps it's not, and I'm just setting a bad example.
|
|
|
|
|
I am the same way. Do it quick and dirty to prove or disprove the concept and/or algorithm.
Make sure the code has the opportunity to Fail Fast so I don't waste time on it.
Then clean it up, refactor it, add error handling and comments.
"Time flies like an arrow. Fruit flies like a banana."
|
|
|
|
|
I agree 100%
"How can I know what I mean, before I see what I say?" 
It is far easier to edit something that isn't so great than it is to make something up out of thin air.
So, get a little down, then edit.
"Do something, even if it's wrong."
"It is not enough to stare up the steps, we must step up the stairs!"
"Action doesn't guarantee happiness. But, there is no happiness without action!"
I got a million of 'em!
"Sometimes I sits & thinks. But other times I just sits."
modified 10-Feb-23 17:01pm.
|
|
|
|
|
good to see you guy's trick here
diligent hands rule....
|
|
|
|
|
Me too!
It must be experience.
Adding error handling and such can be done after the main logic path has been worked out.
And I often have local variables I can test (e.g. in debug) until I'm sure I don't need them.
I might write:
int c = foo() ;
if ( c == 0 ) ...
before changing it to:
if ( foo() == 0 ) ...
|
|
|
|
|
Strange - I'm different. I generally try to "do it the right way" from scratch, even for one off throwaway jobs for me.
Even when I was checking a prototype PCB (solder on the processor and enough ancillary bits of hardware to make it run and toggle a signal, then add a bit more and test that, ...) the code was "production quality" - if only because I got bitten too many times by throwing code together to see if hardware worked and eventually found it was the software not the hardware I was trying to debug!
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
I've learned not to kid myself that the code I just wrote, tested, and checked in can't be improved after looking at it again some time later.
So often I'm driving home from the office (which is a benefit of working in an office) when the, "you idiot, you shoulda done..." monster, strikes. 
|
|
|
|
|
PIEBALDconsult wrote: which is a benefit of working in an office
It works just the same way WFH. But in that instance, if it "hits me" 20 minutes after "leaving" work then I'm in the garden, or putting away the washing and I can just pick up the laptop and at minimum write myself a note about my new brilliant idea, if not implement it fully, decide it's complete rubbish and roll everything back. Rather than be doing 70 (or more likely 15) up the motorway only to be distracted by some idiot who thinks "mirror, signal, manoeuvre" is for wimps and forget all about it. The mind never shuts down; just goes into "energy saving" mode...
|
|
|
|
|
YMMV.
I have always* understood the wisdom of getting away from it (whatever it is) and having a fresh eye on it later.
Yet, my experience (during lockdown) was that I just continued to sit at my desk looking at the code until it fixed itself. When the work is at home, getting away from it can be more difficult, in my experience.
* Since art classes in high school anyway.
|
|
|
|
|
I often get my best ideas in the shower. It got so frequent I had one boss tell me the company should pay my water bill.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
|
|
|
|
|
Well, ummm, during lockdown my personal hygiene was somewhat lacking as well. 
|
|
|
|
|
As well? Mine was not lacking at all and I have no idea why you would think it was. 
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
|
|
|
|
|
I meant -- as well as (perhaps) my coding hygiene.
|
|
|
|
|
So did you take your boss up on the offer?
|
|
|
|
|
No, they laid me off shortly after that. Thankfully, I am finally at a company that doesn't do lay offs. It helps that it is privately held and doesn't have to kiss the backsides of investors.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
|
|
|
|
|
For me, I usually get that "aha" moment at 3:00 AM. Forget about sleep after that.... 😳
|
|
|
|
|
PIEBALDconsult wrote: I've learned not to kid myself that the code I just wrote, tested, and checked in can't be improved after looking at it again some time later.
I have learned that no one writes code that cannot be improved.
Certainly some parts of code that were created by one person certainly seem ideal. But the totality of work by one author will always have places where things could have gone better.
|
|
|
|
|
that's top-down methodology...
diligent hands rule....
|
|
|
|
|
There's a subtle difference between production ready, and functionally complete.
It's (for me) always worth thinking through what the functionally complete (System Engineered) version could include and how it may become over complex with contradictory requirements. Sometimes there are subtle choices that lead to the death-march pit of doom while a slightly different choice would clearly signpost the sunlit uplands of future success.
Then you can focus on the core element, the 'spike', where the tyres hit the road and the concepts hits the existing code, and neater approaches to the same functionality do start to emerge.
Moving fast, always broken, like a bull in a china shop, is not a good look! Production ready is good, full function extendable is even better 
|
|
|
|
|
That is the Hardware way, going full Mandoliran. If you have to hardware tasks get one step at a time is best. I must admit once Visual Studio comes out very seems to be an expert and often tells you you are taking too long you don't need 'try ... catch', test it 'you screwed up with lenght that could be entered' out comes try...catch. 
|
|
|
|
|
This is the way. 
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Out of interest, did you watch The Book of Boba Fett as well?
I just finished bingeing it and am looking forward to series 2, if it ever happens.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
If I'm coding in an area that is new to me I start out with, what I call learning code or POC code.
Once I learn the system to my satisfaction I straighten out and optimize the code to a working state.
Or abandon it and wonder what the hell I was thinking even messing with it.
PartsBin an Electronics Part Organizer - An updated version available!
JaxCoder.com
|
|
|
|
|
ditto
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
Just and FYI - it's not really a dirty secret or something to be ashamed of (not saying you are, at all  ).
its called the Explorative/Ideate phase of Design Thinking. Its a precursor to the prototype phase.
Understand
Explore (Ideate --> Prototype)
Materialize
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
