tl;dr In the wake of the recent Simone Biles “scandal”, it’s important for people who are in like situations to stand up and be counted. So, although this is something I’ve never really kept a secret, it’s well past time to ‘fess up and admit: I, too, have been diagnosed with ADD.
tl;dr I spoke at Seattle Code Camp last weekend, and I wanted to make links to the slides available for anyone who was interested in consuming them.
I’ve been reading a few articles that cross my LinkedIn feed, and this one, on Theranos founder Elizabeth Holmes and her presentation today on the future of the company and who-knows-what-else, struck me as a huge wrong to the industry, startups, and just about everything that the business community is supposed to stand for.
tl;dr In a recent blog post, a commenter asked some questions that I felt were a bit more easily answered in the main blog format than in comments. Specifically, he asked two of the more common “How do I…” questions—finding motivation, and finding time.
tl;dr At last night’s Seattle Languages meeting, I was reminded of what intellectually-honest debate does and does not look like; then, as part of the discussions and argument around the tragic deaths of several black men at the hands of police, I was presented with a link to a page entitled “Ten Signs of Intellectual Honesty”. This is good material.
tl;dr Once again I find myself in the position of needing to call BS on a blog post and deconstruct it: Yes, it is possible to be a good .NET developer, and here’s why.
tl;dr Celebrating success is always a welcome thing. But in a lot of ways, the people we should be celebrating are the ones who failed, and then learned from it. As a matter of fact, there’s a reasonable correlation to be drawn here—that those who are truly successful are the ones who failed first.
tl;dr Recently the Harvard Business Review ran an article on how readers could prepare for difficult business situations, using the analogy of coaches preparing their teams for different eventualities by simulating those eventualities on the practice field. There’s lessons to be learned here for both programming and speaking.
tl;dr Peter Verhas asks a seemingly innocent question during a technical interview, and gets an answer that is not wrong, but doesn’t really fit. He then claims that “Sometimes I also meet candidates who not only simply do not know the answer but give the wrong answer. To know something wrong is worse than not knowing. Out of these very few even insists and tries to explain how I should have interpreted their answer. That is already a personality problem and definitely a no-go in an interview.” I claim that Peter is not only wrong, but that in addition to doing his company a complete disservice with this kind of interview, I personally would never want to work for a company that takes this attitude.
tl;dr By now, everybody has heard that the FBI has issued a request (which is now being backed by a court order to comply) to Apple to provide software to unlock the iPhone 5c of one of the San Bernardino shooters. This is a massive request, with huge implications for everybody (Apple, Americans, foreigners, I really mean everybody). And most of those implications, I believe, are bad.
tl;dr A tweet from Scott Hanselman brought me to a page from a Google Developer Expert talking about his experiences talking at conferences. Like Scott, my experience is wildly different from his, and I thought merited a response—and a call to action, if you’re so inclined.
tl;dr I’ve been asked a number of times over the years how, exactly, I approach learning new stuff, whether that be a new programming language, a new platform, whatever. This is obviously a highly personal (meaning specific to the individual offering the answer) subject, so my approach may or may not work for you; regardless, I’d suggest to anyone that they give it a shot and if it works, coolness.
tl;dr My first (!) course is up at Pluralsight: “On Polyglot Programming”.
tl;dr In November of 2013, through a chance conversation with a casual acquaintance, I happened across what would turn out to be a pretty significant shift in my career path. After two years as the CTO of iTrellis, it’s time to move on.
tl;dr A recent post on medium.com addresses the topic of technical debt; I had an intuitive disagreement with the thrust of the post, and wrote this as a way of clarifying my own thoughts on the matter. It raises some interesting questions about what technical debt actually is—and if we can’t define it, how can we possibly understand how to avoid it or remove it, as opposed to our current practice of using it as a “get-out-of-this-codebase-by-blowing-it-all-up” card?
tl;dr Don’t hedge your answers when somebody is asking you for a commitment; “Do, or do not. There is no try.” (Yoda) Saying “maybe” is, at best, your way of preserving your ego, and at worst, your way of trying to avoid a commitment.
It’s really starting to appear like the “technical monoculture” that so pervaded the 90’s and 00’s is finally starting to die the long-deserved ugly death it was supposed to. And I couldn’t be happier.