Here is a well known clip where talented producer Timbaland guides rapper Jay-Z through a few beats, before finally revealing the one ultimately destined for huge commercial success:
I find the process fascinating in severals ways.
There’s a seasoned salesmanship to it. It might look like they’re hanging out and having a good time, but it’s no surprise that it’s the final beat that really kills it. Also, you’ll see him give a 2 second blip of the sound and pause…teased yet? Aaaand here we go again, as he lets it go and Jay can’t help but stand up, almost confused by its uniqueness and power. It’s a great reminder that in so many situations in life, there’s what you see happening, and then the various levels of thought and strategy behind them.
Also, if you’re not familiar with hip-hop and you might think that Jay-Z sits in studio and creates the song with Timbaland in a more holistic effort. The reality is often much different. As you see here, it’s the producer who creates a variety of beats and says “choose one” to the artist.
Let’s say I’m struggling with pricing for a product. There are many great A/B testing tools out there, but they’re often a bit generic. I think about it and realize a pricing page focused A/B tool might have just the right amount of focus to be immediately useful, and constrained enough that I could build it in a short amount of time.
A/B test your pricing page: react to potential customers in real time, test various feature grouping strategies, iterate towards perfect pricing configuration. Pass or talk more?
If he passes, fine, nothing more to talk about. If he’s interested, having a dead simple way to agree on some basic terms would allow us to move forward and see if there’s anything of interest therein. This could be simple like handshakedealprotocol.com which I hacked together in one weekend.
A good byproduct of this concept is that more people would be focused on building small, focused solutions that make money rather than swinging for the fences and coming up short. Booking a couple small product wins sounds much more appealing to me at this point in my life than spending a couple years on a 0.0000001% shot at millions.
Create a simple way to agree to some terms (“we split time invested and profits made 50/50”), an easy way to keep track of basic progress as this is an asynchronous and part time effort on both sides, and only collaborate with people you trust.
We’re only beginning to figure out different ways to work with each other via the net, and whether this particular analogy holds or not, I’d love to hear your thoughts.
Thanks to Justin Mares for reading drafts of this and helping to get me writing again.
In some ways it’s rather hilarious (a wheat thresher? really?!). In other ways it’s scary (death/violence threat stuff).
I can’t imagine how they shake it off like that. I can objectively understand how to rationalize it away, but on an emotional level I don’t think I could.
In many ways I don’t give a shit what others think about me—I know I’m a good person, I know who my parents raised, and I have an inner confidence that can take some beating.
At the same time, just thinking about someone assaulting my looks, thoughts, quirks and personality traits as they’ve done above…it really gets to me. In some ways I think it’s a direct reason that I don’t put myself out there more, at least online. Yeah, I have twitter (and I very much appreciate the several hundred of you who read things like this), and I’m pretty active on GitHub and elsewhere…but it’s usually more about code or other things, not so much me baring my soul.
Some of you seem to have this great balance between caring for and being affected by others, while maintaining a healthy skin that can shrug off even the mightiest blows.
But I wonder if that’s just putting on a good face sometimes? Would it just feed the trolls to say “fuck, that hurt”, and that’s why we don’t see more of it?
For those who have that mix of caring enough but not too much, I’d love to hear how you do it.
PS: thanks James for the simple guidance on improving my writing by writing. Realizing that I should care more about the usefulness of the topic and value it might provide rather than the criticisms that might come with it has certainly helped in getting me moving.
I just finished reading the real reason i won’t be your technical co-founder and feel like clearing something up:
If you waste months trying to cobble together some rails app I could build in a weekend, rather than spending that time talking to customers, collecting interviews and data, I won't think much of you and your business sense.
Yes, if you come to me with an idea and some wireframes I will think more of it than just the idea, but it really comes down to whether you realize that there is hard, specific work to be done on both sides of the business, not just by the programmer, and early on it’s much more important to prove your business than hack together some shitty prototype. Plenty of time for that later.
Proof of early traction is more valuable than most anything else, so the next time you’re looking to partner with someone, show them some letters of intent or preorders, not that you can copy paste a wordpress theme.
Whatever you’re striving to accomplish, someone’s already done it much better…and far worse.
Don’t worry so much! You won’t be the first to fail or the last to succeed, and you will care about your result more than anyone else ever could.
You determine how you handle your big success or great failure. No one will feel that pain more acutely, or savor the accomplishment more intensely, than you.
Once you realize this, the whole frame shifts: there’s less judgement, fear, and anxiety from external sources, and a more calm, important realization of what matters from within.
Most disagreements have a bit of all three: some good bits that all parties agree on, some challenging areas that are clearly discordant, and often a remaining bit that is hard to nail down.
The worst arguments often overlook the Good, repeatedly hammer home the Bad, and will waste a majority of the time running circles around the Unclear.
A simple strategy for these situations:
- Identify the Good. “We agree on A, B, and C. That’s a start. That can be built on.”
- Acknowledge the Bad. “We clearly disagree on D and E. Let’s set that down for one moment”.
- Fight like hell to take whatever’s left and put it in these two buckets.
The reason why: you can’t resolve what is Unclear. It will stay outside your grasp and cause more pain than debating the Bad ever does.
Next time a meeting spirals down into a confused debate of vague disagreement, find a common place to build from, clarify the points, and work specifically to excise the Unclear.
Join the discussion at 280.io/jackdempsey/the-good-the-bad-and-the-unclear.
Thanks to @benyaco for reading early drafts.
Banged my head against the wall for a good bit on this one.
This is the trick. Let’s say you have a version like so:
version :manualcropversion do #model does not work here process :manualcrop => [200,200,0,0] end def manualcrop(x,y,h,w) model # works here ... end
I think because it feels like the same ‘scope’ we expect model to work in the first situation. However, that’s just a method with a block passed to it. It knows nothing about our model when it runs when the file is loaded and executed. Later, when the processing happens, we have a model to talk reference.
I’ve long been a fan of Rails engines. Still, they’re not very well documented, and whatever information you can find is often out of date.
It’s not so simple for instance to generate an engine and get it setup for development with Rspec and Capybara. I created Rspec Full Engine and Rspec Mounted Engine to help with this. They provide a pretty blank slate to start from. Still, I found the search and replace and renaming of files a bit annoying, and decided to do it again but better.
So tonight I hacked up Rspec Engine Generator. It’s a Thor based gem that goes through the proper Rails generation of an engine and also runs a series of commands to configure the engine to use Rspec and Capybara. Pretty straight forward to use, just :
$ rspec_engine new engine_name_here
At this point you have a properly configured engine, with an example Capybara request spec showing one way to set things up.
If we all put our collective efforts into some good, base engines, I think we could save ourselves a lot of development time. If you like this stay tuned as I have some other engines in the works.
I find myself using less abstractions these days and being happier with the resulting code.— Jack Dempsey (@jackdempsey) May 24, 2012
That tweet seemed to resonant with a few and sparked a couple questions which I’d like to go into further.
I’ve long been a vocal fan of Plataformatec and use many of their projects. One such project is Inherited Resources. Recently though it had started to frustrate me a bit. Do I use the one arg block form or two, or do I just return a URL to redirect there on success, etc.
Upon looking at the documentation once again, I saw this message:
Since Rails 3 came out, I have no longer used Inherited Resources. I have found that the responders abstraction and custom Rails generators offer the perfect balance between hiding and showing too much logic. That said, I suggest developers to make use of the responders gem...and no longer use Inherited Resources. -- José Valim, project creator
If the creator a project says they no longer use it, it’s often a good idea to revisit if you should as well. I did, and realized I agreed with José.
I’ve since converted some controllers and written new controllers with stock Rails code and good usage of respond_with. I write more controllers straight from memory these days, do less doc searches, and can’t say I miss Inherited Resources much. There’s the occasional time I forget to actually write an action, but that’s a tiny inconvenience.
I used to seek out clever abstractions and extremely concise refactorings. These days I’m happy to see a few more lines of code, if it means not having to context switch to a google search or external library.
This is easy to understand, and easy to forget. Hope this serves as a healthy reminder.
These days developers learn the value of testing early on in their career. Often the debate comes down to what to test, not if.
The same reasons for writing tests apply to business as well: does this method work correctly? Can I document these thoughts concisely and verify my assumptions? Can I put something in place to call me out when I’m wrong? And yet, I’ve seen so many people skip past the “does this idea work” and run straight to the “now this is how we’ll build it”.
I have some ideas on how you could put some basic tech to work on solving this problem, but to eat my own dog food here—does this resonant with you? Have you seen someone try to explicitly bring this into business? I’m familiar with Lean, Alex Osterwalder’s Business Model concepts, but feel they don’t go far enough. It’s still too easy to wave your hands and hope for magic.
If I’m being completely honest, I probably care about what others think too much. In fact that ‘probably’ should be a ‘definitely’. I’m even thinking about how this post will go over as I’m typing it.
Is that really any way to live?
The sad reality is that I’ve been taught to think this way. From a young age we’re taught to worry about what the teacher thinks, what our parents think, especially what our peers think, about us: what we’re doing, what we’re saying, what choices we make.
It’s not easy to shake. There are often many times when you should care what someone else’s opinion of you and your actions might be. But, if the first thought that crosses your mind is what others will think vs what you and maybe even the future you would say, I think you’ve got it backwards.
Apologies for the slightly poor sentence structure and rambling thought, but it’s good enough for me.