4 ms·

I have the feeling that TDD-oriented people like me tend to do a lot of top-down, at least mentally. I'll frequently write the general behavior (in my case eith

I have the feeling that TDD-oriented people like me tend to do a lot of top-down, at least mentally. I'll frequently write the general behavior (in my case either the API or runtime params and inputs) then work my way down to make it work. Somewhere in the middle, however, we all need to go down the layers to either store something in a database or figure out how to work on a collection of items. This turns the process bottom-up to some extend. Then the very last phase is going back and forth until both solutions meet in the middle.

hinkley 4y ago
It's a constant problem with trying to talk about process. It's much easier to see the struggles of others, and not your own. I've had a couple bosses who probably could write a book on management, but to a man, their thesis about what makes them successful and which bits are necessary always misses some critical piece, usually lamented in private amongst the senior people. One of these, talking about his own mentor, asked me once, rhetorically, "is he successful because of his theories, or because he uses the same people on every project?" Wish that some of my previous bosses were that aware. They didn't always see the detailed work their senior people were doing to keep the wheels on. You always assume they see that about you when it comes to who they chose to report, but to hear them enumerate the virtues of the team, and omit such things, that stings. There are certain fictions we engage in different strategies for solving problems as well, and there's always a little Socratic method in the middle where we pretend like we haven't seen the solution at the end, and go through a farce of arriving at it step by step. That may reduce the importance of sudden epiphanies, but it does not remove it.
Izkata 4y ago
> at least mentally. Even without TDD, that's kind-of how I go: I'll have the top-down general structure in mind, but not in the code, and write the actual code bottom-up. That way I encounter problems with the implementation details sooner, and can more readily adjust the overall structure without feeling bogged down by what's already written. In the broader structure though it's more like a through-line: One nice input/output, written in that bottom-up-with-top-down-in-mind way, all the way through a use case, then expand sideways with the other inputs/outputs built on the same lower-level functionality.

hinkley 4y ago

It's a constant problem with trying to talk about process. It's much easier to see the struggles of others, and not your own. I've had a couple bosses who probably could write a book on management, but to a man, their thesis about what makes them successful and which bits are necessary always misses some critical piece, usually lamented in private amongst the senior people. One of these, talking about his own mentor, asked me once, rhetorically, "is he successful because of his theories, or because he uses the same people on every project?" Wish that some of my previous bosses were that aware. They didn't always see the detailed work their senior people were doing to keep the wheels on. You always assume they see that about you when it comes to who they chose to report, but to hear them enumerate the virtues of the team, and omit such things, that stings. There are certain fictions we engage in different strategies for solving problems as well, and there's always a little Socratic method in the middle where we pretend like we haven't seen the solution at the end, and go through a farce of arriving at it step by step. That may reduce the importance of sudden epiphanies, but it does not remove it.

Izkata 4y ago

> at least mentally. Even without TDD, that's kind-of how I go: I'll have the top-down general structure in mind, but not in the code, and write the actual code bottom-up. That way I encounter problems with the implementation details sooner, and can more readily adjust the overall structure without feeling bogged down by what's already written. In the broader structure though it's more like a through-line: One nice input/output, written in that bottom-up-with-top-down-in-mind way, all the way through a use case, then expand sideways with the other inputs/outputs built on the same lower-level functionality.