How I become a better coder
-
Today I am staring at two implementations of a DMA enabled I2S parallel bus system trying to make sense of them since they are using very scarcely documented registers and I'm totally new to this. I'm tackling this *because* I can't do it. I tackled LL, LALR, and eventually GLR parsing *because* I couldn't do it. Challenging myself is not only how I make wicked code, it's how I level up. It also keeps me engaged. I don't always succeed, but most of the time I do, and often times when I don't I'll come back a month or sometimes even years after I put it down, dust it off, and make it dance. There's a certain safety in sticking with what you know, and a lot of times in the professional realm, that's the prudent approach. But I don't feel like you grow as much in terms of the craft. It gets to be habit, and empty repetition.
To err is human. Fortune favors the monsters.
You're not only a good coder but a prolific writer. You have a knack for writing that I don't have, I don't express myself very well and it takes forever for me to document a project for my site.
The less you need, the more you have. Even a blind squirrel gets a nut...occasionally. JaxCoder.com
-
You're not only a good coder but a prolific writer. You have a knack for writing that I don't have, I don't express myself very well and it takes forever for me to document a project for my site.
The less you need, the more you have. Even a blind squirrel gets a nut...occasionally. JaxCoder.com
Same here Mike, the documentation ( when I'm made to do it ) takes me longer than the programming.
"Life should not be a journey to the grave with the intention of arriving safely in a pretty and well-preserved body, but rather to skid in broadside in a cloud of smoke, thoroughly used up, totally worn out, and loudly proclaiming “Wow! What a Ride!" - Hunter S Thompson - RIP
-
Same here Mike, the documentation ( when I'm made to do it ) takes me longer than the programming.
"Life should not be a journey to the grave with the intention of arriving safely in a pretty and well-preserved body, but rather to skid in broadside in a cloud of smoke, thoroughly used up, totally worn out, and loudly proclaiming “Wow! What a Ride!" - Hunter S Thompson - RIP
I hear ya. I start out and try to get everything just so and as I get further into it I lose interest and just rush through, so the beginnings are half way decent but the further you read the more convoluted it becomes.
The less you need, the more you have. Even a blind squirrel gets a nut...occasionally. JaxCoder.com
-
You're not only a good coder but a prolific writer. You have a knack for writing that I don't have, I don't express myself very well and it takes forever for me to document a project for my site.
The less you need, the more you have. Even a blind squirrel gets a nut...occasionally. JaxCoder.com
I was kind of a writer first. I wound up being part of "Young Authors" twice, I could have seen getting an English or a degree in literature as easily as I got into coding if things had played out differently. I learned to read when I was 3, and was voracious about it for a long time. I think picking up literacy early sort of wired me for writing. Audre Lorde (activist, poet) also learned to read at 3, although she was a better writer than I am. Still my point is, I think training young is what does it, and the younger you can do it, the easier is is when you get older. I could be wrong. Maybe we're wired a certain way and that leads to early literacy and a knack for writing. Causality in matters like that can get slippery fast. Either way, the gift really helps when it comes to documenting what I've coded. I feel blessed for it. :)
To err is human. Fortune favors the monsters.
-
I hear ya. I start out and try to get everything just so and as I get further into it I lose interest and just rush through, so the beginnings are half way decent but the further you read the more convoluted it becomes.
The less you need, the more you have. Even a blind squirrel gets a nut...occasionally. JaxCoder.com
This might be a situation like TDD where it's a lot less overwhelming if you do it as you go. One thing I do in visual studio when I'm working professionally, or at least on an involved open source offering, is I mark warnings as errors in release builds and also tell it to generate docs from doc comments. That way any publicly exposed methods that don't have doc comments on them get flagged as errors under the release builds. It's a start. But honestly, just try writing a technical article about your code. It doesn't have to be good - you might be the only reader of it. But with it, you can generate an outline, and with that a table of contents. Failing that, you can go through the header files and start your outline with the name of each, before drilling down into them. If you already divide your source code out into multiple files as a matter of course this can work pretty well in terms of getting you started. And if you're not great at writing, write samples. Lean on that. A little bit of verbiage with a lot of example code. I hope some of that helps. :)
To err is human. Fortune favors the monsters.
-
I was kind of a writer first. I wound up being part of "Young Authors" twice, I could have seen getting an English or a degree in literature as easily as I got into coding if things had played out differently. I learned to read when I was 3, and was voracious about it for a long time. I think picking up literacy early sort of wired me for writing. Audre Lorde (activist, poet) also learned to read at 3, although she was a better writer than I am. Still my point is, I think training young is what does it, and the younger you can do it, the easier is is when you get older. I could be wrong. Maybe we're wired a certain way and that leads to early literacy and a knack for writing. Causality in matters like that can get slippery fast. Either way, the gift really helps when it comes to documenting what I've coded. I feel blessed for it. :)
To err is human. Fortune favors the monsters.
I have attention problems, but I'm getting better. I have become a voracious reader, I've probably read 70-80 books this year and I've got many more lined up. My writing is getting better, at least I think so, but it's so hard to get going. I'm finding that many folks can write but few are really good at it.
The less you need, the more you have. Even a blind squirrel gets a nut...occasionally. JaxCoder.com
-
This might be a situation like TDD where it's a lot less overwhelming if you do it as you go. One thing I do in visual studio when I'm working professionally, or at least on an involved open source offering, is I mark warnings as errors in release builds and also tell it to generate docs from doc comments. That way any publicly exposed methods that don't have doc comments on them get flagged as errors under the release builds. It's a start. But honestly, just try writing a technical article about your code. It doesn't have to be good - you might be the only reader of it. But with it, you can generate an outline, and with that a table of contents. Failing that, you can go through the header files and start your outline with the name of each, before drilling down into them. If you already divide your source code out into multiple files as a matter of course this can work pretty well in terms of getting you started. And if you're not great at writing, write samples. Lean on that. A little bit of verbiage with a lot of example code. I hope some of that helps. :)
To err is human. Fortune favors the monsters.
Thanks for the advic.
The less you need, the more you have. Even a blind squirrel gets a nut...occasionally. JaxCoder.com
-
Today I am staring at two implementations of a DMA enabled I2S parallel bus system trying to make sense of them since they are using very scarcely documented registers and I'm totally new to this. I'm tackling this *because* I can't do it. I tackled LL, LALR, and eventually GLR parsing *because* I couldn't do it. Challenging myself is not only how I make wicked code, it's how I level up. It also keeps me engaged. I don't always succeed, but most of the time I do, and often times when I don't I'll come back a month or sometimes even years after I put it down, dust it off, and make it dance. There's a certain safety in sticking with what you know, and a lot of times in the professional realm, that's the prudent approach. But I don't feel like you grow as much in terms of the craft. It gets to be habit, and empty repetition.
To err is human. Fortune favors the monsters.
-
You're not only a good coder but a prolific writer. You have a knack for writing that I don't have, I don't express myself very well and it takes forever for me to document a project for my site.
The less you need, the more you have. Even a blind squirrel gets a nut...occasionally. JaxCoder.com
-
"We choose to go to the moon and do the other things, not because they're easy, but because they are hard."
-
Today I am staring at two implementations of a DMA enabled I2S parallel bus system trying to make sense of them since they are using very scarcely documented registers and I'm totally new to this. I'm tackling this *because* I can't do it. I tackled LL, LALR, and eventually GLR parsing *because* I couldn't do it. Challenging myself is not only how I make wicked code, it's how I level up. It also keeps me engaged. I don't always succeed, but most of the time I do, and often times when I don't I'll come back a month or sometimes even years after I put it down, dust it off, and make it dance. There's a certain safety in sticking with what you know, and a lot of times in the professional realm, that's the prudent approach. But I don't feel like you grow as much in terms of the craft. It gets to be habit, and empty repetition.
To err is human. Fortune favors the monsters.
To be adventurous or to be prudent? Be adventurous about what you discover and prudent about what you implement. If you discover a better less error prone path then it could be prudent to implement it.
-
To be adventurous or to be prudent? Be adventurous about what you discover and prudent about what you implement. If you discover a better less error prone path then it could be prudent to implement it.
That doesn't work for me when I'm learning though, because I learn by doing, which means I'll implement something well before I realize I understand it, and that process helps me understand it further. The implementation I'm left with generally needs some retooling but that's how it goes. :)
To err is human. Fortune favors the monsters.
-
Today I am staring at two implementations of a DMA enabled I2S parallel bus system trying to make sense of them since they are using very scarcely documented registers and I'm totally new to this. I'm tackling this *because* I can't do it. I tackled LL, LALR, and eventually GLR parsing *because* I couldn't do it. Challenging myself is not only how I make wicked code, it's how I level up. It also keeps me engaged. I don't always succeed, but most of the time I do, and often times when I don't I'll come back a month or sometimes even years after I put it down, dust it off, and make it dance. There's a certain safety in sticking with what you know, and a lot of times in the professional realm, that's the prudent approach. But I don't feel like you grow as much in terms of the craft. It gets to be habit, and empty repetition.
To err is human. Fortune favors the monsters.
I believe that when I stop growing, I stop living. Even breaks from direct learning can provide growth just as rest periods are when the muscles grow when weight training. I can always find ways to grow, even in an environment where I'm working with what I know, but absolutely new things are a delight to learn, it's true.
-
Today I am staring at two implementations of a DMA enabled I2S parallel bus system trying to make sense of them since they are using very scarcely documented registers and I'm totally new to this. I'm tackling this *because* I can't do it. I tackled LL, LALR, and eventually GLR parsing *because* I couldn't do it. Challenging myself is not only how I make wicked code, it's how I level up. It also keeps me engaged. I don't always succeed, but most of the time I do, and often times when I don't I'll come back a month or sometimes even years after I put it down, dust it off, and make it dance. There's a certain safety in sticking with what you know, and a lot of times in the professional realm, that's the prudent approach. But I don't feel like you grow as much in terms of the craft. It gets to be habit, and empty repetition.
To err is human. Fortune favors the monsters.
-
In some ways I guess. I think I get a lot more mileage out of helping people, in terms of becoming a better human in the general sense. But I guess it depends on which rubber ruler you use, and what better really involves. It's a slippery concept, for sure. :)
To err is human. Fortune favors the monsters.
-
That doesn't work for me when I'm learning though, because I learn by doing, which means I'll implement something well before I realize I understand it, and that process helps me understand it further. The implementation I'm left with generally needs some retooling but that's how it goes. :)
To err is human. Fortune favors the monsters.
I learn by doing to and I have an enormous codebase of fantastical experimental ideas from which I have learned a lot but would not employ in production code. Having said that, I am retired now and can afford to be wise and circumspect. In fact I specialise in it because it is less stressful. Back in the day though, I used to innovate wildly and put it straight out in the field because it was needed. I had a lot of confidence in what I was doing but it did mean that I had to become an expert at completely refactoring my own innovations without breaking anything - usually because I hit a design cul-de-sac tying up loose ends. Yes, you do have to roll up your sleeves, get your hands dirty and have confidence in your own brilliant ideas. I still do it but I now have the luxury of only publishing what I want to when I think it is ready.
