Burnout is caused by resentment

Which sounded amazing, until this guy who dated a neuroscientist commented[2]:

No. Burnout is caused when you repeatedly make large amounts of sacrifice and or effort into high-risk problems that fail. It's the result of a negative prediction error in the nucleus accumbens. You effectively condition your brain to associate work with failure.

Subconsciously, then eventually, consciously, you wonder if it's worth it. The best way to prevent burnout is to follow up a serious failure with doing small things that you know are going to work. As a biologist, I frequently put in 50-70 and sometimes 100 hour workweeks. The very nature of experimental science (lots of unkowns) means that failure happens. The nature of the culture means that grad students are "groomed" by sticking them on low-probability of success, high reward fishing expeditions (gotta get those nature, science papers) I used to burn out for months after accumulating many many hours of work on high-risk projects. I saw other grad students get it really bad, and burn out for years.

During my first postdoc, I dated a neuroscientist and reprogrammed my work habits. On the heels of the failure of a project where I have spent weeks building up for, I will quickly force myself to do routine molecular biology, or general lab tasks, or a repeat of an experiment that I have gotten to work in the past. These all have an immediate reward. Now I don't burn out anymore, and find it easier to re-attempt very difficult things, with a clearer mindset.

For coders, I would posit that most burnout comes on the heels of failure that is not in the hands of the coder (management decisions, market realities, etc). My suggested remedy would be to reassociate work with success by doing routine things such as debugging or code testing that will restore the act of working with the little "pops" of endorphins.

That is not to say that having a healthy life schedule makes burnout less likely (I think it does; and one should have a healthy lifestyle for its own sake) but I don't think it addresses the main issue.

Then I finally realized how many times I've burnt out in my life, and I became much better into avoiding it. Which is really hard to do.

And it seems to me that this is one of the many points that Ben Horowitz talks about on his What’s The Most Difficult CEO Skill? Managing Your Own Psychology[3]

[1] http://iamnotaprogrammer.com/Burnout-is-caused-by-resentment...

[2] http://iamnotaprogrammer.com/Burnout-is-caused-by-resentment...

[3] http://bhorowitz.com/2011/04/01/what%E2%80%99s-the-most-diff...

His talk about "Boundaries" taught me one of the most illuminating concepts I've learned in my career, about separation of concerns, functional core & imperative shell, unit testing, etc., and radically changed the way I write code - the talk uses Ruby as an example, but can be applicable to any language under the sun.

In fact, watch all five of them, they all reach this outstanding level of being educational, interesting and funny at the same time.

1. Pick one strategy to test at a time and commit to it

2. Pick one platform/audience and commit

3. Have a newsletter and funnel people to it

These steps are mostly because I'm a solo founder and don't have a lot of time. If I experimented with multiple strategies at the same time, I'd quickly run out of time for development.

And building a newsletter is just the most reliable way of contacting people en mass these days. Twitter/Facebook/etc. all have algorithms that can filter you out. Email is a more reliable way of connecting.

As far as marketing strategies go, as a dev, I'd highly recommend the "indie maker / build in public" strategy. This is perfect for devs because it means a lot of your effort is duplicated as marketing.

Here's how it works:

1. Sign up for Makerlog/Twitter/WIP.chat or another community that lets you build in public

2. Post what you're working on before, during, and after it's done

3. Ask for advice and feedback when you need it

This will let people get involved in your product's development and give them a reason to cheer you on when you launch your product or get a new customer. My most popular tweet of the past year (other than my launch post) was getting my first customer. It was also responsible for me getting my second and third customers.

Once you've gotten comfortable on these platforms, you can try this more full process (which I outlined for myself yesterday):

1. Post a rough idea for an article/product/ebook/course to your social network of choice and get a feel for what people like or don't like about the idea. This doesn't have to be a fancy post, just a sentence or two. E.g. "I'm thinking of making a beginner JS course, what do you think?"

2. A few days later, ask a question about how to proceed with your idea or if anyone has done it before. E.g. "Which course platform for releasing paid courses do you like the best?"

3. Again, a few days later, post an outline of your approach for tackling this idea or talk about the content/features you're thinking about including in it. This will again help you measure interest and see where the real value of your idea is. E.g. "Here's what I plan on covering in my course: ___. Would this be useful for beginners to JS?"

4. Work for a few days. Then post a preview of the progress you've made so far. This could be a few lines of code, a blurry screenshot of the final design, or even a picture of you working on your laptop. Just show people that you're actively working on this and give them something to get excited by. Remember: they're probably just as interested in your journey as the final product. Don't focus on the product too much — you're also telling a story about what it takes to build a product.

5. Offer a taste of the final product. Make a thread or post with some of the actual content/features of the ebook/post/product. This could be a 5 minute video from the first lesson of your course. A screencast of you using your app. Or a the first page or two from your eBook.

6. Post a beta tester sign up form that gives people early (or instant) access to the MVP version of your idea. People who sign up are your true fans and will probably give you the best feedback over time. This form can be made with any email marketing software.

7. A week or two later, post a few quotes from early users showing what people said about their first experience of your product. E.g. "I wish I had this when I was first learning JS. I'm learning new things every 2 minutes!"

8. Finally, plan your launch! A few weeks or days before your big launch day, tell people you're launching. Tell them your goals, your hopes, and what your product will let people do (that they couldn't do before) once it's out in the world.

9. Post on Product Hunt, Hacker News, as well as on your social platform of choice. Make sure the product doesn't feel done yet. You want it to be a little rough around the edges. But it should solve a problem and that problem should be clearly stated on the home page.

10. After the launch, post about a piece of feedback you got from a user who signed up during the launch. It could be negative or positive piece of feedback, as long as it was useful to you.

11. Post about an update you made because of user feedback. This will show that your audience is important to you and are active participants in your journey.

12. Don't stop posting. Repeat the last two step (gathering feedback and making improvements to the product) over and over again until your product really starts to get good.

12. After you've improved the product enough that it can be considered a 2.0, launch it again.

The nice thing about this process is that it's symbiotic. Your audience benefits just as much as you do: for every idea of theirs you implement, they benefit by a) seeing their opinions matter and b) getting a final product that's more useful to them.

And, to top it off, you and your audience get to create a story together. It's the story of a fledgling idea coming into reality and finding its way. And they get to help it grow and help it along. It's a pretty magical process when it's done with intention and the desire to make people's lives better.

The basics are surprise/rarity, emotional impact/narrative (which can include comedy, tragedy, drama, etc), geometry and composition (which can include focus control, depth of field, and motion effects), and controlled colour.

Colour control is the one a lot of people miss. The aim is to have a limited colour palette - either one dominant colour, or two or three punchy related colours (complementary or contrasting on the colour wheel) against a more neutral background (white/black/grey/less often - brown.)

Too many colours are chaotic. There are exceptions which can make chaotic colour work as a feature, but if you just snap a random crowd you'll usually get a photo that lacks something, and you're not sure what.

Newspaper photo pages are good for examples. Random sample:

https://www.theguardian.com/news/gallery/2020/jul/14/sammy-t...

You can see how few colours most of these photos have and how often there's a strong colour contrast. A "newsy" photo of flooded buildings still has controlled colour - base of green contrasting with blue in the foreground, and further bright purple/pink contrasts in the background.

And the photo of the soldiers with masks balances black/white against the pale blue of the masks, with complementary gold highlights.

Even the prisoner photo only has three colours - green on the prison shirt, pale yellow gold on the uniform patches and buildings, and some splashes of red, which contrasts with the green.

The opera audience photo is the weakest with a pale nondescript yellow/green wash against grey/white, but it (almost) makes up for it with very strong geometric composition in the architecture.

Edit: non-representational photos usually follow the same rules. The one big exception is high end art photography which uses a couple of specialised standard palettes (usually warm on the flesh tones) and a small selection of standardised subjects that signify "art" in that market.

I think [0] that a better approach, one that’s more likely to lead to a profitable business, is to flip the strategy around. Instead of “Do customer interviews, sniff out a problem, and build a solution”, it can be more effective to find the customers where they hang out (online is ideal), observe the problems they complain about, and crucially observe what they already pay for.

For one, it avoids the natural bias they’ll have while answering questions (they’ll very likely tell you what you want to hear to try to be “helpful”).

For another, it helps you create something they’ll actually want, and pay for, by fitting in with their existing habits and worldviews.

Going into a conversion with the idea of “I need a problem to build a SaaS for” is only one level better than “I need to validate that they want my idea”. The format of the solution is already pre-decided — which is no good if they don’t already pay for SaaS. That’s an uphill battle you definitely don’t want as a solo founder! “If I could just make them see how great this is...” is a rocky start for a business plan.

Choosing an audience you know and already understand is a big advantage. Picking one you aren’t part of is harder.

You don’t need to be new and unique to be profitable. You don’t need to invent a new kind of product or solve a problem that nobody else has solved. All of that just makes it harder :)

[0] I think this because of Amy Hoy and Alex Hillman and their 30x500 class that teaches this approach. Not my own invention :) I’ve had success with it though, and other have too, so I want to give credit where it’s due. They have a lot of great free material at https://stackingthebricks.com

These products do not appear obviously commercializable and multiple years invested into them without materially improving the businesses does not decrease my confidence in that snap judgment. You could probably talk to business owners with problems, launch an (appropriately priced; hundreds to thousands of dollars per year) product against those problems, build contingent on getting 10 commits to buy, and be at +/- $100k in 12 to 18 months. Many people with less technical and writing ability have done this in e.g. the MicroConf community. If you want the best paint-by-numbers approach to it I've seen, c.f. https://www.youtube.com/watch?v=otbnC2zE2rw&t=2s

(I'll note that What Got Done is probably a viable boutique SaaS business if you somehow figured out distribution for it, at price points between $50 and $200 per month. My confidence on this approaches total. HNers skeptical because it is technically trivial should probably reflect for a moment on how much time is spent on standups at a company with 20 or 200 engineers, what one hour of their time is worth, and how likely that company is to put an engineer on this project specifically.)

If you run an API-based business in the future: Usage-based billing is a really tricky business model for a solo developer. Note that you can say "Usage-based billing but we have a minimum commitment", and probably should prior to doing speculative integration engineering work. Your minimum commitment should be north of $1,000 per month; practically nobody can integrate with your API for cheaper than a thousand dollars of engineering time, right.

This also counsels aiming at problems amenable to solutions with APIs which are trivially worth $1,000++ a month to many businesses which can hire engineers. Parsing recipe ingredients seems like a very constrained problem space. Consider e.g. parsing W-2s or bank statements or similar; many more businesses naturally care about intake of those documents, getting accurate data from them, and introducing that data into a lucrative business process that they have.

I would encourage you, to the maximum extent compatible with your sanity, to prioritize "Will this get me more customers?" over behind-the-scenes investments like CI/CD which are very appropriate to Google but will under no circumstance show up in next year's report as One Of The Most Important Things I Did This Year.

For similar reasons, I would suggest devoting approximately zero cycles to cost control. You don't have a cost problem and no amount of cost control will bend the curve of your current businesses to sustainability. You have a revenue problem. Your desired state in the medium term will make it economically irrational for you to think for more than a minute about a $50 a month SaaS expense; marketing and sales gets you to that desired state, not cost control.

    # ARGV=( "one two", "three four" )

    # CORRECT
    su root -c 'rm "$@"' -- "$@"
    rm "one two" "three four"

    # incorrect
    su root -c "rm \"$@\""
    rm one two three four    # wrong arguments

    # incorrect
    su root -c "rm" "$@"
    rm                       # -c doesn't use arguments

    # incorrect
    su root -c 'rm "$@"' "$@"
    rm "three four"          # loses the first argument (?!)

    # incorrect:
    su root "rm" "$*"
    rm one two three four    # wrong arguments

    # incorrect:
    su root "rm $*"
    "rm one two three four"  # command not found

    # CORRECT
    ssh remote -- 'rm '"$(printf '%q ' "$@")"
    rm "one two" "three four"

    # incorrect
    ssh remote 'rm '$(printf '%q ' "$*")
    rm "one two three four"  # wrong arguments

    # incorrect
    ssh remote rm "$@"
    rm one two three four    # wrong arguments

    # incorrect
    ssh remote "rm \"$@\""
    rm "one two three four"  # wrong arguments

    # incorrect
    ssh remote 'rm "$@"' "$@"
    rm one two three four    # wrong arguments

    # incorrect:
    ssh remote "rm" "$*"
    rm one two three four    # wrong arguments

    # incorrect:
    ssh remote "rm" "$*"
    rm one two three four    # wrong arguments

The economics change completely if you self-publish or publish with a smaller firm that has marketing abilities (and better royalty rates).

Self publishing is awesome because you keep all the money, but it takes years to build an audience.

Honestly, writing the manuscript is the easy part. Building an audience, marketing it, keeping the book up-to-date is just as hard as the original manuscript. But it can really pay off.

I'm ready to share this now: our book on Angular 2 did $400k a revenue, per year, the first two years. BUT the reason this was possible was we had a huge audience that trusted us.

Email marketing is more powerful in this space than you might believe. Even today.

If I could give you one piece of advice, it would be to sign up for Ramit Sethi's emails and watch how he markets. After that, get every book on copywriting you can and learn how to write copy.

(Also, if you're interested in writing books with me for 50% royalties, my email is in my profile. I want to do books on Python and Node this year.)

    - Cars
    - Bottled water
    - Computer monitors

How do they differentiate and sell you cars then? Branding, positioning, marketing. They sell the feeling of owning the car rather than any true technical differentiation, because those really don't matter as much in non-technical markets.

Bottle water is another case. I'll generalize and say that most bottled water is pretty much the same. Or, let's put it another way, no bottled water has magical properties that make it significantly better than the others.

Again, marketing. They are selling you an image. In some cases it's a glass bottle with a different feel or a social mission. The product, however, that thing you drink, most of which you are going to urinate, is basically the same. If you position the product well you can command much higher pricing than the competition.

Computer monitors fall under the same category. Nobody cares any more outside of those using them for very specific applications. There are only a few companies who make LCD panels. Every single computer monitor buys from them. So, if you buy a 24 inch HP vs a Dell monitor they very likely have exactly the same LG or Samsung panel inside. They might even share the rest of the electronics. For most computer users these products are perfectly interchangeable; they just don't care because it makes no difference at all.

Not sure how computer monitor makers differentiate their offerings any more to the masses. Sure, there are folks who are more comfortable with one brand over the other (despite the fact that it might actually be exactly the same product inside) and, of course, there's pricing. This is one example of the fact that significant differentiation might not always be an absolute necessity in order to have a successful billion dollar business.

One area where they do differentiate --although consumers never see it-- would be in the terms and relationship they have with distributors and retailers. This is a big money play. For example, HP could drop two million dollars of inventory into Best Buy warehouses, effectively on consignment, and get paid based on what is sold. Best Buy, will, of course, push those products because they represent pure profit without any capital investment to speak of. This is a distribution chain differentiation that drives sales rather than differentiation to drive consumer behavior.

Books have been written about this topic. I've read a few of them over the years. Still much to learn.

  1. learn how to communicate: being a good developer requires as much (more?) social as it does technical skills. I would recommend formal training and practice.
  2. question all assumptions.
  3. there is no silver bullet (read mythical man month).
  4. fight complexity and over-engineering : get to your next MVP release.
  5. always have a releasable build (stop talking and start coding).
  6. code has little value in of itself; only rarely is a block of code reusable in other contexts.
  7. requirements are a type of code, they should be written very precicely.
  8. estimation is extrapolation (fortune telling) with unknown variables of an unknown function.
  9. release as frequently as possible, to actual users, so you can discover the actual requirements.
  10. coding is not a social activity.

1) Identify problem

2) Come up with, or look up for existing solutions

3) Develop, iterate

4) Identify and get some competitive edge

5) Keep pleasing clients

Of course, there's a ton of things underneath all this, like marketing, funding, or simply being lucky with timing.

The copy-cat method is probably the most legit, and battle-tested method. I.e, simply just copy some existing product or solution, with a known market.

The entrepreneurship scene preaches originality and novel idea to hopeful founders, but to me, it always ends up with a race for who can do something better than their competitor.

I've noticed that in many countries outside US, especially western Europe, some of the largest startups are those that play-by-play copy successful US startups, probably hoping to get acquired once the US startups start expanding to said countries.

Some common example tactics include:

Broken Backlink Building: Create high quality page, then look for pages that have historically served the same searcher intent and attracted backlinks but are now no longer available and reach out to sites that linked to that and offer them the newer resource to fix their broken link.

Skyscraper technique: Make a list of similar pages that serve same search intent as a term or topic you are going after, sorted by relevance and links earned. Make a significantly better page, then reach out to webmasters linking to the other resource and suggest your better/more-up-to-date/relevant to readers link as an alternative.

Social Proof Pitch: Before promoting your content to Journo's and Bloggers, try to get it to the top of a subreddit or the reddit homepage or otherwise demonstrate its popularity on other social networks. Then when you pitch it you can point to it likely being a useful resource. Also works if the thing you got to do well socially is a stub of a story and you offer to write in-depth about it or about an important part of a larger story as a guest post.

Citable elements:

Make otherwise hard-to-link-to pages like landing pages easier to link to by adding relevant citable elements (charts, graphs, facts & figures) that bloggers and journo's may wish to reference.

Unlinked Brand Mentions:

Set up alerts for any time your brand is mentioned. If you see one that isn't a link but a link would be relevant in the context of the article, ask the author to make the mention a link.

HARO / SourceBottle / Reporter Connection:

Make yourself available as a subject matter expert to reporters, and when giving expert quotes, reference deeper explanations in articles already present on your site.

Reverse Guest Post: Pay or entice industry authority/influencer to write something on your site to attract additional eyeballs to your other content.

Topical Interviews / Industry Round-ups / Guest Speaking ( podcasts, video, conferences): Go places where relevant audiences already exist and get them interested in hearing more from you.

Get Friendly with Pirates: Use copyscape or reverse image search to find people who are using your content or images without proper attribution. Instead of sending take-down requests, ask that they credit, with a link the source and or do a cross domain rel canonical to the original content.

And so on, and so forth. Good Search marketers have a wide variety of tactics at their disposal. Great search marketers will only apply the relevant ones rather than trying to offer clients one-size-fits all strategies.

Edit: A lot of these are much easier with the help of some tools like ahrefs, semrush, pitchbox/buzzstream, hunter.io and the like.

What proved conclusively positive was adding a discount to the checkout process (a time-limited one did not prove successful). Just to make the customer feel that they're getting a good deal.

Once the customer was on the checkout form we'd display: "This product is almost out of stock," and when they for some reason come back to the product page or listing, we'd show: "43 people are looking at this product."

Which created a sense of urgency. This strategy wasn't legal in all countries, because it was 100% fake, but it worked wonders where it could be displayed.

Customer satisfaction skyrocketed, so... evil as it might be, it only created happy people.

You don't have to be Wall Street to figure out the bleedingly obvious solution to being a starving artist who has so much work they have to turn work away. Raise the prices. Then raise the prices. Then when you're done with that, raise the prices.

At some point you'll be too expensive for the typical businessman, which will make you absolutely crack for a certain type of person common in New York, thus defeating all efforts at being less busy. So it goes. I guess you will have to raise prices.

2. Give them a playground to fail - Offload any non-business critical tasks and let them make mistakes. No one I know ever learnt programming without making any mistakes. Immediately tell them about best practices and how to avoid such mistakes in future.

3. Show them the impact of their work - There's nothing more motivating than seeing the impact of one's work.

4. Build curiosity - Answer as many questions as you can answer. Admit when you don't know any answers and start looking it up on the web right in front of them. People pick habits by looking at their superiors.

If it's absolute beginning to programming, this video is a great way to show how difficult it is to teach a machine to do something and how clear instructions can help get things done: https://www.youtube.com/watch?v=cDA3_5982h8

----------------------------------------------

1. Find a popular SaaS product. Like Intercom, Algolia, Segment. Make sure it doesn't have a free plan. This guarantees there's a market for the tool. Check out GetLatka for ideas. https://getlatka.com

2. Build your own take on the product. Find the minimum set of features that make it valuable. 10% of the work for 80% of the value.

3. Sell it at a 50-90% discount. There will be price sensitive customers that want the popular product, but don't want to or can't afford it.

4. Target bottom of funnel marketing channels: Targeted quora questions. Paid/organic search queries. Set up retargeting ads on Facebook. Product hunt launch it. That should get you a steady stream of customers.

I don't think this is a great way to build a million dollar business, but is a very easy way to make a few hundred. Shoot me an email if I can be helpful.

-----------------------------------------------------

Don't exactly copy another product. It's damn important to reinvent defensible products that either, and hopefully do all of:

a) solve a slightly different problem

b) target different users

c) solve the problem in a 10x better, compelling way

-------------------------------------------------

TIME. Time is the MOST precious commodity. Help users SAVE TIME. Save time finding something of value to the USER. You can't "presume" how much to charge. You have to "TEST" pricing then keep jacking it up until your customers don't pay. How can you pay for something what does not offer value. Stay small. Stay NICHE. Grab a slice from a BIG market. Forget millions. slap-yo-self with fury with delusions of becoming a millionaire, and make a goal of making enough to avoid being trapped in a 9-5 lifer situation. It take a LOT of luck + skill + market segment expertise. Like you have to KNOW the market you are going to be competing in. Assisted living , senior care , retirement calculator is VERY hot now. You'll be at it after your day gig 6pm-2am testing / building / iterating. Good LUCKY. launch a free beta version learn what customers value and how much they will pay ( ask them) THEN when you have enough people crack addict addicted to your service / app start charging. Be merciless. But offer excellent customer service. Always be honest.

------------------------------------------------

While I agree with some of the tactics here (make a twist on similar ideas, contact businesses, buy a business, brush up an existing product you built)

I'm going to suggest an alternative method that has worked for me.

Start with the money.

If you want monetization to be guaranteed you need to prioritize that first.

Take this method and rinse/repeat for you and your skills.

1) How much do you really want to make from this a month, what would make you happy?

Let's say you decide $1k a month would make it worth it after time, expenses and payment processing fees.

2) You then decide how many customers you really want to have to find and how much support email you want to answer.

Usually developers pick prices like $6 and wonder why no-one buys. This low price screams a lack of confidence in the product. That you aren't taking it seriously. That you may not be around in 8 weeks.

Starting without monetization in mind or equally, pricing low is the death of a product because for someone who dislikes marketing you just set yourself a huge marketing mountain to climb.

At $6 each, finding and selling to 150+ customers - when you don't even have one yet is a huge trek to your $1k happy place.

Let's say you feel more confident about finding and serving 10 customers really well. That seems achievable, right?

So with just 10 customers we're looking at a $100 a month product, right?

Whoa, you're thinking you could never build something that's worth that much.

Maybe you're worried it's enterprise level costs now and that's not the type of product you want to build.

Don't worry, a $100 product can be really simple.

Often developers think that a big cost means solving a big problem and that a big problem needs a big solution. Not true at all.

A big problem can be solved with a small elegant solution.

3) Now we know how much we want to make and how many customers we need and how much we are going to sell it for.

We now need to find the problem we are going to solve.

So how big of a problem needs a $100 per month solution?

Not very big at all really.

Let's say a business owners time is super-conservatively worth $50-$100 an hour.

So to add value, we are looking at saving someone between 2-4 hours a month on a task they normally have to do manually. That's not too bad!

Or maybe you want to help them reduce their business costs by $200-$400. Also, very possible. Now we have the value proposition.

We know what kind of problem we are looking for, so value will be clear for the customer.

4) Now we decide _who_ this is going to be for.

Don't pick people the same as you. They have the same skills and can solve the same kinds of problems that you can.

Pick a group of people :-

- That are easily identifiable by what they call themselves on social media (blogger, podcaster, videographer, designer, public speaker etc)

- Make sure they are a group you like interacting with, that you have some experience of working with already in some way (please pick a group you like and care about)

- Make sure they are the decision maker in their own business (don't pick employees of big corps)

- What tech skills have you worked with that overlaps with this customer group?

Let's say you've worked on a few video platforms in the past so you know that space well, so you choose to help YouTubers.

5) What is the issue that we are solving?

Ok, so now we're helping YouTubers to either save 2-4+ hours a month or reduce costs by $200+ - for your $100 MRR product.

This is where we breakdown what it takes to run their business.

What stops them being more profitable?

What tasks do they do everyday?

What can be automated?

What do they hate doing in their business?

If you know this space even a little, you will have answers here.

Maybe video storage is a huge expense.

Perhaps running their community takes up too much time so they can't scale.

Is just publishing a video end to end super time consuming? Look at why.

If you don't know what matters to them, ask. Make a hypothesis and see if it's true.

In just a couple of DM's you might find that they spend a whole day a week on something repetitive. Or are spending money on something that you can optimize. Write a few possibilities down.

6) Make an offer

In just a day or two you can go from no idea, to identifying a significant pain point for a group of people that's easy to reach.

Now you consider a couple of small technical solutions for the problems you've found.

You go back to a couple of your ideal customers and make them a proposition.

Something like - "You said you spent X hours on this particular problem. If I built something to solve that, this week, would that be worth $100 to you?"

If it's a huge pain point they will bite your hand off. If you get weak responses - no worry, you've not built any code yet. You can use the conversation to get to a deal.

They might say it's worth less so you find out what features would be needed to make it worth the $100.

Maybe they suggest a different problem that is more urgent for them.

After a few conversations you should have at least a couple of paying customers and a clear solution.

8) Building

Now you know exactly what you need to build and have customers waiting. There is no excuse but to launch. This will help you focus on the truly essential code.

As you build, reach out to a few more potential customers. (we made sure they were easy to find earlier) Ask them if they have the same problem. Show them what you have.

Go through a few cycles of building and feedback. Make sure people are paying you what you set out in the beginning - or close to it.

Ask your starting customers for referrals. You'll reach your 10 customers with zero marketing spend.

You then have all of the elements needed to scale further if you wish!

Remember that code comes last in this method for a reason. Only build when you have paying customers.

https://news.ycombinator.com/item?id=18047553

#1 Change you (accept what you are unable to change)

#2 Change the other (convince them to follow your vision)

#3 Fly (divorce, quit)

#4 Stay and suffer (include drinking, doing drugs, whining)

It is amazing how many people chose number 4.

I've run 100,000+ line Rails apps in WSL (well technically through Docker, which I connect to through WSL) and I never noticed a slowdown that was bad enough to make me think "this sucks". It's always been pretty good. I run all sorts of Rails, Flask, Phoenix and Webpack driven apps and all of them run fast enough where I don't think twice about it.

Personally, I find the WSL set up somewhat close to native Linux in terms of the user experience. I'm not talking about I/O performance, but I mean how it feels to use the OS in general.

For example:

I spend 99% of my time in a WSL terminal using tmux + terminal Vim + ranger. So that takes care of coding and managing files.

Then I use a browser and other graphical apps (image / video editors) that run directly in Windows.

Dexpot sets up virtual screens with key binds that are comparable to how i3wm lets you switch and move windows to another screen.

Keypirinha lets you launch apps with a fuzzy finder (like dmenu but better IMO)

AutoHotkey lets you easily manage global hotkeys (just like i3 does) and more

When you put all of that together, you get a really really good development experience that also doubles for gaming and running programs that don't have a good alternative on Linux (such as Camtasia on Windows).

Then for the icing on the cake, since you're running Ubuntu 18.04 in WSL, you can provision WSL itself with the same exact configuration management scripts you would use to provision a production box. For me specifically I run all of the same Ansible roles against WSL that I do in production. I can set the whole thing up with 1 Ansible command. Plus my dotfiles also happen to work exactly how they do on my native Linux laptop so it's easy to keep things in sync and feeling the same.

This all runs from a i5 3.2ghz / 16GB of RAM / SSD / etc. $750 desktop built 5 years ago.

Even if Apple tax didn't exist I would still use this Windows / WSL set up if I weren't in a position where I could run Linux natively.

In my opinion, the best material for lenses is the cheapest: plain uncoated CR-39. It has the best Abbe number of any common material (lowest chromatic aberration), and good scratch resistance. I clean mine using a microfiber cloth (carefully pre-washed to remove any grit), hot water, and dish-washing detergent. This leaves them clean enough that water will "sheet" off them, leaving them visually flawless. I find dirt on the lens more annoying than reflections, so I'd rather have uncoated lenses than coated ones that won't survive aggressive cleaning.

I'd recommend CR-39 even for moderately high prescriptions. Weight of lenses increases super-linearly with size, and glasses inherently have bad off-axis performance, so there's little point wearing huge glasses where index of refraction makes a big difference. The low index of refraction of CR-39 also reduces reflections, which is important when you're omitting anti-reflective coatings. It's also worth considering that all glasses designs are trading optical performance for convenience; for maximum optical performance you need contact lenses.