187 karma · joined February 26, 2009
Even if we factor in other costs during that period beyond loan servicing, such as insurance, taxes, utility repairs and maintenance it seems unlikely I will have LOST money in the process.
It's not a terribly GOOD investment, but it's not a financially asinine choice either.
There are already Yelp reviews: http://www.yelp.com/biz/dumb-starbucks-los-angeles
It's not about requiring everyone who works for us to be a 23 year old with no family or life who spends every night hacking on shit, just about a baseline standard for community engagement. Lack of Github account with some level of activity (even if that's just starred repos, forks, etc) is a pretty strong indication someone wouldn't meet that level of engagement, and so wouldn't be a good match.
That said, if you're a Rails developer and you don't have a Github account, I'm still probably not going to read your resume.
With agile, sometimes the word is used to justify a rigid excess of ceremony, or as a firewall for lazy developers to hide behind to avoid being responsive to non-engineering members of the organization, or as an unrealistic attempt to turn software development into an assembly line of a bunch of jack-of-all-trades "cross-functional" team members ("specialists? we don't need no stinkin' specialists!"). But the core observation of agile is that writing huge planning documents and spending weeks perfecting PRDs and GANTT charts at the outset of an engineering project and then using these to derive project timelines and costs is inefficient, and that "delivery to QA" 3 months over an arbitrary schedule and 70% over an arbitrary budget is a classic failure mode for this approach to planning. Instead, a focus on building self-organizing, trusted teams who are delivering working software frequently and iteratively, and gathering customer feedback and adjusting "the plan" after each delivered increment of software can result in both happier developers AND happier customers.
Similarly, "lean startup" CAN be synonymous with "changing my mind about what business I'm in and 'pivoting' every 3 weeks", but really the core observation could be summarized as "build things people want", with all these new-fangled buzzword-y tools like customer development interviews, business model canvases and even "pivoting" as a means to this end. While the Ries book is useful, Steve Blank's The Startup Owner's Manual (http://www.amazon.com/The-Startup-Owners-Manual-Step-By-Step...) is phenomenal and the ideas there certainly "transfer very well outside the world of tech start-ups."
Take what works, leave what doesn't, ignore the hype and think critically.
I'm CTO of a web and mobile development shop with about 20 employees. Finding good frontend developers is REALLY hard - to be a great frontend guy these days, working on modern web apps, you need to have strong engineering chops, with knowledge of the html5 apis, css3 and serious JS experience, including an understanding of memory and performance management in large frontend-heavy apps; ideally have worked on a couple of medium size apps with 5-7 person teams; probably have at least some exposure to the current JS framework scene; ideally (for our stack) have experience with preprocessors like sass or stylus and coffeescript; have good design sense and the ability to work in a collaborative feedback loop with a designer, etc etc. It's a really cross-functional role. There's a lot more people who "know HTML and CSS" but have never worked on serious apps, or have solid JS chops but can't produce design with reasonable fidelity to save their lives.
A relationship with a recruiter who understood this "candidate profile" and could bring me people who would be a good fit, not just resumes with "HTML", "CSS", "Javascript" and "5 years of experience" on them, would be worth its weight in gold.
There will always be new problems to solve. There will always be better solutions invented to existing problems. And solving problems experienced by a lot of people, and solving them well, will always be worth a lot of money.
I run a 20-person webapp design and development consultancy, with employees all over the US and no central office. Group communication is a constant problem for us: we use Campfire rooms for most project communication, but frequently have to drop into Skype for ad-hoc video calls. I wind up in Google Chat several times a day with employees and clients as well. Campfire is great for realtime-ish team conversations, but if you want to ask a question like "hey, anyone want to go in on a house for SXSW?" you're probably better off sending an email if you want everyone to see it and have a chance to respond. We keep a lot of company docs in Google Docs, stuff which would really be more useful in the company wiki we don't have setup currently. I could go on, but the gist is that our communication tools for project teams, the company, clients, and 1-on-1 conversations are pretty fragmented.
Theoretically Yammer should solve this problem. It doesn't. We've experimented with it in the past, and it's a poor fit in a thousand tiny ways. We're a bunch of geeks living all over the country designing and building software products, not a division at Big Co.
But, y'know, everything's been invented. ;)
Imagine instead being able to use an app where, in any urban area, you can have a car sitting in front of your house in 3-5 minutes, with reasonable mileage rates, exact GPS coordinates preprogrammed, and no haggling over tip and payment method at the end of the ride.
Speaking as half a couple paying $1000 a month in car payments, car insurance, maintenance and gas, this is going to fundamentally change the calculus for private car ownership in America.
We're a web and mobile consultancy and work mostly with early-stage startups. Primarily US-based but fully distributed team (i.e. we don't care where you live).
Strong Javascript skills (know backbone well? +1 / coffeescript? another big +1) and experience with Rails apps are big bonuses.
Full job ad here: http://www.authenticjobs.com/jobs/13901/front-end-developer
Company site here: http://turing.com/
This is one of the things which annoys me most about a certain strain of SF startup culture: too much worrying that there's a holier of holies you haven't managed to get into yet (Davos, seriously?) and not enough time nose down on change-the-world problems.
I think the far bigger threat to Facebook is in the "it stops being cool" market fragmentation possibility. As long as a huge percentage of people in the world are spending a chunk of their time on Facbook, I wouldn't bet against eventually finding a way to market to them effectively.
Sometimes this spelunking is both constructive and instructive.
Sometimes though, dismissing the assertion that the earth was created 6000 years ago or that the world will be ending next month with a quantitative assessment of the intellectual capacity of the asserter is a completely appropriate shorthand.
The key is judicious application. ;)
2-3 iterations is doable - trying to maintain a backlog of stories 2-3 releases ahead usually results in a big sloppy mess of a backlog.
Unfortunately, I've worked with many clients where thinking about priorities in the future far enough to have 2-3 days worth of stories in place beyond the current iteration is a struggle. This is where things usually go really off the tracks, because you build the thing it's easiest to describe right now to keep everyone working, or run from externally-directed fire to fire, instead of setting a cadence of development which represents the business' true near-term priority mix.