Ask HN: How do you overcome decision fatigue in software development? - <AUTHOR> Name any kind of project in nearly any domain, and you can choose from a dizzying array of possible language choices and tech-stacks. The modern state of software development in nearly any mature ecosystem, and many even that aren't so mature, allows for building just about anything on any platform. Want to build a web app, but don't like javascript? There are so many options in languages that compile to JS, as well as languages with front-end WASM frameworks. Want to write a websocket server? Nearly any language can do that now too. Want to store your data? Phew don't get me started on the infinite ways to do that one, with or without a database, with or without a server... it just seems overwhelming, in part because software development is very time-consuming. You don't want to spend all the time on the inferior choice or the choice that will bite you later and trigger a rewrite and decision fatigue all over again. Or so the psychology seems to go. How do you deal with it? <comment><USER2> A few mantras I try to use for this type of problem:

* There are no solutions, just tradeoffs. Don't think there's a perfect tech stack.

* Done is better than perfect. Velocity matters. This generally means pick something you know if delivery is important.

* Boring tech tends to be reliable. Things like PHP, Rails, Django, etc. These tools have been around a long time and ironed out the kinks. Lots of documentation and tooling to make your life easier. Odds are very low your new fancy idea has any requirements that boring tech can't deliver on. This counts for every layer of the stack (frontend, DB, OS, etc).

I think the most important thing to keep in mind is you'll never have a perfect solution and that's ok! Don't get fooled by all the hype from new technologies that try to make you feel inferior for using other tech.

<comment><USER3> I've noticed that managers tend to over-emphasize the benefits of boring (solved problems, consistency, easy to hire for), and devs tend to over- emphasize the downsides (verbosity, cruft, harder to attract top tier talent, harder to keep top tier talent). Few people recognize the need to strike a balance.

<comment><USER4> Some devs want to try the latest and greatest as resume fodder or out of boredom.

<comment><USER3> Well, sure. I mean, a valid reason to not use boring technologies is because you're bored with them. Devs need to grow and be challenged, or you're going to lose them. That's where management makes its error; they'll pick technologies based on what is popular ('easy to hire for'), or currently in use, or they used in a former life, and miss that none of those equate to good problem domain fit, dev engagement/challenge/growth, ability to attract talent (i.e., jobs offering Java vs Kotlin vs Scala vs Clojure, will attract different types of people, despite all being JVM languages), etc

Where devs make their error is, if they're junior, likely missing the technical tradeoffs (yes, other tech may be better for X, but it's also worse for Y), and if they're senior, likely missing the organizational ones (i.e., do other teams want to learn it, does devops/QA/etc have to do anything, what's the ramp up time, will the proposed productivity gains offset that, etc)

</comment></comment></comment></comment><comment><USER5> Most respondents here seem to be focusing on language/framework/tool choices, but decision fatigue is also much more fine-grained. Lots of people here saying to choose "boring" so that you supposedly don't face decision fatigue, however, even within a boring language or framework there are lots of decisions to be made as you develop software. If you're doing OO development, for example, you're constantly deciding what your objects/classes should be, what objects are responsible for what actions/tasks, what's the inheritance hierarchy(or maybe avoid inheritance altogether)? Even down to how you want to organize code into files. And then there are data structure choices: Do I want a linked list here, or maybe a binary tree would be better? I think a lot of folks here are saying "choose boring and you're decision fatigue goes away" but I don't think it's that simple.

Decisions about architecture, code structure, algorithms, data structures, etc. are an inherent part of software development. That's not a bad thing per se. And yes, you will experience fatigue - it comes with the territory - it's partly why we get paid the "big bucks" (for some value of "big"). The best way to deal with it? Take a break. Go for a walk. Get away from it for a bit. Soften your focus. Take some time to play - write some fun code for a personal project where it doesn't matter if you make a non-optimal choice. If need be, take a sabbatical for a few months or even longer if you're experiencing burnout.

(30+ year Software Developer)

<comment><USER6> I'm reminded of Siderea's excellent essay: "What Software is Made Of" [https://siderea.livejournal.com/1241996.html](https://siderea.livejournal.com/1241996.html)

> A computer program is a specification of the behaviors of an inanimate > object. And since inanimate objects, definitionally, do not have behaviors > of their own, every single one of those behaviors specified in a computer > program – and every single aspect of every one of those behaviors – has to > be deliberately chosen and imbued into the object by code. Every single > behavior, at every level of abstraction, represents a decision as to what > the program is to do in that moment being described.

(Yes, the page is ugly. The words are worth it, or copy-paste into your favorite editor).

</comment></comment><comment><USER7> I tend to use 'boring' technology if that serves the purpose, and I try to not experiment with new tech in projects that I need to deliver.

For experimentation and prototyping I tend to check out new things, those might end up in the 'boring' stack once I'm familiar with them.

For me it's a personal stack of tools that work for me, and I try not to be too influenced by what's the next new thing on sites like StackOverflow or Hackernews, I use what works for me and what makes my clients happy.

<comment><USER8> I'm kind of a broken record in this sense, but I'll say again that one can pay too much attention to HN and, if they do, they might come to believe that PHP and Ruby are far too slow for most cases and that only serious developers write their backend in Elixir, Python, or Rust, use NoSQL, integrate Kafka for a data pipeline, build frontends in TypeScript or Elm with Svelte, WebPack or GTFO, and containerize everything and scale out with K8s.

99% of the developers here aren't even close to needing to think in terms of that scale, beyond simply not doing dumb things in your code that can happen no matter what tools you use. Hell, there are whole companies that don't need to do these things. A few companies I've worked for or contracted with were bogged down, IMO, because someone couldn't settle for "adequate", making the company suffer because their architecture is so hard to figure out.

I like using "boring" tech(in particular Ember.js, Node.js, Ruby, CouchDB and PostgresSQL/SQLite) because if something gets the job done in a reasonable amount of time, most of which I think comes down to having a competency with a set of tools, then I really don't care very much for drinking from the firehose of frameworks and libraries.

Letting go of ego is tough but, when you do, you're freed from the need to be "like Twitter" or "like Uber" and instead just build things using tools you are genuinely interested in or work for you. It's one thing if you really have the desire to be the kind of wizard to work at Google(and not be relegated to writing shell scripts all day), but if that isn't for you that's fine because the vast majority of jobs out there don't need an archmage.

What most companies need is someone who is going to KISS and not eff things up. If you can do that, you'll have a hard time getting fired even if you sometimes slack off.

<comment><USER9> Valid comments but there really is no reason not to use Typescript these days if you are considering JavaScript. Even for small/single-person projects there is no reason not to use it given its benefits and the fact that it takes 10 minutes to learn if you are a JavaScript developer already.

<comment><USER10> Typescript programming invariably results in time spent figuring out how to properly type otherwise valid JavaScript code, ie debugging code that doesn't wind up in your app. In a large app, the types can be their own special form of spaghetti. The typing system is clunky and inelegant compared to Elm, which is what I would use for a non-JavaScript frontend. I'd never greenfield a project with TS if I could avoid it.

<comment><USER11> > In a large app, the types can be their own special form of spaghetti.

I have a relatively neutral opinion of Typescript, but oh boy does that quote ring true. TS can be a very nice safety net when refactoring (just fix all the type errors, and the app should mostly work as it did before), but you can also very well paint yourself in a corner with similar-but-slightly-different types all over the place that'd just work if it was in JS.

<comment><USER12> Yeah, agreed, but it's nice that it gives you the flexibility to be able to throw a `// @ts-ignore` in there and tell the compiler not to worry about it. I've definitely done that when consuming wonky libraries with messed up type definitions.

</comment></comment></comment></comment></comment></comment><comment><USER13> The overwhelming engineering contributor to success is latency to add functionality¹. The overwhelming contributor to reducing latency to add functionality is codebase familiarity. Conditional on the codebase being my own, the overwhelming contributor to familiarity is proficiency with the tools. The overwhelming contributor to proficiency is sustained use. I have sustained use of Rails+React on Heroku.

So I use Rails+React-on-TypeScript on Heroku for a web-app. I use Scala+Spark on Databricks-on-AWS for data wrangling. I use Python for local scripting. That's because in these domains I have mastered my tooling and that's way more valuable than using the best tooling that I have not mastered. The program design choices are similarly non-decisions. Just always do the same thing.

I do experiment for fun because it is enjoyable to me, and that's the mechanism to add more things to the proficiency list. For instance, I like Rust (and use forked Rust utility programs for personal use) but when I write my next command-line tool I use Python or Go. When I become proficient in Rust, it may become a possibility that I use it.

¹ Of course, the overwhelming contributor to product success is the product choices not the engineering. Few products succeed or fail on the engineering. In each case, you only want to innovate on the differentiator. It's like a variant of the "optimize the bottleneck alone".

<comment><USER14> I had a similar reaction. I do not consider a new project, and then consider what stack to use. I first consider what stack to use, then I consider projects which are suitable for that stack. Most projects I might consider that are on other stacks are filtered out this way. Over the course of the past decade for me, the stack that I consider projects on are ones that use the Android framework.

I do branch out somewhat. If I need a REST API I program it in Python. I dabble in other languages when I need to or when I want to. But for the past few years, most of my work and side projects have been in the Kotlin language, using the Android framework.

</comment></comment><comment><USER15> Most of the time and in most places use proven, boring, technologies.

There's time and place for using cutting edge solutions. But if that time is 'always' and that place is 'everywhere', you might be doing it wrong.

Keep things simple.

<comment><USER16> Well said! Over the years working in web development, "Keep it Simple" saved me countless times. Unless a project has strict requirements for a new, novel and/or complex solution, stick with the simplest, proven, heavily-tested option--usually the most boring. When selecting tools for your stack, ask yourself: "How will my end users/customers benefit from this tool?" For example, very few will care if you used Angular, React, Vue or jQuery for your front-end as long as the page works well.

<comment><USER17> Keep it simple and get the basics right. That's when having good education matters. College won't prepare you to the market in sense of cutting-edge technologies but will give you good basics on "boring" but essential knowledge that helps you think in terms of trade-offs and evaluate new technology properly. So you don't have to shoot yourself in the foot jumping into, say, an Electron bandwagon and writing big, resources-consuming applications when something simpler could suffice or adopting NoSQL and having to deal with the lack of ACID just because "shiny new tech" and "everybody is doing it".

<comment><USER16> Exactly. I was very close to using Mongo for a project that had mostly relational data and a few unstructured fields. MySQL with a few JSON columns worked much better in the end.

<comment><USER18> We asked for a basic inventory management product that would have uniqueness constraints, mainly relational data, and be used by a small group of users. Our devs wanted to test out angular to see if it would speed up development on other projects (fair enough), and pitched dynamoDB on AWS. Angular took just as long or longer as their usual methods, required outside consultants for extra cost, and dynamoDB got us a product that failed uniqueness constraints all over because the devs were unfamiliar with NoSQL as well. I guess it helped with adapting the software quickly and adding fields as new requirements popped up though. Nice experiment, but definitely not something you'd want to have to deliver on a schedule to a customer with strict requirements and a competent QA team.

</comment></comment></comment></comment></comment><comment><USER19> Simple: use what you know best, ignore the rest and concentrate on the _business_ side of your problem. The tech is the least interesting part unless you enjoy looking at blinking lights. It is all virtualized and packaged to the point that you really shouldn't be having any kind of emotional or functional investment in it anyway. Make sure that you have a good grip on your data, that's where the value sits, and that your code is maintainable no matter what stack you use. Ensure it is broken up into chunks small enough that they can be discarded if you feel the need to replace them with something else.

<comment><USER20> Deciding between a tech that you already know and know will work well for the problem, and a tech you don't know - that's an easy choice.

A harder choice is when you know the tech you known doesn't quite fit. Do you go with what you know, or do you try something new?

Concrete example I'm currently considering: If I want to make a web pages that does some background work, should I use Django and Celery like last time, and spend months tweaking Celery settings I don't understand and still feel like the system's kinda clunky (like last time). Or do I use Elixir where there's little difference between handling a HTTP request and running a background task, and where I can just spin up a few thousand threads to monitor background tasks?

TLDR: What do you do when "what you know best" isn't the right choice?

<comment><USER19> Webpages that do background work will need something client side, not server side. Javascript + a timer to kick things off periodically should be enough for that.

Unless I'm misunderstanding what you mean by 'background work'.

</comment></comment></comment><comment><USER21> This article is a bit older but still relevant[0]. I do more or less this, most of the stack is proven tech I know then I might swap out a few components with something newer or more shiny, evaluate and may or may not take that new thing into the next project.

[0] [https://mcfunley.com/choose-boring- technology](https://mcfunley.com/choose-boring-technology)

<comment><USER22> This is a very pragmatic approach, I like it.

But I want to share an alternative to this because it helped me greatly in the past:

Sometimes this kind of decision fatigue is actually clouding something more profound and you might be on to something valuable, some kind of truth that is hidden away and still needs to come out.

Your decisions get blocked (from your subconciousness?), because you know this in some way and you cannot quite grasp why that is yet.

The hard part is to decide whether this is the case at all. I don't have a silver bullet for this, but one thing that helps is to try to be optimistically self-critical.

If you determine that this is actually the case: You have found some deeper idea/connection that you don't understand enough yet. Then you want to explore the idea by writing prototypes and text to figure out whether there is some pragmatic core that you can extract.

Note that sometimes these ideas are positives or rather solutions. But often they are problem statements or criticisms. The latter needs more exploration, often with different technologies.

<comment><USER21> This is an interesting idea, are you suggesting that sometimes what manifests itself as decision fatigue is actually stemming from lack of a deeper understanding of the problem? I will try to apply that.

<comment><USER22> > This is an interesting idea, are you suggesting that sometimes what > manifests itself as decision fatigue is actually stemming from lack of a > deeper understanding of the problem?

This can easily stand on its own as a general reason yes. But I meant specifically in combination of having some "rough diamond" (please excuse the pathos) that is nagging you in the back of your mind and blocking decisions because you are not pursuing to find and polish it.

Often the pragmatic or "boring" approach is just right. But sometimes it isn't because of a reason that is hard to articulate and it just doesn't leave you alone. I think this is the nature of the creative process. Being brave and exploring it would be the "right way" in this case to figure out whether the idea is feasible or sound, (which it often isn't, but you can't help it and figuring this out is valuable in of itself).

</comment></comment></comment></comment><comment><USER23> > You don't want to spend all the time on the inferior choice or the choice > that will bite you later and trigger a rewrite and decision fatigue all over > again.

This is classic perfectionism.

When suffering from perfectionism, a person overweights the consequences of arriving at an imperfect solution and underweights the consequences of not arriving at any solution at all.

In other words, it becomes safer to exist in an undecided state where all options are on the table than to make a decision and potentially deal with regret later. We tend to think of perfectionists as people who tirelessly work until the problem is solved to perfection, but many perfectionists simply get stuck in decision paralysis. If you never make a decision, you never have to deal with irrational fears of picking the imperfect solution.

In reality, most of the time it's better to pick something and run with it as fast as possible. Worst case, you have a good but not great solution. Best case, everything works just right. Either way, it's better to have some solution than nothing at all.

Perfectionism is a classic killer of ambitious startup teams. Put a lot of smart, dedicated people on a problem and they'll want to produce something they're proud of. They want to collect all of the best practices and state of the art tools, as only the "best" will do for their work. Good intentions, but while they're on their second rewrite and spending weeks rearchitecting to 100% test coverage, their competitors are running circles around them by shipping product that is good enough, even if it's not ideal or perfect. Mediocre products that ship are better than perfect products that never ship.

If you find yourself struggling with this, there is a large body of work and self-help materials for dealing with and overcoming perfectionist tendencies.

<comment><USER24> > When suffering from perfectionism, a person overweights the consequences of > arriving at an imperfect solution and underweights the consequences of not > arriving at any solution at all.

So eloquently put, thank you!

</comment></comment><comment><USER25> Here are my rules:

* Stick with what you know. I personally know Python best, so if the solution can be achieved in Python, I go with that.

* Avoid fads. I don't use a language until at least two years after I've first heard about it.

* If you've gotten this far in the list, you'll have to learn a new language or brush up on a weak one, so look for one with a strong community and a lot of libraries.

* Old usually means stable. If it's an old language but still in active development, they've probably found most of the worst edge cases by now. Also there is a lot of best practices.

* Everything is a tradeoff. Nothing is the perfect solution, so know where your solution might be deficient (or learn).

* Doing cool tech is cool, but make sure you're solving the business problem (or personal problem) you set out to solve.

</comment><comment><USER26> I forget where I heard this the first time but it shows up now and then and it's held true for me since the first time I heard it.

If you have a big work/production project, go with what you know, whatever that is. When there's a deadline or someone will lose money with a delay, it's irresponsible to use that project to add another line to your resume or play around with $NEW_TECH.

If you want to learn a new technology, do it on a project where you can afford to throw your hands up at some point and scrap the whole thing, because you very well may end up in that position.

<comment><USER27> > If you want to learn a new technology, do it on a project where you can > afford to throw your hands up at some point and scrap the whole thing, > because you very well may end up in that position.

Think of it as having two goals for the project: learning $NEW_TECH, and writing a program to do $TASK. Don't use $NEW_TECH unless the goal of learning $NEW_TECH is at least as important (or valuable) as the goal of writing a program to do $TASK.

This implies that you want to experiment with smaller programs. But when you do, recognize that you may not be seeing all the problems and limitations of $NEW_TECH.

<comment><USER26> Exactly this. I want to play around with kubernetes but I know a big part of it's benefit is for big projects.

I also just haven't gotten around to it yet.

</comment></comment></comment><comment><USER28> honestly the best solution may be to cultivate other non-programming hobbies so that your time becomes appropriately more precious. unless you're in a high volume or high stakes situation, most of the options give a workable result and to the extent you realize you make mistakes, that learning experience makes the future decisions easier to make. point is, there's probably not a short cut.

</comment><comment><USER29> Increasingly for me it comes down to "principle".

If you try to support all the features that could be supported, you will end up buried in the bottommost layers of the tech stack, because that is how these things always turn out.

If you try to make life as easy as possible, in contrast, you most likely end up sucked into the Web stack and limited by what the browser does.

If you try to make the project "minimal" you may end up boiling the water into an empty pot - it does nothing because it wasn't trying to do anything.

But if you have other principles in mind as you start the project you can evaluate the stack in terms of whether it facilitates study of each principle. "Minimal" is just the principle people tend to grab when they lack for others - add others and minimalism has the intended clarifying effect. There are still tradeoffs to that, but they are much less deleterious.

What other principles can be applied to software? You have many options: Ethical concepts, of course, center the good for society. Cosmology often has ideas for the specific design paradigms. And artistic ideas like improvisation, remix, and so on suggest the mode of use. Most software tends to assume Taylorism by default: Automating for speed and productivity along a few measurable axes. If you relax that assumption you can often streamline the features.

In any case, having a set of principles in hand lets you shop for tech purposefully: From principles you end up with rules, and from rules, specifications. That makes evaluation easy.

</comment><comment><USER30> Decision fatigue is almost universally the result of executing against an insufficient plan.

A better approach to solve for this problem is to completely ignore, at least for the moment, any idea of decision fatigue and instead focus on developing a solid plan. A good plan will account for risk acceptance, business requirements, a task list, and costs. The most valuable part of a solid plan is not having some magically complete roadmap or blueprint, but that it puts all your challenging decisions up front. It forces you to examine what you are willing to pay in terms of money, time, and effort.

Once you have a well envisioned plan the only consideration of decision fatigue should be limited to maintenance. If a given maintenance effort is too expensive or requires too much investigation or risk then you need to refactor and break things down into more primitive units.

When it comes to running a team there are only two things to consider heading into planning: a defined performance baseline and scope of effort. Those two things are completely in competition and you have to balance them against a budget of available resources. As the team leader be willing to accept input and suggestions from your team, but set the baseline with confidence and don't let the children run the daycare.

<comment><USER31> 1\. "Make a plan" is not a solution to decision fatigue, it's how you get to decision fatigue.

2\. Calling your team of highly paid professionals children who don't deserve autonomy? Not a winning strategy.

<comment><USER30> What is the measurable minimum level of autonomy necessary to achieve the greatest result?

</comment></comment></comment><comment><USER32> This is what is known as the 'Tyranny of Choice'. Human brain does real good with 2 or 3 choices. Beyond that the number of choices make it hard to do a valid comparison.

The fear of making a bad choice paralyzes many people. So let me offer a little help: Do not worry you will get it wrong, you will get it wrong. Invariably there is something better you have not heard of. Just aim for the top 25%.

<comment><USER33> [https://www.chronicle.com/article/the-tyranny-of- choice/](https://www.chronicle.com/article/the-tyranny-of-choice/)

[https://en.wikipedia.org/wiki/The_Paradox_of_Choice](https://en.wikipedia.org/wiki/The_Paradox_of_Choice)

</comment></comment><comment><USER34> It is all about trade offs, there is no perfect solution.

Here are a few things that I have learned:

# Requirements \- List out clear requirements, get an agreement with your co- decision makers, and the necessary people. Make sure you address for at least 2-3 yrs of requirements. It is likely, that new requirements would pop up and your system should be adaptive to this \- if you think that your system is not going to address a specific thing, think twice, you may get buy-off & assurance from product, directors. However be prepared mentally that six months down the line, this will change.

# My Dos and Don't (always subject to change :))

\- Do keep things simple

\- Don't make a career out of a single project.

\- Do list tradeoffs in your design

\- Do document and perform deep dives.

\- Don't ship prototypes.

\- Don't be afraid to get critical feedback. If someone gives critical feedback, spend a few days to clearly understand the feedback

\- Don't be defensive

\- Don't be attached to what you build, it does not represent you.

\- Do use new tech in baby steps

\- Do experiment - The more you experiment, the more you learn, the more you will fail. Is this something that you have the mindset for? You can also ask how much do you have the time/energy for?

<comment><USER35> > \- Don't be defensive

+1 to this. The very first thing I'd teach computer science students is "You are not your code... ego investment will only cloud your thinking" .

When the compiler says it doesnt work, trust it's not a compiler bug.

When the computer does what it's instructed and it doesnt work, trust it's not a JIT bug or that your code "clearly says to do what you think it does..."

When a coworker suggests an alternate solution, it doesn't mean either of you are a "better" engineer. (These kinds of decisions can only be decided across many variables and many data points).

</comment></comment><comment><USER36> Identifying reversible versus irreversible decisions.

Reversible decisions should be made quickly and emotionally cheaply. Draw straws if you have to.

Irreversible decisions should be delayed as long as you responsibly can. The extra data helps reduce speculative arguments, gives your solutions a little more time to mature, or may discourage you from even tackling that problem at all (changing your goals or finding partners)

</comment><comment><USER37> For a web development project you're not really doing much programming (in a sense, I'm not saying you're not a "real" programmer -- you are! no need for gate keeping). Your job is to translate business requirements (crappy, vague language) into code (less crappy, more specific language). In this sense of "programming," you don't need to make a whole lot of choices! Use a framework where all of the details are already thought out and you can spend time doing the translation work you're doing.

There are a thousand and one frameworks. You're going to pick one and you're going to learn it. And you will get on with your life. The only thing that matters when picking a framework is whether you feel motivated to learn it. Figure out what motivates you: is it a popular framework with lots of users so you have plenty of people you can ask for help? Is it a framework that you have to use because your IT department controls what infrastructure or languages you can use? Don't spend too much time worrying about which framework is best. That's not your job: you're translating requirements into code. Get that done and people will give you praise and money.

Game development? Use an engine and framework. Make the game. Same deal.

Where it's a bit different is when you're building the infrastructure and tools. Not too many people get to do that. Keep your scope small and don't try to be all things to all people is my advice. If you're writing libraries: make it do one thing. If you want to write frameworks then that's all you're doing is making choices on behalf of your users so they don't have to: so make good choices, make them the default, and prefer convention over configuration.

 _Update_ : clarified opening paragraph, don't want to come off as gate keeping!

</comment><comment><USER38> You don't, you just sort of exist doing what you're doing but always thinking there's a better way of doing things / better tech stack out there. There usually is. But that's just technology for you. You can't be on top of everything all of the time otherwise you'd literally spend all day every day just learning about new technology.

At some point you need to commit. It's like relationships. How do you choose a partner out of billions of options? You browse around, learn what you like and don't like, make judgement calls, play around with some and eventually either make a conscious "this is the one" decision or else make a "we've been together so long, I guess we're a couple now" decision. At some point it becomes formal and you stop actively looking at other options because you're content with the option you chose.

</comment><comment><USER39> I like the concept of an "innovation budget". For example, if you're using a compile-to-WASM system for the first time, just use the database you already know.

If the system is all completely new to you, then pick a very small project (or wait until you have a lot of time on your hands and failure is an option).

</comment><comment><USER40> I wouldn't go into a new project using new tech or with the goal of using new tech. That's setting yourself up for failure. Go with what you know.

You should look a new tech as something to be experimented with and tried out in a casual sense. New JS Framework? I'm going to try and re-create this thing that I know how to do in the Old JS Framework and compare. New database? Make a simple app to explore it and flesh it out.

If you don't know enough about the new product to compare it to what you know, you shouldn't be considering going with something new. New stuff comes out all the time, but that doesn't mean it's good or worth looking into.

</comment><comment><USER41> Meta: The fact that we're having this conversation all the times says _something_ about our field. I'm just not sure what.

How long did it it take carpentry to get past the great debate between "hammer vs screwdriver" ?

Will anyone ever refer to the saw as a "boring" way to chop wood ?

Should there be resume screenings for gardeners with "x years of experience with the acme showel" ?

Would the world be a worst place if you could just use a decent language with a reaonnable GUI library to store bits in a working DB ? (None of which I'm probably skilled enough to build...)

Maybe we would have to write software that actually works for a living, and we would be played much less.

</comment><comment><USER42> Most of technology choices comes down to "the language / framework I know." Few engineers are deeply skilled in multiple languages and frameworks that solve the problem. I sometimes see engineers who are newer with more seniority than the team come in and say "we're building new service / rebuilding old thing in X tech," and they superficially justify it, but it's often because "I know X." There's a push and pull between polyglot shops and specialized shops.

<comment><USER24> Perhaps because I do have a production background in nearly half a dozen languages, this has complicated it for me. I guess someone who has only ever written JavaScript and has settled on react as their tool of choice will just do anything with that particular stack.

</comment></comment><comment><USER43> This thought process goes beyond tech stack decisions and gets into software design decisions when you are writing code. Over-engineered solutions, and ones that seem like someone wanted to apply a design pattern everywhere take longer to implement and require more maintenance. If they go off the reservation of common solutions to common problems then when someone else has to pick up your code and grok what it does, it will take them longer, they may not understand it and could introduce bugs.

Keep everything as simple as possible.

For business purposes when it really comes down to it, the tech decisions don't matter. Sure you could choose the _wrong_ technology for a problem but because there is a wrong option doesn't mean there is only _one_ right option, there are probably many right options with different trade-offs.

For example, if you have data with strong, well defined relationships, don't pick a data store that is NoSQL, pick a RDBMS. Does it matter which one? Not really, it matters more what your people are most familiar with since that will go a lot further. Pick based on your non-technical constraints - cost, skills, etc.

This all changes if you are tinkering on a hobby project to learn something. In that case, pick whatever you want. That might help alleviate making boring tech decisions for your employer.

</comment><comment><USER44> There's a bunch of things you can do to make a choice easier. The most obvious thing you can do is just taking the time you need to make an informed choice. Read the docs, source code, check out known issues, examples, etc. Do you plan to integrate tech X with tech Y? Check if everything you need is supported. Keep notes if it's really overwhelming. You can speed up the process by eliminating choices early if you know your project's hard requirements. If all this doesn't apply to you, e.g. because there are multiple choices that fit your requirements, just pick one and see how it works out for you.

At the end of the day however, you just need to pick something and roll with it. If it turns out not to be the best choice, you'll have at least learned something and the next time you have to choose you'll be better informed.

Don't stress out about it too much. It's a natural part of software development. When you are coding (after selecting all your tools), you are _still making tons of choices_. It's just in a different context; how will you structure your code? What coding paradigm will you apply? What algorithms will you use to solve your problems? You learned to cope with this stress too. It just takes time and experience.

</comment><comment><USER45> You should have programming pals you can network with. You should have entrepreneur friends you can network with.

Alone you are going to make bad decisions, if you have friends you can learn from THEIR mistakes and bad decisions, and their good decisions too, much faster than you alone.

Those guys have already made databases, they have built web apps or whatever you want to do.

If you know successful people on your field, use whatever they use, just copy them, correcting for your own circumstances and capabilities.

It is probably the best way humans(and primates in general) learn, by imitation from the best.

This can and is hacked by advertising industry because it works subconsciously: You see the best tennis player in the world drive a particular car model or wear a watch and you want this car model or watch. Or they watch their favorite musician take drugs or get tattooed and want to do the same.

This makes no sense(copying some master outside her area of expertise) but if you are into tennis you should "spy" what the best tennis player does for training and so on.

What is incredible is that most people will help you if you just ask them.

Once you do you will learn:

* It is not overwhelming. There are very clear tradeoffs with each technology.

* There are not so many options available that are mature and proven.

</comment><comment><USER46> One of the things I've used successfully is a decision register, where decisions are formally recorded, with the justification.

This doesn't necessarily help the original decision, but it does stop a bunch of re-litigation of previous decisions, and this is often a cause of noise and distracting headspace. Importantly, it can remind everyone that the decision was made with a good reason at the time.

<comment><USER47> Posted in another thread, but:

[http://www.getoutcome.com](http://www.getoutcome.com)

</comment></comment><comment><USER48> It's quite simple, actually. In most cases, the "inferior choice" comes from decisions other than the stack itself. The stack itself is not as important as long as you select something ubiquitous and mature and has plenty of support i.e. you can find lots of answers when you have to search the internet. Sure, there are cases where you need extreme performance, or a language with good data science libraries. But those requirements just narrow the choices making it easier to decide. Just pick something your team already knows, and/or something you can easily hire people for, and run with it.

The inferior choices you need to worry about are things like poor architectural descisions, or bad coding habits. These are the things that will "bite you later and trigger a rewrite". Not the stack itself.

</comment><comment><USER49> One great engineer I worked with, he did many years in PHP. At work, we use mostly c++. He quickly learned a lot of it, though he's not an expert, he can get the tasks done.

I wouldn't personally like to work with PHP (my first language...), but I don't see the problem with that, if you do great work. Personally, I think that Python, javascript, and c++ are popular enough that they are solid choices.

Afterwards, it's a question on if you're making a choice for yourself, for the project, or to work with others. In any case, if you have some sense, you can learn given some time.

And I think if you're working on a personal project, you probably just want to see it grow. So, have fun. I'm sure you can re-write the prototype later.

</comment><comment><USER50> A lot of people have mentioned boring technology, and I 100% agree. But John D. Cook recently posted an idea ([https://www.johndcook.com/blog/2020/07/25/worst-tool-for- the...](https://www.johndcook.com/blog/2020/07/25/worst-tool-for-the-job/)) that I also thought useful: Try to choose the _worst_ tool for the job.

Naturally he's not talking about choosing deliberately bad technology, so much as he's saying to lean toward choosing crude tools for most tasks, and only opting for sophisticated tools when experience shows you need them.

What I particularly like about this idea is that it short-circuits the idea of even wanting to have nice things, so that you can get straight to solving the problem in the most direct way possible. If your dinky solution doesn't work, it's probably also fairly easy to replace when the time comes.

For example, it's easy to slurp CSV files into almost any database, and code that relies on CSVs for storage probably has a simple enough interaction model that it's easy to migrate it as well. So picking CSV might make it easier to get to work, and save tomorrow's problems for tomorrow. But migrating from PostgreSQL to Cassandra, or vice versa, is a terribly daunting change. So you _really_ want to be sure you're making the right decision on the first try. It's really easy to let that knowledge breed analysis paralysis - and it's arguably even irresponsible not to let it do so.

I have similar thoughts on programming languages: I'd rather default to the crummy old one, because newer, more sophisticated tools are much more likely to be able to easily speak to code that's written in a crummy old language, than to be able to link to each other.

The overall article isn't really about the question at hand, but some of Yossi Kreinin's thoughts here also seem pertinent: [https://yosefk.com/blog/redundancy-vs-dependencies-which- is-...](https://yosefk.com/blog/redundancy-vs-dependencies-which-is- worse.html)

<comment><USER24> > But John D. Cook recently posted an idea > ([https://www.johndcook.com/blog/2020/07/25/worst-tool-for- > the...](https://www.johndcook.com/blog/2020/07/25/worst-tool-for-the...)) > that I also thought useful: Try to choose the worst tool for the job.

There are some killer ideas for new perspectives in this thread! Thank you!

</comment></comment><comment><USER51> I've gotten lots of insight from the other commenters. One of the few lightning moments in my life in terms of awareness came from watching an interview with the poet Ferreira Gullar. He said "the important thing is not to be right, the important thing is to be happy".

Every choice is going to be inferior in some sense. If you can make a choice at all, consider it a good thing. Participate in the mess. Choose what makes you happy.

Paul Graham was onto something when he recommended having friends in programming [1]. Use what your friends are using.

[1] [http://www.paulgraham.com/pfaq.html](http://www.paulgraham.com/pfaq.html)

</comment><comment><USER52> Not to plug too much my writings but I dedicated an article about this topic:

[https://www.kabdebon.com/cto/2020/06/20/making-boring- techni...](https://www.kabdebon.com/cto/2020/06/20/making-boring-technical- choices.html)

My two cents, if you want to build a business or a project for a company: go with battle-tested, mature technologies, always. Take away the risk of immature technology getting in the way of the only mission: delivering value to your customer

Now for a personal project... go crazy, have fun and try what's new out there.

</comment><comment><USER53> Don't plan on working a full day. You have to take breaks to recharge. Don't feel guilty about this.

Don't feel bad about letting tasks slip. The initial task is to learn what you should really do. If it's new development, this can take quite a long time.

Don't estimate the happy path. Yes if you already knew how to do it, it would take 2 hours to write the code. Estimate for the learning and the unhappy path.

Six hats is kind of dumb, don't take it too seriously, but there is something useful there: Plan to spend time planning, doing, testing, task managing, communicating. Like really plan for it.

</comment><comment><USER54> I treat big, non-obvious, hard-to-reverse decisions as a task in my to-do list. When I get to them I take some time to write out the options. For larger projects or projects that involve collaboration, this lives in a working design doc. For smaller or personal projects, I keep this in a per-project journal document.

Once the task is checked off, I can mentally free myself from the burden of thinking about the other options. If the decision turns out to cause unforseen problems, I can revisit my notes on why I made the decision and reevaluate with the new information.

</comment><comment><USER55> I write down the trade offs.

[https://github.com/andrewt3000/web_development#web- developme...](https://github.com/andrewt3000/web_development#web-development)

</comment><comment><USER56> I went from writing shell scripts all day to writing Perl scripts all day to writing Java most of the day. From having to write everything in vi (not vim) with no IDE support to IntelliJ basically spoon-feeding me, the "boring" technology being alluded to in this thread is "new-tech" for me. And boy I am so grateful for decent type support, vast ecosystem and a chance to focus on design patterns and clean code. Just to provide an alternate perspective for those who think Java is "boring".

</comment><comment><USER57> It's a question of where to focus your attention. Consider the explore/exploit trade-off. Boring tech may be a little, well, boring, but that means you get to spend your limited decision-making capacity on solving your actual problem. If your actual problem is betting on a niche language early, then go for it! Otherwise, use the thing that balances your existing knowledge, interest, existing 3rd-party resources and has the right outlook over the expected timeline to get your outcome.

I think this site leans pretty niche.

</comment><comment><USER58> It's the exact same as tools in your garage. You will use a hammer, screwdrivers, and pliers often. If you do a lot of work, you'll end up getting a ratchet set and some power tools. If you find yourself with an air compressor and a nail gun trying to hang a picture frame on your wall, you're probably over-engineering. There is a perfect tool for every job, but there is a tool in your toolkit that can probably get any job done too. The important factors end up being other things.

</comment><comment><USER59> There are a ton of great suggestions and tribal knowledge in this discussion, be sure to mine this for all its worth.

My approach to this is recognize why its happening.

Its not the "dizzying array of choices" that is causing the indecision, its your thoughts about the array of choices that is causing the indecision.

The "dizzying" aspect of this is what you're brain is adding to the neutral array of choices. If you continue to think about it this way you'll be stuck in indecision.

Recognizing that is the first step.

</comment><comment><USER60> If I'm comparing options, I try to pick what's most popular. Community support, being able to find things on Stackoverflow, etc. is better than the small technical wins right now. And it will likely have a longer shelf life.

For situations where there is not a clear popular or technical standout, I timebox the research time. After x (days|hours) I need to have a decision spec'd out. That way if I spin my wheels too long, then at some point I hit a deadline and my time is up!

<comment><USER61> > what's most popular

A clarification here that I think is worthwhile:

Pick things that are "popular" as in widely used, not things that are "popular" as in "trendy" or "in vogue".

<comment><USER60> Ah, yes, exactly. This is kind of similar to picking "boring tech" that others in here have mentioned.

</comment></comment></comment><comment><USER62> [https://en.m.wikipedia.org/wiki/Vipassan%C4%81](https://en.m.wikipedia.org/wiki/Vipassan%C4%81)

<comment>

[https://en.m.wikipedia.org/wiki/Model- driven_engineering](https://en.m.wikipedia.org/wiki/Model-driven_engineering)

<comment>

[https://music.youtube.com/watch?v=YMl7TEnpB7M&feature=share](https://music.youtube.com/watch?v=YMl7TEnpB7M&feature=share)

</comment></comment></comment><comment><USER63> Focus more on the business value of what you are delivering and less on the amount of programming time it takes to get there. These things are not linearly related.

</comment><comment><USER64> Being really busy and having a lot of people waiting for your perfectly reliable and long lasting solutions to their business problems really helps.

When you only get paid for creating solutions that work or your earning capacity is reduced when you spend too much time dealing with broken systems, it makes these decisions very simple.

</comment><comment><USER65> Do you change a car everytime you see a new one which sounds cooler ? No, you stick with your car as long as it does the job.

This is the exact same in code, start with the language and the tools that you and your team know.

When you start a project, a new feature, a new anything, you should always start with what has worked for you in the past.

</comment><comment><USER66> You're an artist. Pick a medium.

When you start a new project, instead of viewing it as "I need to do X", instead view it as, "I need to do X using Y." You're not trying to write the best web app ever, but rather you're trying to write the best web app using Coffee Script and React.

All mediums have disadvantages and restrictions. Watercolor may lot look as realistic as oil paint, but the watercolor painter isn't concerned with that. The watercolor painter is concerned with watercolor and watercolor alone.

I say this because some of the most fun I've had programming was writing assembly for 8-bit retro computers. In terms of productivity, choosing a shitty CPU from 1980 as a target is _not_ productive whatsoever. But that's not the point. I wasn't trying to achieve the global optimum of success. I was trying to achieve success given a list of restrictions set at the beginning. And that was a more attainable, healthy goal.

So pick a choice. Pick whatever you think would be an interesting challenge. And stick with it. It's your medium now.

</comment><comment><USER67> There is a balance to everything. I sleep better running on proven solutions. Keep it as simple as possible. Focus on what your customer needs most and make that part rock solid, even if its boring for the dev team.

</comment><comment><USER68> 95% of the time, the best tool for the job is the tool you know best.

If you don't know any tools, pick one and learn it well.

</comment><comment><USER69> "Opinionated" means decisions that have already been made for you.

</comment><comment><USER70> Use what you know. Should make the decision easier.

</comment><comment><USER71> HAPPY HARDCORE (no joke, it helps me)

</comment><comment><USER72> This is the art of being an effective person, let alone doing good engineering, and personally I find building and using this craftsman's intuition to be the great joy of working in software. Contrary to many of the comments here, I would never just go for a "boring framework" because it is tried and true, or just use what I already know. That sounds like a great way to grind yourself into burnout.

Instead I would start jamming on a whiteboard or in a notebook. Think about the problem you are tackling: what are the inputs, what are the outputs, what are the key functions, and what data structures and algorithms might be important? How about the team? Is it just you, or are you working with other people? What are your experiences, interests and passions? What's the timeline? Spend some time exploring libraries, reading paper and blog posts to inform yourself of the space. Maybe read some open source libraries. Don't go nuts, but scan around to soak up some good ideas and build a mental model of the space. This all helps put some parameters around the situation and give you some confidence that you are making informed decisions. Now you can think about the MVP, key interfaces, etc, and you might find that you can do some quick and dirty components for 80% of the project while really focusing on the heart of the challenge in that last 20%.

Often times if you define good interfaces you can swap early hacks and experiments out for something fancier (faster, more scalable, etc) later on, so then you don't need to worry as much about making optimal decisions. For example, you might use some distributed key value store or message bus in the end system, but to get the ball rolling you can just spin up a Redis instance during development, or even just write a couple functions that fake it in- memory or using JSON on disk for starters.

Now you can think about what you want to learn in this project. What's going to be fun and interesting about it? Do you want to dig into some new algorithms, a different language, a machine learning model? I like to use my curiosity as a major motivation to differentiate from other solutions and push through what could otherwise be boring aspects of the project. Say you need a service that just manages logins and sends back some tokens. That can be done in a million ways, and it is likely to get swapped out down the line anyways as you scale or whatever. So make it interesting, pick a new library or language and go nuts. This of course needs to be balanced with making sure you can accomplish the task in a reasonable amount of time, but this kind of learning is empowering and it will make you a more capable engineer. Now 20 years into my career I can program in 10+ languages on embedded micro- controllers or virtual cloud clusters, and picking up a new language or framework isn't daunting at all.

Have fun doing it, and you'll get better faster than everyone who is picking the boring framework in their same old language to solve it the way that the blogs are telling them to and then frantically searching stackoverflow because half way into the project they discover that their square problem doesn't perfectly fit into the framework's glorious round, ahem, hole. That's not engineering or craftsmanship. That's nervous fanboy frenzy that is the opposite of empowering.

Everyone has to find their own explore vs exploit trade-off, and we need people whose experience is narrow and deep as well as others who have learned far and wide. Choose what kind of person you want to be and make it happen.

</comment><comment><USER73> My solution to this problem is relatively simple in comparison to some of the other posts. First you don't need to be on the latest tech stack. Tech stacks come and go, but some stick around with force for a very long time. In fact the most successful will always stick around. For instance, while I wouldn't start a new Java based stack today, I would have no problem starting a Kotlin one, which will end up using the same technology under the hood. The reason is that I'm not particularly found of Java, but I'm pretty sure there are a huge amount of people that would start a brand new Java project with no hesitation. And they would be right to do so. Consider the following: \- what is your team familiar with? \--if your team is comfortable with a strong, battle tested technology, that's a strong incentive to use it. \- is the technology of choice not too obsolete? \--if you start a brand new Cobalt project, then you are dealing with some serious problems in your environment. In fact, in some extreme cases, choice is non-existent, but in those cases you would not have the so called "decision fatigue" to begin with, since there would be no choices to speak of. \- does stack X solve a problem you are having with stack Y? \-- if the proposed stack doesn't address real world issues with you current stack, than there is no need to change. \- is stack X an evolution of stack Y? \-- in same cases the new stack is very familiar, an evolution of kinds of your current stack. For instance .Net Core is and evolution to regular .Net. In those cases, migrating your team to the new stack should be pretty easy and provide some benefits. Just be careful not to jump the ship too early. Make sure the features you rely on are available, and that the new platform is stable.

If you read the above, you might get the impression that I'm saying people rarely change stacks. And that's actually true. At the end of the day, people tend to stick with what they know, because it works, and has worked for years. Rewriting software is risky and expensive. But even for new projects, if the teams sticks to their current tech stack, they can reuse years of work, as well as rely on the expertise they acquired through the problems they faced. Now I know that this kind of question often comes from people that are either new to the field or not very experienced. So I will give some advice if you get a fresh start, as in a start up with no legacy code or existing team, or if you are building or own project, or maybe you get a team that is somehow isolated from the rest of the company.

Basically if you have no real world bias (as opposed to personal bias) towards any tech stack, then the only solution is to do a lot of research. Building prototypes often help test out the options. But first learn about them. Learn their motivation. Why was this stack built to begin with, what problems were they trying to solve. Are their problems similar to what you expect in you project?

Sometime people build new stacks to address real world problems. Some times they build them because they can. I'm not saying you shouldn't use a technology just because the other had no good reason to built it, just had to opportunity. Sometimes people build really good products even if they are not trying to solve world hunger. And if you find such stack go ahead. But in general, try to find stable, battle tested tech, that solves your particular problem. Ignore the trends, focus on reliability and familiarity.

</comment><comment><USER74> Haha, everybody is going to have their opinion on this. Heck, I read through the comments and I didn't see this answer but probably in the time it takes to type it up, someone else will post it.

So Adam Savage had a video[1] a few months back on weathering prop money to look like a properly "gangsta" stack of bills rather than a set of nice printed paper. And when it was broadcast it was live and he took questions from the audience while some espresso was drying on the bills in his oven, and one of those questions was about someone needing a prop that looked properly covered in dirt and blood, and what is the best way to do that?

He said that the dirt part was easy (I assume he meant, just bury the stuff for a day or two and come back and it will be covered in dirt) but the blood part was harder because blood doesn't stay red for very long. But at the end he had some really great commentary, looking back at the question he said

> So, your question though, "what is the _best_ way"... The answer is, _there > is no_ , there is no best way! There is the way you figure out how to do it. > Yeah! That's really the thing. It may be that you've gotta, like, _take a > brush_ and kinda work at a whole bunch of different bills, and then take the > stack and then effect the stack, right?, I think that's like a multi-stage > process, and then you should do some tests with different paints and see, > like, under the lighting conditions these will be seen—I don't know if it's > for a theater or a film—does it communicate? Does it _tell you_ that it's > bloody, dirty money? That's the question to be asking, you gotta hold it up, > look at it, _[mimes looking at it and pausing and thinking] "does that sell > to me?"—and ask other people, "does this sell?"... and like most of the time > they're gonna go, "no," and you're gonna keep on going. But it's trial and > error.

I present this advice to you in part as a way of combating decision fatigue. It's gonna be trial and error, there's not gonna be a 'best way,' so spending too much time up-front trying to figure out _what is that best way* is gonna be a waste of your precious limited resources of attention and drive.

Because the actual definition of "best" is coming from these extrinsic factors. Sure you don't have lighting. But maybe you have a constraint that you would like to build a JavaScript game around the same rules engine as you're using to analyze the game and figure out cheap play and winning/losing, and it would be really tremendously inconvenient if you discovered that the two rules engines are subtly different and your analysis misses a loophole that breaks your JavaScript game. So you write the analysis engine in Node.js or so, so that you can reuse identical code in both places—or maybe JS is an inconvenient language because it does not have a great library that some other language does, like maybe you need to do a Fast Fourier Transform as part of this game so now you have to switch to a client-server model with the server having access to your FFT library. I don't know. But the decision is made not by which technology is intrinsically better, just like the decision of which red goes into your blood paint is not about which paint is intrinsically better.

Two minor tips,

(1) I commented recently in another post that you should not concern yourself at all about scaling problems. I want to repeat that here. On initial selection of technology, do _not_ worry about whether it scales. On initial selection of algorithms, it is even acceptable to brute force through some _n_! number of ways of permuting some elements until you find some better heuristic. Always start with doing it whatever is the easiest way for you personally, because _you do not know until you see it in its eventual lighting_ what parts will and won't work. It may be that this _n_! is indeed too long, mostly _n_ is small but every once in a while it goes to 12, 13, 14, or even 15. But it may also turn out that the final decision can be effortlessly cached and then it becomes O(1) after that, so it is a one-time cost that doesn't need to be recalculated. Or maybe it does. Spend all of your time optimizing that, and you may find out that _n_ is never more than 8 in practice and the thing completes in some fraction of a second. You don't know how to choose tech or algorithms to scale until you know what your scaling problems are, and when you know that you'll be able to measure them. Never start with Kubernetes, never start with anything intricate, just do the easiest thing which might work and then see why it doesn't. And this solves a lot of decision fatigue.

(2) In addition to ease, you might consider joy. Start writing the thing in Haskell, if that will bring you joy. You may find that with a Data.Map.Strict and a System.Random.StdGen that you can very easily load a dictionary of names and frequencies into Haskell and then randomly generate a name according to that frequency table, and maybe that is fun to you, that this fits in just a couple lines of code. If you are playing then you aren't nearly as subject to decision fatigue. Nobody sits there with a box of lego trying to make a castle going "but is the 2x4x3 brick a _better_ material to build this castle rather than say the thinner, longer walls of a 1x6x3 brick? What about a 2x4x1 brick, a larger number of thinner layers in case I need curvy designs built into the walls?" Like those decisions do have to be made but you kind of just _make_ them and if it's wrong you unmake them later, and you don't care because you're _playing around_ and so it doesn't feel like a big decision to you.

Those are my three pieces of advice. There is no best way there is just the way that you figure out which does the thing; do whatever comes easiest to you and worry about making it better later; and feel free to play around with other things you're curious about.

1: [https://www.youtube.com/watch?v=igEqC3snaYY](https://www.youtube.com/watch?v=igEqC3snaYY)

</comment><comment><USER75> Use frameworks.

<comment><USER76> Very funny: for me frameworks are like the old saying: you had a problem and you chose X? Now you have two problems. Good framework help, bad frameworks are a disaster..</comment></comment>


Unexpected DuckDuckGo search for "ruby gsub!" - dj-wonk http://djwonk.tumblr.com/post/55257965895/duckduckhack-squatting

<comment><AUTHOR> I put the query in quotes and got it to work. Ddg reserves the "!" syntax for bang and ddhack searches. This is probably what you were looking for: [http://stackoverflow.com/questions/1234741/ruby-gsub- regex-m...](http://stackoverflow.com/questions/1234741/ruby-gsub-regex- modifiers)</comment>


Netflix introduces new plans and price changes - <AUTHOR> http://blog.netflix.com/2011/07/netflix-introduces-new-plans-and.html <comment><USER2> Does anyone share my opinion that Netflix should have taken this opportunity to clarify as to why these price hikes are inevitable, due to the sky high content licensing costs they themselves have to pay to the content providers to keep streaming possible. I didnt see any mention of this in their entire PR release and I think at least the community would have read that and not perceived this announcement as a "more money grab" and as Netflix doing what it has to, to keep offering the best content available for streaming.

I think it threw away that chance and left the door open to a lot of these "entitlement" type comments that harp about how Netflix used to charge $8 per month and can never ever change that. Ever.

I for one, plan to stay with Netflix and opt for the Streaming option as long as it makes sense. As for DVD/Bluray, I will go to my neighborhood Redbox.

Blockbuster? You, I havent yet gotten over the $4.99 rental fee, so you stay in the shit list for a little while longer.

<comment><USER3> The streaming prices didn't change, so this isn't a licensing issue.

<comment><USER4> [http://money.cnn.com/2011/07/08/technology/netflix_starz_con...](http://money.cnn.com/2011/07/08/technology/netflix_starz_contract/index.htm)

 _"Netflix has another year or two on most of these contracts, and then the game completely changes," says Michael Pachter, analyst at Wedbush Securities._

 _Pachter predicts Netflix's streaming content licensing costs will rise from $180 million in 2010 to a whopping $1.98 billion in 2012._

<comment><USER5> Michael Pachter is an analyst for a private equity firm. Google for some choice opinion and meta-analysis.

And for all we know, Wedbush is short on NFLX.

People have been parroting this guys opinion as if it's fact. It's worthwhile analysis, perhaps even correct, but they've got money in this game on one side or the other and without knowing which, this opinion is useless.

<comment><USER4> Your skepticism is well-reasoned and fair.

All I'm saying is, Netflix's actions today would seem to point to Pachter being correct.

</comment></comment></comment></comment></comment><comment><USER6> I'm really unclear how the 1 disk out at a time is 'unlimited'. It's more along the lines of 'either I or my wife can see our choice'. And to call their streaming unlimited ignores the lack of depth in their streaming catalog.

I really only want the dvds for things that they don't stream. So, their new dvd plan is essentially a tax on me for their streaming plan not being good enough.

And now, given how often I actually get around to watching something, It's barely worth it at the current price, and not worth it at 2x.

[ edit quantification -- I've been a member this time for a year and a half, and just shy of half the streaming was in the first week, (two sick parents and kids to entertain will do that), and 7 titles streamed in the last year. We've gotten 7 dvds in that whole time, and watched all of 3 of them. Doing the math -- not worth $16/month. ]

<comment><USER7> The streaming selection is getting better all the time. They are adding stuff faster than I can watch it. And I already have 100's of hours in my queue.

Streaming offers more than I could ever watch...

<comment><USER8> For me a bunch of stuff has disappeared while I was trying to get through a series. I'm now wary of starting any long series for fear it will be gone before I get to the end. I used to get on netflix to see what new stuff was added, now I get on to see what's been taken off.

It really sucks when things just vanish from your queue and you find they're gone from the service for good. Feels like bait and switch.

</comment></comment></comment><comment><USER9> Looking at the comments I'm amazed at how quickly the sense of entitlement sets in. Netflix cut the cost and hassle of entertainment by 80-90% over what was traditionally available from rental stores and cable subscriptions a few years ago. Big content is seeing their profits evaporate and playing hard-ball with Netflix, and all you get is whining from customers about paying $15/month.

<comment><USER10> It doesn't matter that they cut costs compared to "what was traditionally available". What matters is they RAISED costs compared to what they had before. For a long time now, I shared a plan with my parents - they used the DVD's, I used unlimited streaming, and we were happy. Now we have to get two separate plans, and pay more. Since there's no better option, we'll do this, but I think we're fully within our rights to complain.

<comment><USER11> "I think we're fully within our rights to complain."

Wait, what? You were violating their terms of service and you're complaining because they're raising the price you will have to pay to keep violating their terms of service? It's not like they're even threatening to cut you off.

I'm pissed they're raising my plan, but certainly you must have known you were getting away with something.

<comment><USER12> Surely it is only a TOS violation if he doesn't live with his parents.

</comment></comment></comment></comment><comment><USER13> My problem with this announcement is they try and tell their customers what a good deal this is for them when it is obviously not good for them. It's a more expensive deal then what they currently have, if they had been upfront about it and said "our costs are going up due to content providers charging more for their content" or "in order to acquire more premium content for our streaming service we need to charge more" then I think people wouldn't have such an issue.

It's the worse deal + treating customers like they won't notice it that is the problem.

<comment><USER4> At the very least, it could have been spun as a move "to better serve our streaming customers with more premium content," which might have at least rescued the post from the level of "insulting."

</comment></comment><comment><USER14> I wonder how many Netflix members are also Amazon Prime members. I'm currently on a $15/mo 2-disc/streaming plan. But I also have Amazon Prime. I have the Amazon channel on my Roku and have checked out the catalog a couple times. At a glance, it looks pretty similar to Netflix. It never occurred to me to use it because streaming was included in my Netflix plan and I've already been using it for years.

I'm not so much bothered by the price hike. My price will go up to $20/mo. I'm not going to gripe too much considering how much I use Netflix. But now that DVDs and streaming are separate plans it creates a strong incentive for me to use Amazon Prime for streaming. I'm already paying for it so I can get the free shipping. Now I can change my Netflix plan from $15/mo (soon to be $20/mo) to $7.99/mo and get the same overall service. I wonder if they thought this through.

<comment><USER15> That was my first thought as well. I'll almost certainly drop my Netflix streaming entirely come September 1st, and just use Prime for streaming (also convenient because Amazon has a pretty good selection of newer/better content you can pay for, and this way I don't have to make sure I can play Netflix AND Prime on my home theater device).

On the other hand, my guess is that the number of Prime subscribers is tiny compared to the number of Netflix subscribers. So while this could be a great opportunity for Amazon to do something about that, I don't think Netflix has to worry about losing huge numbers of subscribers to Amazon as things stand.

</comment></comment><comment><USER16> TLDR: Netflix raises subscription cost 60%. The comments on the post are vicious.

They are duplicitous. DVD by mail is not a separate product. It is a workaround for the fact that they have failed to license their entire library for streaming. Now they have a perverse incentive to limit their streaming library to encourage people to pay extra for DVD service.

[edit] Now had they just said, "Hollywood is putting the screws to us, we need to raise our prices" I could respect that.

<comment><USER17> Except their costs for DVD services are a _lot_ higher (hence it being more than a $2 add on). Netflix wants everyone to stream, but because they haven't been able to license and not everyone is interested in streaming (bandwidth and viewing location being two obstacles) they will have to keep the DVD side up for quite some time.

</comment></comment><comment><USER18> I find the (dis)honesty of this post baffling. I understand that they want to increase prices, whether because of greed, licensing, or other costs - I don't care. What seems extremely dishonest to me is to say that this somehow benefits the customer when it just doesn't. People want streaming w/ physical DVD as a backup for things that aren't there on streaming. This, therefore, is just a price increase.

</comment><comment><USER19> I pay ~100/month for cable. I've had a Netflix subscription for ~6 months. Since subscribing to Netflix, my girlfriend and I have watched less than 20 hours of television via cable. We maintain a cable subscription for pretty much the same reason people rationalize a landline phone (just in case).

Netflix can raise their prices about 10x before I'd even consider not renewing my subscription.

"But comparing Netflix to Cable is a bullshit comparison, the content on Netflix is way less" you might say. In theory, you are right. The content available via Instant Watch is way limited; and it has less newer content.

All I know is that since we've started using Netflix, I've stopped buying DVD's (I used to order 15-20 a week from Amazon), I've stopped watching the DVD's I already own (I have about 1000 sitting in giant plastic tubs in the closet that I never dig through), and I've stopped watching regular television.

<comment><USER20> 15-20 a week from Amazon? What the fuck. I know one series you may end up on: Hoarders.

<comment><USER19> Once or twice a year I'd prune out all the movies that I was certain I'd never want to watch again (Shallow Hal, I'm looking squarely at you).

I did the same thing with CD's when I was younger. Thankfully, the universe ran out of music that I like.

</comment></comment></comment><comment><USER21> I really think they could have done a much better job of framing the discussion around this increase. Talking about why they're doing it (not some B.S. about how "they really want to show people that they are committed to DVDs by mail") would have been appreciated.

Customers are not stupid. They see right through PR speak, and you can clearly see that in the comments.

<comment><USER22> I think your post nailed what's intriguing me right now: Netflix did a terrible job communicating these changes. It's odd to me to see such a large, well-liked company spend so much of their social capital (brand loyalty or belovedness) without better messaging.

For example, in an age where bundling is ubiquitous, I think Netflix needed to have a better explanation for why one service is being split into two and why there's no discount for joining both. Netflix needed to do a two-pronged approach -- here's what we're going to do for you, and here's what you're going to do for us. We all understood the latter (we're going to pay more), but nobody gets what Netflix is offering in return.

</comment></comment><comment><USER23> I don't know why people are complaining so much. The company did exactly what they should have - they hiked the price to stay in business and clearly informed their customers in advance. Evidently many people were abusing the unlimited streaming + DVD subscription before and it was not cost-effective for the company to continue to offer the deal.

Percentage-wise while it sounds a huge increase, it is absolutely nothing when you look at the real dollars. My cell phone bill is $100+, ISP is $70+, web hosting is $30+, and I pay $10+/month for many different web services (include many startups I found via HN). How is $8/mo for renting 3-4 DVDs a month too high? Sure, it was $2 before but you can't expect any company to make money on deals that get abused by more than a few.

I'd rather have Netflix charge their customers appropriately than go out of business or start nickel and diming like airlines or cellphone companies.

<comment><USER24> The pricing doesn't seem all that great. Take $7.99 per month for 1 DVD out. That equals to 8 DVDs rented for one of those DVD rental boxes in a grocery store (RedBox, BlockBuster) assuming you return them the next day. In order for you to rent 8 DVDs in 30 day month, you have to be getting new DVDs every 3.75 days.

So basically, in order for it to equal the cost of a comparable product, you have to get the DVD and watch it the same night, then ship it back and hope 2.75 days is enough for Netflix to ship you another one.

Don't know about others here, but I don't really get time to watch DVDs during work days. This leaves the weekend, so for $8 a month, I can rent 2 DVDs per weekend and receive greater amount of entertainment during a more convenient time.

So using your example of 4 DVDs per month, that's $2 per with Netflix or $1 (50% less) per with box rental services. So in terms of actual spending, you are still only saving 4 bucks (not even a cup of coffee), but % wise, you save 50%.

(and yes, I go to the store regularly, so I'm not counting cost of gas in this example)

Now, if they only had the latest stuff in the streaming catalog... that would be entirely different story.

<comment><USER25> If you only watch new releases, your math makes sense.

But the big draw of Netflix DVD by mail is its enormous back catalog. The size of the Redbox library pales in comparison.

<comment><USER24> Very true, and that is also where their streaming service is reasonably good. Although, there are still holes.

</comment></comment></comment></comment><comment><AUTHOR> The really bad news: No more Unlimited Streaming + Unlimited DVD combines plan.

\---

 _Second, we are separating unlimited DVDs by mail and unlimited streaming into separate plans to better reflect the costs of each and to give our members a choice: a streaming only plan, a DVD only plan or the option to subscribe to both. With this change, we will no longer offer a plan that includes both unlimited streaming and DVDs by mail.

So for instance, our current $9.99 a month membership for unlimited streaming and unlimited DVDs will be split into 2 distinct plans:

Plan 1: Unlimited Streaming (no DVDs) for $7.99 a month Plan 2: Unlimited DVDs, 1 out at-a-time (no streaming), for $7.99 a month.

The price for getting both of these plans will be $15.98 a month ($7.99 + $7.99). For new members, these changes are effective immediately; for existing members, the new pricing will start for charges on or after September 1, 2011._

<comment><USER5> So for folks like me, who have Unlimited Streaming + 1 Disc + Bluray, we've been paying $11.99 before taxes.

Now, we'll be paying $17.99.

That is a very significant increase and very unfortunate.

I don't begrudge what they're doing: Weaning you off your DVD habit and onto their streaming service.

But I just think they are jumping the gun. Get some more first-run content available first.

As it is, I'm going to take it on the chin and pay the extra $6, but with a lot less love for Netflix, for at least a little while until I forget about this.

<comment><USER26> "I don't begrudge what they're doing: Weaning you off your DVD habit and onto their streaming service."

Neither would I, if they weren't REDUCING the streaming service from my perspective. Dozens of movies on my streaming queue have disappeared before I could get to them - something I didn't mind so much so long as I could at least get the disc version.

General consensus seems: if pretty much everything were available streaming, fine - but it's not, and it's that "not" part which is small enough to make the DVD plan too expensive yet the content is personally important enough that we'll pay anyway.

<comment><USER5> I agree, I hate that. The nuts and bolts don't matter, bad service is bad service, but in case you're just curious, the reason that most often happens is due to their StarzPlay agreement.

A lot of the decent newer movies on their service come from their contract with Starz to stream any of the movies currently playing on that network.

Well, Starz only gets movies for a certain period (same as any other TV network). So when the run is over on Starz, it's removed from netflix as well.

This isn't the entire story, but I've found 9/10 of the movies that are removed from my instant queue are because of this.

</comment></comment></comment></comment><comment><USER27> I've taken to getting DVDs from my local library.

\- I can reserve online and they'll get it from any library in the network.

\- Generally get new release DVDs much faster then Netflix

\- Get entire seasons of TV shows at once instead of a disc at a time.

\- Free

The big negative is I have to actually go and get them, but I generally pass the library daily, so it isn't that big of a deal.

</comment><comment><USER28> This sucks. The streaming collection sucks even more. Every time I login the only titles being added are bottom rated movies and "Mock busters". Complete crap honestly.

It also looks like the meat of the customers are in these lower end plans.

I have no intention of passing Netflix on as just another cable bill.

 __We need more innovation in this space. __

</comment><comment><USER20> Netflix brought this on themselves by including streaming in the plans for free to start with, which gave the message that this should be valued at $0. Now they want to charge $8 for that, and should not be surprised if there is a backlash.

</comment><comment><USER29> seems nothing more than just a price hike.

at the very least, they could have thrown in some good news about how they are increasing the quality of each service by adding a ton more stuff to netflix instant etc.

<comment><USER30> Unfortunately their streaming catalog has just _decreased_ recently as a result of ongoing negotiations with sony. All of this is probably in preparation for the fact that streaming rights are set to increase dramatically over the next 2-3 years

</comment></comment><comment><USER31> I think this is a horrible idea. I was actually thinking about upgrading my unlimited streaming plan to get the unlimited dvds option for $9.99. That price is such a good deal and I think it attracted a lot of customers because they were getting bang for their buck. But now that Netflix has announced this new pricing schema, I will definitely will not be doing so and I'm sure many customers are unhappy about this change.

</comment><comment><USER32> For everyone complaining in this thread, I will remind them of the article from several days ago indicating studios have increased their streaming licensing costs from ~180 million to ~1.98 Billion _.

If they think this price increase is enough to stay afloat, honestly, I'm impressed

_[http://money.cnn.com/2011/07/08/technology/netflix_starz_con...](http://money.cnn.com/2011/07/08/technology/netflix_starz_contract/index.htm)

<comment><USER20> They didn't actually raise the price of a streaming-only plan though.

</comment></comment><comment><USER33> I wonder how many people now live close enough to a Redbox location that dropping the Netflix DVD service and going streaming + Redbox ends up being cheaper and affording of more DVDs/month.

<comment><USER34> Interesting point. Since Redbox is $1 a movie and the "1 movie at a time" Netflix plan is a minimum of about $.80 per movie, it really does make the two pricing plans pretty equal. The Netflix cost per disc goes up if you don't watch and return them as soon as possible.

On top of that, Redbox would let you get four movies on a Friday night to watch Friday & Saturday while Netflix would require you to watch movies during the work week (to keep the price per disc equal, at least).

</comment></comment><comment><USER35> To those who are unhappy that customers are whining, I'd like to offer some context:

The instant viewing section is almost unusable since they launched their layout redesign in early June. The only logical explanation for introducing such a poor UX is to restrict users from accessing content in the first place, to reduce costs.

There continue to be a substantial number of complaints following that redesign, to which Netflix never adequately responded. Now they are raising prices on an already reduced customer experience. It's possible that Netflix could have gotten away with raising prices (with a reasonable explanation for doing so), but this change is happening in a broader context where Netflix is essentially taking its customers for a ride.

I suppose I could be completely wrong. The redesign might offer a wonderful experience that somehow I can't grasp. But that seems unlikely.

</comment><comment><USER36> There's actually a reason for this: [http://money.cnn.com/2011/07/08/technology/netflix_starz_con...](http://money.cnn.com/2011/07/08/technology/netflix_starz_contract/)

People can complain all they want, but the price increases are necessary.

<comment><USER37> If it's a price increase because costs went up, then say so. We might not like it, but we'll understand. Don't spin it to pretend that they're doing something for our benefit.

</comment></comment><comment> brown9-2 The oddest part to me about this pricing announcement is that the company announces a new set of plans, but only mentions the price of _just one_ option in the announcement - the one in which prices are rising the highest (1 dvd at a time plus streaming).

I am currently paying for 2 DVDs at a time plus streaming, for $14.99/month. According to the recently updated Your Account page, this will cost $19.99 in a few months, a price raise of 33%.

Not as dramatic as the rise mentioned in the announcement - so why not mention that? Why make me hunt for how much other plans will be changing?

<comment><USER38> I'm pretty sure that was by far the most popular plan.

</comment></comment><comment><USER39> This sure sets the table for spinning off the DVD rental product. Prior to this arrangement the two were practically inseparable.

</comment><comment><USER40> Pay $7.99 and have both by switching your plan during the month when you want streaming and when you want DVDs.

</comment><comment><USER41> I feel like this is a chicken and egg scenario between big media wanting more for their content and consumers wanting a better selection of first run movies via streaming. Netflix (at its current pricing structure I assume from the comments here) can't afford newer titles however people want a better selection in the streaming section. One's gotta give and I feel like they chose to go with letting the customer pay more in an attempt to secure better streaming titles. Unfortunately in the climate of hearing about monthly caps from ISPs I don't feel like it was the best choice. I am going to go back to physical medium, and somewhat debating if I even want to continue that. $12 is 3 decent titles from a console service or Amazon a month. A la carte will win the day.

edit: clarity of second sentence.

<comment><USER42> Contrary to what you've said here - I've never been a fan of a la carte pricing. I want the unlimited plan. When I get home from work - I generally have netflix on in the background with some documentary or other while I do housework or hack on stuff - same as I'm going to sleep. I probably play 3-4 titles every single day. Clearly a la carte pricing would not be a viable option for streaming 90-120 programs a month.

<comment><USER43> My use case is very similar and, as such, I agree with you. Unfortunately, given unlimited plans, heavy usage like ours tends to be subsidised by people who aren't anywhere near the average usage but still pay the same amount. I'm generally in favour of such subsidies (even for services where I'm an underutiliser), but I don't believe this to be a popular opinion since it's "unfair".

</comment></comment></comment><comment><USER44> Random aside: The Netflix blog doesn't have page titles!

</comment><comment><USER45> I appreciate the overall disturbance in the rental and cable industry that netflix pulled off, but as a canadian ex-customer, this will not get me back. In fact, it still feels like a liability when you couple a really bad selection with our shitty bandwidth caps.

</comment><comment><USER46> This was a botched attempt at spinning bad news into something else. If the message was more forthcoming I suspect there'd be a lot less ire. I'm unlikely to opt for a streaming+dvd plan. Hey, maybe I'll get some stuff done around the house!

</comment><comment><USER47> By looks of the comments I guess people don't understand if Netflix streamed everything they offered on DVD then A) Cable TV business model would crumble bringing down billions of dollars or B) It would have to be as costly as cable TV.

Netflix streaming is great and it's turned this once illegal downloader into a consumer.

Im sure in the future they will offer high priced streaming plans that offer more, but of course not too much more. Understandably Hollywood does not want to cut off a huge revenue stream and all of us entrepreneur are smart enough to know this ... the general public not so much.

</comment><comment><USER48> Even at that price it's a steal. It should be at least 5x more. I really don't see how netflix pulled it off with content providers, they must have a really large user base i guess. Also, I've seen a lot of people talking about "money grab" - consider that entertainment production is a REALLY expensive sport, with each product considered a startup in its own right. Lots of them aren't successful and tag along their successful brothers.

</comment><comment><USER26> I'm on the "unlimited 2-at-a-time" plan 'cuz my wife & I have separate queues (sappy romantic comedies vs. sci-fi action).

BIG QUESTION: how will Netflix handle the distribution of rather large queues now? We've spent quite some time assembling three queues (2 DVD and 1 streaming) totaling some 400 movies, and will be quite cheesed off if 2/3rds of it disappears just because the service provider encouraged/forced us to switch plans.

<comment><USER49> I'm guessing that if you backed up the queue that's about to be eliminated -- by saving a copy of the queue page to disk (as HTML, PDF, etc.) -- it would take you about an hour to reenter its contents into your remaining queue. Annoying, but survivable.

</comment></comment><comment><USER50> I'm pretty sure they're just passing along the licensing costs, but as little content as I consume, this is just pushing me towards iTunes where I can outright purchase what I want, with a little more 'ownership' rights and still spend roughly the same amount per month.

For heavier consumers though, $16 + a cheap Netflix streaming device is still a steal compared to satellite/cable and movie channels.

</comment><comment><USER51> Redbox + Amazon Prime is now far preferred to Netflix. Starting Sept 1st they'll see my cancellation in the mail.

</comment><comment><USER52> I would love to be able to export my movie ratings before I cancel my account. Anyone know of a way to do this?

</comment><comment><USER53> Consider the price of The Office Season 1-6 DVD set, $169.99.

Now consider the price of HD streaming The Office Season 1-6 on Netflix, $7.99/mo.

Thank you, Netflix.

[http://www.nbcuniversalstore.com/the-office- season-1-6-dvd-g...](http://www.nbcuniversalstore.com/the-office- season-1-6-dvd-gift-set/detail.php?p=282319)

<comment><USER20> Missing the point. Netflix has sizable gaps in their streaming that are only filled by the DVD plan. Filling those gaps for $2 is a lot more reasonable than $8.

<comment><USER53> No, I get the point. The services are not equal in terms of catalogue depth. They're also not equal in terms of viewing volume.

If I used the DVD plan to fill those gaps, I would be annoyed too. But I don't, I only use streaming. I suspect the majority of users were either overwhelmingly streaming or overwhelmingly DVD oriented. The cost to fill the gaps for those users wasn't adequately covered by the $2, and since they were the minority, they put a wall between the services.

My point was, I still perceive $7.99 unlimited streaming as a great value for the product. Gaps and all.

</comment></comment></comment><comment><USER54> Pricing gripes aside, by packaging DVDs and streaming separately, they'll have much clearer signals about which one users really want, as measured in dollars.

I'm assuming they'll be watching the numbers for DVD rental drop until it no longer makes business sense to offer that service.

</comment><comment><USER55> I wrote a post about why Netflix is actually doing a good thing here:

[http://www.bathouselabs.com/archives/yes-netflix-raised- it%E...](http://www.bathouselabs.com/archives/yes-netflix-raised- it%E2%80%99s-prices-now-chill-out/)

</comment><comment><USER56> Just to be clear, this affects ALL levels of membership, not just the low-end ones that are constantly being referenced. My (once standard) 3-at-a-time plan is going up to $24 in September.

</comment><comment><USER57> I'd be happy to pay $15-25/mo without question if they had a better streaming library. I wonder what % of their streaming customers would pay more?

</comment><comment><USER58> > Given the long life we think DVDs by mail will have...

Yes, shipping pieces of plastic around is the way of the future.

</comment><comment><USER59> Great, so if I use and want to keep BOTH services, I have to pay more to get what I already had...

</comment><comment><USER60> I understand prices rise...I am just pissed for me is it almost $6/month for the same plan.

</comment><comment><USER61> Gee, that's a funny way to say "we're raising the price of your subscription by $5.99"

<comment><USER43> Because that would simply be untrue. My subscription price is unchanged.

</comment></comment><comment><USER62> Really too bad to see such a large price increase, they have lost money from me.

</comment><comment><USER63> Well maybe Zediva the video on demand service that puts DVDs in physical drives and streams them will actually stand a chance of being profitable. There was some discussion on HN about it here:

<http://news.ycombinator.com/item?id=2334332>

Although I still find it hard to believe this is economically viable.

</comment><comment><USER64> They just doubled my subscription price, for the exact same content. So, I would pay another $8 for streaming content that is mostly old, and often mediocre. It's like having TBS streaming to your PC. On top of that, their encoding is often lousy, and there's no separate way to report it.</comment>


Ask HN: Tour guidebooks for business travelers - <AUTHOR>

Recently as I have traveled a lot through my local airport hubs (Orange County, CA and LAX), I find myself giving a lot of restaurant and things to do recommendations for business travelers visiting the region.
There are a lot of tour guides for regions, but would any of you be interested in a tour guide book/app for a given airport?
So say you are a business traveler flying into LAX, you would get a tour book specifically geared towards business travelers.  So for example, it would highlight restaurants good for after work, and activities good for the weekend.  Ideally it would be customized per airport region.
Things the guidebook would omit would be sleeping accommodations because the assumption is that it would already be booked through a business traveler's respective work.
Any thoughts on this? <comment><USER2> Sounds interesting. But you may want to look at online resources and other apps to see if they do not currently offer the information you are looking to provide. I am not sure how much traction your book/app would have though. There are so many travel books and apps now that your offering may get lost in the noise of the other offerings.

Perhaps, you could try partnering with existing sites/apps/books to offer this sort of information that they could incorporate into their offering. You would need to show how the experience would be for the users as well as how your information would add value.</comment>