Early Startup Time Wasters - <AUTHOR> http://talkfast.org/2012/05/05/early-startup-time-wasters <comment><USER2> I've had the opposite experience with working at home vs working in a shared space. I was much, much more productive working at home (having a 'home office', aka a room with a desk and no tv was key) but I am far happier working out of a shared space where I have other humans to bond with (and whom I have become close friends with). On balance, moving into a shared space has been a great decision but I do sometimes miss the ruthless productivity that came from having absolutely zero distractions.

<comment><USER3> I came on here to say basically this. Some days, especially when I've had too much of the same atmosphere, I find that going home and working from there via remote desktop can increase my productivity, if it's maintained for a day or two. Then, when I return to my normal office, I'm similarly productive -- and both of these are more productive than the day before that I didn't work from home.

The "work from home" is definitely a "your mileage may vary"

<comment><USER4> Above all else, a commute to the office will suck all the creative juices straight from your cranium. Spending 30+ minutes schlepping through traffic each way makes the whole day a waste.

<comment><USER5> Don't drive yourself then? You chose where you live, if daily commute factored so low, well, that was your choice. I walk or get the bus depending on mood/weather. Great way to start the day.

<comment><USER6> This comment is smug rather than constructive or helpful. It might be useful the next time the poster decides to move, but it's certainly not useful right now.

<comment><USER7> I think that in a way, your comment actually proves the parent's point. As you said, "the next time the poster decides to move".

The operative part there is that it is the poster's decision. I think most of us who have the resources to begin a startup or afford renting a coworking space also have the ability to be somewhat mobile within our local geographic area. Americans in particular are known for moving quite often.

To conclude, I think that considering a walkable or bikeable commute or the availability of public transit is great advice for anyone who is planning on moving within the next five years — which is nearly 75% of the US population.

</comment></comment></comment></comment></comment></comment><comment><USER8> Of course, everyone's mileage varies. There are many items on that list that should be universal, though:

Invite-only access (pisses me off as an interested user all the time), go- nowhere "partnership" promises from other companies (I too wasted _a lot_ of time on these dubious proposals during my startup time) and, the closely related point: "quick" meetings with people who do nothing but serve their own [and often times underwhelming] agenda.

Working from home on the other hand is probably a personal thing - some people think it's great, for others it doesn't seem to work out at all. Personally, I prefer a mixture. At home I _do_ get a lot of things done that require concentration.

</comment><comment><USER9> This.

Startups are an acute instance of "too much to do, too little time". Good task prioritization might be the SINGLE MOST IMPORTANT skill that a startup founder needs to develop.

Not all failures are time wasters though -- some of the items in that list seem reasonable enough (techcrunch amazon affiliate links).

DHH said something like "If you're not working on your single best idea, you're doing it wrong". He was talking about startups, but I think that could be applied to your to do list as well.

<comment><USER10> TechCrunch is a really neat cap-feather, but it mostly just pulls in a lot of non-real-user inbound interest in my experience (VCs, potential partners) - and if you're not close to ready or even interested in funding/partnerships, all that inbound interest wastes a lot of time, too - so you might as well get closer to a point where you're ready and willing to handle the inbound queries (i.e., capture your users, make them happy first), and then get the coverage.

<comment><USER11> "Lookie-loos," "window shoppers," etc.

</comment></comment></comment><comment><USER12> I have to agree with the first point of the article regarding 'Invite Only' - this has been one of the biggest headaches in all of the projects I've been involved in. It seems there is little to gain in preventing people to sign up with your app. It doesn't seem to increase interest for users and, in all reality, denying access when the visitor is ready to sign up is just not smart. Numbers count; 10,000 potential users doesn't seem to be as strong a number as 1,000 actual users.

<comment><USER11> It started with the original GMail invites and became somewhat of a mythical buzz-producing technique that really only worked for a limited number of sites. Turntable.fm is the last one that I remember learning about in a way that seemed to generate more interest.

</comment></comment><comment><USER13> I tend to be much more productive on days when I work from home, but after a 1.5 year stretch with an out of state company I found it harder to stay focused at home.

I've found lately that occasionally varying my work location – maybe 3 days in the office, 2 at home or at a quiet cafe – is refreshing and helps me avoid the slump.

</comment><comment><USER14> I enjoyed this post quite a lot. I'd like to see a companion post on specifically engineering time-wasters - e.g. did you find that evaluating new technologies to solve problems to be an unnecessary risk, or a pleasant surprise that ended up saving time and effort in the long run? What about the tension between "one size fits all" tools and tools that are so specialized that you need a tool to select the right tool?

<comment><USER15> Developing general solutions to specific problems is an engineering timewaster, in my experience.

Using complicated tools and tooling where simpler tooling would cover your actual needs with less effort.

Developing a solution that attempts to meet all needs with a lot of effort, instead of developing a product that meets the needs that can be effectively addressed.

I'm guilty of the last one, so what I do is develop two solutions:

1\. a solution that actually "solves" the problem with engineering (the "right" way to do it), and

2\. a second approach that is an order of magnitude (sometimes a few orders) easier to implement that _partially_ solves the problem, but requires a bit of management to stay "solved" over time.

Engineers seem to prefer engineering solutions (go figure), but especially in business, a combination of engineering and management is usually the most cost-effective approach.

</comment></comment><comment><USER16> There's 2 big ones:

1\. Writing code. 2\. Not committing.

You should never write a single line of code until you have a customer lined up. Not in theory, in reality. Not a friend that says it's a great idea, and they'd use your software. A list of verifiable people that you don't know that want to pay you money. Someone that can write a check at BigCo. Someone that is beta testing your product live.

On commitment, cue the joke about pig & chicken opening a ham & eggs restaurant: The pig says no thanks, he'd be committed, the chicken would merely be involved. This kind of ties in with #1... If you don't have an actual paying customer lined up, it's really easy to get involved in "side" activities... I'll just bust out this contract real quick... Sounds like a cool company, I'll go interview (especially bad when it involves samples).

<comment><USER17> That sounds good on paper but in reality writing code for new product is based on faith. You don't know what will work and figuring that is both the most risky part of writing software as well as most lucrative (when solved).

And the only way to find out if something will sell is to build and try to sell. The method you advocate (get sales before you have a product) just doesn't work.

"A list of verifiable people that you don't know that want to pay you money"

How do you propose to "verify", or even find, people that you don't know?

"Someone that can write a check at BigCo."

Would _you_ write a check for something that doesn't yet exist? How do you know, from just a description of the product, whether it's going to be moral equivalent of Vista (a massive flop by Windows standards) or 7 (a massive success)?

You don't, which is why no one pays for ideas or description of future products.

"Someone that is beta testing your product live."

That does require that code has already been written, doesn't it?

<comment><USER16> You don't have to actually have a product before you sell it, or build something to see if it will sell... It's called vaporware : a computer-related product that has been widely advertised but has not and may never become available

<comment><USER16> Don't hate peeps.

It's called "Minimum Viable Product" now, but 15 years ago we called it vaporware.

<http://en.wikipedia.org/wiki/Minimum_viable_product>

 _The canonical MVP strategy for a web application is to create a mock website for the product and purchase online advertising to direct traffic to the site. The mock website may consist of a marketing landing page with a link for more information or purchase. The link is not connected to a purchasing system, instead clicks are recorded and measure customer interest._

That is how you get sales before you have a product... Or at least know that you'll get sales.

</comment></comment></comment></comment><comment><USER18> It maybe worked for him but I found it hard that it can be applied to every startups

1\. Invite-Only Access. Depending the service your startup offer ( Storage & bandwidth heavy ), you will have to offer to do invite only because you can't just spend all the money you don't have on this. Invites will allow you to control the cost of it all.

2\. & 3\. Real-time traffic measurement & User admin dashboard Those are the only one I agree :)

4\. Experimenting with ads too early. Using ads early can be a really asset. For example, It can allow you to A/B test some new messages or value proposition. It can also help you see if you product can appeal to a certain niche by hyper targeting your ads ( Does 20-25 old people living in New jersey and who likes Soccer and BBQ will be interested in my product? )

5\. Amazon Affiliate links I think its great he took the time to try it out. The goal is not to make loads of $$ with "a few thousands uniques/day" It's to see the conversion rate. It didn't work out in his case so that "business model idea" he can write off of his list.

6\. Techcrunch TC offer you so much more than traffic & SEO. It will be let the world you exist to important people ( angels, VC, etc )

7\. One-off partnership projects. His experience isn't a good one. Probably didn't negotiate hard enough with his partner. BizDev / Partnership can bring tremendous traction to your startup if done right. Just don't get screwed up by the other guy and don't waste time "building a prototype" for him without a signed contract.

8\. coffee Meetings Sure the productivity can take a hit if you do it "too much". But think about the social aspect of it. Wether it with coworker or external people to network. it will help build a strong relationship.

9.Excessive side projects As a manager you have the duty to keep everyone happy and productive. The coders will always have side project. Better to have them work on a side project for your company and under your supervision than to pissed them off and make them work on the side project during the Weekend.

10\. Working from home Working in an open space can be a pain in the ass for some people. Because people will interrupt them all the time because of a bugs / ideas / whatever. If they are to introvert to say no, their productivity will go down the drain. So better for them to work some times from home to be truly focus on their work.

Cheers,

</comment><comment><USER19> I do have to say that he's talking about learning the ropes of your business, not 'time-wasters'.

An example for me would be that we have one area of business where we organize events. In order to attract attendees, we tried Google Ads, Facebook ads, email blasts, flyers in popular locations/stores, newsletter ads. None of it worked, or it barely worked. By year two we figured out that for our market, postal mailers worked like crazy. Sending a letter to the prospects home gave us super ROI.

Do I wish I'd known that at the beginning? Yes. But it took going through all of those other methods to hit on the one that worked, which gave our company domain knowledge.

This is really just a version of the business axiom 'Fail faster.'

</comment><comment><USER10> Great advice. I know better now, but I often wonder how much time we would have saved our first few years if I auto-deleted anything that included the text "jump on a call."

</comment><comment><USER4> This is really interesting. I'm planning my own limited invite-only beta rollout. However, this isn't the first time I heard it's a time-waster.

Does anyone else have opinions on this?

<comment><USER5> Do you really think you're going to be overwhelmed with sign ups?

Simple beta: Add 'we're in beta' to your sign up page.

Done.

Invite-only: don't link the signup page to the rest of the site. Add it to the ignore in robots.

Done.

Anyone who finds it, well they just wanted it enough. Too many sign ups? Take the page away. Get rid of the template page, whatever. It takes about 10 secs to kill a page in most languages without a redeploy.

Writing lots of extra code?

Sucker.

Don't over-engineer.

<comment><USER4> The only thing is that this is not a free service, so I want just a couple users to flesh things out and get some new opinions, before releasing something that flops and gets a bad rap.

<comment><USER20> Make a signup page to be part of the beta, include the disclaimer that it's free during the beta but once the service is publicly available it will be charged for and the fees are waived during the beta in exchange for bug reports, possible issues/downtime, etc. Then, whenever someone signs up, just automatically send them an invite. You don't limit the people who want to use it in the beta and can provide valuable feedback and you set expectations appropriately for leaving free status and to the state of the application. And if you think that you may get a bad rap for being in "beta" and it not being as good as Google's beta, just call it "alpha" instead.

</comment></comment></comment></comment><comment><USER21> Great list. I really like that idea of shot selection. 1000 options of what you can do...which one will yield the best results? What a tough question.

</comment><comment><USER22> Love this post, I definitely focus on TC too much. Love seeing how to maximize press outlets.

</comment><comment><USER23> 6\. TechCrunch

Yes.

</comment><comment><USER24> Thats a great list to avoid... but why not partnerships? Specially when working on a B2B platform, I believe its important to build relationships from the get go.</comment>


Ask HN: What programming language should I learn next? - <AUTHOR> Recently I've been itching to learn a new language.
I work mostly in Python currently. I've also worked extensively with Javascript (browser/nodejs). I've worked with C# and Java and Dart. Dabbled in C and C++. Played with Lua.
What should I learn next? My goal is to expand my skillset and maybe find the holy grail of programming languages (probably not). I'm a generalist and a freelancer.
My shortlist:
- Go - Rust - Elixir - Swift - Kotlin
Or maybe something I haven't listed? <comment><USER2> I recommend Clojure. It will, along with other lisps and functional languages, completely change the way you think about coding. It has a vibrant community, the author is very active and gives great talks, it's interoperable with Java, it's a lisp, and it's functional. You can also hit swap production code with ease.

It's a fun language to learn as it has a repl to interactively develop with and it has a fun online, free book to begin with called Clojure for the Brave and True.

The single biggest reason I recommend it, is purely because Code is Data. In other words, you can write code to write code very easily and it's a super meta concept that is very accessible to beginners.

<comment><USER3> i second this.

mainly because that pg god guy says it's good or something.

but i also happen to believe it.

even osama bin laden was right about some things.

</comment></comment><comment><USER4> I'm not going to recommend a programming language. What I am going to suggest is that you try working through the book "Structure and Interpretation of Computer Programs" (also referred to as SICP). The original, which is the one I am trying to get through, uses Scheme as the programming language for the examples. More recently, some courses working through the book use Python for the examples.

I am not suggesting that you learn Scheme. Scheme is an esoteric language, well down the list of commonly used programming languages.

What I am suggesting is that working through the book (using Scheme or Python) will give you a deep dive into many of the fundamentals of computer science. If you get all the way through the book (many more start it than finish it) you will have a powerful conceptual toolkit that will help you, no matter what programming language you're using.

</comment><comment><USER5> Can I suggest you find languages that solve problems you are facing?

Go is great if you do a lot of scripting or web dev. But wouldn't be so good if you're making chatbots.

A chatbot or real-time message passing would be great to use Elixir for.

Rust is great for WebAssembly or desktop programming as a replacement for C/C++.

Swift and Kotlin are the obvious choices for mobile development. Are your customers asking for mobile apps? Do you want to build mobile apps? These would be obvious choices.

Chase the problem you're trying to solve and use the right tool for the right job rather than trying to learn a language just for the sake of learning it. I find trying to learn a language I won't use to be something that quickly drops off my radar.

<comment><USER6> I also considered the 'Blub paradox' that Paul Graham talks about. I asked where the different programming languages fit on the "power continuum" \- that is, its features, what's present and what's "missing", and how I should weigh each when thinking about that next language to learn.

Along with power, I like the view on utility.

As you write, thinking about your immediate problem and future problems (i.e., if you could anticipate) to solve, are also good points to consider when deciding about that next language to study.

<comment><USER7> Plus going for something that you feel solves a problem, or at least scratches a personal itch, makes it _so_ much easier to actually go and learn/tinker/build.

Without that motivation, a lot of us struggle with going beyond various ineffective learning strategies (reading the docs, doing a hello world, getting sucked into the particular language's bike sheds).

</comment></comment></comment><comment><USER8> I would reccomend trying a ML language like SML, OCaml or F#, I have recently written some f# again after break and it is nice to come back to a simple language that is fun to write in.

<comment><USER9> I'm somewhat in the same position as OP, except that I know I want to explore FP. I've more or less settled on Ocaml, although I might be sqwyed by F#'s integration with the .net ecosystem (will have to look at some F# code to see if it makes me want to dive in as much as Ocaml)

<comment><USER8> F# and ocaml are very similar, adn if you learn one of them you pretty much learn both, there are some problems with ocaml, for example it has two std libararies, the normal one and core by Jane Streeet. It also has to competing async libraraies. But the main code is pretty similar there are of course some things that are in ocaml that is not in F# (for example functors) but there are also things the other way.

</comment></comment></comment><comment><USER10> I recently decided to learn Elixir because I had heard good things about it from happy Elixir developers. It was the first functional language I learned and I found its concurrency model to be particularly interesting.

I don't think it's a language that will solve everything, but it certainly seems to excel in its specialty, which is concurrency and robustness. I'm looking forward to learning Phoenix, which will allow me to develop web applications in Elixir.

If anyone is interested in Elixir, I've been regularly writing about Elixir as I've been learning it at [https://inquisitivedeveloper.com/](https://inquisitivedeveloper.com/). The idea is that you can learn Elixir along with me as I learn it and write about it. I make some comparisons to Javascript and C#, as those are the languages I use most often at work.

I was expecting to encounter a lot of very unfamiliar concepts, but to my surprise, I was already familiar with most of them. I guess my experience with the functional aspects of C# and libraries like Bacon.js and Rambda in Javascript really prepared me well for moving to a functional language.

<comment><USER11> This is excellent, thank you. I'll be learning along with you.

</comment></comment><comment><USER12> I've really enjoyed working in Go (coming from a PHP background). The language is simple, and most of the time, code that's written in Go is just as readable/understandable months or years later as it is on the day you wrote it. It's a really enjoyable experience. I don't think it's a particularly good choice for GUI applications on any platform though. I've been down that road and it's pretty painful. For that, I'm learning Rust.

<comment><USER13> Wish Go would get flutter bindings! How good is rust for gui bindings though

<comment><USER12> I'll preface this by saying that I'm super new to GUI programming in general, but my best guess at the problems that I've been having with Go are that GTK expects all the UI code to be single threaded, and the Go scheduler will just move stuff around to different threads as it sees fit. In practice, this ended up being just one giant function with all of the handlers inlined as anonymous functions. Really gross. My troubles could also stem from lack of understanding of Go internals too.

In Rust, my understanding is that it's a bit more like C or C++ in that multithreading requires an explicit opt-in and you can be a bit more thoughtful about what workloads are running on what thread (i.e. lock gui to one thread, do background processing elsewhere). This also looks pretty neat: [https://azul.rs/](https://azul.rs/) Not sure about the state of it, how useful it'll be, etc, but it already looks more complete than most GUI libraries for Go.

</comment></comment></comment><comment><USER14> As a shameless plug, there are a lot of interesting perks for a generalist to using Elixir.

\- Declarative + functional programming \- Highly productive (great frameworks for embedded + web, developer ergonomics, etc) \- Great exposure to Actor Model concurrency \- Great generic performance (no stop the world gc, strong multicore use via Erlang scheduler + processes, and lots of optimizations based on vm immutability) \- Lots and lots of exposure to systems stuff + strong devops tools (built for distribution __ __*, Erlang runtime tools, observer, great logging and telemetry libraries, etc) \- Lots of built in services /tools (can use ETS instead of redis for things like auth-checking throughput)

</comment><comment><USER15> It depends what you do. Most of these languages are general purpose but might be better suited for specific needs.

Go: It is really good for web apis and making cli apps

Rust: Suited for system level very high performance computation

Swift: Mostly for apple ecosystem

Kotlin: It might be most general purpose language, can be used for mobile apps, Web backend, native development

</comment><comment><USER16> Sounds like you have a lot of experience with imperative and procedural languages.

If you want to try something pretty difficult, but familiar, try a super- strict language like Ada.

If you want to try something completely different, I would suggest a functional language.

Elixir is already on you shortlist. I would also suggest taking a look at OCaml, Erlang, F#, Clojure, etc... However, I would not suggest Haskell if you're just starting out in functional.

</comment><comment><USER17> To get a job right now: Go

For a great low level language with a pleasant syntax and a good community: Rust

Skating to where the puck is going to be: Elixir.

</comment><comment><USER18> Go for Go. Industries are adapting it like crazy! Plus good Go developers are scarce so as a freelancer, you will have increased opportunities. Also, to a fellow freelancer, I would like to suggest you making plugins for chrome and Wordpress. No matter how crowded their store looks like, there is still plenty of room of requirements. Here's my website [https://boosters.in](https://boosters.in) created on wordpress! I personally had to create a wordpress plugin for such a small website and small usecase. So I'm sure the world is full of possibilities. Have a good day!

</comment><comment><USER19> Preaching what I like, and I'm not into extreme performance much:

\- Ruby for most things (most generalist language I know)

\- JS for whatever can't be done in Ruby

\- Other languages when anything really can't be done (or a magnitude harder) in JS or Ruby

I think just trying out to make some simple thing (e.g. an Hacker News scrapper) in different languages will tell you much more than any person's opinions.

[https://learnxinyminutes.com](https://learnxinyminutes.com) helps grabs the basics of a language quickly (especially as you are familiar with other languages).

<comment><USER20> OP said he already works with Python most of the time, so even if I live Ruby as the next guy, it's not a good recommendation.

I would say try Elixir since trying to go and think only functional for a while can be refreshing and useful also when you come back to the languages you already work with.

<comment><USER21> I use C++, Python and Ruby daily, but only Ruby showed me what truely poetic code looks like.

</comment></comment></comment><comment><USER22> I definitely recommend Go. Not only for the language itself, but for the lesson about simplicity it provides. Sometimes developers using others languages uses and abuses of features to be productif, smart, ... causing more damage than benefict. It's not the way to do things in Go.

Go is multiplatform, and you can easily cross-compile for other OS or other CPU architecture. It produces a single binary then it's easy to deploy. It could be useful.

Go is really easy to learn, in a single day you will have a good understanding of the language itself. It's really something interesting to learn and practice a bit, without needing weeks of work. Even if it doesn't suit you, you had not loss many time.

</comment><comment><USER23> After a lot of C/jS/TS/Go I finally found my pleasure with Rust.

It has some drawbacks like very slow compile time but it make your code sooo more robust!

On the other hand Go's pointer system and lack of immutable semantics make it really easy to introduce bugs when LOC >= 15k.

Rust support for arm, and wasm (without runtime, unlime Go) make me feel it have a great future and personally I'll never look back.

Go's lack of algebraic data type is a real panacea and make programming experience so painful.

Be prepared to have a bigger CI/CD (due to resource intensive compilation) but then your infra will requires far less resources! And you'll finally be able to sleep at night without fearing to have your infra burning.

Please note my use cases are HTTP APIs, cli programs and banckend dev like infra.

</comment><comment><USER24> Define and implement a compiler for your own language. Or implement a standard language or a subset of a standard language. Write the compiler in its own language or a subset that you can hand compile to, say, python. Nothing will give you a better appreciation of the nature of programming languages and their design. Not having to deal with types and storage management is cheating.

If you are simply cutting notches on your bedpost, write a utility or application in Haskell or Erlang. Even more instructive is to write a program in macro assembler.

</comment><comment><USER25> I've seen Rust mentioned, but not for the reasons I'm thinking of. My biggest complaint and simultaneously source of praise for the language is that it changes how you view other languages.

Implicit copying, unsafe access in multithreaded scenarios, deficiencies in type systems, and more - all become obvious and inescapable observations when using many other languages.

I'd imagine this effect is lessened if you came from C/C++ and watched the birth of Java, JavaScript, C#, etc., however as someone who started programming more recently, Rust has been the lightbulb moment for me for how languages work under the hood.

</comment><comment><USER26> TypeScript first, as it will be like steroids for your day job.

After that, do you want something practical or something educational?

Kotlin is a solid balance of both, and having JVM ecosystem interop makes it extremely useful for a generalist.

</comment><comment><USER27> How about dart? You have swift and kotlin on the list. With dart you could build native apps for ios and android

<comment><USER28> That's on his list of languages he's used. (It looks interesting though. I hadn't heard of it in a while and forgot about it.)

<comment><USER27> I didn't see it! It looks very interesting in combination with flutter.

</comment></comment></comment><comment><USER29> If you already know Python, Java and Dart, Go will be a breeze, so you can learn it anyway.

If you want something challenging and practical, I recommend Rust. It'll be much faster and easier to parallelize than the languages you've worked with, which may open up new possibilities for you.

</comment><comment><USER30> Have a look at [http://norvig.com/lispy.html](http://norvig.com/lispy.html)

And then create your own language :)

For prototyping, I recommend Python's lark-parser library, which will generate a parser from your grammar for you.

</comment><comment><USER31> You're missing all of the assembly languages.

You're missing all of the HDLs. (Verilog, VHDL, etc.)

</comment><comment><USER32> I've recently started learning elixir and it's an absolute joy to use so far

</comment><comment><USER33> Why don't you learn some functional languages? Scala, Haskell, or OCaml. Or learning lisps is always interesting: Racket, Common Lisp, Clojure.

Personally, Scala is my favorite language.

</comment><comment><USER34> Go is the most popular of the five you listed. Someone in my network who teaches at Stanford and worked at google said she is teaching her child go :-)

</comment><comment><USER35> Makefiles. They teach you a new way of thinking about code and dependencies and they are a universal tool that can be used in any stack.

</comment><comment><USER36> What does the job market look for in your area?

Is there any industry you want to work in that requires a certain language?

What is the end result you want?

</comment><comment><USER37> Elixir. It's the most different from what you know but has great online resources for picking it up.

</comment><comment><USER38> Scheme or Clojure

</comment><comment><USER39> Scala. Get the Manning book.

<comment><USER40> The weird thing about Scala is it's so nice and pure except all of the Object methods from Java, which sort of break the whole FP thing with it. I really want to love Scala, but it always feels 9/10ths of the thing.

</comment></comment><comment><USER41> Try Prolog.</comment>


A collection of iPhone UI screenshots, showcasing design patterns - <AUTHOR> http://pttrns.com/

<comment><USER2> If only there was an Android version too</comment>