Guess. Apologize. Compensate. This is a nice slide from a talk by Jonas Bonér, CTO of Lightbend.
Three golden rules for giving code reviews, from this article on sofiacole.com: 1) Ask questions rather than give statements, 2) Limit personal preference, and 3) Check its purpose.
Regarding the second rule, I don’t know anything about it, as I’ve never been on a team that allowed “personal preference.” Each team (or company) agreed on coding standards, and used them.
These are a few notes on Apple’s Swift open source development project, taken from this mailing list post by Apple’s Chris Lattner:
- Open source is pretty great. It has been incredible to see such a vibrant community working so well together, and to see you come together practically overnight.
- Open source also brings challenges. I think it is fair to say that “open design” is slower and less predictable than “closed design”. However, the end result is significantly better, and therefore the tradeoff is worth it.
- Software scheduling (particularly with open source) continues to be difficult-to-impossible to predict.
- It is *good* to have high goals, but we need to do a better job of communicating that “goals” are not “promises” so that people don’t feel misled.
“You can use an eraser on the drafting table or a sledgehammer on the construction site.”
~ Frank Lloyd Wright
The last few weeks I've been looking at ways of estimating software development projects using "Use Cases". I'm all over Use Cases -- I think they represent a good way to document the flow of an app, but a significant problem with them is that your use case is not the same as my use case, even for the same subset of an application. This leads into many problems estimating how much it's going to cost to develop a software app.