The best way to learn something is to come up with it yourself.
That's been bugging me, and it's been bugging me because it's not entirely right. It's not entirely wrong either, though.
Given an undirected graph, in which you need to calculate the shortest path between two vertices, would you slog it out or would you just find a shortest path algorithm?
Now move that up a level, from feature implementation to feature design -
If you had to federate identities between two directories, would you hack something together, or would you have a look to see if someone else has done that before? Assuming the latter, you'd probably discover OpenId, OAuth, WS-Federation, and SAML. Would you then use one of these or try to roll something that models their behaviour?
Take that up all the way until you reach the age-old build vs. buy debate, and the connected enterprise and so on. Building something just to understand it is not making much sense to me.
> Given an undirected graph, in which you need to calculate the shortest path between two vertices, would you slog it out or would you just find a shortest path algorithm?
Probably just find an algorithm. This is because my goal was not to learn about shortest path algorithms, rather it was to find the shortest path. Whichever algorithm I chose and however I implemented it is of minimal concern - if it turns out to be bad, I can probably redo it without significantly affecting any other part of the program. I claim that, if, on the other hand, you wanted to learn about shortest path algorithms, it would be better to first at least try to think of a solution or two, then go for the books.
Speaking of software architecture, given the profound impact a solution will have and how disastrous bad choices can get, it should be your goal to learn about whatever you're dealing with.
> If you had to federate identities between two directories, would you hack something together
Right, that "try it yourself" part can get very big and impractical. But the idea still stands: it would be better if you first tried to think how a solution would look like and what it would do, in very general terms. Are the two systems very similar and a solution would be little more than mapping one thing onto another? Or are the systems very different and complex translations would be have to be performed?
Once you do that, you can have a look at any existing solutions, and almost certainly you'll have a better understanding compared to if you didn't do the thinking part first.
It is also important not to switch the order of "thinking" and "looking". If you first look for existing solutions, then your thinking will be biased by what you have seen.
That's been bugging me, and it's been bugging me because it's not entirely right. It's not entirely wrong either, though.
Given an undirected graph, in which you need to calculate the shortest path between two vertices, would you slog it out or would you just find a shortest path algorithm?
Now move that up a level, from feature implementation to feature design -
If you had to federate identities between two directories, would you hack something together, or would you have a look to see if someone else has done that before? Assuming the latter, you'd probably discover OpenId, OAuth, WS-Federation, and SAML. Would you then use one of these or try to roll something that models their behaviour?
Take that up all the way until you reach the age-old build vs. buy debate, and the connected enterprise and so on. Building something just to understand it is not making much sense to me.