Hacker News new | past | comments | ask | show | jobs | submit login
Not Invented Here and New Programmers (webicity.info)
70 points by Macha on May 8, 2011 | hide | past | favorite | 24 comments

there are 3 stages each programmer must go through.

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.

You assume a lot. What makes you think novel programmers don't get taught (either by teachers, professors, a book, or an online tutorial) the basics? A teaching institution that teaches their students how to use frameworks so as to put buzzwords on their CVs instead of the core concepts is an incredibly poor one.

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...

> There are a lot of abstractions that make programming simpler; complex is rarely better.

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.

Yes! As a novice programmer, this is exactly the stuff that has driven me away from programming time and again. Glue code is usually very time consuming (since I'm not familiar with whatever framework/legacy system I'm gluing to), and yields very little in terms of learning experience. I can't say I know how to become a great programmer, but I sure know one way not to.

It depends on what you want to accomplish.

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.

There's nothing wrong with spending a couple years writing glue code.

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".

I firmly believe that to be a decent web programmer, you have to have gone through phase of writing your own web framework.

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...

BS, all code is glue code, even assembly (what, you don't write your own hard drive controllers and NIC firmware?).

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.

I think you missed the point. New programmers generally aren't working an a production/work environment. People learn to code in their free time. Or at least, that's what I did.

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.
However, that is exactly what the OP is advocating. He is complaining that 'kids these days' don't first write their own ORM layer, templating system and MVC framework.

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).

You definitely misunderstood my point. While I wouldn't consider myself a new coder anymore, I've only been doing it 4 or 5 years, so I'm not complaining about odd these days not learning anything. I'm more speaking from my own experience. Most of the books I had stressed finding a library that already existed and using it for your purposes and when I showed people my early apps, there was a tendency for people to go "why didn't you just write a drupal plugin?", or "why didn't you use PDO?"

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)

I like the idea of learning by attempting to improve/debug open source software.

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.

At work - I will use whatever external code I can find. Doing side projects there is nothing I love more than to write something basic and than see how other people / frameworks / code solve the same problems. This is the basic unit of learning - doing and comparing.

He's forgetting that the computer industry reinvents everything on a 4-5 year cycle.

"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.

The first real script I wrote that accomplished anything was a script that spammed a small forum I'd been a member of for years. It wasn't malicious, just a toy at the behest of a more experienced friend. The idea was that it'd teach me about HTTP and screen scraping. It sure did. It's been incremental steps all along the way to where I am now.

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.

I don't see how this is particularly inherent to new programmers. I feel that 90+% of my code is either glue code or mucking with configurations.

My idea of NIH is "we can't use this code/library/app because we didn't write it ourselves." I've been guilty of this kind of thinking. I justify it with the task being so simple that there's no excuse for not writing it myself. Then comes the feature creep and ultimately it would have made more sense just to use a library.

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.

I kind of disagree with this post. Tanks to Modern frameworks young programmers can ship clean code easily. I think frameworks help young developers become better by the day.

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 frameworks help young developers become better by the day.

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.

As an aside, a way to do old things that haven't been done yet is to do them on a new platform.

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.

Rails is a quite heavy framework to learn. I have to internalize models of how rails work and how they fit together. Plus, you still have to write good models/controller/etc code anyway.

"May 10, 2011 at 07:00 PM": in which date zone is this guy living?

Fixed. I wrote the first draft of this April 10th, left it for a month as other things got on top of me and forgot to update the day part of the date field when I did the month. (Too late to fix the URL though, or Google Analytics, Disqus and Twitter will assume its a new page)

No problem. It was the first time that I noticed a wrong date and I was so confused that I doubled checked my calendar!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact