Are there any tell tale signs that help you notice these types of bugs faster? I am learning Ruby on Rails but I assume there is some type of continuity with how this rears its head between languages.
I will definitely experiment with the tips posted above - I am learning Github which could be useful for this I think, but do you recommend any simple tools for showing someone who is remote your code? The issue with copy/pasting is figuring out which code is relevant to show someone.
If you use git, that can definitely help you. The trick is in making small, targeted changes that do one logical 'thing', and then committing that. Don't be afraid to make tiny commits -- often I'll make a series of 1-liners if they aren't strictly related. Commits are very cheap in git, so don't worry about making "too many".
Then when you run into a problem, you can easily use "git bisect" to figure out which commit caused the problem, and if you've kept to small commits, you should hopefully be able to figure out the offending line(s) of code pretty quickly.
But beyond this, I think the early sign is your gut says, "it should be so simple but I can't figure out what's wrong". Listen to your instinct -- it's probably right! Don't spend another 2 hours poking at it. That's a good time to either step away for a bit or ask someone else to look over your shoulder for a bit while you try to explain to them what's going on.
To echo one of the comments on the linked post --- it is because of bugs like this that I am a firm advocate of languages with strong static checks.
A few claims:
* no matter how good a programmer you are, you will make stupid mistakes (such as typos, as in the case of this article) every now and then.
* it is statistically inevitable that you will make many such errors in a large code base.
* bugs are easier and cheaper to fix the earlier you catch them; the best time to catch a bug is before the code is paged out of a programmer's brain.
* it doesn't take too many experiences of discovering a typo bug in your "production" code base before you realize there must be a better way.
My personal approach is the following:
* restrict the use of untyped scripting languages to pieces of code that can fit in one screen or so; that is, just small enough that you can keep all of the moving pieces in your head at once.
* as much as possible, use languages and tools that provide strong static checks for larger projects. This includes language type systems (e.g., Scala, OCaml, Haskell, etc.) and tools that help you check your code (Prefix/Prefast, Coverity, Findbugs, etc.)
* testing is good, but static checks are far better.
Unfortunately these opinions don't match common practice in the web programming world.
For me a big tell is if it should work and you have no clue why it doesn't or why it really behaves strangely/unexpected.
For showing code to others in general i really like pastebins. http://paste.pocoo.org/ supports "multiple files" which means you can upload multiple distributed snippets at once. http://jsfiddle.net/ is really great for javascript/html and helps others to change/modify the stuff.
I often try to simplify the example (if the persons i am showing it to are not working in the same team as i am) to make it clear what the problem is and make the problem more accessible. This simplification often helps me to understand and solve the problem.
The best way to prevent these kind of bugs is to change your programming style. Always inserting { } for if-statements, even for one liners, is a programming style, and helps eliminate this specific bug. You will pick up these things as you write programs, or by looking at other peoples code.
Someone suggested the same thing over on my blog - it definitely makes sense, I just didn't think to apply it to programming. When I proofread papers it always helps to have someone around to read outloud to - things that seemed great in my head end up sounding completely different. I can see this applying to code as well.
I read this article and was really impressed. With all of the negativity surrounding their funding and first product, its great to see the team rebound with something fresh. The concept of a "Visit" and being able to stream video to your friends (and friends of friends) in an easy way is great. Facebook integration is a good move.
The discovery of these incubator models is one of the most interesting things happening in the startup community - in addition to giving aspiring entrepreneurs an opportunity to build great things, they are creating an even more tightly knit startup community. They are making it easier for new people to get involved in this network/community, who in turn give back because they have such a great experience.
I'd say go for it if a.) the core functionality is intact and b.) you set the customer's expectations. I am in a similar situation at my company and we have begun letting customers use our product. My basic feeling is that the more people you can get using the product the better - they will provide you with feedback and help you test how things scale early on. If the only problem is small UI things, it shouldn't matter so long as you manage is expectations correctly.
I agree. If this guy is a customer instead of (friends, family, etc) for private beta, he's going to represent part of the people paying you for this.
Congratulations. You're basically getting early feedback by someone who really really wants this. He wants a beta to use in production, and he knows that. That's how much he wants it.
Lay down the ground rules as far as production support and bug fix turnarounds based on what you can manage without trying to spend every waking minute keeping them happy. They may not get every new feature request they ask for, and , like you said, some UI might change.
This letter isn't in line with Netflix's strategy. They want the Netflix brand to be completely unassociated with by-mail DVDs. Sure Qwikster is a stupid name, but in a years time we will think of it as it's own entity/brand. Netflix classic would not accomplish this.
Making incremental increases makes sense. I can see that helping with the issue of getting overwhelmed by details and frustration from getting ahead of yourself.
I will definitely experiment with the tips posted above - I am learning Github which could be useful for this I think, but do you recommend any simple tools for showing someone who is remote your code? The issue with copy/pasting is figuring out which code is relevant to show someone.
Thanks for your insightful comment.