How I become a better coder
-
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.
