|
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
|
|
|
|
|
Like anything with tech, there's an art, and with that, that means there's no one size fits all approach IMO.
For instance, if I'm creating a POC or just want to toss something together to see if the program can be useful before I put real effort into it, then rolling out a few iterations that aren't perfect, just to see the concept is ok. If it turns out being useful or someone else will ever see the code then it can be re-designed.
Keep in mind though, on a functional/unit level, it's always strive to do things the right way. More so talking about the architecture aspect.
However, if I'm being paid to develop something, then it's not really my job to see if the app is viable or not. It's my job to just make the thing. In that instance I'll put in the effort to think about design as a whole upfront.
So, it really depends.
Jeremy Falcon
|
|
|
|
|
I agree with you.
Yes, yes... you read it right 
If it is something private... it is like v0, v00, v00+ until it gets to v1 in a nice form.
If it is for work... I prefer to do like (I don't remember who told it but... anyways): If I have 8 hours to chop a tree, I will spend 6 hours sharpening my axe.
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
I agree also.
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
Nelek wrote: Yes, yes... you read it right
Nelek wrote: I will spend 6 hours sharpening my axe.
It just makes sense. Time and time again I've seen "spaghetti code" projects because folks don't take the time to do that.
Jeremy Falcon
|
|
|
|
|
|
Yep ... I've refactored, and factored back again. Created "new" routines I had already created (and forgot about). It's called: "Flow".
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
Guilty 
I keep refactoring till I retire.
I'm a C# developer.
With every new version of the language, I look at my code to see where I can 'fit it in' the new stuff.
I found a module last week that I refactored 98 times in the past 3 years. 
My mantra is:
First make it work, the refactor it till it doesn't, and finally start over.
|
|
|
|
|
|
My approach is similar. I call it the "diamond cutter method". I write the best code I can but, once finished, I look back and find better ways. Once this set of changes is done, I look again and see what can be improved. Like the apocryphal Michelangelo quote: "just remove everything that is not David". Disclaimer: I'm no Michelangelo and none of my code is David 
Corollaries:
1. My oldest code is my best code because it's been through so much polishing
2. My code is never finished
3. I cannot write the same code twice: the second time I find a better way.
Mircea
|
|
|
|
|
A sensible approach, I have to say.
The simple implementation is the (reliable) reference for all the following clever code.
"In testa che avete, Signor di Ceprano?"
-- Rigoletto
|
|
|
|
|
I do that myself. Our products are large, so it's inefficient to try out something new. Many times I'll write a command line or GUI program to act as a test bed for the concept I'm working on. Most of the time I end up with source code that can be dropped into the product and hooked up with relatively little fuss.
Software Zen: delete this;
|
|
|
|
|
It is neither dirty, little nor is it secret, it seems most of us do this. I think the real trick is getting the newbie to refactor the code prior to production!
Never underestimate the power of human stupidity -
RAH
I'm old. I know stuff - JSOP
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
