On the topic of talent
Jorge Quinteros, writing on the Topic of Talent.
Talent is the natural ability to do something for which people may think there’s not much effort put into accomplishing something and that’s simply a result of people not always being previewed to what you go through to do what you do.
I’m a very good software designer. Proof? I have a long track record of excellent software. Those who know me and my work invariably describe me as talented. Therefore, ipso facto, I must be a good software designer because I am talented. Rubbish! Bunkum and tummyrot!
Speculative work hurts
Sebastiaan de With, a really great designer, posts on Facebook of all places on how speculative work hurts the design industry at large.
Happens in software too, where clients expect you to plan, document and design the software before entering into a contract.
Machine-driven
Via Buzz Andersen,
Google products are machine-driven. They’re created by machines. And that is what makes us powerful. That’s what makes our products great. Marissa Mayer, In the Plex
Explains why their design comes up short.
Design is Horseshit
@yongfook, writing in Design is Horseshit!, makes a good point:
Focus on value creation. Design enhances value, it does not create it. Stop creating shitty startups that look amazing.
He’s not saying that you should dump design and designers (phew!), just that he is sick of over-designed new startups that provide no real value.
Money quote:
Think hard about what problem you can solve that a customer will give you $10 for and work your ass off at delivering that $10 of value as fast and as cheaply as possible.
Seek the Criticism
Brendan Baker nails it in Fuck the Accolades. Seek the Criticism on Quora. Just read it. It’s short.
Two productive things can come out of a meeting with a VC:
They help you directly. Money or connections.
They make you better. They criticize you where it counts. They poke holes. They make you defend. They make you justify. They make you question.
Seek the criticism, because accolades don’t help you.
Don't give up on your techs
My good friend, Brad Lindenberg, writing in The diminishing value of technical founders in startups talks about the value of the super technical people needed to perform the heavy lifting at the beginning of a startup.
This value of technical people in startups diminishes quicker than you think and entrepreneurs need to be careful not to give away equity to developers who are super valuable in the short term, but end up twiddling their thumbs in the long term.
The usage lifecycle
Joshua Porter writes about the Usage Lifecycle in Designing for the Social Web: The Usage Lifecycle, well worth reading.
The stages in the Usage Lifecycle of a product are:
• Unaware This isn’t so much a stage as it is a starting point. Most people are in this stage: completely unaware of your product.
• Interested These people are interested in your product, but are not yet users. They have lots of questions about how it works and what value it provides.
The lost art of the print statement
Debugging software is hard, especially if you were not the original author. All programming languages come with debugging tools, from the arcane GDB to the dead sexy step-through debuggers in Xcode and Visual Studio. But, having watched some newbies recently attempt to debug some code using these tools, I noticed something. With all the data in the world on their screens, breakpoints, stacks, watches and code hovers, the information they needed to solve the bug was being lost is the mix.
Write code for someone else
Whether you are just hacking up a script, writing the next must-have app, or working for the man, always be writing code as if someone else has to read it and understand it. Usually, that someone else is you, six months into the future, older, wiser, with a different mindset. And you’d hate to piss yourself off then, right?
This hiltmonism is a big one. Its easy to think you can fix something later, even though you know this mysterious later never comes. Its easy to think that you can just get this code out because once its done, its done, even though you know its never done. Its easy to hack to a deadline, and hope you are not the bunny who has to fix it when it fails, even though you are stroking your bunny ears at the time.
Kindle Fire lets kids charge up a storm
Reuters, today, in Amazon’s Kindle Fire lets kids charge up a storm writes:
…it comes with your Amazon account information preloaded, along with “1-Click” ordering. That means anyone who is holding that device can place an order, whether it’s their account or not.
My question is whether this behavior is by design or by accident. In Almost No-one Changes Their Settings I referred an example from Microsoft where the settings were the result of what the developer left them as, not what was best for the user.