Yadi

There is not a Wiki, but a subbreddit and I also think that recently a few folks launched a Podcast around this topic:

- subbreddit: https://www.reddit.com/r/shutdown/

- podcast: failory.com

In machine learning, hands down these are some of the best related textbooks:

- [0] Pattern Recognition and Machine Learning (Information Science and Statistics)

and also:

- [1] The Elements of Statistical Learning

- [2] Reinforcement Learning: An Introduction by Barto and Sutton

- [3] The Deep Learning by Aaron Courville, Ian Goodfellow, and Yoshua Bengio

- [4] Neural Network Methods for Natural Language Processing (Synthesis Lectures on Human Language Technologies) by Yoav Goldberg

Then some math tid-bits:

[5] Introduction to Linear Algebra by Strang

----------- links:

- [0] [PDF](http://users.isr.ist.utl.pt/~wurmd/Livros/school/Bishop%20-%...)

- [0][AMZ](https://www.amazon.com/Pattern-Recognition-Learning-Informat...)

- [2] [amz](https://www.amazon.com/Reinforcement-Learning-Introduction-A...)

- [2] [site](https://www.deeplearningbook.org/)

- [3] [amz](https://www.amazon.com/Deep-Learning-Adaptive-Computation-Ma...)

- [3] [pdf](http://incompleteideas.net/book/bookdraft2017nov5.pdf)

- [4] [amz](https://www.amazon.com/Language-Processing-Synthesis-Lecture...)

- [5] [amz](https://www.amazon.com/Introduction-Linear-Algebra-Gilbert-S...)

Hilarious code:

>>`"so your first mistake was using my code, but since you are clearly reading this let it be known that mutuals.py lets you create a mutuals list on the hell site known as "twitter dot com".`

It would be cool to make the list private.

Congrats on the launch mbeissinger, this is pretty cool and useful product!

Neat, maybe add a hint button and show what kind of terms one can search into the 2 input fields.

They are talking about the OSI model layer.

I recommend looking into Network+ material, don't do the exam, but I learned quite a lot studying for the exam using the CBT Nuggets videos.

Also, Cisco has the ICND1 and ICND2, or rather called CCNA, which goes into depth on network technologies.

If you're more on the Web technology side, I recommend looking at this book called "HTTP: The Definitive Guide"

By far it was one of the best books I studied in undergrad, it goes over a lot of Network protocol fundamentals.

Superb!

Thanks for sharing the source code as well:

https://github.com/stared/tagoverflow#tagoverflow

Hey This is awesome :)!

I will be sharing some of my bots on here :).

Awesome seeing someone use the reddit dataset :)!

Wouldn't a w2v as a recommender for the user might have been better?

Taking user's comments/likes/subreddits as a feature.

I don't think that was the case for the fellowship.

Applied after the 2 days with my team! Didn't get a view on anything not even a click. Again, yeah it might be the case that it was nothing interesting to them and just skipped it. But to be honest it's a bit disappointing to see no indication that someone have actually looked at 2 days of work.

Because in a startup life, 2 days (48 hours) would be enough to build and ship a feature to a customer.

I agree though with the regular YC applications, I've heard that advice more than a few times from past alums.

It can be computationally expensive for a robot to use any sorts of deep learning on board for improvement during work.

It takes hours if not days sometimes to train a good scaled model. Then retraining the model could take a quarter of that time, which is too much delay for a robot. However, with linear models things can be easier.

Also, there are very few people who know how to manage DNN or creating neural nets from scratch in a proper required way. Otherwise Boston Dynamics have to stick to one of the existing libraries which wouldn't be ideal.

DNN is amazing for some work that am sure they must be using them already, for example models that can help them with the feature engineering and such.

It looks good, am sure there will be lots of folks to help on the project.

Ah yes that is true regarding the usage/req :), but I thought you might have tried it in production with some requirement.

Hey! This is interesting (&awesome), the other day I was looking at Riak and some Redis alternative written in Go, both had some different approach which wouldn't make the best use of persistencey and distrusted approach at the same time.

The performance table looks great, though what would be a recommended minimum underlying hardware requirement for production? (since the test is on a Mac-Air)

Yup:

https://twitter.com/sama/status/626523690533027840

Yeah I would actually pay for it!

I'm a freelancer consultant and I get decent clients reaching out to me from Reddit.

I read about CompSci and Machine Learning almost on daily basis and the subreddits that I visit help me on that stand point a lot.

But here is the deal! People Love freaking drama and some thrive on it. So whenever there is a 0.1% of drama it gets amplified.

Also one other thing! I respect the HN community, but I've seen harsher feedback & more harassment here than Reddit.

PS: I'm a 5 years club member on Reddit.

Indeed, founders usually have a better complete vision the the folks around them.

Though I was just pointing that out for over time. One time around the tech-debt is not that big of a deal, until it becomes a beast and hard to overcome.

Thanks, that is a very good metric that you shared with an example:

> "correctness vs. completeness spectrum."

and yes! It's a double edge sword:

>"Getting that wrong either way could lead to the failure of your startup."

This is an awesome reply! Just awesome.

Folks rarely notice how much a decision making matters on this regard and technical knowledge matters a lot on the way. Since having a company* acquired sometimes could be a good business return, but in the first place due to hitting the pedal it has brought lots of technical debt which makes an acquisition impossible.

Thanks :)! Lots of good clarified points.

Thanks. Indeed, I agree with you regarding how startups are about "creating value for the customer."

But I think at some point, this might become very difficult due to the technical debt when the startup can't deliver more value than it promised.

Thanks. Right, perhaps having some pieces of a technology solidified could help with moving on to new features.

For example an API that users pay for would only be updated or relied on when it's debt free.

Hey that is another interesting point, thanks:

>"the schedule of technical interest payments they will have to pay one way or the other if they are still in business."

Thanks, yes it's hard to point out one specific example of a startup, because it can be an inter-related cause as you mentioned.

Though someone else here mentioned how friendster lost their game due to technical debt:

I looked it up and it looks like that indeed it was an issue.

http://highscalability.com/friendster-lost-lead-because-fail...

> "Technical debt reduces uptime, increases bugginess, and makes it harder to fix bugs."

Yes, that is one of my concerns usually. It's good to go fast and build more, but not to an extend where it slows the process down on longer run.

Thanks a bunch! You're a champ.

Yeah sometimes making these sorts of decisions could easily lead to big pitfalls on the way.

Regarding this part:

> "I also allowed the team to create their own modules instead of extending some existing node.js modules that existed in the community, which to me was a waste when I saw what we did."

This is technical debt as well by the definition of Wikipedia and some 101 CS books. Having enough contribution from a community could always be better of being used, unless that part of the technology is propriety in the product.

That's interesting. Thanks for pointing it out, after you mentioned that, I had to look it up:

http://highscalability.com/friendster-lost-lead-because-fail...

> "technical difficulties proved too pedestrian for a board of this pedigree. The performance problems would come up, but the board devoted most of its time to talking about potential competitors and new features, such as the possibility of adding Internet phone services, or so-called voice over Internet protocol, or VoIP, to the site."

Thanks, that is indeed the on spot point I'm looking for.

Drawing some conclusions to what technical debt could eventually lead to at the end.

> "Anything that delays shipping is going to contribute to the failure of a startup."

Edit: forgot a word.

@Zigurd, this is some Dev- fron-tline deep wisdom right here!

> 'Think of it as building empathy for "product owners" who might otherwise be dismissed as beancounters.'

See this is what I suggest most of the time!

My first startup that I built and sold had 0 test written, but I knew on spot what I'm giving up for what. I always say that last line of yours:

Making "the chance to do it right with cheaper money." rather than a whole team to re-do everything from scratch or break down already running product.

Sort of goes back to your point with cost of capital, indeed.

Thanks, good points :)!

>> " Most often, product owners and developers were not able to establish good communication, which led to developers basically creating a product that didn't match what customers wanted. Period."

Thanks a bunch for pointing this out! It's important for me to hear this here :).

Regarding my definition of technical debt is this:

* Lack for proper documentation where on boarding devs is becoming a burden.

* Lack of written tests to a point writing new features is almost inevitable from breaking the product.

* Delayed refactoring which has led to serious performance issues.

* Lack of alignment to standards where the engineers have written everything in Javascript like a 5 years old painting all the wall with same color, rather than using a different language for some specific purposes.

Some other Technical Debts that I meant were:

* How engineers go on a trajectory of writing code where no one knows something new have been added.

* Lack of clarity who have done what, regardless Code commits, this one is about knowing who lead a milestone or a feature to production.

Indeed, there are lots of factors to lead to a product fail.

Though, I'm really curious, mind if I ask what sorts of technical debt you had in your startup that led to such massive slow-down in the process?

Were the debts among any of these:

* Documentations for on boarding devs. * Lack of tests. * Delayed refactoring. * Lack of alignment to standards.