4 ms·

From one standpoint he's right. Frameworks come and go, and what you use in 5 years, will most likely not be the same today. I think he misses something key t

by kemiller2002 8y ago

From one standpoint he's right. Frameworks come and go, and what you use in 5 years, will most likely not be the same today. I think he misses something key though. Learning a framework is not just about understanding you call method X to do Y. It's about understanding why people who created it designed it that way. He touches on this briefly, and he mentions some books that everyone in SD should read, but they don't really show how in depth application of how things can be put together. Learning about a framework shows you concrete examples of how things can (and sometimes cannot) function together. IF learning a framework is just about learning the names of methods and results, you've missed the key point to learning it.

commandlinefan 8y ago
> why people who created it designed it that way Yep, exactly. Once I understand the problem that a framework was designed to solve (which is nearly always the hardest part of the framework to uncover), the details are almost obvious.
- SlowRobotAhead 8y ago
  I have been seeing a real issue with tech people, code comments, datasheets, SDKs, git readme, framework descriptions, stackexchange posts, and generally all spoken words around computer science that people seem to forget or just for some reason aren’t mentioning intent. Tell me how you INTENDED this code to run (‘why’ comments, not ‘what’), tell me how you INTENDED this micro’s peripheral buffer and registers to work, tell me how you INTENDED this framework to solve this problem - and I’ll see if what you intended works for me or not. The drastic alternative is not seeing a better solution because you only ever implement something the way someone else told you to - but specifically for this discussion, that’s what a framework is anyhow.
  - tabtab 8y ago
    I intended my code to work ;-)
brightball 8y ago
Frameworks are most valuable in 2 situations: 1. You are going to be using this framework in multiple different projects, so the time investment will yield time savings returns over the course of multiple projects as well as ease of maintenance of each project over time. This accelerates further with popular frameworks that have common bolt-on functionality. 2. You need multiple people to work on the same code base under a specific set of standards. Your options there are to either, select a framework for which those rules already exist OR to create your own framework of rules and then teach them to other people. People generally want to invest in portable knowledge and are much less likely to want to invest in your framework than they are in a framework they can use either at home or in other jobs. Neither of these apply in situations where the code surface is very small or isolated, so be wary of increasing the size of the code base with a framework where it isn't necessary or valuable.
seanalltogether 8y ago
I agree. Frameworks tend to codify a set of design patterns and fundamentals into a nice package, they offer you training wheels to a broader set of concepts. If the author said that frameworks are great to learn for your first 10 years, then spend time after focusing on more abstract fundamentals I would agree with him. But as it stands I think he's making a blanket statement that is misleading to newcomers.

commandlinefan 8y ago

> why people who created it designed it that way Yep, exactly. Once I understand the problem that a framework was designed to solve (which is nearly always the hardest part of the framework to uncover), the details are almost obvious.

SlowRobotAhead 8y ago
I have been seeing a real issue with tech people, code comments, datasheets, SDKs, git readme, framework descriptions, stackexchange posts, and generally all spoken words around computer science that people seem to forget or just for some reason aren’t mentioning intent. Tell me how you INTENDED this code to run (‘why’ comments, not ‘what’), tell me how you INTENDED this micro’s peripheral buffer and registers to work, tell me how you INTENDED this framework to solve this problem - and I’ll see if what you intended works for me or not. The drastic alternative is not seeing a better solution because you only ever implement something the way someone else told you to - but specifically for this discussion, that’s what a framework is anyhow.
- tabtab 8y ago
  I intended my code to work ;-)

brightball 8y ago

Frameworks are most valuable in 2 situations: 1. You are going to be using this framework in multiple different projects, so the time investment will yield time savings returns over the course of multiple projects as well as ease of maintenance of each project over time. This accelerates further with popular frameworks that have common bolt-on functionality. 2. You need multiple people to work on the same code base under a specific set of standards. Your options there are to either, select a framework for which those rules already exist OR to create your own framework of rules and then teach them to other people. People generally want to invest in portable knowledge and are much less likely to want to invest in your framework than they are in a framework they can use either at home or in other jobs. Neither of these apply in situations where the code surface is very small or isolated, so be wary of increasing the size of the code base with a framework where it isn't necessary or valuable.

seanalltogether 8y ago

I agree. Frameworks tend to codify a set of design patterns and fundamentals into a nice package, they offer you training wheels to a broader set of concepts. If the author said that frameworks are great to learn for your first 10 years, then spend time after focusing on more abstract fundamentals I would agree with him. But as it stands I think he's making a blanket statement that is misleading to newcomers.