Functional programming's smugness problem  - <AUTHOR> http://www.sdtimes.com/content/article.aspx?ArticleID=36534 <comment><USER2> I have never, ever seen "Monads are just monoids in the category of endofunctors" used in an actual conversation with someone who is trying to learn monads. The phrase is and always has been a joke; surely part of the joke is that most of us who use monads don't understand all that jargon ourselves. [http://stackoverflow.com/questions/3870088/a-monad-is- just-a...](http://stackoverflow.com/questions/3870088/a-monad-is-just-a- monoid-in-the-category-of-endofunctors-whats-the-problem)

BTW, the article asks about design patterns that structure functional programs. Well, monads are one such pattern. That's why they're important, not some mathematical jargon.

<comment><USER3> Please read between the lines. The author wasn't implying that anyone actually said that, just like he doesn't think anyone has ever said this in real life:

>"Design patterns? Hey everyone, look at the muggle try to get the wand to work!"

<comment><USER4> Well actually... [https://mobile.twitter.com/bos31337/status/18756470625548697...](https://mobile.twitter.com/bos31337/status/187564706255486978)

</comment></comment></comment><comment><USER5> I can speak only for Haskell-land, but I honestly see no truth in any of the author's negative arguments towards the functional programming community.

I have been doing most of my programming in Haskell for 3 years now, having worked in Ruby and Python before that. I can tell you that the Haskell community is among the most cordial, helpful and communicative I have ever seen in any field. In fact, many members of the community will cry foul if anyone dons on a "smug" attitude at any point; I've seen countless comments on reddit get buried for this alone.

If you want proof, just ask a question on StackOverflow[1], join #haskell on freenode or check out the reddit[2] page.

[1]: <http://stackoverflow.com/questions/tagged/haskell>

[2]: <http://www.reddit.com/r/haskell/>

<comment><USER6> I find that many functional programmers, including Haskell programmers, seem convinced that I will completely abandon C++ if only I spent the time to understand Haskell.

After spending quite a bit of time learning Haskell, seeing a number of advantages and disadvantages, and being unconvinced and staying with C++, the assumption is I didn't "do enough".

Of course, I also know a number of lovely functional programmers as well!

<comment><USER7> Maybe you're not ready to leave C++, but if you don't have a slightly icky feeling from C++ compared to Haskell, then you've been programming C++ for so long that the weirdness has metabolized.

<comment><USER8> Errr... perhaps you meant metastasized? Or solidified/ossified?

I think if it had metabolized, that would mean your body had burnt up the weirdness and gotten rid of it.

</comment></comment></comment></comment><comment><USER9> This article serves to fracture the community in a manner disturbingly similar to that in which the 'smug functional programmers' he complains about do. I can't help but sigh.

I think the recent rise in popularity of functional programming is a sign that more people are beginning to approach computing from a 'computer science' perspective as opposed to a 'programming' one. That is, to say, that the industry has matured to a point in which a significant portion of industry programmers are getting excited about some of the more abstract concepts brought to us through functional programming.

Few people will argue that the concepts underlying FP don't take some time to internalize, but the number and quality of FP learning resources is increasing at an incredible rate. This, alone, makes me skeptical of the author's points — people are going out of their way to create accessible learning resources so that they might share something they find to be useful/interesting. In any movement of any kind, there will always be evangelists. Some (read: most) of these evangelists will be overly aggressive and preachy, but they are rarely (read: never) representative of the larger body.

In the past two years I've become quite a fan of Clojure, and I have found the community to be tight-knit, welcoming and eager to share.

<comment><USER10> Is that why more people are learning FP? I think it's a different trend: recognition that programming is no longer about writing tight loops. Those have mostly been written. Instead, practical programming these days is dominated by orchestrating different people's code. Functional languages move more quickly here because functional code is, in some sense, more reusable by default.

<comment><USER9> I don't think our ideas are mutually exclusive — what you're describing is the notion of abstraction as it is applied to writing code. FP gives programmers incredible power with regards to reusing code (macros, first class functions, etc) at the expense of taking a little longer (in some cases) to wrap one's head around.

I was merely commenting that I think part of the reason people have been drawn to FP lately is that the industry as a whole has matured to a point in which more people recognize the need for and have developed the skills necessary to embrace such abstractions.

</comment></comment></comment><comment><USER11> The downside of being better than everyone else is psople tend to assume you're pretentious.

I learned FP by doing it, not asking around what monads are. There are plenty of great tutorials and no one has ever seriously talked about monads in that way.

The only time you really need to know what monads are is when you are building a new one.

<comment><USER12> _The downside of being better than everyone else is psople tend to assume you're pretentious._

The article used the word "smugness", not "pretention". They don't quite mean the same thing. Being merely better than someone might certainly seem pretentious depending on context.

Telling everyone about it (in a context without relevance or evidence), however, is undeniably smug.

</comment></comment><comment><USER13> I've just started having a play with Haskell which I got interested in after working through the seven languages in seven weeks book.

I've not really seen much smugness in the Haskell community. Though there are some proper clever people talking about stuff I don't understand, I don't feel they've done it in a patronizing way (or at least its been to subtle for me to pick up on!) That's my experience anyhow. I realize that the plural of anecdote is not data.

I'm actually more interested in the second part of the article where the author talks about claims of productivity gains from functional programming being exaggerated. I am curious if folk on here can point to counterexamples to the study quoted.

My strong suspicion is that there is much more likely to be a large variance in the productivity of programmers than in the productiveness of a particular language or way of programming.

</comment><comment><USER14> My experience is the _exact_ opposite. Whenever I struggle with an FP concept, those deeply nested in the community tend to be both eager to help and pretty unassuming. This is especially true among Haskellites (Haskellistas?) who usually understand there's a high learning curve associated with the language.

<comment><USER4> His examples come from the Scala community; I wonder if it's more pronounced there? I get the impression Haskell folks are fairly laid-back too.

</comment></comment><comment><USER15> I suspect that OOP had a similar problem at one time.

<comment><USER16> I'm not so sure. OOP entered the scene and became a dominant paradigm in a short amount of time - this doesn't happen without massive amounts of evangelization (from existing users) and marketing, neither of which can be particularly smug if they intend on being successful.

<comment><USER17> OOP was able to become dominant because it came with some clearly defined "killer apps", the likes of which I have yet to see materialize from the FP world. I mean, Smalltalk shows up in Byte and says "look, here is an entire system for graphically interacting with a computer, creating music, simulations, animations, drawing programs, documents, and more. It is so easy that school children can use it. We have managed to accomplish all of this in a few hundred thousand lines of our language called Smalltalk, which incidentally also contains the implementation of all the dev tools and the standard library. How large would this be in the language you are currently using (probably COBOL, Pascal, C or something similar)?"

I get that FP has some very good characteristics, and I have tried to add a bit more "functional-ity" to my code over the years, but at the same time I get an overwhelming urge to say "put up or shut up" every time I am confronted with an article talking about how terrible OO and the programmers who work in it are, and how those working in FP are in some sort of enlightened programming utopia.

Convince me by showing me some examples of programs so good that I can't possibly ignore them, the way OOP did. Convince me by becoming the foundation of almost every program I am currently running on my computer right now, the way OOP did.

Don't convince me by writing article after article showing how insanely elegant your implementation of a mathematical function (My head will literally explode if I see another Fibonacci example) is, and how brain damaged what I am currently using must be. Numerical code comprises probably 0.1% of any computer system I am currently using. Show me instead how easy you just made to it interact with my computer, to write the type of programs that I am currently using and, for bonus points, to write the types of programs that I didn't even think were possible.

<comment><USER8> Hmmm. The killer app, when it comes, will probably be for parallelism. Since FP languages are better able to control state, they can neatly sidestep many of the contention issues that plague imperative programming in multi-core scenarios. Problems that require heroic programming in imperative realms become much simpler in certain FP languages. And given that clock speed is settling down while core numbers are ramping up, I think this alone will make FP more compelling.

It's more about appropriateness, though, than anything else. I still think OOP is great for things like GUIs, modeling complex domains.

As always, the trick is to pick either the right language for your problem, or pick a multi-paradigm language, and choose the right approach for your problem.

<comment><USER18> _The killer app, when it comes, will probably be for parallelism._

If that's the case, then FP's got a problem in the form of OOP having already done it first and famously with projects like Hadoop.

I think that too much hay is made of the tradition of minimizing mutable state in functional programming. It's not something that's exclusive to FP. And I'd even go a step further and suggest that excessive use of mutable state isn't a hallmark of imperative programming so much as a hallmark of _bad_ imperative programming. Though I'm sure there's also plenty of room for argument there.

Regardless, the fact remains that when functional programming proselytizers suggest that imperative programmers need FP to escape from the bugaboos of excessive mutability, it comes across as somewhat naive. While many functional languages make mutability less convenient, this is not the same as making immutability more convenient. Which I mention by way of pointing out that really the only thing people working in imperative languages need to do to cut back on their use of mutable state is _cut back on their use of mutable state._

Now, if the current fad for FP made more noise about something that distinguishes functional languages much more tangibly, it might be more impressive. Take higher-order programming, something most functional languages do very well and most imperative languages do poorly (if at all). Imagine doing something like node.js in a non-functional language.

Or this couple minutes from a lecture on F#, where the presenter converts sequential code to asynchronous parallel code in just a few keystrokes. Sure, managing state properly is an important precondition to being able to do that, but the real magic is in the async workflow (a type of monad). <http://youtu.be/HQ887aOZITY?t=53m>

<comment><USER19> > with projects like Hadoop

You do know where the "map" and "reduce" in MapReduce come from, right?

<comment><USER18> Yes. That's precisely why I chose it as my example. One of the major themes in my post was statements to the effect of "you need functional programming languages to do X" often being mistaken, so that detail makes Hadoop a rather poignant case.

<comment><USER8> I agree. I think perhaps, a better point to make is that FP makes certain things easy, or the default, while doing it in am imperative language requires discipline, which I think is a mistake to rely on at the industry level.

It's a bit of a reductio ad absurdum, but remember: technically everything _could_ be written in assembler. Languages and their idiomatic usage matter. Any C++ person could point out that, yeah, everything you can do in Java can be done in C++, but the fact that Java does automatic memory management still has value to many people.

<comment><USER18> Totally. And I also think a lot of imperative languages make that kind of discipline more of a hassle than it needs to be. (Giant peeve: .NET does not have any decent options for immutable collections in its standard libraries.)

But the author does bring up a good point: The industry is full of people who were taught using Scheme in university, but quickly switched to an imperative language when given the chance. Having TA'd classes that are taught in Scheme, and spent a lot of time tutoring people who fit into that class, and watching the way they go nuts when they're finally shown set! for the first time, I've come to the conclusion that it isn't merely a preference. Most of them really do have a genuinely easier time reasoning about and writing correct imperative code. It would also be a mistake to rely on a programming paradigm in which many people have a hard time functioning at the industry level.

If there's a middle ground that allows people to keep their FOR-loops while discouraging them from using mutability in the contexts where it's dangerous, that's the direction I think industry should be headed in.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER20> Out of curiosity .. when was the last time you read a story that told of company x dominating the market because they used programming paradigm n.. just a thought.

<comment><USER10> Viaweb?

<comment><USER20> The wikipedia entry states viaweb was partially written in lisp .. would be interesting to know what part lisp played .. is pg in the house?

<comment><USER21> This nine year old essay by pg is very well known: <http://www.paulgraham.com/avg.html>

_Our hypothesis was that if we wrote our software in Lisp, we'd be able to get features done faster than our competitors, and also to do things in our software that they couldn't do. And because Lisp was so high-level, we wouldn't need a big development team, so our costs would be lower. If this were so, we could offer a better product for less money, and still make a profit. We would end up getting all the users, and our competitors would get none, and eventually go out of business. That was what we hoped would happen, anyway._

</comment></comment></comment></comment><comment><USER22> I dont think it gets much friendlier than Learn You a Haskell

<http://learnyouahaskell.com/>

</comment><comment><USER23> Smugness is in the eye of the beholder.

<comment><USER16> That's just something smugly people say. ;-)

</comment></comment><comment><USER24> I totally agree with the author in my experiences. To be fair those individuals were also egotistic elitists in other realms of their life. "If there's anything around here more important than my ego, I want it caught and shot now!"

</comment><comment><USER25> OP strikes me as someone who is trying to position himself as a "moderate" but who is mistaking a caricaturized extreme (<0.25%) for "functional programmers". Honestly, I like FP extremists better than their OOP cargo-cult counterparts, who have the same smugness but are usually better, in most companies, at getting managerial blessing. In many companies, OOP acolytes glow in the managerial sun like Dudley Dursley, despite the general crappitude of their ideas.

"Functional programming" in the real world isn't about dogmatically eliminating mutable state. It's about _managing_ it. It's about _modularity_. It's not far from the original vision behind OOP-- before it got taken away by the wrong crowd-- which was that when complexity is inevitable, it should be encapsulated behind simpler interfaces. For example, SQL is append-only (as functional as one can get over a growing knowledge base) if you never use DELETE or UPDATE. The inner guts of SQL are not "purely functional"-- caching and indexing cause internal state changes, for performance reasons-- but the interface is.

I don't even know what endofunctors are. If it's relevant to my job, I'll learn about them, but I care more about writing good software than reciting category-theory arcana. I'm sure it's important (especially as an inspiration for design) for some people, but you don't need to know them to do functional programming. Not even close. And I was already a productive functional programmer (in Ocaml and Lisp) before I even knew what _monads_ were.

<comment><USER26> The problem is that the best, most expressive functional languages (lookin at ya Haskell) are _mathematically based_ on this theory. If you want to use these languages, you have a choice between (a) learning the theory, and (b) not fully understanding the tool you're using. Both have significant downsides from a UI perspective.

 _Learn You A Haskell_ is a classic case of (b). As a tutorial it's completely successful, and how? It tells you that you can learn Haskell without learning PL theory. It also neglects to tell you how to _debug_ you a Haskell (without learning PL theory). But once you type in the examples, I'm sure you can figure it out.

A lot of people are smart enough to program on top of mysterious black boxes. That is: a lot of people are smart enough to work past this UI problem. Moreover, the smartest people can learn Haskell by rote and then gradually, through intuition and experience, learn to grok the black box. This is not to say, I think, that it's not a problem.

Of course you could just learn the theory. I'd say anyone who can graduate with a math degree from an Ivy-class university can do it. Is you a member of this set? Find out by reading the Wikipedia page for Hindley-Milner:

<http://en.wikipedia.org/wiki/Hindley%E2%80%93Milner>

I'm sure there are simpler explanations of H-M (Haskell's type inference algorithm). But they're not on Wikipedia. I sent this link to a friend of mine with a PhD in astrophysics from Caltech. "Which seems easier to you?" I asked. "This, or special relativity?" You can probably imagine his response.

So, wanted: a higher-order typed functional language whose type system is easier to understand than special relativity. Or of course a proof that such a device is impossible :-)

<comment><USER27> Do you think H-M, which can be presented in full in less than a 60 minutes functional programming lecture, is harder than a whole subfield of physics? I don't think so. Astrophysists deal with large objects every day and there might be a reason why they find relativity easier.

BTW: Debugging is much less used in Haskell, this is not a strong objection to LYAH.

<comment><USER26> Special relativity is a few formulas, not a "whole subfield of physics." But yes - I didn't really regard this as a serious scientific criticism.

I can present LR parsing in a lecture as well. However, if you had to understand LR parsing to write an HTML 5 app, there would be a lot fewer HTML 5 apps.

By "debugging" I didn't just mean tracing. I meant one of the most basic tasks of the programmer - interpreting and responding to error messages. Is there a single error message shown or explained in LYAH? If so, I missed it.

This is germane because, when a type system works perfectly, it appears magic by definition. When it issues you an error, however, you have to understand what went wrong. It is sometimes possible to do this without understanding the black box, but the skill is again recondite.

I refuse to believe that Haskell programmers are so godly that their programs work the first time they're typed in.

<comment><USER27> I think "special relativity is a few formulas" is an underestimation, but this is not important.

> By "debugging" I didn't just mean tracing. I meant one of the most basic > tasks of the programmer - interpreting and responding to error messages. Is > there a single error message shown or explained in LYAH? If so, I missed it.

Yes, although not much; grep for "error" in [http://learnyouahaskell.com/starting-out#babys-first- functio...](http://learnyouahaskell.com/starting-out#babys-first-functions) or other chapters.

I could code comfortably in Pascal long before I knew how exactly does "expecting a semicolon, found a number" arise. I could code comfortably in Haskell many months before learning HM as well. You know what to do when you see "no instance for Num Char" as well as you know what to do with that parsing error. No need to think about unification or parsing, a kneejerk reaction is enough.

> I refuse to believe that Haskell programmers are so godly that their > programs work the first time they're typed in.

Of course that's false -- but once a Haskell program is typed and compiled, there are much larger chances that it will work first time compared to, say, Java.

<comment><USER26> _I could code comfortably in Haskell many months before learning HM as well._

This is a better argument for you than for Haskell. I wasn't disputing that there's a set of people who can intuitively command an incredibly recondite black box they don't (yet) understand - or that that set includes you. What I will argue is that that set is _small_ , making it very hard to produce a critical mass of Haskell users despite the tremendous academic subsidies Haskell has received.

Imagine you're a helicopter pilot. That it's easy for you to fly a helicopter doesn't mean it's easy to fly helicopters. If we compare the set of people cognitively able to use PHP, to the set cognitively able to use Haskell, I don't think we're far from comparing car drivers to helicopter pilots.

 _Of course that's false -- but once a Haskell program is typed and compiled, there are much larger chances that it will work first time compared to, say, Java._

Indeed. (I'm not just agreeing for rhetorical purposes - this really is true.) Inasmuch as the programmer isn't perfect, however, he spends his time chasing not runtime errors - but static type errors.

<comment><USER27> I agree that using Haskell is like flying a helicopter when others use cars. However, I still strongly disagree with the choice you wrote earlier:

> If you want to use these languages, you have a choice between (a) learning > the theory, and (b) not fully understanding the tool you're using.

Please bear in mind HM is only a basic idea of how Haskell type system works. Current inner workings of GHC type checking are described in 80 page research paper on OutsideIn(X), <http://www.haskell.org/haskellwiki/Simonpj/Talk:OutsideIn>. I never read more than half a page from this. Yet I can use GADTs, type families, existentials, rank-2-types and so on with no trouble. I don't think Haskellers who did not read those 80 pages are "not fully understanding the tool they're using".

Why should I know theory - OutsideIn(X), HM, category theory etc., to "fully understand" the tool? Intuitive understanding gained by practice is enough.

<comment><USER26> Intuitive understanding gained by practice enough for _you_. If Haskell didn't exist, you could probably invent it. The result might even be better.

Neighbor, how much code is there in the world? And how many coders as good as you? Divide these numbers, and you'll see why the world can't possibly adopt Haskell.

Some people can climb Half Dome with their fingernails. That doesn't mean there shouldn't be a fixed rope, too - that is, if your goal is to maximize the climbers of Half Dome. (If its goal is to separate the men from the boys, Haskell is already doing just fine and shouldn't change a thing.)

<comment><USER27> I think intuitive understanding gained by practice is enough for every programmer, not just me. Learning by programming is easier than reading research papers and digging the theory. What more, it was a prerequisite for me: I could not understand papers on type systems or category theory before I saw Haskell code. I heard similar opinions often - Haskellers learn Haskell first, can code comfortably, and only then are able to read about the theory. Theory seems hard, dull and useless at first. Even now, I feel a lot of it is cruft.

The semi-official motto of Haskell is "Avoid success at any cost", not world domination. It is enough as a tool for hackers, not for everyone. Haskell expands extremely slowly, yet steadily.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER28> Oh, stop. I'm tired of hearing about "smug" being the worst thing ever. Too easy to toss this insult around.

Instead, personally my issue with functional programming is the aversion to side effects. It seems to cause a lot of weird contortions, when the whole reason we make software in the first place is for the side effects. Programming in a functional style brings with it a lot of wonderful, powerful ideas. But that one has always struck me as unfortunate.

<comment><USER29> I couldn't disagree more.

I find that the aversion to side effects even when working in imperative languages is one of the most useful things I've learned from functional programming.

It is true that, at one level of abstraction, we write programs for their side effects. However, it is also true that having the right side effects is extremely important - so important that a program with the wrong side effects can easily be worse than no program at all. From that perspective, a focus on minimizing, containing and controlling side effects is very valuable. And an aversion to side effects is a good way to sharpen your focus on that.

<comment><USER28> > _I couldn't disagree more._

I know. Trust me, I know.</comment></comment></comment>


Joining Stripe - <AUTHOR> http://notes.deaxon.com/joining-stripe/

<comment><USER2> No managers? I'm curious how Stripe compares culturally to Valve, GitHub, and Zaarly.

If I ever decide to work for someone else, I'd want to choose a decentralized place like those.

<comment><USER3> (I work at Stripe)

Patrick answered a question on Quora about why Stripe doesn't have product managers and the cultural aspects behind that decision: <http://qr.ae/TFjJK>

<comment><USER2> Thanks - I'll take a look!

</comment></comment></comment><comment><USER4> Congrats! So Stripe is acquiring Kickoff, and I saw from this tweet <https://twitter.com/bdc/status/311134449293201408> that Kickoff will still be developed?

Will the current Kickoff team be developing it on nights/weekends? Or is Stripe taking over the product and developing it together?

<comment><AUTHOR> Yeah, Michael and Ben will still be maintaining Kickoff. There's some precedent here: before Saikat and Sheena joined Stripe about two years ago, they'd previously been working on Mockingbird (<http://gomockingbird.com>). Since then, they've kept the business up and running (on Stripe!). Given both that precedent and how much work Michael and Ben have put into Kickoff, we felt it made sense for them to keep it alive.

<comment><USER5> I'm sorry but last time I checked, Mockingbird development is all but stalled since the founders got hired by Stripe. Which is a shame, given how a great product it was.

Since you're probably gonna see them around, please ask them: why don't they just hire an employee to do actual work for Mockingbird? Thanks!</comment></comment></comment>


Show HN : Entofly - Tv show subscription and download. - <AUTHOR> http://www.entofly.com

<comment><USER2> surely this is fodder for 6 strikes.</comment>


Ask HN: What traits of senior engineers do you find most valuable? - <AUTHOR> I'm curious to know what non-senior engineers (juniors, mids, managers, CTOs etc)  see as valuable traits in their senior engineers (and "above").
Some observations of the seniors on my team I really respect:
Patience in many forms. Patience to read docs and understand beyond surface level, to not jump to conclusions, to think about a problem abstractly before diving into implementation, etc
Strong communication. Whether translating a difficult problem to juniors, management, or non-technical folks. This also includes a significant amount of EQ (i.e. they're just nice people). Plays a role in mentoring and also arguing "up" for support on engineering priorities.
Willing to let go. This is a harder one to grasp - but basically being okay with scratching a project or area of code when it makes sense to, willing to set aside an opinion or lose an argument when it makes sense to, etc.
What else? <comment><USER2> All of the above, plus -

A senior engineer sees the big picture more readily, and understands the negative as well as positive impact of a change.

In any decision there's seldom one "absolutely right way". Usually it's a case of which compromises are the easiest to live with. Being able to see "both sides" and being able to see beyond the immediate is a key attribute.

Here's a hypothetical example - a Junior programmer wants to switch the development team to using Linux, because "there are lots of advantages to doing this". A good senior would ask the question - "ok, tell me why we _shouldn't_ switch?". There are, of course, disadvantages to switching (just like there are advantages and disadvantages to any decision). To show that you understand _both_ sides of the decision is critical. It's not enough just to know the positives, you have to understand the negatives as well.

In my experience you will get all kinds of advice to "absolutely do this". But when quizzed the reasons for _not_ doing something have not received the same level of thought. Folks who can see the big picture, and see the long-term impact of a decision, make better decisions.

[Of course the junior may be right, in the sense that it may be a good thing to switch. the outcome of the decision is not my point, it's the consideration process that I see as a differentiating factor.]

<comment><USER3> Yeah. The answer is almost always "it depends". A may be a better option than B in light of our particular tradeoffs, but almost always A is not better than B in all circumstances.

So if you're advocating A, and you sound like a teenage girl talking about her boyfriend or her favorite band, you're almost certainly junior. If you're saying, given these particular technical aspects of our situation, A looks like it might be a better choice, then you're talking like a senior engineer.

</comment></comment><comment><USER4> There's lots of them, but there's a couple that make one stand out, and they aren't technical.

\- Dealing with ambiguity.

\- Diplomacy skills. Knowing how to negotiate.

</comment><comment><USER5> * Communication

* Ability to learn and use new technologies and methodologies and not be stuck in one box

* Ability to get things done/finish something or hand onto someone who can

* From above, delegation skills would be good!

<comment><USER6> Ability to get things started.

Ability to get things finished.

Respected by juniors to do the above.

Trusted by superiors to do all the above.

</comment></comment><comment><USER7> Decisiveness, make a decision and go. Don't waste energy by trying to collect tons of information that just wastes resources and time.

<comment><USER8> Until the feature stakeholders see it and say you completely missed the point of the required features and you have to re-do your work.

</comment></comment><comment><USER9> friendly, wants to teach</comment>


Tell HN: just made my first dollar on the Internet from my freemium web app - <AUTHOR> ..and I am surprised at how good it feels. Its not much (just $12) but I feel it is a huge mental step forward for me, which I thought many here could relate to :-) <comment><USER2> If you don't get a high, a rush from selling something to someone, you're not cut out to be an entrepreneur.

Congratulations on your first sale.

Last month I sold my first piece of software online and I literally woke my wife up to tell her. I also sell guns and gun accessories. Last night, a customer purchased $1100 worth of products. In an industry with tough and large competition, we somehow convinced him through our website to give us $1100 of his money. Two years later and my business partner and I still send each other texts when an order comes through.

It's such an amazing feeling.

Again, congratulations on your first sale and I hope many more to come for you.

<comment><USER3> Sidenote, I dont want to be a buzzkill but be carefull with your 1100$. I worked for an ecommerce website a few months ago, when we launched we received big orders we were so happy but unfortunately it's turn out that we had been scammed by people with stolen credit card. Scammers are always looking for new ecommerce to scam, they love ecommerce that are fresh because it's easier to scam newbies :/

I know nothing about your business, and I wish you all the luck in the world, just wanted to warn you. Congratulations for your work ! (and your energy :) ! )

<comment><USER4> Since he is selling firearms, he'll be shipping to a FFL located in the state of the purchases. Buying firearms is (usually) highly regulated, so the background and ID checks to complete the purchase should rule out most chances of fraud.

</comment></comment></comment><comment><USER5> I remember getting my first check through the post, and the first time someone handed me cash. This was 15 years ago, and I still remember them clearly.

Well done.

May I make a suggestion? Start keeping a diary. Nothing big, nothing fancy, just notes about things like this. If you become an entrepreneur full-time you'll want to go back and read about days like this.

Congratulations.

<comment><USER2> Yup, a small Moleskine notebook is perfect. Fits in your pocket and you can jot down milestones like this.

<comment><USER6> It will cost him $12 he just earned! But Moleskine is great, not loosing the shape for many years and it is great to have it many years after :)

</comment></comment></comment><comment><USER7> I have my email client set up to play a cash register sound every time an order goes through. It sounds dumb, but it never gets old.

<comment><USER8> I actually recently set up something similar. I use opengateway with authorize.net and it will post to a url during a transaction. I have it post to a local server, that plays a specific .wav file depending on the transaction type.

There are 5 transaction types and I use a slot machine, cash register, bells, and crowd cheering noises.

Got the idea from this movie <http://www.imdb.com/title/tt1251757/>

<comment><USER9> Ours play Shoot To Thrill (AC/DC)

</comment></comment></comment><comment><USER10> Good move. Yesterday, I got around $5 from Squidoo for a lens that suddenly become popular and was able to get 300 views in a month. I made it, if I remember well, months ago and forgot about it. But man, it only took me 10 or 15 minutes to make it and that was all I have done.

So I thought about it and decided to dig in for some keywords and create even more pages. If I only have 20 lenses like that, it would make me $100 a month. Not that much, but nice money to pay my Internet, phone and SaaS bills.

I'm writing this comment to tell you that I feel your happiness. Although it's a very small and tiny amount of money, you are very happy. I know it, because I'm feeling it right now.

May be it's the effect of money that comes from selling products and not working under a boss. Already felt it when selling scripts on CodeCanyon.

Nice work and now improve and promote more your product!

<comment><USER11> > May be it's the effect of money that comes from selling products and not > working under a boss.

I think it is more of an affirmation thing. It was for me first time I was paid for a product all those years ago. It was originally written (quite naively and so badly in many ways, but it worked!) because I needed it so it didn't have to make money: but when it did it felt very good because someone else thought that my work was worth paying a little for.

</comment></comment><comment><USER12> Many congratulations, and thank you. "Thank you" because I know from my own experience that these kinds of posts are extremely motivational.

I made my first sale a year and a half ago, and recently increased the sales so that I could go full time. Maybe I should've followed my own advice and posted it on HN: [http://www.elstensoftware.com/blog/2011/01/21/going- fulltime...](http://www.elstensoftware.com/blog/2011/01/21/going-fulltime/)

<comment><AUTHOR> Thanks and congrats on going full time

</comment></comment><comment><USER13> We've just put up a calendar on the wall, crossing off the days we're making money.

Feels VERY good!

<comment><AUTHOR> Nice take on the Seinfeld technique. I will try this.

<comment><USER14> Thanks for naming the idea. For those wondering what the Seinfeld technique is but who are too lazy to Google at the moment: <http://www.nevblog.com/motivations-the-seinfeld-calendar/>.

</comment></comment></comment><comment><USER15> Congratulations!!

I just started last month too, and my first batch of customers with recurring payments are about to recur tomorrow. I'm both incredibly excited and worried (no one unsubscribed yet).

<comment><AUTHOR> Thats awesome. :-)

</comment></comment><comment><USER16> Congrats! It is a big deal. Now while sales < 1000000 do ;)

<comment><AUTHOR> Thanks. :-)

</comment></comment><comment><USER17> I'm still waiting for my first dollar from my password generating android app "Password Specialist". It was added in Dec 2010 to the market and still 0 sales :)

<comment><USER18> hate to be a stick in the mud, but aren't passwords hard enough to remember when they're not randomly generated?

</comment></comment><comment><USER19> I love reading stories like this.

There is no greater motivator than seeing that first sale or first deal come through the door. I've been lucky enough to have that feeling with two companies now - and it never gets old or tired.

I love the comments about waking/emailing PayPal receipts to wives. I did the same thing. I still do when I good sized deals come through. As leftnode said - that's the high of being an entrepreneur.

Congratulations on the sale. Hopefully it will be the first of many. It's a really good idea - I've forwarded it on to a few friends in PR and marketing agencies. Hopefully at least one or two of them will send $12 your way before long...

<comment><AUTHOR> oh thats great. Thanks a ton for the forwards

</comment></comment><comment><USER20> Congratulations! It probably is the sweetest feeling ever, esp the feeling you get when you realise that something you built was of value to someone else.

I demand a "first sale party" on behalf of those of us who aren't YC funded. :)

<comment><AUTHOR> yes... I am up for it

</comment></comment><comment><USER21> Congratulations on your first sale! Ysd I had another sale on my 4-month old startup, so I know how it feels to get this paypal/gateway emails.

Good luck!

</comment><comment><USER22> congrats on your first dollar! i had exactly the same experience last week!

i bought a domain more than a year ago, been doing development ever since but progressing very slow (it's a solo project and i have a full time job). last month renewal notice showed up and made me think, "wow, it's been a year, and it's still in my laptop."

now it has been launched. and last week i got my first paying customer. i literally cried and jumping around in excitement, and immediately gtalked my girlfriend. very stupid considering it's less than $10, but it gave proof that "my idea works" (it's just an e-commerce for Indonesia market).

anyway, nice work and always positive minded :)

<comment><AUTHOR> >>>now it has been launched. and last week i got my first paying customer. i literally cried and jumping around in excitement, and immediately gtalked my girlfriend. very stupid considering it's less than $10, but it gave proof that "my idea works" (it's just an e-commerce for Indonesia market).

Thats how a felt. Please post the link

</comment></comment><comment><USER23> I have yet to break into web development(and start a company etc. to make money online) but I finally finished an app for a local business that has started making payments to me. Getting checks feels nice. Congrats!! :)

<comment><AUTHOR> Thanks

wow.. its amazing how many of us share this feeling about the first sale

every sale actually. congrats

</comment></comment><comment><USER24> Congratulations. It's a huge moment when you suddenly realise you've made something that strangers on the internet are willing to give you actual cash for.

I'm still slightly bemused by it myself :)

<comment><AUTHOR> Thanks

</comment></comment><comment><USER25> This must feel good indeed, congrats! You just did the MVP of customer development. And a great prototype for brand monitoring. Good luck!

<comment><AUTHOR> Thanks. It does and is also very motivating. I feel that if I can sell one I can sell more.

I am thinking of working on the UI and the positioning a bit more.

</comment></comment><comment><USER26> Congrats. Happy for you. It is a $12 you will remember all your life. Relish it.

</comment><comment><USER27> Congrats! I just sold my first product online last month. Great feeling.

</comment><comment><USER28> Congrats! I'm anticipating my first sales early next month.

<comment><AUTHOR> best of luck

</comment></comment><comment><USER29> congrats! Just repeat a few times (!) and you're rich :)

<comment><AUTHOR> I am on it already :)

</comment></comment><comment><USER30> Congrats- I'll have a beer for you!

<comment><AUTHOR> lol Thanks

</comment></comment><comment><USER31> Well done, congratulations!

<comment><AUTHOR> Thanks

</comment></comment><comment><USER32> congratulation on your first sale. few years back i as one of you :)

<comment><AUTHOR> Thanks. feels great. You can post your story so we know the road ahead :-)

</comment></comment><comment><USER33> Congratulations mate ! :D

<comment><AUTHOR> Thank you

</comment></comment><comment><USER34> Congrats!!!

</comment><comment><USER35> Congratulations!

Link? :)

<comment><AUTHOR> Thanks. Here it is <http://www.trackthisnow.com/>

<comment><USER16> Very cool app

<comment><AUTHOR> Thanks.. It was originally designed as a free software. I introduced the paid option when I realized there was a demand for it, especially from the PR industry.

</comment></comment></comment></comment><comment><USER36> Congrats on first sale :) What's your app's url ? Share with us ....

<comment><AUTHOR> here it is <http://www.trackthisnow.com/></comment></comment>