Advantages of pre-deploy code review, over post-deploy audit:
- Authors have a strong incentive to craft small, well-formed changes that will be readily understood, to explain them adequately, and to provide appropriate test plans, test coverage and context.
- Reviewers have a real opportunity to make significant suggestions about architecture or approach in review. These suggestions are less attractive to adopt from audit, and may be much more difficult to adopt if significant time has passed between push and audit.
- Authors have a strong incentive to fix problems and respond to feedback received during review, because it blocks them. Authors have a much weaker incentive to address problems raised during audit.
- Authors can ask reviewers to apply and verify fixes before they are pushed.
- Authors can easily pursue feedback early, and get course corrections on approach or direction.
- Reviewers are better prepared to support a given change once it is in production, having already had a chance to become familiar with and reason through the code.
- Reviewers are able to catch problems which automated tests may have difficulty detecting. For example, human reviewers are able to reason about performance problems that tests can easily miss because they run on small datasets and stub out service calls.
- Communicating about changes before they happen generally leads to better preparation for their effects.
I like to think of funded startups vs. bootstrapped web sites like the split between signed and unsigned bands.
Think about what a band has to do if they sign with a major label. They write music, perform/record it, and play it. Now think about people like Prince, Aimee Mann, etc. that do every single aspect of their music themselves. They have to create and record and distribute music, but also book tours and hotels and hire roadies and even oversee building websites. On the positive side, those going their own way talk about making more money from lower record sales than they did on a label, even though they do a significant amount of work.
So it’s a lot of work, but I would argue it’s totally appropriate for anything that isn’t a huge world-changing idea. And there are a lot of benefits that come from it.
Matt Haughey — My Webstock Talk: Lessons from a 40 year old (now with transcript).
Writing beginner level tutorials. A number of useful tips. My favorite: “use words and phrases that your reader can Google to find more information.” For producers of documentation, I think the biggest challenge is putting yourself in the mindset of the reader. The second biggest challenge is closing the feedback loop between the person who has the knowledge and the person who wants the knowledge.
Today we differentiate between blogging on blogging platforms and sharing on social platforms, but that is just semantics. The essence of blogging is not defined by a platform but by what I learned from Dave and his blogging platform — that media now is raw, collaborative and instantaneous.
Blogging is communal: In 2008, I wrote that “blogging is not just an act of publishing but also a communal activity. It is more than leaving comments; it is about creating connections.” That is the single biggest lesson learned of these past 10 years. Every connection has lead to a new idea, new thought and a new opportunity.
Being authentic in your thoughts and voice is the only way to survive the test of time.
Being wrong is as important as being right. What’s more important — when wrong, admit that you are wrong and listen to those who are/were right.
Om Malik — My 10 years of blogging: Reflections, Lessons & Some Stats Too
Meet wpshell – the power of WordPress at your prompt. wpshell is an undiscovered gem. Someone should lead a WordCamp talk about it and the secrets it holds.
In other words, my theory is: Cheating (on a systematic level) happens because students try to get an edge over their peers/competitors. Even top-notch students cheat, in order to ensure a perfect grade. Fighting cheating is not something that professors can do well in the long run, and it is counterproductive by itself. By channeling this competitive energy into creative activities, in which you cannot cheat, everyone is better off.
Panos Ipeirotis — Why I will never pursue cheating again. A computer scientist teaching in a business school details a year of trying to combat cheating on assignments. Overall, he spent 45 hours addressing the problem during a 32 hour lecture course, and 22 of 108 enrolled students admitted cheating. Solutions could include:
- Public projects – All of the work ends up public, so embarrassment is the deterring factor.
- Peer review – Students have to present their work in class, and are judged by others.
- Competitions – Grades are performance-based (e.g. students build websites to attract the greatest number of unique visitors).
Takeaway: If plagiarism is your biggest worry, you’re doing it wrong.
Hyperlocal Post-Mortem: Lessons Learned From InJersey. Fantastic pragmatic takeaways from Ted Mann. Highlights: local advertisers don’t like self-serve, build your site cheaply, and make it ridiculously easy for contributors to publish (e.g. don’t have them email posts to editors, and then require the editor to copy/paste, edit, and then publish).
How hyperlocal has a future. Dave Winer’s advice for publishers: “be sure you control your own publishing and distribution.” NYU has a hyperlocal conclave this Saturday with a tools discussion that’s sure to be fun.
Learning how to learn. Scope out a project and just start.