At a certain point, Chris drops the pretense that this is an actual investor meeting and just starts coaching me on my pitch, feeding me questions, and then correcting my answers.
“Give me a second and I'm gonna give you your pitch back.”
And then, right there, not far from the freeway overpass near Pico and Bundy, he steps into the role of me, starts giving the pitch I should be giving.
...Alex Blumberg: That was amazing!
Chris Sacca: That's your story, right?
Alex Blumberg: That is great. Holy [BLEEP]. I thought I was a storyteller. Now I feel bad about my job.
I'm thinking, oh, if he pitched my idea that well, he must be into it, right? He's going to invest. But then he goes on.
At this point, I have no idea what to think. I'm drained, my pits are drenched, and Chris Sacca has just given me two completely convincing cases in favor of and against investing in my business. Whatever shred of conviction I had about this process at the beginning is gone.
- pushing on them to get as much understanding as to what needs to be done to communicate it to the customer (it can be a strength that you don't know too much about what they do. once you understand it, the customer can too).
- not pushing into the unknown and forcing answers where they don't exist yet (e.g. no numbers in estimates, identifying amount of perceived risk in addition to perceived effort).
- working out contingencies with them.
railscommand to the
bindirectory of the application, but this collides with any existing
railscommand put there by the
--binstubsflag, and the two are not compatible.
--binstubsflag, but to call
bundle binstubs [gemname]individually on gems you want in your local bin folder. For some background on these changes, check out these commit comment threads: rails bundler.
--binstubswas in effect, but that change was reverted for semantic versioning. My understanding is this change will be re-attempted in Bundler 2.x.
When geniuses like Neil Simon and Mike Nichols can't put their fingers on a problem, what hope is there for the rest of us?
So when you get stuck just know, there is no Dr. House for writing. At times we’re all Frank Burns.
They create too many possible exit points for a function. To write correct code, you really have to think about every possible code path through your function. Every time you call a function that can raise an exception and don't catch it on the spot, you create opportunities for surprise bugs caused by functions that terminated abruptly, leaving data in an inconsistent state, or other code paths that you didn't think about.
A better alternative is to have your functions return error values when things go wrong, and to deal with these explicitly, no matter how verbose it might be.
It is funny how people think that the important thing about exceptions is handling them. In a well-written application there's a ratio of ten to one, in my opinion, of try finally to try catch. In the finally, you protect yourself against the exceptions, but you don't actually handle them. ... because in a lot of cases, people don't care. They're not going to handle any of these exceptions. There's a bottom level exception handler around their message loop. That handler is just going to bring up a dialog that says what went wrong and continue. The programmers protect their code by writing try finally's everywhere, so they'll back out correctly if an exception occurs, but they're not actually interested in handling the exceptions. (quotes re-arranged for my emphasis)
The title of the [prior] article was a reference to a specific code snippet that I copied from a book, where the book's author claimed that the code he presented was “cleaner and more elegant”. I was pointing out that the code fragment was not only cleaner and more elegant, it was also wrong.
You can write correct exception-based programming.
Mind you, it's hard.
It's easy to write bad code, regardless of the error model.
It's hard to write good error-code-based code since you have to check every error code and think about what you should do when an error occurs.
It's really hard to write good exception-based code since you have to check every single line of code (indeed, every sub-expression) and think about what exceptions it might raise and how your code will react to it. (In C++ it's not quite so bad because C++ exceptions are raised only at specific points during execution. In C#, exceptions can be raised at any time.)
Metrics have a purpose and a place in organizations and teams. They cannot be used as a substitute for thinking. Nor can organizations think management by numbers is enough for effective software delivery. Organizations must be vigilant against the undesirable behaviors that emerge due to the inappropriate use of metrics.
Use the following guidelines to lead you to a more appropriate use of metrics:
1. Explicitly link metrics to goals
2. Favor tracking trends over absolute numbers
3. Use shorter tracking periods
4. Change metrics when they stop driving change