Not Invented Here and New Programmers
blog.webicity.info
blog.webicity.info
In stage 1 you program to prove to yourself you can. The results not about making something new or original, but rather making anything at all.
In stage 2 you program to prove to others you can. This is the phase when using a library is anathema. Libraries are for people who can't do it themselves (or so you say...)
In stage 3 there's no need to prove anything any more. Now you can concentrate on other goals, like economics (or, how to make a program profitable) or perhaps it's about solving some new problem.
You can't skip a stage - the process is important - jumping to stage 3 is more like being at stage 0.
That said I like programmers in stage 3, they're not trying to prove anything - not trying to compete with their team mates, and more keen to just get the job done, as best it can be done.
As others have said before - those that ship, win.
I certainly agree that, for want of a better term, the NIH syndrome is the best way to learn to program―you don't learn to run before you walk, neither do you learn the structure of sentences before you learn to spell.
> I wrote a PHP social network. [...] How would a newbie do that nowadays? They'd install cakePHP or Django or Rails, getting them a DBA layer, templating, MVC all written for them.
They would? They could. At the same time, however, I wouldn't say it's that bad. Do you understand how your kernel handles networking for you? Memory management? There are a lot of abstractions that make programming simpler; complex is rarely better. Getting tangled up in all the small details hinders much more than it helps.
Frameworks, eh. It wasn't long ago that all programming was done in assembly language...
I think the point is that, getting tangled up in that complexity, and then coming out on the other side successfully is a process that all programmers must go through to become "good". To programmers who have only used frameworks and wrote glue code, they miss out on the fundamental process that makes one truly good.
If you want to be known for great modules that lots of other programmers use and glue into their own stuff, then write modules that have few dependencies and are as glue-friendly as possible.
If you want to make user-facing products and succeed in the 90% of programming jobs that involve making database data entry screens, learn a few popular frameworks and libraries and learn how to stick them together as rapidly as possible.
Nor is there anything wrong with spending a couple years using an operating system before building your own.
There are plenty of libraries to write that haven't been written yet, yes, DB abstraction layers have been done to death, but I'm sure there's still a better way to make CSS sprites, or platforms for which ANY library is not readily available.
In my opinion, "If I have seen further, it is because I stood on the shoulders of giants".
In some ways, I don't think you truly appreciate the value of (and how best to use) any given framework until you've tried doing it yourself (whether through ignorance, hubris or curiosity)
And judging by the number of (largely abandoned, or single-serving) web frameworks out there, many have come to the same conclusion...
It's ALWAYS been the case that if you want to go deep, generally, the best way isn't to write your own, shitty ORM, or HTTP Server, in a production/work environment (in your free time, go ahead, that's a great idea).
I'd say, the best way is to work with those who know better. With OSS and things like github today this is easier than ever. And at a certain point, you might say "I think I can write a better HTTP Server", and you'll have the background to actual say that with some confidence.
You don't have to write a fully functional HTTP server to better understand how HTTP requests work. I wrote a simple python script that listened for http requests. I sent it requests with curl and then wrote some routing and logic to return various responses. It wasn't even high enough quality to call it an alpha framework, but it helped me understand how a MVC framework is different from serving static pages, or even php files. Many people I've helped get started with web programming benefitted when I walked them through the crappy HTTP server I wrote. It helped them see what was going on behind the scenes.
You don't have to write a fully functional HTTP server to
better understand how HTTP requests work.
I agree with your parent and call BS on that attitude. You don't need to handwrite a BIOS in microcode before you can say you understand how it works and call yourself 'a real coder'.
Newbies simply need to practice, practice, practice. Whether they are gluing stuff together or designing large, important components from scratch is irrelevant. You don't need to write an ORM layer to be able to get a very thorough understanding of how it works, simply by using one and reading it's code (which you will have to do anyway if you want to do anything nontrivial).
My point wasn't that people should do those things before anything else, but that there shouldn't be as much discouragement against it in code that's being written for fun or for learning. (Obviously production code is different and in that case relying on the tried and tested code is best)
But I do think there's a difference between "glue code" and other sorts. Basically, it comes down to the amount of time you spend reading documentation versus actually writing code. If you are solving problems on Project Euler, you're not going to read much of any documentation (unless you're unfamiliar with the programming language you're working with)--you'll be solving the problem. On the other hand, if you write a CRUD application in Django, you'll constantly be looking up functions and classes.
"Throw out that mainframe, servers rock! ROI in 3 days!"
"Physical servers... ha! Virtualize them on these here super-powerful 4-socket boxes and consolidate to a cluster of big computers!"
Wash, rinse, repeat.
Basically everything I've written has been done before by someone better than me, but who cares? It's not about WHAT you code, the benefit comes from the process of doing.
From the newbie's perspective, how is he supposed to know what libraries implement which algorithms? Moreover, he usually doesn't know the algorithm name or thinks his problem is unique and so he's sure a library doesn't exist. My experience years ago with this was spent wading through belittling comments from IRC participants while I described what I needed to do before someone with a brain said "OK, you want Algorithm Z. Not sure what libs are out there but someone has probably solved this problem." Now I can search.
As for glue code, learning against several libraries with different coding/naming conventions is a Super Pain in the Butt, regardless of experience level.
First learn about MVC and the first project they writer ends up being somewhat maintainable. It relies on state of the art paradigms, is modular and should be relatively safe.
With time, the framework will not provide all the needed functionality. This is when the young programers start to modify or write simple plugins. So they learn about the Framework API.
Even later, they need to modify some parts of the framework to make it possible to hook into it with a plugin. So they learn about the core Framework.
At every step, the programer is confronted with code written by more experienced programers… To me, this is the best way to learn programing.
I think you're confusing better code with better programmer. A good programmer can come up with solutions to complex problems. Good code is focused on the end result: maintainability, clarity, security, efficiency. A good programmer ships good code. But good code doesn't have to come from a good programmer for all the reasons you mentioned.
You do not learn how to be a good programmer by writing glue code.
So, old games got rewritten in flash, then javascript, iOS and HTML5. Every other app got rewritten as a webapp - and I bet the same is happening right now for iOS.
Maybe not appropriate for every beginner.