| Time |
S |
Nick |
Message |
| 00:20 |
|
bear |
oh I like it - I guess my reaction now is viewed thru the lense of experience |
| 00:20 |
|
bear |
lens? lense? (*sigh*, speling is hurd) |
| 00:23 |
|
pdurbin |
:) |
| 03:47 |
|
pdurbin |
After you've added a feature to some software, what do you call the thing you write that describes how you implemented the feature and why you made the decisions you did? Is this a "design document"? Is there a better term for this? The audience is not end users but rather other developers and people who are familiar with the internals of the system. |
| 11:13 |
|
aditsu |
bear: lens (yes, singular ending in s) |
| 11:14 |
|
aditsu |
also, omg, a bear! run for your lives! |
| 11:14 |
|
bear |
thanks, I thought it looked odd |
| 11:14 |
|
* bear |
runs! |
| 11:14 |
|
aditsu |
um... that works :) |
| 11:14 |
|
bear |
:) |
| 11:15 |
|
* aditsu |
just did google code jam |
| 11:17 |
|
aditsu |
pdurbin: could be design document, or maybe internal documentation? |
| 11:20 |
|
aditsu |
heh, "return 12;" - that does sound like a microsoft thing |
| 11:21 |
|
aditsu |
it's just missing a comment - "// 12 should be enough for everyone" |
| 11:21 |
|
bear |
:) |
| 12:13 |
|
pdurbin |
aditsu: ok, so you think "design doc" is ok. Thanks. Here's what I ended up writing: https://docs.google.com/document/d/1ENQCT0g2x9tdTep3ImtAHFww8f1WJr9d2o4UMcr_gSM/edit?usp=sharing |
| 12:14 |
|
pdurbin |
It's all the stuff that was top of mind last night. I suspect I'll keep adding to it. |
| 12:15 |
|
pdurbin |
If another developer comes along and hacks on the feature, it would be awfully nice for them to understand the design decisions behind the feature. That's part of what this doc is. |
| 18:59 |
|
pdurbin |
sivoais: https://github.com/codeforscience/community |
