Podcast: Play in new window | Download
Subscribe: iTunes | Android | RSS
Justin and Jason talk to Kyle Bragger, founder of the developer and design community Forrst, about what sparked the idea and how he launched it as a side project, how he selected the technology stack and how it’s evolved, how they’ve dealt with scaling and security, his thoughts on coding frameworks and development methodologies, why and how they created a user-linked karma system and his vision for Forrst’s future growth as an angel funded business.
Great episode!
I’m on Forrst since October 2010, and I find it more addictive than Facebook and Twitter. But it’s a healthy addiction 🙂
@Jason, you can protect S3 files with a certain signature in the URL, and it will be valid for certain time.
Also, you had a great insight regarding working on something you like and have fun with.. this is something I try to do as a freelancer, only choose projects I feel excited about [no more lame websites!] and work with the frameworks I like and etc..
@Kyle, it feels like Forrst is your 10th startup or something. You did things really really good. I wish you would write more or give more interviews, it’s always interesting listening to you.
@Justin, you’ve been quiet..
OMG, the last part was HILARIOUS!
I loved this episode. I’m tempted to sign up for Forrst!
Interesting take on the testing. I diagreed with the post on HackerNews after all if you dont know what you are creating why are you writing code to begin with?
I agree with what Kyle said though. I figure for any complex method I will generally write enough tests that makes the tests 3x the size of the code in question.
Sure it takes time, but it also allows me to refactor, look for performance gains etc… Plus when I do find a bug later I add a test for that and can be certain I wont repeat the bug. The biggest advantage is that I end up with code thats easier to understand because its testable to begin with. I think this is one of the overlooked features of tests. Proper unit tests force you to write decent code by nature.
For anything trivial though I throw specific intgration tests over it. EG say I write a get X from database and return as JSON, I will actually call the API and verify that it works as expected. Easier to write, and verifies the database connection and everything else.
@Ben Boyter – I very much admire your coding self-discipline. I’m curious – does this self-discipline carry over to other parts of your life for things like diet, exercise, sleep schedule, paying taxes, returning emails, etc?
@Jason Somewhat. For all of the above yes. I have always been pretty disciplined in the things I want to or have to. Possibly a result of being highly independent due to having lived for a long time in a town consisting of 4 people all of which were my family.
The reason I have become so controlled in code is that in my day job I maintain rather large custom enterprise applications. The ones which I was able to exert influence over and really provide proper testing from the beginning are easy to maintain. The ones where I was unable to do so can literally be a nightmare. Think typical enterprise application with multiple levels of abstraction in code, thousands of views and stored procs etc….
Its quite a change for me because I was a cowboy coder for a long time. I feel there is a place for both, but for me the middle ground delivers results and makes your life a lot easier a year later when it comes to maintenance. Less bubblegum fixes and the like make my life easier and lazier.
@BAMS – Which part in particular did you find funny?
@Jason the “WAIT WAIT WAIT! One more question!”