>Rhythm. Waiting until the right moment preserves energy and avoids clutter. Act with intensity when the time comes to act.
What does this mean ?
Mastering Programming: An Outline
121–130 of 136 posts
Re: Mastering Programming: An Outline
#122Something that is helping me a lot recently is trying to know all there is to be known about the tools/concept that I am using and the problem that I am solving. Too often have I used tools I half understood to solve problem that I didn't define clearly enough.
Yeah, this is a bad pattern I started noticing even way back when I mucked about with Wordpress theming. Hell, I could go further back and notice this pattern in assembling LEGO. And sadly I still catch myself doing it even now whenever I'm caught up in this "this shit doesn't work, let me try that real quick" loop, where 'that' is only one of many variables I don't really understand. What I've noticed works best for…
> notice this pattern in assembling LEGO
What do you mean?
Re: Mastering Programming: An Outline
#123www.prod.facebook.com That's new to me.
Welcome to Facebook, where you are the product (even in the url)
Re: Mastering Programming: An Outline
#124>Rhythm. Waiting until the right moment preserves energy and avoids clutter. Act with intensity when the time comes to act. What does this mean ?
Measure twice cut once perhaps? That's what I took from it.
Re: Mastering Programming: An Outline
#125Earlier quoted context omitted.
It works very well, until it doesn't. Then you have a pretty interface, an elegant test suite, and a big black box full of entropy and ignorance labeled "then a miracle occurs".
Even when that does happen... and I'd argue that it often does not, if you've done the work to make your interface pretty, and write a precise, accurate test suite, you've usually done the work to make the actual functions neat and orderly... Even when you end up with a black box full of entropy, it's segregated from the rest of the system. You can feel free to change the rest of the system around it and know that th…
Absolutely! Get something working and then keep it working while making small steps.
On the other hand, the example that comes to mind is Ron Jeffries' TDD sudoku solver.
I've seen several systems where the magic black box is doing things hilariously wrong---as long as it works on the test cases and the production results are sufficiently difficult to verify, it'll be accepted as gospel.
Re: Mastering Programming: An Outline
#126> Call your shot. Before you run code, predict out loud exactly what will happen. That's probably my favorite bit of advice. It really helps with understanding how much your assumptions diverge from reality.
That's great from beginner to master levels. Although master programmers call shots that are correct almost always :)
Re: Mastering Programming: An Outline
#127Re: Mastering Programming: An Outline
#128Earlier quoted context omitted.
Yeah, this is a bad pattern I started noticing even way back when I mucked about with Wordpress theming. Hell, I could go further back and notice this pattern in assembling LEGO. And sadly I still catch myself doing it even now whenever I'm caught up in this "this shit doesn't work, let me try that real quick" loop, where 'that' is only one of many variables I don't really understand. What I've noticed works best for…
> notice this pattern in assembling LEGO What do you mean?
Well, usually the first time I'd have some new package of Lego, I'd want to construct the exact thing I bought from the instruction booklet.
Sometimes I'd be working on different parts at the same time and use a piece that was similar to another. I recall a few times looking everywhere for the missing piece or disassembling a part to find it only to find out that another little part I assembled had the missing piece.
Re: Mastering Programming: An Outline
#129Earlier quoted context omitted.
Exactly. I have not seen a new thing in many years. All the so called "new" things are simply rebranded decades old ideas.
Isn't everything?
Even your statement isn't new! 2200 years ago King Solomon wrote, "There is nothing new under the sun." We just keep finding different ways to rehash the same core concepts.
Re: Mastering Programming: An Outline
#130> Call your shot. Before you run code, predict out loud exactly what will happen. That's probably my favorite bit of advice. It really helps with understanding how much your assumptions diverge from reality.
Agreed. This is akin to "rubber duck" debugging. Highly effective.