Ok, got it on the docs! Thanks! FWIW, way back in the day, I was laid off of a job in part because the Powers that Be thought I wasn’t doing anything substantive. I ran into one of them a year later who fessed up and apologized, saying that as a result of my leaving, two projects died and two others were significantly delayed because nobody there could figure out the system I’d implemented. My only question was why they never bothered to look at the ~200 page document I left behind that explained everything I’d done? Apparently they never bothered to look at any of my docs.
The moral of that is … docs are great, but people need to take the time to read them! Anyway, back to the project at hand … is this something that they’d want to bother taking the time and effort to find someone with the exact expertise to work on? Or find someone like me who “comes close” and might work a bit more slowly (due to less familarity with the exact subject matter) but could ultimately get the work done? -David On Mar 24, 2014, at 7:05 AM, JD Austin <[email protected]> wrote: > I'll 3rd on documentation... even if you do it yourself. > > > On Mon, Mar 24, 2014 at 5:20 AM, Stephen Partington <[email protected]> > wrote: > I will second the documentation comments here. > > On Sunday, March 23, 2014, George Toft <[email protected]> wrote: > ... The moral of the story is you must include time (and time is money) for > documentation. Pound this into their head. Document requirements. Document > test cases. Document architectural decisions. Document engineering > decisions. Document process flows and data flows. Make this a brain dump. > BTW - this will easily take as long as the coding, but if you don't, when it > breaks and you're not around, they're screwed. > > >
--------------------------------------------------- PLUG-discuss mailing list - [email protected] To subscribe, unsubscribe, or to change your mail settings: http://lists.phxlinux.org/mailman/listinfo/plug-discuss
