[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Sun, 26 Jun 2005 10:03:05 -0500
I'm actually less concerned about your design decisions or
your choice of tools, even XML if you feel you must. Do whatever
it takes to solve some part of the problem.
Believe it or not one of my main concerns is that the code
be well documented or should I say that "the document is
well coded". Try to keep the mindset that you're writing
a paper explaining the problems and their solutions rather than
the mindset that you're writing code and will "document" it later.
It's a hard transition to make but it's a hard lesson to learn
after the fact. Axiom will actually benefit more from a description
of what your plan of attack is, what tools you plan to use (along
with prototype skeleton examples), what the architecture and API
you've chosen for communication (as well as code), what problems you
see that still need to be solved with pointers to parts of axiom
that might need changes, etc. In my recent experience of documenting
the current Axiom code every line of working code takes at least 10
lines of documentation, which is much harder to construct if you
didn't write the code. I'm currently documenting the coercion
code and it's turned into a real research task.
It seems like a lot of work but you'll already be doing it in
your head and you'll benefit from having to think about it clearly
enough to write it down as you code it.
We'll all also benefit in the long term because the next programmer
to "pick up the torch" won't have to re-invent the world (like
embedding another web-server or maintaining "frames" of values that
axiom can already do).
A second piece of advice is to "release often". I know it feels
like criticism when many people "jump in" but there are a large
number of very clever and motivated people on this list who can
be very helpful.
My last piece of advice is the make sure your work get integrated
into the overall "make". People who get open source expect it to
work "out of the box" by typing "make".
My "next+1" piece of advice is to have fun. Enjoy it, learn something
from it and do things because YOU think they're worth doing. That's
really the essence of open source programming.
I envy you your summer job.