How about double-linked lists? Dynamic array classes? ODBC clients? Could you write a graphical user interface that works like a popular one you know and like?
Can you create your own web-browser widgets? Do you know when to write a multiplexed system versus a multi-threaded one? How to decide between a file- or a memory-based database? Most developers simply have never created these types of core software implementations themselves and therefore do not have an intimate knowledge of how they work.
The consequence is all these kinds of software are viewed as mysterious black boxes that just work. Notify me of new posts by email.
This site uses Akismet to reduce spam. Learn how your comment data is processed. I realised then that the same thought can be applied to software development. So, what does this concept even mean? Using a framework in your project allows you to build on what someone else has created.
Design patterns — Similar to a framework, using a design pattern allows you to use a common design for source code to achieve a goal. It might be worth rewriting quicksort , but is it worth rewriting a basic language feature which is more minutiae than meat? Probably not. If we look at quicksort, we get a potential for it to be a rote coding exercise for something like a job interview, to it being a good, general purpose sort implementing recursion at an intermediate level. Beginners will probably just copy code since it involves understanding data structures, Big O notation, algorithm use cases, recursion, and divide and conquer among other things.
You can also treat this as a standard distribution bell curve of skills. You have a specific level where you get the most gains for a given task, and then standard deviations of skills away both more advanced and less which dip drastically.
The same is true of technical challenges. Too easy is just busy work, but too hard and the eyes just glaze over. The failure from working with XML showed me what my limitations were and taught me how to better identify when a task is difficult. Though I got very little out of the coding except redundant experience with error handling and an insane level of conditional spaghetti, I learned just how hard XML was.
The earlier in the learning process you are, the less sure or less accurate you will be about where you are. You deal with a good bit of uncertainty one way or another.
The only way to break through is to just try. The two are similar, but the subtly is that between a night and an evening. For example, James Hart reinvented the wheel. And he liked it:.
But who's James Hart? Just another programmer. The conventional approach, enforced to a greater or lesser extent, is that you shall use a standard subroutine.
I say that you should write your own subroutines. Before you can write your own subroutines, you have to know how.
0コメント