My dirty little coding secret
-
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'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'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.
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 ) ...
-
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.
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! :laugh:
"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'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.
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
-
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! :laugh:
"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. :sigh:
-
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.
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
-
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. :sigh:
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...
Telegraph marker posts ... nothing to do with IT Phasmid email discussion group ... also nothing to do with IT Beekeeping and honey site ... still nothing to do with IT
-
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...
Telegraph marker posts ... nothing to do with IT Phasmid email discussion group ... also nothing to do with IT Beekeeping and honey site ... still nothing to do with IT
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'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.
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
-
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...
Telegraph marker posts ... nothing to do with IT Phasmid email discussion group ... also nothing to do with IT Beekeeping and honey site ... still nothing to do with IT
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?"
-
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 also subscribe to the idea that "simple is better", where possible ... Something like "fast prototyping" and keeping the code understandable while refining, and also, measuring the complexity ... I think that this is the mainstream of the expectations: [Why Senior Devs Write Dumb Code and How to Spot a Junior From A Mile Away | HackerNoon](https://hackernoon.com/why-senior-devs-write-dumb-code-and-how-to-spot-a-junior-from-a-mile-away-27fa263b101a)
-
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. :-O
-
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.
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
-
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 think most of us do it like that. At least I know that situation also. Now to stay calm, simply call it 'iteration' according to Scrum bla bla and you are fine then ;) The nice equvalient to describe that: Scrum-Iteration == Trial and Error ;P :laugh: [Edit] But what me bothers after that is: After all I see how to do it more perfect. But in 90% I'm too lazy to refactor :laugh:
-
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.
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 :-D 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
-
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.
-
Well, ummm, during lockdown my personal hygiene was somewhat lacking as well. :-O
-
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?"
-
As well? Mine was not lacking at all and I have no idea why you would think it was. :rolleyes:
"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.
