Firefox Voice - <AUTHOR> https://voice.mozilla.org/firefox-voice/ <comment><USER2> I see a lot of skeptical voices here, (somewhat warranted, given it's a voice assistant technology), but the fact remains that if we want open, on-device voice recognition, we'll have to do the work and donate sample data.

This extension is trying to provide some useful functionality in the hopes that Mozilla gets more data for [https://commonvoice.mozilla.org](https://commonvoice.mozilla.org)

I'd at least consider recording your voice, especially if you're a non-native English speaker, like myself, have an accent etc.

It took many years for free software to start to take on the smartphone segment, with previous efforts, (including by Mozilla), failing and only now PinePhone & Librem 5 giving it another go, but unless you're a super hardcore enthusiast, you carry an iPhone/Android today.

I see this as a way to push back on the likes of Amazon, Google and Apple with this. If regular Firefox users are able to use an on-device, privacy respecting voice assistance and other open-source projects can use Mozilla's tools and datasets to build compelling competitors to Alexa, I'd see that as proof that free software is able to address new, emerging markets too.

<comment><USER3> > if we want open, on-device voice recognition, we'll have to do the work and > donate sample data.

Fair enough, but is any stopping Mozilla from _also_ selling your voice data to third parties including advertisers and commercial ML interests?

(Asking this because Firefox has started sharing our data with leanplum)

<comment><USER4> It still remains a risk well worth taking. With Mozilla, it is merely uncertain but for just about every other company, it is all but guaranteed. You can plainly see this philosophy in the industry's naming sense, where super-computers of yester-year are relegated to "edge" roles.

As of today, the open source and free software equivalents to machine learning and AI products are sorely lacking when compared to commercial offerings. Whether it is open-ended speech to text with good ergonomics, text to speech, intent recognition, speaker recognition, OCR for text, OCR in the wild, translation, object recognition, image segmentation, image to text or natural language processing, commercial offerings are leagues ahead of what free software can do.

If we look at one of the most impressive AI demonstrations in history, GPT-3, it is not apparent whether open source can even replicate it because with AI, unlike in the past, time and skill is no longer directly fungible with money. I would argue the concentration of such capabilities to Microsoft and Google servers is a threat to the ideals of free software as great as any it has seen before. Yet, relatively little attention is spent there because people are too focused on yesterday's problems.

This concentration is difficult to avoid because current algorithms require large amounts of data and computing ability, which only large corporations can marshal. Mozilla is far from perfect but despite their many stumbles, they're the only large organization seriously attempting to address this imbalance. As much as these algorithms are marketed as AI to users, ML is better thought of as libraries, in the line of ffmpeg, to programmers. Mozilla still do seem to care about creating a local-first offering. If everyone stops using them then what is gained exactly?

<comment><USER5> >With Mozilla, it is merely uncertain but for just about every other company, it is all but guaranteed

I disagree, most large companies view this data as a competitive advantage and won't sell it directly. They may sell the results but the data itself is their moat. Smaller companies on the other hand are more willing to sacrifice future profits for current money.

<comment><USER2> This is an open dataset. There's no point selling a dataset that's already free.

As far as recording things I didn't consent to, the likes of Google way more likely to do that[1].

1 - [https://mashable.com/article/google-assistant-microphone- smo...](https://mashable.com/article/google-assistant-microphone-smoke-alarm)

</comment></comment></comment></comment></comment><comment><USER6> I've looked into open source voice assistants before. I found mycroft, Jarvis and a few others, but either got bogged down in dependencies or configuration. Many supported shipping your data to Google or Amazon if you configured it, or an open source voice recognition tool.

I hate this idea that our voice has to be shipped somewhere to be processed. I remember a lot of the speech-to-text tools in the early 2000s weren't all that great (they needed a lot of training), but why haven't we been able to advance on-device processing? Why is everything done in "the cloud."

So the only way to semi-accurately do voice recognition is to source algorithms that re-train off of millions of people? We have processors in our desktops and laptops that dwarf that compute power by leaps and bounds. We should be looking to Star Trek TNG level voice processing, on each individual device, without some central mainframe.

But marketing, advertising revenue, data mining, free (as in beer) software that pumps your data like an oil rig, efficiency in data centre (cloud) design .. all these factors have led to these powerful little Intel/ARM/Ryzen chips to be nothing more than thin clients when they're not playing games.

If Mozilla really wanted to make something amazing and in the spirit of Firefox, give us an experiment where voice processing is done on our devices. Even if it meant I needed to download a 230GB data set, I'd gladly do it, if it could remotely help in getting away from these data silos.

<comment><USER7> > I found mycroft, Jarvis and a few others, but either got bogged down in > dependencies or configuration.

More recently, there is also Rhasspy ([https://rhasspy.readthedocs.io](https://rhasspy.readthedocs.io)) and voice2json ([https://voice2json.org](https://voice2json.org)). I'm the author of both, if you have questions.

> Why is everything done in "the cloud."

Besides being a way of collecting data and ultimately making money, it avoids some of the "bogged down in dependencies or configuration" problem. My voice projects need to run entirely offline on a variety of hardware and operating systems. If each client was just a little app piping audio data to a cloud service, it would be way easier to write and maintain.

> So the only way to semi-accurately do voice recognition is to source > algorithms that re-train off of millions of people?

Nope. You can absolutely tune a speech model locally on your own samples and get great accuracy. The trouble comes with open-ended speech: people expect the voice assistant to recognize that new artist or movie they heard about yesterday. That doesn't work without upkeep somewhere.

Rhasspy/voice2json are intended for pre-defined voice commands using a template language. You can get almost perfect accuracy with this approach, even with millions of possible commands. Re-training only takes a minute, so personal upkeep isn't bad.

> Even if it meant I needed to download a 230GB data set, I'd gladly do it, if > it could remotely help in getting away from these data silos.

It's a lot less than that; at most 1-2GB for a given language, usually a few 100MB: [https://github.com/synesthesiam/voice2json- profiles/](https://github.com/synesthesiam/voice2json-profiles/)

<comment><USER8> @synesthesiam your work is wonderful and I am willing to test both ASAP.

It kind of fills a gap left from snips.ai, will check and compare with what's on the market now.

Super recent (less than a year for both projects, but may be wrong) and apparently well documented. Hats off

</comment></comment></comment><comment><USER9> I'm sorry, but cloud based speech recognition in itself would already be a red flag, even if Mozilla was doing it in-house. Outsourcing it to Google though? I feel like a company as ostensibly privacy-focused as Mozilla should really know better by now...

<comment><USER10> They're building their own open voice platform. Google speech to text is presumably for testing.

> Note: In the future, we expect to enable Mozilla's own technology for > Speech-to-Text which enables us to stop using Google's Speech-to-Text > engine.

edit: s/texting/testing

<comment><USER11> Mozilla DeepSpeech is rapidly maturing, but it needs thousands of hours of validated audio data to train each language. Its a feat that with only 2000 hours of audio they can achieve a 5.97% word error rate.

Baidu had 5000 hours of audio data to train their DeepSpeech and DeepSpeech 2 models, meanwhile Google, Microsoft & IBM have people constantly giving them fresh audio to train and validate their models with.

Firefox Voice data should help rapidly expand the Common Voice audio corpus beyond the 1492hrs it currently contains: [https://commonvoice.mozilla.org/en/datasets](https://commonvoice.mozilla.org/en/datasets)

</comment></comment></comment><comment><USER12> Had to read the privacy policy to see they use Google.

>We share your audio recording with Google Cloud's speech-to-text service to assist us in processing and carrying out your commands. Audio recordings are shared without personally identifiable metadata, and we've instructed Google's service not to retain the audio or transcript associated with a command after it processes the command

<comment><USER13> It's in the FAQ section of the page under "How is my audio processed?"

</comment></comment><comment><USER14> I've been working on this exact thing for Chrome the last 3 years: [https://www.lipsurf.com](https://www.lipsurf.com) Anyone can make an open source plugin for it to do anything with voice ([https://github.com/LipSurf/plugins](https://github.com/LipSurf/plugins))

I've wanted to port it to Firefox, but the HTML5 SpeechRecognition API ([https://developer.mozilla.org/en- US/docs/Web/API/SpeechRecog...](https://developer.mozilla.org/en- US/docs/Web/API/SpeechRecognition)) is still not available. Why not just make the API available and leave this in addon territory for all developers?

<comment><USER15> I built something like this 7 years ago, it's called Hands Free for Chrome, a now languishing project that I lost interest in a long time ago, unfortunately. It made the top 10 of HN back then though! My site's design is not nearly as nice as yours.

[https://www.handsfreechrome.com/](https://www.handsfreechrome.com/)

I just didn't get enough users or support to really care about it. But I wish you the best. It was an exciting thing to build and using it always felt futuristic to me.

This is just so fascinating though. It's like seeing what could have been if I had been a better developer and found the dedication to really stick to the project in the longterm.

Edit: I see we had the exact same idea! Your "tag" is my "map." Love it. One big difference is that mine was just a free project. I'd be super interested to know how many users you've got. I never had more than ~1100. From looking through your website mine was a much less intensive project. (Oh, CWS says 4000+ for you....wow, wonder how many are paid.)

Edit2: Looking over your update history is almost nostalgic. "Fixed issue with overlapping commands -- delaying commands that are partial matches of other commands." Had to do the exact same thing!

Edit3: We have so many overlapping command names that I wonder if you took inspiration from my project, almost. Either that or it's just a case of convergent evolution.

Edit4: Suggestion for dictation: a way to alternate between a special character and actually writing the word. Doesn't look like there's a way to do ^ vs carrot or & vs ampersand. Something like "Enter special character caret". Maybe you already have a plugin for this though, idk.

Edit5: God, this is so well architected! plugins and contexts are just fantastic ideas for this domain. Click by voice using hidden search-for-text is also a perfect solution to that problem. I wonder if this could be made more intelligent, i.e. "Click Submit in the sidebar on the left"\-- challenging though.

Edit6: Wow, just noticed someone else built something called "Handsfree for Web" somewhere along the way and theirs is ALSO way better than what I had built. Geez. Starting to feel bad about my awful website.

<comment><USER14> Never saw yours before, but I discovered "Handsfree for Web" a few months after I started - and thought he had ripped mine off. But I no longer think so. Yes, seems like many commands are the same. Shame that so much wheel reinvention is going on. One thing that makes LipSurf "special" is the deep integration with sites. I wanted to use Duolingo, Reddit, HN and some others more with voice - so they get special plugins. Doing Duolingo with voice is a game changer for language learning - and if it weren't for usecases like that I would have likely lost interest like you long ago.

<comment><USER16> I want hands free for CAD.

Imagine being able to vocalise and build a model.

I did have a HN user who said they be happy to collaborate with me to build it but I dropped the ball and have since killed that email address.

<comment><USER17> If you manage to get into the GPT-3 beta, I'd love to work on that with you :D.

For simple models, English -> OpenSCAD sounds like it's doable given the things I've seen on Twitter and for normal modeling, GPT-3 would probably make an excellent intent recognizer for voice commands.

<comment><USER16> How would I go about looking in to this?

I'm a metal fabricator by trade but also technically minded, AutoHotKey scripts for a few things and can very basic Python and C# if I need to.

I tend to learn in a very _solutions oriented_.

And would be keen to collaborate / learn / skill share.

<comment><USER17> The GPT-3 beta is something every programmer and their dog wants to get into these days and most of us can't. It's a really impressive new language processing neural network that people have managed to train to (among many other things) generate code from an English description of the program. If it can do that, it might be able to generate some reasonably complex Constructive Solid Geometry models and even something like MEL commands in Maya.

Greg, OpenAI's CTO, occasionally manually lets people in if they convince him of their use case (or, as one guy did, plant a bunch of trees in his name) in an email (firstname.lastname@example.com). It might be worth shooting him a message explaining the idea. From what I've heard, once you have a key, it's mostly a matter of feeding the model examples until it does what you want.

</comment></comment></comment></comment></comment></comment></comment><comment><USER18> You should try rhasspy. It's open source. It respects your privacy by using offline services. Fully customizable (each service can be replaced by another) All the services are containerized for easy installation and is available for several architectures such as arm ( on a raspberry pi). There is even n Option to use Mozilla deepspeech tts service.

[https://rhasspy.readthedocs.io/en/latest/](https://rhasspy.readthedocs.io/en/latest/)

</comment><comment><USER19> "We've instructed the Google Speech-to-Text engine to NOT save any recordings."

Hahaha! :D Thanks for the good laugh.

<comment><USER20> Bigger players have the leverage to get companies to do something they don't do out-of-the-box. They can contractually oblige them to do that, as well as sue each other if one side breaks its part of the deal.

<comment><USER21> If they could guarantee Google doesn't, they'd say that. Thus the much lesser claim "instructed" which carries no such assurance.

I agree with and applaud their truthful choice of words. There's _no such thing_ as "contractually oblige".

// To keep yourself cognitive, consider one party receiving a National Security Letter ("NSL") with gag order.

</comment></comment></comment><comment><USER22> I guess Mozilla's own speech to text ([https://github.com/mozilla/DeepSpeech](https://github.com/mozilla/DeepSpeech)) isn't good enough, so they have to use Google's?

<comment><USER23> Presumably the reason they want you to opt-in to saving recordings is so they can train DeepSpeech.

<comment><USER24> But DeepSpeech has already been trained with millions of data samples!

I'd feel way better about it if they went for a slightly worse DeepSpeech based implementation, but kept it working in the free software spirit they have been known about for many years.

Also, for desktop devices inference on DeepSpeech is cheap enough, so they could even go the extra mile and work on some Wasm magic to get offline recognition.

That's the kind of work I'd expect from Mozilla! Not wiring up your data collection to the Google Cloud APIs and call it a day! I'm genuinely disappointed with them...

<comment><USER11> The audio Mozilla DeepSpeech is trained on is not very large (about 2000 hours) or diverse (eg: mostly native American English Male voices) and has very little ability to handle noise, accents or other errata.

Comparatively, Baidu had 5000 hours of English to train their versions of DeepSpeech and DeepSpeech2 on, and thus had better results years ago. Google, Microsoft, IBM and other companies have users providing more audio samples on a daily basis, enabling much better quality speech to text.

Mozilla's Common Voice project only has 1492hrs of validated English currently: [https://commonvoice.mozilla.org/en/datasets](https://commonvoice.mozilla.org/en/datasets)

</comment></comment></comment></comment><comment><USER25> Mozilla needs to come more around to Apple's way of thinking. These things need to be done locally on the device, not farmed out to some cloud. Use the cloud (CDN) to deploy the software, but run the software locally.

</comment><comment><USER20> Alright, gave it a shot. First impressions:

* "Make me laugh" always brings me to the same YouTube video.

* Had pretty much no issues with the default prompts. It was able to find some challenging Spotify playlists, open random websites (including non-standard English domains ones when I spelled them out).

* "Read this page" uses an awful TTS engine, which is a shame considering that I might actually use this feature on a somewhat regular basis. I'm assuming it uses whatever it detects on the OS level, and so far I haven't bothered with finding a better one (on Ubuntu, if you know of one, please suggest).

* "Set a timer for X min" works just fine, which is probably the only thing I use Google's assistant on my phone (or whatever it's name might be now).

* I like the idea of routines in the app settings, which is supposed to tie multiple queries together. I could see myself using it for something like a morning routine (tell me what time it is, give me weather info, read me news, etc.)

<comment><USER26> I tested the phrase "go to kyle's channel on twitch" and it actually went to twitch.tv/kyle - which I found impressive.

</comment></comment><comment><USER27> Google-worries aside, judging from the preview it's pretty slow. I'm not a super-fast typer, but these delays sure look like something that would discourage me from actually using it. Maybe it's not even that it's slow, just that the delays are super-obvious somehow, all these disruptive animations and such.

</comment><comment><USER28> Speech to text in the cloud is a hard no from me. Especially if it's Google's speech to text.

<comment><USER29> Don't worry, it says they asked Google to not save everyone's voices!

On a serious note, it does bother me how much Mozilla constantly uses Google, even when they have their own solutions They could easily choose not to, especially with their massive budget, but often don't. They have their own Voice API, but they use Google's. They have their own location API, but they use Google's ('use my location' sends your info to Google in Firefox). They have thrown Google analytics into browser components before, and used it on their own websites.

<comment><USER30> Agree, though Maybe google is giving them free/barter compute credits?

</comment></comment></comment><comment><USER31> I don't understand the utility of it. Yes, I can see how this might be considered cool and hip, but.. which my problem as a user does it solve, exactly?

<comment><USER32> Speech-based control is almost mandatory for people with various disabilities (the blind, those with hand-movement problems/disabilities) and the elderly, a huge chunk of the population.

</comment></comment><comment><USER33> So do I yell out my password to log in to websites?

<comment><USER34> I mean, who doesn't?

</comment></comment><comment><USER35> Voice browsing on Windows is exactly what I don't need. I'd have a lot of use for being able to search the internet by voice and have the browser read an article to me while my phone is mounted to my dashboard. Without having to configure my whole phone for visual impairment, that is.

</comment><comment><USER36> I actually tried this with Siri while cooking yesterday. It's not there yet but I asked "Hey, Siri ... read me the synopsis of the movie Adam's Rib" and Siri proceeded to read a short synopsis of that movie. It worked on another but had to make me choose one of 7. It failed on the 3 try where I tried another movie, it gave me selections, when I picked one "read me the first one" it just repeated the title instead of telling me the synopsis.

</comment><comment><USER37> Is there a preference to have text to speech via another service provider?

</comment><comment><USER38> Google charges 2.4 cents per minute for STT so there's no way Mozilla could afford to offer this service if it actually got popular. I mean, that obviously won't be an issue, but still.

<comment><USER23> Maybe the long-term plan is to run the trained model locally?

</comment></comment><comment><USER39> > When you make a request using Firefox Voice, the browser captures the audio > and uses cloud-based services to transcribe and then process the request.

Is it that hard to do local processing, either due to computational power or storage requirements? Or is it just more convenient for them to do it this way?

Edit: this comment in another subthread kind of answered the question: [https://news.ycombinator.com/item?id=24098950](https://news.ycombinator.com/item?id=24098950)

If I'm drawing the right conclusion, it's a bit of both: hundreds of megabytes of storage is fine for most people but not everyone, and while I probably wouldn't listen to the latest and greatest artists (and binary diffs are a thing, small additions aren't that large), it is convenient for devs to just push it to a server and be done rather than pushing model updates to everyone all the time.

Edit2: [https://news.ycombinator.com/item?id=24096836](https://news.ycombinator.com/item?id=24096836) Wait, what?! The data is all sent to Google? I was thinking of using this for their sake (opting into using my data for common voice) but this is an instant deal breaker.

</comment><comment><USER40> The default keyboard shortcut wasn't working and it was opening a different extension instead. I went to the voice extension settings and thought it was bad ux how you have to enter the case-sensitive keyboard shortcut names instead of pressing the keys to read the keys.

</comment><comment><USER41> Recent HN thread _Thoughts on Voice Interfaces_ [1] about a blog post by one of the Firefox Voice engineers.

[1] [https://news.ycombinator.com/item?id=24040539](https://news.ycombinator.com/item?id=24040539)

</comment><comment><USER42> No one here has mentioned this.

But I believe speech recognition will not take-off until it understands whispering speeches.

Vocal chords strain makes current solutions unsustainable for continuous usage

</comment><comment><USER43> The Google Recorder app on Pixel phones (and I'm pretty sure general Android release) does super accurate on-device transcription, for what it's worth.

</comment><comment><USER44> Dupe? [https://news.ycombinator.com/item?id=23904846](https://news.ycombinator.com/item?id=23904846)

</comment><comment><USER45> I am a Mozilla supporter so I am happy to support this.

</comment><comment><USER46> I still haven't understood how any of this is an improvement of a shell.

</comment><comment><USER47> Opera had this a decade ago. RIP

</comment><comment><USER48> Whats wrong with deep speech?

<comment><USER49> DeepSpeech is too large to run as a browser extension.

<comment><USER48> Have they tried nanonets?

<comment><USER50> Googled those, and it looks like some company selling remotely-running models, which I think is what GP was referring to. Is there another technique that's been SEOd out by this company?

</comment></comment></comment></comment><comment><USER51> So let me get this straight. They break global keyboard shortcuts, which people could use to play/pause media on different websites three years ago:

[https://bugzilla.mozilla.org/show_bug.cgi?id=1411795](https://bugzilla.mozilla.org/show_bug.cgi?id=1411795)

and instead of fixing that, they introduce this shit? Fuck Mozilla. I am already using Waterfox, looks like that wont be changing any time soon.

<comment><USER52> Unless they only have one engineer, adding a new feature is not at the expense of fixing one bug.

<comment><USER53> Yet somehow they haven't allocated 1/N engineers to fix a 3 year old accessibility bug.

<comment><USER54> Whether they are non-profit or not, they still run like a business, and the business decision to allocate resources are likely to use the same metrics as any other businesses - maximize profit protential (however you define it).

It may just be that fixing accessibility bugs just doesn't produce much "profit".</comment></comment></comment></comment>


How To Find Every Single Vulnerable Website - <AUTHOR> http://blog.nerdydata.com/post/57544050832/how-to-find-every-single-vulnerable-website

<comment><USER2> What a wasted opportunity. They have a good, linkbait worthy title yet _it looks like_ there's not a single actionable link back to their search engine. Upon closer inspection, the links are there (they are the images) but as a reader, I expect that when I click a link labeled "Click image to expand", that the image gets better. That's not what happened - I was taken to the page showing the search. Why not just have the link to the site visible and easy to see?

I'll let someone else talk about the tongue-in-cheek attitude of "Our search engine is what you should use to do harm to others. We think that's pretty cool and want to encourage you. Here - have a tutorial that will make it easier for you!"</comment>


Code Club – inspiring a new generation of programmers - <AUTHOR> http://successfulsoftware.net/2013/04/19/code-club/

<comment><USER2> This is an awesome idea! As a university student I'm trying to get involved in code club. We need to get kids hooked on programming early; make them realise that it can be a fun, creative activity and a way to express themselves.</comment>


Grow your online presence starting today - <AUTHOR> https://gumroad.com/a/238777459/PBkrO <comment><AUTHOR> I created my profile on Twitter in 2015 but until recently I have been just a consumer of content on the platform. I never posted anything and didn't understand the importance of giving it back to the twitter community.

Around two month back, I started following this person Daniel Vassallo who had quit his 500k job at Amazon in Feb 2019 as he had lost motivation at his job. Since then he has grown his twitter profile from 150 followers to 35k followers in little over an year.

It's amazing how one can influence people by providing valuable content on Social media. And in the process of creating content, you'll learn a lot yourself. Its unbelievable.

Daniel has a course on Gumroad where he explains how he was able achieve this by building his credibility.

I bought his course and absolutely loved it. After buying this course I've been a active content creator and I'am friends really great people.

I just wanted to share this with Hacker News community if someone is interested to grow their online presence as well.

Here's is the course link: [https://gumroad.com/a/238777459/PBkrO](https://gumroad.com/a/238777459/PBkrO)</comment>


Ask HN: Good online link checker? - <AUTHOR>

I need a way to spider my clients' web sites and check for bad links.   What works? <comment><USER2> Sorry, this one isn't online but I use it as a Windows app (in parallels). Its free and very good: <http://home.snafu.de/tilman/xenulink.html></comment>


Be nice to programmers - <AUTHOR> http://edu.mkrecny.com/thoughts/be-nice-to-programmers <comment><USER2> The punches are pulled in this piece. Not only is the compiler continuously complaining, once you ship code, your customers call in to complain about every conceivable bug and a great deal that weren't conceivable. You can have thousands of happy customers, but you as the developer will hear from the three guys with obscure configurations and bizarre setups encountering bugs. Shipping software is ten seconds of "Hooray", followed immediate by a breakdown of what terrible things are already wrong with the next release.

I'm surprised any of us can hold up under the withering torrent of negativity that is any serious programming job.

I actually don't mean this as a complaint, either. I've adjusted. I've been doing this for 15 years. But I've been sort of stepping back lately and looking at my job from other points of view, especially as I deal with coworkers who aren't so adjusted/adapted, and not only do I now understand where they are coming from, I find myself wondering how adaptation is even possible. It's absurd how negative the interactions are. Keep track someday of your professional interactions and look at how many of them are negative; bug reports, missed deadlines, "we can't do that", etc. Or perhaps, don't, if you've never thought about this before. I sure hope you have an otherwise positive workplace.

<comment><USER3> Ha. I'm a sysadmin.

Do you know when your sysadmins are doing the job right? When you don't notice.

The only possible way for a sysadmin to get noticed is to screw up.

<comment><USER4> The sysadmin cycle of life is to get hired then spend several years fixing, consolidating and automating until someone decides they don't need to keep paying a sysadmin "for nothing".

<comment><USER5> No, that's a good sysadmin. Bad sys admins are indispensable.

</comment></comment></comment></comment><comment><USER6> I get what he's saying, but I think he answered it himself, when he questioned if he was being overly dramatic. He is being really over-dramatic.

I would love to hear about any occupation where the negatives aren't run into in a similar way that he describes programming.

That being said, the one thing that I dislike about programmers in general is that I think we believe we sound smarter if we figure out ways how an idea won't work. It's annoying when you come up with a new idea, and all you hear is a litany of reasons why it won't work.

The most important lesson I learned was soon after I had moved to the Valley, and I gave a suggestion to one of the senior engineers. Instead of shooting it down immediately like others loved doing, he simply said something like "Okay, I'm not sold on it but give it a shot." I had been prepared for a lengthy argument over why my idea was good, and I was taken aback at his immediate open-mindedness. It's something I've taken to heart since then.

<comment><USER7> I'm not sure that specifying how things won't work is done to appear superior rather than giving feedback. There probably isn't enough time in a day to try everything and if you can save some time by pointing out why something won't work off the bat it's probably a good thing. As with everything though, it kind of comes down to how you communicate that something won't work.

<comment><USER8> It also comes down to being right about it. It's often much easier to write something off ("that won't work"), than to accurately assess the reasons why it may not work, and possibly be part of modifying it so that it will. That difference is also subtle (just as subtle as the presentation in many cases), but also very important.

</comment></comment></comment><comment><USER9> There is nothing intrinsically negative about _anything_ said here, just neutral things viewed in an extremely negative lens. Here's the exact same set of steps making up the "normal workflow", but framed as a positive feedback loop:

      1. write some code
      2. run the code
      3. get further than you did before (perhaps with a new error message)
      4. decide what's next and go back to step 1

I don't think negativity is intrinsic to the profession. I get to build things every day. I get to fix problems. That's an incredibly satisfying and positive thing.

<comment><USER10> That reminds me of an old story about how different people can look at the same job in different ways:

A man came across three masons who were working at chipping chunks of granite from large blocks. The first seemed unhappy at his job, chipping away and frequently looking at his watch. When the man asked what it was that he was doing, the first mason responded, rather curtly, "I'm hammering this stupid rock, and I can't wait 'til 5 when I can go home."

A second mason, seemingly more interested in his work, was hammering diligently and when asked what it was that he was doing, answered, "Well, I'm molding this block of rock so that it can be used with others to construct a wall. It's not bad work, but I'll sure be glad when it's done."

A third mason was hammering at his block fervently, taking time to stand back and admire his work. He chipped off small pieces until he was satisfied that it was the best he could do. When he was questioned about his work he stopped, gazed skyward and proudly proclaimed, "I'm building a cathedral!"

<comment><USER11> But this isn't what the piece describes. The author is talking about the _feedback_ one receives while doing work. Take the 3rd mason and start giving him a list of what's wrong with the work he's doing every day until the cathedral is built, and see what happens. This stonemason example, while touching and certainly applicable to some situations, is just too far removed from the reality of what many programmers experience to be relevant here.

<comment><USER10> I was addressing what the parent comment (from peeters) insightfully observed about the original article's four-step workflow description: getting to the next bug and fixing it could either be thought of negatively ("damn, I have another bug in my code") or positively ("I've solved this problem and made some forward progress"). Whether you find this negative or positive is a function of your mental state.

This is analogous to the mason's iterative workflow: noticing that his stone doesn't yet fit quite right and chipping a bit more off the side until it fits perfectly.

During development, most of our daily feedback comes from the code itself, not from people yelling at us about how broken it is (although that does happen sometimes).

<comment><USER11> The author explicitly says that fixing bugs feels good. But the point (as I see it) is that the workflow often obscures the larger positive goals of the endeavor and tends to burn people out, and that's a net negative. You can argue that it shouldn't, but I don't think you can argue that it doesn't.

Everyone wants to be that 3rd happy mason. But that story doesn't tell you how to do that, it just suggests that it's a better way. Saying that it's just a function of your mental state is tautological.

<comment><USER12> The story tells you explicitly. Don't stare at your watch, think about the product vision.

Every day I go to work to fend off spies who want to steal your data. Protecting the powerless, defending your freedom! I will never meet you, and I will never even look at the treasure I am defending, and most of time is spent fixing broken configs, but I am doing it for a good cause, and at the end of the month I enjoy my paycheck too.

</comment></comment></comment></comment></comment></comment><comment><USER13> This brings up an interesting concept. All great creators (artists, programmers, woodworkers, hairdressers, etc) tend to be more pessimistic than optimistic. If you attitude is "Wow this program I wrote is totally awesome, I deserve a pat on the back", then you'll never improve upon your program and you'll end up never improving your skills and will end up a rosh katan[1]. You have to be the kind of person who sees each of your creation in a constant state of less than perfect in order for you to act upon making it better.

Interestingly enough, people on the other end of the spectrum (sales people, executives, marketing people, etc) have to be the opposite. You can't have any doubts about the awesomeness of the product. Doing so would be counterproductive.

[1]<http://www.danappleman.com/index.php?p=31>

<comment><USER14> "I deserve a pat in the back" is not an optimistic attitude... It's self- indulging, that's all.

Optimists see bug reports as a way to improve things. Optimists bet on early tech because they see a bright future ahead (rails 0.9? ios 2.0?).

Being pessimistic will only feed your ulcer...

<comment><USER15> I definitely agree with you on this. Optimism and arrogance are vastly different.

</comment></comment></comment><comment><USER16> Among all the non-programmers I've talked to about work, I've never found one who doesn't have to deal with some sort of constant, repetitive negative feedback. Teachers have to deal with some kids that simply won't stop acting out, and who continually perform poorly on assignments (not to mention parents happy to tell them everything that the teacher is doing wrong). The salespeople have countless deals they fail to close. The manager has to make painful decisions about other peoples' livelihoods, and absorb the criticisms coming down from higher up the chain. The artist has to deal with everyone being a critic, and doesn't have the luxury of dealing with things that either work or don't work, it's all subjective. The doctor can't cure everyone. The lawyer can't get justice for everybody. The data-entry clerk peon has to ignore that they're completely replaceable and that they'll probably be replaced by a computer sooner or later. Anyone building anything (not just software) has to deal with the reality that 95% of the time, it's not done yet, and you still have more work to do and things to fix.

That's not to say that some people aren't going to be happier in certain fields than others, or that some subsets of the field fit some mindsets better than others, but software is pretty good work. The article acknowledges this right up front, and then ignores that to dwell on the negatives. It blew my mind a little to see such a negative perspective. If I fix a simple bug in my code, it doesn't bother me much, because I know I sometimes make mistakes. If I find and fix a really interesting subtle thing, then it means I learned something new, and that the product is now in better shape than it was yesterday. If there's a usability issue, it's an opportunity to figure out a new way to do it. And all the while I have the constant positive feedback of knowing that this thing that I built is _doing something_ , I can directly _watch_ it do that thing, and that it's being used by people to get stuff done.

Unless you build everything exactly right the first time, and never have to deal with external changes that mean the software needs to change, you're never going to be free of negative feedback. So you should start looking at why you're letting the negative parts drive your attitude.

EDIT: My own personal idiosyncrasy is that I get very suspicious, maybe even paranoid, about a complex task if everything seems to work right the first time and I don't have a few cycles of negative feedback. I know it's complex, and so I don't expect perfection out of the gate, so a few runs through the "fix one thing, find another issue" washer are oddly reassuring to me. Even though rationally I know that fixing things I knew to test for doesn't mean it's any less likely that there are errors in the things I haven't thought to test.

<comment><USER17> I agree with you. I feel like this article is pretty melodramatic. I've been a (professional) programmer for the better part of 10 years and I've had my share of ups and downs, but this job is definitely a very, very good one. The sheer amount of freedom we get from a) the good pay and b) the fact that programmers are so in-demand right now that companies bend over backward for us really can't be matched in many other jobs.

The lamenting in this article is from somebody with very little perspective on what most people have to do just to survive.

<comment><USER18> I think these are two different things. It can still be a nice job to have, even if the process is broken. Writing reliable code is hard, probably harder than it should be. Just look at the amount of software with security holes[0] and/or performance issues.

[0] <http://www.exploit-db.com/>

</comment></comment></comment><comment><USER19> It's times like these I'm thankful for a life lesson I was taught about 4 years ago.

I'm not a professional coder, but I do a significant amount of hacking and coding for one of my research fields (Computational Economics). I noticed this cycle too--this cycle of focusing on the negatives. It really did bring me down.

I chatted with my adviser, who was married for a number of years to a child psychologist. She recommended to him that every time he accomplishes something small, get up and walk around. Do something small to reward yourself. Then, get back to coding. This inserts a positive stimuli in an otherwise negative feedback loop. The more bugs you solve, the happier you are.

I've found this to be very helpful for me. Hope if helps some of y'all too.

<comment><USER20> I do this with things like Hacker News.

The challenge lies in getting motivated to go from the reward back to the work. :-)

</comment></comment><comment><USER21> Taking the time to do postmortems can help.

My partner and I just had our first iOS game approved. We had to ship without a bunch of features we had planned for (e.g. non-English localizations) simply because we ran out of time. During the final stages of the project, we thought we'd like to do something like a web-comic, to share the human story behind the development of the game. Now that the game is approved and we're reviewing our notes and drawing the comic (it can be loaded dynamically into the game as a slideshow, and it will also go into our facebook page/company blog at <http://noisytyping.com>), our view has shifted from 'we could have done better' to being very pleased about the whole journey: how we started out, what challenges we faced (automating level-generation was one) and how we managed to stick to our plan and ship it. Without the postmortem, we'd probably never be motivated to make a game again.

</comment><comment><USER22> I went to a tradeshow for my company a few weeks ago, where I got to just interact with potential customers all day. I had an absolute blast, by the end of the day where the other folks on the team were tired and ready to leave (I was the only developer), I was pumped and already thinking of how to come across even better to clients at the next day of the show. It made me realize how programming has adversely affected my demeanor and way I interact with people.

I realized that not so long ago, I was actually outgoing and cheerful most of the time, but programming has made me more surly and sometimes reactive in an insidious way. With programming you're always dealing with problems, and if you're not solving them in code, or being infuriated by something that you thought would take 30 mins but has blown your entire day, you're dealing with people problems.

"Why isn't this done?", "Why should we pay that much?", "When is it going to be done?", "How long do you think its going to take?", "Why is it going to take that long?", "Can you just squeeze this one thing into the iteration?", "That sounds easy", "Why is this broken?", "Who broke it", "Why can't you just code", "You ask too many questions" ... aaaaaack.

its just this steady barrage of crap you have to deal and you're usually the one saying "no", "we can't do that", "Why do you want to do that?" to where you just become this proxy for negativity even if you don't want to be, because ultimately you're going to be the guy cleaning up the shit when everything explodes because nobody thought to figure out how to do the whole thing properly.

Unless you're working at a real top notch engineering place, where half these questions don't come up or the top brass understand how the whole thing works, it can really mess with your attitude.

When I had that epiphany after the tradeshow, it really freaked me out to realize how professional programming was changing my attitude to people and life, so I don't think I'll be doing 100% development for much longer.

<comment><USER12> Need more quality time walking, talking, and talking to people.

</comment></comment><comment><USER23> _Hour by hour, day after day, I do this. Always searching for what's wrong with what I'm creating, rarely thinking about what's good about it. It's a negative reinforcement feedback loop._

"Dude, you're so lucky to be a master sculptor. Always hanging out with famous models and actors who want nothing more than to strip for you. Your works will be celebrated for more than two thousand years. I wish I could do that."

"Actually being a sculptor is making me pretty miserable."

"Woah, dude. What do you mean?"

"Hour by hour, day after day, I do this. Always searching for pieces of stone that don't belong, always trying to remove the elements that aren't part of my work, rather than being able to focus on the stone that remains. I can never truly build anything, only erode. It's a negative reinforcement feedback loop. I think I'll try watercolors next."

</comment><comment><USER24> This guy has not discovered what it means to be a programmer, he is simply in a phase of his programming life. Chasing down bugs all the time? Why? I don't do this, and when I run across a bug it is usually a quick fix and not a big deal.

The goal is not to write it perfectly without bugs. The goal is to release it perfectly without bugs, and to do this all you have to do is test your code often as you make changes to it. (alt tab || cmd tab is your best friend)

Now, if you are running into bugs that take you 4+ hours to resolve, you simply have not been programming long enough. Over time these will be trivial issues for you.

What is amazing about being a programmer is the ability to create amazing things. Being a programmer is not awesome because writing conditionals and for loops are badass.

<comment><USER25> Sounds like you've never been tasked with working on a huge base of code you'd never seen before. If all I ever did was work on code I wrote, I could see myself thinking like you do.

This is not the case for a lot of people. Maybe in this HN startup bubble, but not in the "real world" of software engineering.

<comment><USER24> That is a good point, but I do have the perspective you talk about. I started out at a web shop for 4 years, so I'd spend a lot of time in other peoples code. I then moved on to a nice little SaaS company with a 10 year old code base which had a bunch of legacy code that I had to deal with when first starting out. I had to pick up a variety of languages that I had not used professionally before. I have spent 4 years there and am leaving at the end of this week to start my first company.

But my belief is the same, the solution to the problems described in the article is time/experience, not the adoption of some pessimistic mindset. You will run into bugs when working in other peoples code, as a result you will learn not to make those mistakes. Over time you will get quicker at identifying similar bugs and will be able to resolve them quicker each time as well.

The most common answer to any CS question that you are asked in college is "It depends". So how do you resolve these nasty legacy code bugs? Well, it depends. Is this code reused a lot in other places? Is this critical functionality to the user? Once you determine how important the buggy code is, you can decide whether to solve it with a hack or a well thought out solution.

Don't sweat the bugs, don't become a Debby Downer, fix them as they rise, and keep building cool shit.

</comment></comment></comment><comment><USER26> For me, this cycle is a different one:

(Step 0 is possibly 'get a bug report')

1\. Write a test

2\. Watch the test fail

3\. Write code

4\. Watch the test pass (if fail, goto 3)

5\. Make the code pretty

6\. Watch the test pass

7\. Repeat

Instead of negatives, you're looking for positives. At the end you're rewarded with nicer code than you started with and green lights all the way down.

It's all about how you frame it - why would you frame the activity you spend most of your life doing negatively?

<comment><USER27> >6\. Watch the test pass 7\. Send it to QA. 8\. Everything is wrong and this isn't what they asked for (it is but that's not what they MEANT) 9\. Goto 3

<comment><USER26> No, you GOTO 1, and write new tests that match better. Just because you have a dysfunctional organization that doesn't let QA and development talk doesn't mean that's how it has to be.

</comment></comment></comment><comment><USER28> The question is not "What's wrong with this?" The proper question is "How can I make this better?" He's adopted a negative mindset by choice, whether he realizes it or not. That's not even what really grinds my gears about this post.

The really bad part of this post is the implication that this mentality (whether one takes the author's negative point of view, or my slightly more positive interpretation) is endemic to software development. It's not. Asking the question, "How can I make this better," ought to be a fundamental part of one's daily routine. Had the author adopted this mentality in general, he might have noticed a flaw in his workflow:

1\. Write some code

2\. Run the code

3\. Get an error message

4\. Find the error and back to step 1

There are some critical steps missing. A more appropriate approach would be:

0\. Think about what I'm building

1\. Write some code

2\. Run (Test) the code

3\. Get an error (of some sort)

3.5 Think about what might have gone wrong and verify it

4\. Go to step zero.

That's right, when you find an error there are two distinct thought processes involved. First you think about what might have gone wrong. This would be the forming a hypothesis step of the scientific method (I've lumped testing into step 3.5 so as not to stray too far from the author's initial workflow, but suffice it to say that testing should be a recursive call to this entire process). Once you've discovered the source of the error, it's time to consider how best to fix it. Yes, more thinking. Only then should one go back to writing production code.

Sadly, I don't think the author's method is that rare. I had a professor who referred to the write/run/test/fix method as the original genetic programming. I think that's a fair statement. The problem with this method is that one ends up with a system that may work, but with no deep understanding of why it works. Absent that understanding, it will be more difficult to improve (fix) the system.

God help the next poor soul (aka the author in six months) to work on the system. Therein lies the negative feedback loop.

</comment><comment><USER29> I think one way to help fix this negative feedback loop is to use the advice of the Harvard Business Review's article "How Customers Can Rally Your Troops" (src: [http://hbr.org/2011/06/how-customers-can-rally-your- troops/a...](http://hbr.org/2011/06/how-customers-can-rally-your-troops/ar/1) ). The premise is that consistently showing your employees proof of the positive effects your organization's products produce for end-users can drastically improve motivation. I just linked to the abstract, but the full article goes into the dramatic effects this technique had on a university fundraising call center (a job with constant negative reinforcement).

<comment><USER10> Positive feedback is definitely important. As developers, we very frequently hear about things that have gone wrong but we're only rarely told about how what we did resulted in success for the company.

</comment></comment><comment><USER30> After being a programmer for 20 years, I never thought of it that way. I think it is one of the better jobs out there, and I've always considered myself fortunate to be able to make a living that way. I will say, however, that spending the last 5 years working as at technology director at a school has been more rewarding, but it is not so much the kind of work I'm doing, but that I really value this school and the work they do. I feel privileged to be a part of it. In fact, the most difficult thing I dealt with in my programming career was not the work of programming, but working for companies where I did not always believe in the product.

</comment><comment><USER31> Yea I got over that. Shit happens. Don't sweat the small stuff, yada yada yada. Besides when you fix it everyone lights up. It's the closest thing I've seen to a performer doing some amazing stunt with me being the amazing person. Focus on that, and not so much on that it broke. The difference between developers and non-devs is we can fix it, and that's really cool power. This article is almost like Wolverine complaining about his super powers being lame and always having to save the day. YOU'RE WOLVERINE STFU!

I think after being a programmer I have changed my outlook for the better because I realize what's possible instead of being trapped by other people's ideas/mistakes. I see how things are connected and if I changed this or that how it changes our limitations. Anyone can say "What if" very few can "Here's how." And that is really empowering and liberating.

I suppose when I was younger I was negative I wanted everything to be perfect like it couldn't be, but as I matured I see bugs, missing features, bad design as just opportunities and not the end of the world. Being late, bugs, complaining users, whatever it just doesn't bother me.

I'm not tuning them out just choosing to listen to what's really important and cutting through the bull because I expect all of it to happen. We're late ok I'll work a little more realizing I can really only make it about 10% faster, there bugs give me a reproducible test case and I'll fix it, users bitching reach out to them personally and find out what's the real problem.

And just like anything else in life, whether it's programming, football, music, or ditch digging, your attitude is your choice. The difference came when I chose to be positive...and laugh a lot more at all of the irony, bad choices we make, and gotchas that always creep up. Laughing really helps.

</comment><comment><USER32> I have a very intelligent friend who try as he might cannot learn programming. He has interests all over the academic board and teaches two unrelated courses. I think I understand now why he cannot. He's an eternal optimist. I tell him he's selectively ADD about programming, but maybe he's just allergic to the negativity of it all.

<comment><USER33> He can't be that intelligent if he is externally optimistic about everything. Part of being smart makes you aware of the negatives of everything.

<comment><USER34> Sometimes I feel like people are starting to go out of their way to make it onto the "Shit HN Says" Twitter stream.

</comment></comment></comment><comment><USER35> This is awfully melodramatic drivel. If you don't like what you are doing then stop doing it.

</comment><comment><USER36> I've been through this myself. I realised that the problem was me, and the projects that I was working on. I was fortunate enough to be able to step away, then go and find work that IS rewarding (for me it's playing with the front end, where people play with the app and go "ooooh!" and "aaaah!").

The key for me was to document the things that I hated about the job, and avoid them at all costs, but to acknowledge that criticism is something that feeds back into an application improvement process. ie. Don't take it as personal that someone is criticising you/your work. Find methods of improving the communication channel so that you don't spend days/weeks coding only to find "that's not what I wanted! that sucks!"

I'm fortunate to have an ex hacker/programmer as my manager who knows/understands/addresses my needs very well in my current role.

At some point I stopped chasing the higher paycheck, because I recognised that with a higher paycheck comes higher expectations, demands, hardships. Look at it from the employer's perspective - "We could hire 2 graduates at your cost, at that rate we expect you to not make mistakes, and to get twice the amount of work done."

A friend earns almost twice as much as me, with similar years of experience, but he is expected to miss lunch, stay back until midnight, answer calls to China/India on a friday night. No please/thankyou/you're doing a great job. Just "do it".

Keep searching until you find the right role.

</comment><comment><USER37> What we have done and what happens to us all accumulates inside ourselves and becomes the basis of our future consciousness and state of mind. Peoples' minds and consciousnesses are comprised of energy. If we use the example of a lightbulb, the consciousness is most akin to an electrical wave produced by the generator and the mind is most analogous to the light radiated by the bulb.

If we work in such a way that produces high entropy codebases, hides problems instead of illuminating them, or produce (or have to work with) highly inter- braided (complicated) architecture with no way or occasion in which to improve matters, then it's easier for people to be caught by grudge at their employer, clients, or circumstance. People can be influenced by these bad circumstances to abandon themselves, and in doing so, their resultant ignorant behavior will make their mind mind become dark. This is a most dangerous circumstance for a human being to live in, so the task of the modern programmer is to find out what they have worth living for, to find a good self, and to protect themselves from wrong relationships and from destroying themselves (through loss of simplicity in one's life) such that they can effect their benefit for themselves and the world. Without individual awakening then it doesn't matter what profession they hold, they still can't guide their life properly. So the most important teaching for programmers to save their way of life is that they have to understand properly what life is, how great a teaching it is for us, and just how precious is the opportunity that we have been given through our lives as human beings.

</comment><comment><USER38> Being wrong is fantastic. You simply have to come to appreciate it. Every time you learn that you are wrong - and this applies for everything in life, not just with programming - you never have to be wrong in that way ever again. Not for the rest of your life, if you can remember, will you be wrong in that particular way. How amazing is that?

You're not 'focusing on the negatives', you're getting to be wrong, a fantastic opportunity. Most people don't get to be wrong. They persist in their wrongness and swim about in a sea of mediocrity with no sense of personal advancement. To get to be wrong on a regular basis is nothing short of exciting. Sure, others will misunderstand it. Managers and business types will not understand why you simply couldn't do everything flawlessly from the start and they'll try to give you a hard time about it. But it doesn't really matter. No matter how hard they push you, they can't make you think. No one can. It has to be undertaken entirely under your own will. And when you do so and come up with something wrong - you know you are actually guiding yourself to develop rather than stagnate.

Go on, be wrong! And then never be wrong in that way ever again!

</comment><comment><USER39> Apparently, I come off to some people as very pessimistic. I don't feel pessimistic but, as I programmer, I'm trained to focus on all the things that can go wrong and consider all the edge cases. This is a useful skill but can also be perceived as very negative even if that's not what I intend. Unfortunately, it's a skill that is also hard to turn off and ironically it's worse if I'm actually enthusiastic about something.

</comment><comment> AD-Edge Interesting post

For myself personally I feel the positive of making progress, or implementing that new feature, by far over-weighs all the little bits of negativity and frustration of a bug or error. Even if that implementation isnt 100% correct, its still satisfying to see something happening which takes you another step towards the goal. Sure it can be pretty destroying to get stuck on that one main problem for a long time, unable to find a solution and with a million errors being thrown, but then when that problem is solved the positive feeling can be even larger anyway, depending of course.

I find it unrealistic to expect it to be any other way, youre an imperfect human trying to design something so complex, within an environment that has zero tolerances for mistakes. Hell, if you even accidently capitalize a single letter somewhere in thousands of lines of code, the whole things going to fall in a heap.

So I cant say I overly relate to the main attitude of the article, as much as I understand what its saying.

</comment><comment><USER40> A quote from the article: "There's so much about programming that is incredibly satisfying and empowering. But it doesn't change the fact that, for me, programming builds an acutely negative mindset over time."

The author of these words seems to miss the fact that all systems that move from one state to another require "negative feedback", but the "negative" in "negative feedback" doesn't have the meaning he's giving it.

The author sees programming as emphasizing the fact that software is usually broken. I see programming as emphasizing the fact that that I can fix it, and once fixed, it remains fixed forever. Compare that to "fixing" relationships, or government, or nearly anything else one can name, _all of which respond to your efforts by getting worse_.

When viewed this way, programming is (like mathematics) an escape from a world in which efforts to solve problems are either ineffective or make the original problem worse. The fact that the end result might actually be useful to someone is frosting on the cake.

</comment><comment><USER41> I really don't know about this. For every bug I fix, there's a time I run the code after a change and the change does just what it was supposed to do. For every time a client complains about something that doesn't quite work yet, there's a time she told me how happy she is with what does work.

Is it really that different in other professions? Does the doctor always bring good news? Are all of the teacher's students bright chaps? Does the firefighter save each and every life? The lawyer win every case? The financial advisor always make a plus? Are a real estate agents' clients always happy with their sales price? Sure, there are lots of professions where there are rarely any negatives, say, a taxi driver, but is that a rewarding job?

I think this is really about your mindset. I often feel like a sculptor... I start off with something that doesn't look at all like the final product I have in mind, and over time I approximate the final result closer and closer. Error messages or not, to me that's just feedback, just like the sculptors' fingers find roughly hewn spots on the surface. Is the sculptor supposed to get mad at a little rough spot on his sculpture? Of course not, he just chips it away.

The one suggestion I have for programmers who are offended by error messages is to give TDD a try. With TDD, the test failures you get are to be expected: after all, you specifically engineered them to fail in the first place. So you don't have to feel bad about those, and you can revel in the positive feedback you get from a passing test. And if a test fails unexpectedly you can be happy that your safety net has actually done its job! I'm not being facetious: if you see error messages as negative feedback (again, I don't, but maybe you do) then TDD might just give you the positive feedback you've been craving.

Impatient clients with overblown expectations notwithstanding, but you get to pick those :-)

</comment><comment><USER42> Having the mindset that the mere existence of bugs constitutes a personal or professional failure is probably very unhealthy. Is this something developers experience? I've never felt bad about a bug before. I just go and fix it. No pain, just gain.

Breaking things and inconveniencing others are a much bigger drag for me. Those are the problems I stay late at work to solve.

<comment><AUTHOR> It's not that "that the mere existence of bugs constitutes a personal or professional failure".

Rather, in order to debug I have to go into negative mode. It's a mindset where I'm mentally combing over something, trying to illuminate everything that's wrong with it.

It's not even that important that it's your code. Focusing primarly on the good aspects of something is a healthier mental model - but not one that will get your code debugged.

</comment></comment><comment><USER43> There's some irony to be found here. More likely than not, someone just like the OP built the bug tracking app that encourages clients/customers/users to give negative feedback and report problems.

This is also highly apparent in social apps (e.g. Facebook, Twitter, Yelp, etc). We _encourage_ negative feedback when we give people a platform to do so. For better or worse, a lot of what we create is simply enabling the insatiable devil inside of people.

It sucks, but most people are unhappy and they will always look for another avenue to vent their frustrations. We just turned it into an easy-to-use textbox that's available 24/7.

You cannot expect people to be positive when the thing you gave them (seemingly, from their perspective) encourages negativity.

All that aside, you can't let people get to you. The world is getting increasingly judgmental and you just have to roll with the punches.

</comment><comment><USER44> Have you ever done fundraising for a startup? To raise 1m - 2m dollars, you will on average talk to between 20 - 40 different investors during the seed round. At least half of these discussions will end with a "no". This is not a good feeling, because this "no" represents someone who has the ability to enable your company, your co-founders, your vision, your dreams, and even your employees to have a future. Being told "no" is incredibly difficult to hear in the early stages of a building a company.

My point is that being an entrepreneur, regardless of your role, is not always easy. Controlling your own destiny means you get the good and the bad; you're never shielded from the stuff that's hard to swallow. While I feel for this particular situation, I don't think other roles in a startup have it any easier.

</comment><comment><USER45> This is exactly why I love test-first development for most (but not all) projects. Instead of code, run, bug.. fix, bug, fix, etc, I get to say "I want to achieve X!" and then strive towards achieving X. Rinse and repeat. A gross simplification but a test-first approach has made me a lot happier.

</comment><comment><USER46> I'm sad I can only give this one vote.

This theme has been on the tip of my tounge for a long time; in fact, I tell coworkers that I see every item that is in the ticket system, be it a bug or a feature, as a "delta", a change in the system to make it have some characteristic it doesn't have now.

I'll just say that stress management is one of the issues you must face if you're going to be an effective (and happy) developer. It's important to get exercise and take breaks, but it's most important to understand your sources of stress and deal with them. Sometimes you can take action, by say, getting a motorized standing desk and tall monitor arm to avoid pain. There are other sources of stresses that you just have to accept.

</comment><comment><USER47> I call shenanigans. If focusing on the negatives makes everyone miserable, explain to me why I turn the dial to the Car Talk guys to make me smile.

People who fix things can have a positive outlook on life, mostly because they improve and make the negatives into positives.

</comment><comment><USER48> Instead of submitting yet another bug report, you should totally submit a "bug" that is nothing but positive feedback.

A truly good product will have fans sending in messages and talking about the things they love -- make sure these comments make it to the developers too!

<comment><USER33> Yah, but you always get that one person who no matter how good the product is can find a way to rip it apart. It's really sad :(. However the person who wrote this is most likely a "bug fixer", I know a lot of programmers who's day is

* Make something * Meet about making something * Make something else * Go home

And they never see or hear about bugs :)

</comment></comment><comment><USER49> It is a different mindset when you are writing code and thinking 'Did I cover all the cases?' instead of 'What can go wrong?' For me, thinking about all the cases is a positive and fun thinking process, not a negative one focused on what can go wrong.

</comment><comment><USER50> It really seems to me that in general programmers have such an good life that they (we) have to find something to complain about. I'm not pointing any fingers, since I often have the same thoughts. There was actually a quite nice article on HN lately (I read it on Sunday, but my google-fu is failing me), something along the likes of "Why wouldn't you want to be a programmer?", which arrived to the same conclusion as I usually do after trying to compare it to many other professions in an unbiased way: overall programming is quite a sweet deal.

I have to admit though that I never held any other jobs, so I'm very interested in reading about the opinions of those that have.

</comment><comment><USER51> The same plight is shared by any creative person. If programming makes you miserable, you're doing it wrong. The feeling of sublime satisfaction when something finally runs and does what you expect far outclasses any transient misery inflicted by the terse crowing of the compiler.

Any path worth walking is fraught with forks that lead you through brambles and strife before returning to the main road. The painter seeks the one perfect brush stroke that comes next; the carpenter seeks the perfect arrangement of nails and dead trees. If there weren't a thousand thousand ways to do it wrong, it wouldn't feel so wonderful when you finally got it right.

This is a feature, not a bug.

</comment><comment><USER52> I can identify with some of what the author has saying, as I've struggled with a pessimistic attitude throughout most of my adolescent and adult life. However much of it was formed long before I learned to code. I've recently been working to be more optimistic as I think it can be learned.

However, I suspect pessimists tend to make good programmers rather than programming causing someone to become more pessimistic.

If you're interested in understanding some of the psychology between Optimism and Pessimism, I recommend reading Learned Optimism by Martin Selligman. <http://amzn.com/1400078393>

<comment><USER10> "However, I suspect pessimists tend to make good programmers..."

It might also be that pessimism could limit programmers' capabilities by making them afraid to take on ambitious problems. Being somewhere in the middle of the spectrum might make someone a better programmer than being either too optimistic or too pessimistic.

</comment></comment><comment><USER53> how do you create good and worthwhile things if you do not try and make them better? how will you make them better without finding the elements that can be improved and improving them? maybe this is part of the engineering mindset, the ability to approach the world with "how can I make this better" and not be depressed and overwhelmed.

I used to get super frustrated and depressed when people edited my writing/prose. each comment was some way in which I sucked. then I compared, side by side, my early drafts with finished works. now I'm not frustrated or depressed when people find problems with my writing! or my code.

</comment><comment><USER54> Perhaps it's all about context in terms of how you view how salient the negative feedback is. I can only speak of my experiences but I always found that no matter how frustrated I get while coding, the moment that everything finally functions releases such a dopamine rush that I quickly forget about the frustration. Perhaps two things (probably more) are necessary in order to overcome this negative feedback loop:

Learning how to let go of failures. Focus on the euphoria of fixing a bug.

Remember that as humans we essentially are very complex machines and perspectives partly determines how we will react to a stimuli.

</comment><comment><USER55> Same a doctor could say, I guess—they look for problems in order to help. Too bad they don't have unit tests.

Finding a bug is good, the worse the better, not finding one means software has bugs you don't know about. Distance yourself. You shouldn't allow one project's problems influence your state of mind, since it can hurt other 'patients'.

For me, most of the frustration comes not from working as 'just a' developer, but from leading projects and interacting with customer. It's exciting to solve higher-level problems, but communication is easy as the ocean.

</comment><comment><USER56> If you don't like your workflow, change it. It's really as simple as that. If you can't change it, switch to a job where you can. Trying to change how other people perceive you or your job will only make it worse. Just because so many are feeling that they are stuck in a continuously endless loop of negative feedback, doesn't mean its right or the only thing there is. You, and only you, have the power to change your own mindset (for the better or worse). There's nothing that does that for you.

</comment><comment><USER57> I think this is one area where dashboards can help. Chart the metrics that are important to your organization, and prominently display them.

Chart the number of users on your site throughout the day. The number of times they do X or Y, that your app enabled them to do. Put a big counter on the wall for sales/new users/etc. Make a big deal when milestones are reached.

Bug trackers, user complaints, etc can definitely weigh us down. But hopefully there's some encouragement in the data that we're doing some things really right.

</comment><comment><USER58> I think that people need to realize that a developer is someone that simply builds the solution to a problem no matter what that problem may be (ease of use, a new business etc.) If you use that train of thought it only makes to focus on all of the things that do not work to successfully achieve the goal of finding the thing that does. So regardless of how good their code is the developer has to have the mindset of first fixing all the bad to deliver a working solution.

</comment><comment><USER59> It's this way in every job. Every chef should be thinking, "does what I made taste as good as it can?" Every car repairperson should be thinking "am I doing the best job of replacing this brake caliper? Not banging it around, not kinking the brake hose, not getting greasy fingerprints on the rotor?

In every job you should be thinking about the quality aspects.

It's just that in programming, the problems can numerous, subtle, and hard to find.

</comment><comment><USER60> On tough days at work, I am often reminded of Vladimir Vukićević's blog post about the "best visual representation that I've seen of what a programmer's job is often like":

[http://blog.vlad1.com/2008/07/21/other-peoples-thoughts- on-p...](http://blog.vlad1.com/2008/07/21/other-peoples-thoughts-on- programming/)

[links to a humorous video with NSFW audio commentary]

</comment><comment><USER61> <http://cdn.memegenerator.net/instances/400x/28066871.jpg>

This blog post is really silly. Writing software is refining something over time. You take a lump of clay and gradually shape it into what you need.

If you get all broken up about a bug or whatever, you should probably try to get some perspective.

</comment><comment><USER62> Doctors see sick people more than healthy people. Divorce lawyers get more business than the lawyers for happily-married couples (I guess they can help them with a will.)

We programmers live on the borderline between respected professional and prole grunt. Is it Doctor/Lawyer/Software Engineer; or Mechanic/Technician/Software Engineer?

</comment><comment><USER63> Try your hand at security and come back to appreciate the optimism and positivity(#) pervading the programming world.

(#)relative.

<comment><USER64> Indeed. Or go work on software for manned space vehicles, or medical devices, or huge financial institutions, or anywhere where the consequence of bugs is "people die" or "national security is compromised" or "society collapses" or the like.

I wonder if you couldn't formulate a rule to the effect of _the more serious the task you are working on, the less you can afford to be optimistic._ When Serious Things are on the line, you _have_ to be a pessimist, because you have to find and root out all the possible weird failure cases _before_ they bite you. When all that's on the line is a comment on someone's photo of their lunch, optimism is a more sustainable philosophy.

<comment><USER65> Something that struck me from your comment is that yes, there are more serious repercussions than others. The problem here is that the pressure and feedback from those repercussions is relative, and knowing this makes it especially difficult to accept tons of negativity. If a bug caused someone to die, and this was preventable (i.e. obviously your fault) then yes, you should feel horrible. Most of our jobs though, involve loss of money, not loss of life. The pressure to fulfill these tasks is therefore completely constructed. Success or positive feedback is simply that the people paying you continue to make money, the status quo continues.

Being optimistic or pessimistic isn't quite relevant when people's lives are on the line, I think it's more about being _realistic_. Everything can fail, and everyone makes mistakes. This is reality. When people can die, there is much more impetus to pay (time and money) for everything to be triple-checked and triple-redundant.

But in pretty typical software development, that money and time isn't there. And the feeling of knowing you could have done better, if only given a chance, is horrible and eats away at your resolve. Then you wonder, "well perhaps I'm not fighting strongly enough," or "People are coding for space shuttles, and I can't even get this page to load!"

I believe it's a human right that your individual problems are no greater than another's, because it's relative. If you feel about it strongly enough, then it's valid. Saying it's not because people's lives aren't at risk is invalidating the human right of pursuit of happiness.

</comment></comment></comment><comment><USER66> I think this is true of any profession. Just in case anyone on HN hasn't heard of the Dunning-Kruger effect yet: <http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect>

Competence relies upon willingness to admit mistakes.

</comment><comment><USER67> Another writer who reports adverse effects from the critical / judgmental / negative thinking required to create good software:

[http://telepatch.blogspot.com/2008/04/why-being-latency- monk...](http://telepatch.blogspot.com/2008/04/why-being-latency-monkey-makes- you-want.html)

<comment><USER68> Hey, I know the telepatch guys.

</comment></comment><comment><USER69> the point isn't the criticism coming back. the point is the critical thinking the programmer is doing. the problem is focussing on finding flaws and holes.

in social conversations and in life, it is a virtue to let things pass, to support the joy that comes from simple optimism, from believing in hopes and dreams without practical certainty or probability. it is a virtue to talk about things without knowing the context, without digging into the challenges, the holes, the flawed rationales, the white lies that help us feel better about ourselves, each other, and our journeys through life.

too much of anything is a bad thing. i just assumed everyone had this problem of focusing on the problems and undervaluing progress and success.

</comment><comment><USER70> It sounds like a plateau, where he's not getting noticeably better from the mistakes he's making (so that he's not making them as much with each chunk of code he writes). Maybe this happens when you're close to your full potential?

<comment><USER39> Programming always gets more difficult. I'm a much better developer than I was 10 years ago and I don't make the same design or development mistakes. But instead of writing perfect code, I'm working on larger and more difficult problems. In fact I'm now responsible for so many more platforms, systems, and programs that I probably spend more time dealing with problems than ever before.

<comment><USER70> I guess my take on it is different. The things that I've found to be the source of bugs/problems for me are areas that can scale to larger problems. Things like component communication, algorithm edge cases, typos, poor memory management, etc. For me, the error rate slowly goes down, because I've learned to compensate for my weaknesses. Maybe your (and his) weaknesses are not as portable to other and larger problems/systems?

<comment><USER39> I'm sure my error _rate_ is a fraction what it used to be but I'm producing far more code and working on far larger problems. You better hope that areas of improvement on are the ones that scale to larger problems.

<comment><USER70> The original article was about error rate, that's what I was talking about:

      1. write some code
      2. run the code
      3. get an error message
      4. find the error and back to step 1

      Hour by hour, day after day, I do this. Always searching
      for what's wrong with what I'm creating, rarely thinking
      about what's good about it. It's a negative reinforcement
      feedback loop.

If the error rate was lower, steps 3 and 4 would happen less frequently.

<comment><USER39> My original point was that #1 doesn't stay static -- if it did, then I'd be writing perfect code right now. Instead the code you write gets harder.

Even then, I don't think the author intended you to take that so literally. That's an easy way to describe the problem to someone who isn't a programmer. The negative feedback loop is much longer and more complicated than that.

</comment></comment></comment></comment></comment></comment><comment><USER71> Indeed this is very dramatic. Positive feedback boosts egos, negative feedback gets the work done. If no one ever received negative feedback, we would spend our lives believing we're perfect while doing everything wrong.

</comment><comment><USER72> Once I heard from an architect(in the original, designer of buildings sense of the word), that he wished he would get as instantaneous feedback of his work, as a developer can from a compiler.

</comment><comment><USER73> this seems to be largely a matter of personal mindset. i'm a programmer. i've worked in a number of companies, from deeply dysfunctional to wonderful. but invariably, the only thing i ever disliked about my jobs was dealing with company bullshit and unpleasant people. i've never felt any negativity attached to my actual work - i always feel like i'm building something and making forward progress, whether that something is genuinely new code or simply bugfixes.

</comment><comment><USER74> How about we stop being nice to computers? Put some of the onus on them. We do all of the work, they just crunch the numbers.

Make the compiler responsible for something.

</comment><comment><USER75> Now I get it! My son is a programmer and he's always looking for fourths in me ... Just like his mother :)

</comment><comment><USER76> I don't think it's useful or accurate to generalize about the subjective experience of programming.

</comment><comment><USER77> i disagree with the last part being that failing is frustrating... now it could just be me, but that's what i love about programming which is finding and solving puzzles that I've made subconsciously for myself.

</comment><comment><USER78> it makes you wonder if the real success of companies like google really is in the uplifted, positive, work environment to help pull you out of that negative feedback loop.

</comment><comment><USER79> lol, nobody gets paid to see the positive things. Everyone else at the company is also being paid to be critical and fix problems (lawyers, finance, HR, CEO, etc.).

</comment><comment><USER80> This is price of making things people care about.

</comment><comment><USER81> Negative people think negatively.

This is nothing new.

</comment><comment><AUTHOR> OP here. Thanks for all the great comments. Especially all of the negative ones, validating my thesis ;)

</comment><comment><USER27> This is extremely true. I love the phase where you are just _building_ putting pieces together, solving interesting problems. Then QA comes in and tears your shit apart, gives extremely unhelpful advice and generally just kick over your sandcastle.

</comment><comment><USER82> And that's just the code, never-mind the people you have to deal with!

Negative reinforcements have arrived! (Great article, BTW)

</comment><comment><USER83> TLDR: write better code

functional programmers get to express their ideas as code

imperative programmers are so busy playing whack-a-mole with their bugs that they don't have time to think about new ideas

just look at the research[1] coming out of the <del>Clojure</del> functional programming community - especially Datomic. once you learn how to get your defect rate under control, you have time to explore crazy awesome new ideas

        [1] https://thestrangeloop.com/archive/2011
        [1] https://thestrangeloop.com/archive/2012

edited

<comment><USER84> Most bugs have nothing to do with the code being imperative.

<comment><USER83> <http://www.infoq.com/presentations/Simple-Made-Easy> (this is so fundamental to this topic that it is required watching to even have an opinion on this subject)

<http://clojure.org/rationale>

[http://www.dustingetz.com/2011/05/05/how-to-become-an- expert...](http://www.dustingetz.com/2011/05/05/how-to-become-an-expert- swegr.html)

[http://www.dustingetz.com/2012/10/07/java-sucks-because- idio...](http://www.dustingetz.com/2012/10/07/java-sucks-because-idiomatic- java-is-bad-code.html)

<comment><USER84> You don't have to convince me of OOP's faults; Clojure is my favorite language. But I write code for a living, mostly in OOP because that's where the jobs are, and I do not write very many bugs caused by OOP's poor design. I write bugs when the business is ill-defined, or when I misunderstand how a library's APIs are supposed to work, or when I'm careless and don't consider "what do I do if this function returns false"; all stuff that will come up in FP as likely as it will in OOP.</comment></comment></comment></comment>


Worlds best Tetris player - <AUTHOR> http://kottke.org/11/05/worlds-best-tetris-player

<comment><AUTHOR> This is so awesome! I had to share it with you guys</comment>