jeffshek

RenTech is also known for hiring/poaching almost everyone from a former IBM voice research team.

Amazon chooses to make little/no profit as a long-term business strategy to reinvest everything.

Tesla is forced to make little/no-profit as a short-term business obligation to their suppliers.

More technical debt comes from growing quickly (engineers, turnover, employees) and changing business assumptions, not the programming language.

# max(market_cap, enterprise_value) || most_recent_private_valuation

Uber - 50bn

Palantir - 10bn

SpaceX - 40bn

AirBnB - 35bn

Dropbox - 10bn

Pininterest - 10bn

2) Stripe's most valuation is 35 billion 3) GitLab latest's valuation is 2.75 billion

In addition, the feedback they gave is now written. What if the founder lacks social etiquette and tweets "VC Y said my idea sucks because Z [some charged topic]"? If you look at the missed out on investment X/Y/Z emails that VCs sometimes release (anti-portfolios), you'll notice almost aways the releasers asks for permission first. VCs network effects largely need to be polished and appear to be knowledgeable about sectors -- giving feedback to a random startup that might be horribly wrong would hurt that reputation.

It makes sense as to why many VCs don't give feedback.

That being said, the answer is to never ask for direct feedback. Instead, you should have a middleman and backchannel. Ask the middleman to find out why they didn't like X -- this generally works. The middleman is impartial and can be objective (versus the founder who is often defensive) and is able to extract truth.

Just have to pick your head up and continue.

I learned WAY more about deploying ML in production environments than neural networks. ML DevOps was surprisingly hard. the ecosystem is a bit fragmented with managing TensorFlow / PyTorch / Docker / Nvidia dependencies. since there's SO MANY ongoing changes they have a lot of out-of-date documentation.

the backbone of the algorithms running this is from gpt-2 (openai's text generation algorithm). i experimented with almost all of the other text models including bert, transformer-xl, xlnet. i looked into ctrl (salesforce). most of them had incredibly high memory requirements, speed wasn't the fastest, or the output wasn't as good as gpt-2. this isn't a knock on the other algorithms, they were designed with the focus of answering questions in test sets (reading comprehension, etc).

i fine-tuned gpt-2 medium w/gradient checkpointing for five different datasets: legal, harry potter, game of thrones, song lyrics, academic research. training was relatively straight forward, but the data scrubbing was incredibly tedious. i'm still training/updating the research models.

reddit has made some amusing harry potter and game of thrones fanfiction w/this so far: https://www.reddit.com/r/FanFiction/comments/d5s9yh/i_made_a...

app hosted on google cloud. everything is run via docker containers (which is also hard w/nvidia). autoscaling on usage. the main inference runs off from either cascade lake (cpu, surprising reasonable performance), k80s, or p100s. i experimented with the speed and profile of them a lot.

open-sourced at https://github.com/jeffshek/writeup-frontend, https://github.com/jeffshek/open

i'm going to write a detailed blog post about the code/deployment/infrastructure soon if you're interested. love to answer any questions and get feedback! thanks!

One hack is for the medium-level models, you can actually run them on Cascade Lake (which are sort-of more optimized for ML) than traditional processors. There's a 30% performance there. Mathematically, GPU vs CPU in performance at inference time, you're paying an annoying premium!

Right now, the default writing style "medium" is running in Cascade Lake (no gpu). I also (over)optimized the microservices running the endpoints too.

I'm not certain how random users feel when knowing their selection knowing it's being used to improve an algorithm. In this case, it's relatively easy for me to log the prompt and the option that was selected -- just doing it felt a little ... bad, and I'm a little too scared of GDPR for a fun project.

The other thing is humans sometimes select the funnier option even though it may not necessarily be the best one. In a Show Reddit post, the most upvoted response is a Game of Throne's character Tyrion and a brothel story.

https://www.reddit.com/r/FanFiction/comments/d5s9yh/i_made_a...

Open-sourced Code: https://github.com/jeffshek/writeup-frontend

https://writeup.ai - It has multiple different models in here to select from (including fictions like Harry Potter, Game of Thrones and things like legal documents).

AFAIK, This is still being worked on PyTorch via XLA, but not quite there yet.

Best trick is to make sure your test coverage is strong early (I know this is easier said than done ...), then you can just merge updated requirements without ever worrying.

GitHub has a type of service that would check requirements already, it just never felt as polished as Dependabot. But it goes to show how far a committed team can prioritize over bigger players. IIRC, they still use Heroku, which seems like a lot of discipline in prioritizing the right product features over just building tech stacks in BigCloudProviders.

I found his essay particular useful in explaining how he makes decisions.

I've been meaning to add it. I'm currently switching out some of the tech infrastructure to improve readability and improve search and then will get to this, promise!

I'd be glad to add more to this. I've recently added (and credited) about 5-10 things from reddit.

If a lot of the knowledge is specialized in one area, the "trivia" (I feel this is such a negative connotation lol) has come in handy. YMMV.

- To your point, Jeremy Howard has never saved my production server (yet), but knowing how to scp, grep, cat around a list of files out has though :)

- Looking at my deck, most of the one-off questions have long half-lives. Most of these are answered as easy and are about 3-5 years before it's asked again ... personally, that's a fair tradeoff.

- Knowing certain "trivia" facts have been a hack to demonstrate expertise. It can also be used to relate to someone's experience. I interviewed a candidate once who had worked at DuckDuckGo. Having a conversation with him about experiences with "Gabe" (Who is the CEO of DuckDuckGo?) and some of his Mental Model essays immediately cut the tension.

- The opposite has also happened. Knowing about a very specific term in Django got me an offer. This has actually happened twice.

- EDIT (next this + next two points): I was thinking about this and realized I had other times when knowing trivia is a lazy heuristic for expertise. (I'm not saying this is right, just saying it happens). Knowing the hourly cost of AutoML immediately convinced someone that our team had the expertise and tentatively agreed to a MM deal. I had never used AutoML.

- Rattling off an answer to an esoteric question in due diligence changed the tone from us convincing we were technical to the person convincing him he was technical enough to do due diligence on us.

- Simpsons Paradox: Whenever I'm answering these trivia questions, I'm saying it quite confidently, which conflates the results.

- The knowledge stacks up in really interesting ways. I think of more things similar to connected graph trees.

If most of my decks were about random Jeopardy facts, then I'd certainly agree that it's not the best use of my time though ...

Thought rs.io is/was really well done, great curated stuff. Added a reference link to your pages.

Hit me up at jeffshek@gmail.com anytime! I sheepishly already follow you on Twitter lol.

https://senrigan.io/blog/everything-i-know-strategies-tips-a...

OpenAI's accomplishment illustrates scaled hardware and DRL is leading some AI breakthroughs, this is particularly because most DRL algorithms are sample-inefficient and the prevalence of cloud computing.

2. Your clients should not be the first one to alert your site is down. Pingdom does a great job to alert you before your customers/users do.

3. The author brought up some of the queries weren't paginated and running an expensive SQL query, so there's a few options. Since he's using Django there's some Django specific options in this list.

A) Implement a backend cache that will return back the JSON query (throw it on a redis). Cache and return that from the backend.

B) Add a Django throttle to the view (can be done via IP / username).

C) Enable logged in users only to access endpoint (harder to do on the fly though, since you need to make changes to your frontend). If a logged in user is causing you hell, turn off signups and kick that user off.

D) Have CloudFlare cache a public response for you on endpoints and return it (you need to make sure the JSON should always be the same for every API call though, which is very very risky).

E) Author brought up DRF JSON serialization is slow. Another alternative is to use Serpy which sees a 50-100x speedup. I'd only recommend that for complex JSON payloads. Not because it's hard, but because it's additional complexity.

The author is also using Dokku which is fine for most projects, but you'd imagine at some point it'll probably be switched onto a load balancer + web machines. Alerting can also be set on the load balancer level if it goes above % threshold.

Since he's using Dokku (so by that definition docker), they could probably use a log aggregation service that would allow him to access his logs much faster to see what's going on. Papertrail, etc.

Monitoring CPU usage would also be helpful here, but I'm not sure if Dokku allows that.

Minor frustration: Someone in the <5 employee count deserves more equity. Yes that % is pretty common, but I think that's wrong.

Another way I've tried to tackle this is on day 1 of a job - I've blocked out a huge chunk (4 hours) of my daily calendar of "Coding Time - No Meetings, No Slack, No Email" before anyone could tell me no.

Point 2 (and 5) is probably one of the biggest things I think about a lot these days. Most of my tech stacks are relatively tried and true, with the exceptions of Netlify and GCP. Where it's possible, I will generally try to put a $10-20 dollar SaaS product instead of code. That comes with counter-party risk, but I trust Pingdom more than I would my own notification servers.

When I wrote this article, I struggled with explaining how my thoughts of what a 10X engineer changed over the years. I recognized people would yell 10X != memorization, but the compound effect of working (and learning) without friction (in this case, human memory. in many other scenarios, technical debt) leads to exponential advantages.

https://senrigan.io/blog/chasing-10x-leveraging-a-poor-memor...

Books: -- Founders at Work

Another great book that I'd recommend is Lost and Founder (TinySeed's terms are based on the Rand Fishkin's most recent startup terms).

This book (Never Split the Difference) was also pretty helpful to me, but it's easy to forget to apply in scenarios.

Most of the posts there are ways of confirmation biases - it's very difficult to get someone to see what they don't want to see in his/her cryptocurrency.

There are certain coins that are exceptionally polarizing (Ripple and IOTA come to mind) - it leads to this my coin vs your coin behavior. It's so fascinating, yet odd at the same time.

I read about 3/4 of the emails before coming to the conclusion I had no idea what was going on.