Hacker News new | comments | show | ask | jobs | submit login

How consistent you are about the patterns you use must have an enormous impact on how easy it is to resume work on something three projects ago.

If you're switching between frameworks all the time, it would be even more difficult because you wouldn't have deep knowledge, but at least there is presumably a group of people somewhere to consult. If you're lucky they even had some plan when they came up with design decisions.

I can see how you avoid a lot of cruft, but how do you discipline your own projects? How much documentation do you create for your own later reference?




I just reference a piece of code where I know I've done something similar in the past, even for public frameworks like rails.


I can't speak for the grandparent but my approach has developed slowly into:

1) Consistent but evolving paradigms. In other words, let's not be static, let's keep most change happening relatively slowly. But let's review and try to fix problems as they happen, cleaning old code slowly and continuously.

2) Try to document everything to at least a basic extent.

3) Let the documentation practices evolve. Don't try to document too much too soon. Start out with a basic level. As the project matures you will have a better idea of what needs more documentation and you can spend your time on the areas that help.

4) Don't underestimate person to person mentoring.


Its a really good point and Im not going to try and cover up the pitfalls you pointed out. I'm trying to document the reusable core as much as I can because 1) Im forgetful and at times will need a quick refresh 2) Im hoping that I can open source it soon and it might have a chance of helping someone that likes it. I know that producing core code to bundle into a framework when I don't use frameworks is pretty hypocritical but even so thats an intent I have for the future.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: