4 ms·
What I learned building [Pulitzer winning] PolitiFact
- Slzr 18y agoFTA: 2. Meetings suck. My favorite game right now? I sit in meetings, guessing what everyone around the table makes, and then I figure out how much this meeting is costing. Then I figure out how many page views at so much CPM its going to take to break even on just that meeting. I'm pretty sure I'm descending into madness, but the point is this: a demo cuts down on meetings. You don't have to spend time explaining what you want to do. You just show it. A demo is not a finished product -- there's still plenty of work to be done -- but the meetings stop being about the idea and start being about execution.
- iamcalledrob 18y agoThis is essentially a very brief summary of the 37 Signals (e)book, "Getting Real" http://gettingreal.37signals.com/ http://gettingreal.37signals.com/ I suggest you all read it. They have some really, really good points and analogies.
- gmazzola 18y agoI've worked at a very large (60,000+ employee) company, so perhaps my background clouds my judgment somewhat, but I think requirements documents are quite helpful. The Software Functional Specification that was handed to me provided a good background to the problem space. When I wrote the Software Design Specification (100 pages, oof...), I easily solved 2/3 of the bugs before I touched a single line of C code. I was surprised, since I didn't think I would enjoy the documentation process, but it really helped. I designed my module using English and pseudo-code, sent the spec around for comments, and when the spec was approved it was a (somewhat) simple matter of conveying a solid design into C. Meetings still suck and should be minimized, but documentation is really essential. I always glance at the Design Spec for a feature before going into the code, since it gives you some solid background as to what exact problem they were trying to solve.