It's full of great advice...but I think one of the key take aways is to "find a market" before you really "have an idea"...and he walks you through some really good ways to do that (using real world case studies of people that are doing it)
121 karma · joined July 15, 2010
It's full of great advice...but I think one of the key take aways is to "find a market" before you really "have an idea"...and he walks you through some really good ways to do that (using real world case studies of people that are doing it)
Amazing how well that old-school growth hack still works...
1. Amazon is still pushing out it's own ideas and features for it...they haven't fully released it to the wild west of developers (many have learned to wait until the dust settles before wasting time/energy on potential features that will be blocked or taken over by the powers-that-be).
2. The speaker bit is cool, but really it's just Siri in a speaker instead of a phone (very cool but not a "wow" out of the box)...it's the next gen. that I think everyone is really excited about and waiting for (when the SDK, and api access, is baked into more than just one stand alone speaker - that is, if/when it becomes the voice interaction for the internet of things; that becomes super exciting and interesting)
3. Not an adoption limitation, but I can say that having worked with the v1 of the tools for building on this stuff...it's still pretty clunky and painful. I think they (AWS) are adopting and upgrading that quickly...but there are some hurdles there as well before "anyone can build a voice powered/interactive thing" can become a reality (and that's the HUGE sensation IMHO)...
He's the most hacker-like angel investor I follow/read (and no he has never backed any of my projects...yet) ;-)
Keep in mind that you left for a reason...and the only thing you can really change is you...have you changed so much that you are missing it? That you can't move on without it?
My advice, as long as you have other reasonable options, take one of those paths instead...
Burnout is generally a result of getting stuck doing lots of stuff you don't want to the majority of your time...and generally very little of what you do want to be doing...
So in my experience you only get over burnout by focusing and rediscovering what you were truly passionate about in the first place (or at the very least what you are insanely passionate about now).
Then, once you can figure out what excites you, start getting small wins in that direction however you can...and before you know it, you'll be full of energy and near impossible to stop again.
That being said - all the serious math/data people I know love both R and Python...R for the heavy math, Python for the simplicity, glue, and organization.
My point was just that when people do pay, in their mind I think they are paying for the podcast itself...and don't really care all that much about the middle men (same basic thing with music really -- there are, of course, exceptions)
Who cares if other devs. or companies don't like his business model? Does that affect his users or potential customers in any real way? I don't think so.
Also - the patron model is super interesting and I'm excited to see people continue to play with and test it...but I'm not sold that it's a sustainable solution either.
The question to me is: Do people care enough to pay for podcasts? And for those that do, in their mind are they actually paying for the content or the experience/environment? What pain is this specific app itself actually fixing or removing compared to my alternatives?
Marco has proven he's amazing at building experiences and environments people love...and I think he can continue to do very well down that path...but without owning/controlling/providing the content or the 'talent' on the client side he'll never break out of being just one of the middle-men in that part of the ecosystem (and thereby evaluated and paid by users as such).
No college is going to give you a magic bullet of knowledge that ensures happiness or success...but every one will give you an opportunity at unique experiences and resources (and if you go the school route - take as much advantage of those as you can).
It shouldn't be about earning a grade or messing up and losing a grade...it should be about your dreams, hopes, and ambition...about what you want to get out of life and how you develop those tools, qualities, and skills to get it.
If you've figured out code and tech is your passion and you've figure out how you personally best grok it...then you're already years ahead of most university students ;-)
If it's about opening up to the larger world so that more things can be built and accomplished, you want to make it as easy as possible to use and understand across the board.
You can be as strict and stern about RFC specks and rules as you want when building your thing...however, the more rigid you are, they more you'll need to be operating from a position of power from the start or the more you'll struggle to get real adoption (and to be realistic, most of us are not really releasing things from a position of power)
Having the verbs in the URI is not DRY (so that kind of sucks) but really it's not very damaging either...and so I believe the upside of (human readable) clarity outweighs the downside of a tiny bit of redundant expression.
In the end, unfort. because so many don't follow RFC 2616, devs are forced to read/pay attention to the documentation for a given service anyway (at least that's always been my experience)...so in a perfect world, I would agree verbs are the methods (and not needed in the URI)...but we are a ways off from a perfect world still...
I prefer (and use) git myself, but it took awhile (and much of my developer/friend network to go first) for me to commit to the switch from subversion...my main issue was that subversion worked well enough for what I needed/wanted at the time. I didn't really switch until it became harder to work with others because of my subversion use and easier to work with others if/when I adopted git.