rodp

Next year, the coach got replaced. The new coach benched me and gave me no feedback. Though he didn’t say it, it was obvious he didn’t believe in me, for whatever reason, justified or not. I started playing worse, which only reinforced his view, and then my minutes went down, which gave me less opportunity to improve, which reinforced his view further, etc. I was still on the same team but I wasn’t the same player. I was but a shadow of the player from last year.

Whether the new coach was right about me or not, I will never know. Was I falling behind because others were improving faster or because I internalised his lack of trust? Maybe I wasn’t as promising as I had thought and he merely saw it or maybe he was unjust. Whatever the reason, he ended my basketball career that year (though it would take a few more years for me to realise it).

As a young basketball player, your window of opportunity to develop is small and, if you miss it, you’re basically done. As a young software engineer, you have more than enough opportunity to find a better team and, more importantly, a better coach.

I will probably just get rid of the features that require write permissions. They aren't essential.

Since ancient times, two philosophers would often have a debate by exchanging letters. The goal was not publicity, though many of such correspondences eventually became public. The goal, as I see it, was simply searching for truth. I wonder if it's possible to build a platform for something similar today. Even if it never becomes as popular as social media, I hope it could at least create a clear distinction between entertainment and actual conversation.

I've registered this Twitter account: https://twitter.com/DebubbleMe. There is nothing on it for now, but if Debubble takes off in any shape or form, that's where I'll be posting the updates.

The app lets users send tweets or DMs and I didn’t find an obvious way to narrow the required permissions down to just that. But a few people have now pointed this issue out and I think I will just remove that functionality and require only read permissions.

Frustrated by filter bubbles and the general state of online debate, especially on Twitter, I made Debubble.

It’s a publishing tool that will let you challenge another Twitter user to a debate. If they accept, the two of you will be able to engage in a public but distraction-free conversation. Debubble will make sure you wait for your turn before you can deliver your arguments. It will also limit each response to 1500 characters (roughly one page) and the entire debate to 12 turns. Instead of cheering for their side like sports fans, registered readers will be able to signal the value they got from your conversation by starring the whole debate.

I haven’t properly tried to launch it yet, as my day job and kids are keeping me very busy at the moment.

That said, I can imagine other languages (like Java or Go) could still end up being more efficient than Node.

If an A-level developer can perform 50x or 100x better than average, I'd guess that an A-level CEO can perform 500x or 1000x better.

Having freelancers who have 0 emotional attachment to your vision build the first version of your product and then replace them with someone else is a really bad idea in my experience. Your #1 employee should be someone who is almost as excited about the product as you. Furthermore, they should ideally have substantial skills and experience and complement you and the rest of the founders well. Most important: they should be a culture fit. Competitive salary and benefits shouldn't be cruical for the first employee. Vision and stock options should. Trying to save money by hiring someone less experienced or indifferent to your vision does not pay in the long run.

Ryan's advice is more about economics, but I feel that, since we're talking about hiring the first person, it should have been about vision and personality.

When Twitter introduced annotations, I thought that was the beginning: soon, we would have Twitter classifieds, Twitter marketplace, Twitter as a data firehose for anything... All I was waiting for is annotations in the Search API. I'm positive that's all that was needed to provide the initial infrastructure for semantics -- the community would take care of the rest. Unfortunatelly, not only has it never happened, but Twitter took an entirely different course.

I can understand them, though. They had to start making money fast and took a less risky road. But I can't help thinking: bugger, this could've been so much more than celebrities and hashtags.

We ended up using Browserify instead. It's a Node.js module that lets you use CommonJS-style require in your client-side code. Browserify scans your code for all requires, figures out in which order the dependencies should be loaded and merges the code. Optionally, it lets you compile CoffeeScript on the fly or use filters, such as UglifyJS (to minify the output). Another great advantage, IMO, is that Browserify can package most Node.js modules for client-side use. Instead of downloading & distributing JS libs, you can manage them as modules via NPM and require them as you would in Node.js apps. Browserify will grab the code from the module and package it for you.

However, if you can't use Node.js on your server, Require.js is definitely the way to go.