joemoon
Just in the first couple of paragraphs alone:
- The author discusses the "why" by pointing to research on how new information triggers dopamine pathways. Maybe this is obvious to you but it's not necessarily obvious to everyone.
- The author points out that this would have historically been an evolutionary advantage (at least that's my interpretation), but access to modern high-volume, low-nutrient information has made this an addictive unhealthy habit.
- For those already familiar with how modern access to high-calorie, low-nutrient food (that triggers the dopamine response), the author is showing that the same mechanisms are at play with information.
I think it's actually your comment that contains the tweet-able one liners (as "key points") that are likely to result in head nods and smug self assurances but aren't doing anything to encourage deeper thought.
As I understand it, rather that training the smaller model to produce the CoT/rationale as a part of the (decoded) response, it actually has two output layers. One output is for the label and the other is for the rationale. The other layers are shared, which is how/why the model is able to have an improved "understanding" of which nuances matter in the labeling task.
If help desk isn't the answer, then maybe another type of platform. Generally, I think you need to ride the coat tails of larger platforms.
(Note: I do realize this is developer focused today, but it didn't necessarily need to be.)
Eventplicity provides a SaaS product for venues that book private parties and special events. We're not your outdated online booking system from 2005. We provide a modern application that tackles the surprising number of complexities involved in planning private parties from start to finish.
Currently a team of 15, we're a startup with a positive, exciting growth trajectory. With more than 50 venue partners and nearly $2 million in events booked, we're using our industry expertise to continually evolve our platform into a decision engine that helps customers build out their events online.
Every venue is different, every event is different, and every booking is different. Join our team and help us build the right set of abstractions and the modern interface that will wrangle these complexities into a smooth, easy-to-understand online interface.
- Competitive salary and equity compensation.
- Supportive environment and flexible schedules.
- High focus on code quality.
- Collaborate as a team to decide how we can evolve the product in a way that allows us to have a clean, stable code base while still rapidly iterating on the product.
Front-End: Javascript ES6, React, Socket.io, Bootstrap
Back-End: Python, Flask, Redis, PostgreSQL
jluna [AT] eventplicity.com
Your website is all about what kind of software you can build. Your clients don't care about that. They want to know what kind of business value you can deliver. What kind of results can you achieve?
As a business owner, I don't want to see example websites, I want to see a case study about how you increased revenue by 20% with a new user onboarding process. I want to see how you saved 100 hrs per month in staff time (i.e. expenses) with the new set of automation features you developed.
If you don't have this data from past projects, then start collecting it. Start framing all of your conversations this way from now on. If a client is working toward a business objective, help them achieve it and make sure you put mechanisms in place to measure success and assign a real dollar value to what you helped them achieve.
Location: Remote or Gainesville, FL
Startup seeking senior level RoR developer that can help cleanup an existing code base and establish best practices for a team of less experienced developers.
jluna -at- eventplicity -dot- com
I thought it was a typo the first time you typed it, but I thought you should know when I saw it a second time.
A "conversion" means different things to different companies. It would be extremely easy to game the system if conversion rate affected quality score.
http://searchengineland.com/google-warning-more-about-bad-li...
After all, the people that read all the way through the entire blog post are your target audience. These are exactly the type of engaged readers you want to capture.
- Have a vesting schedule for your equity. This way if things go south, you'll have a certain portion of your equity vested. - Negotiate a higher equity stake in the first place if you're playing such a founding role. In my opinion, if the product didn't exist before you joined the team, then you're a founder. Remember that we're looking at this with the benefit of hindsight. - Made the agreement up front that you had control over the technical decisions since you have the expertise to make those decisions.
I don't necessarily agree or disagree with the advice, but it's clear that it is intended for "people who do the actual work".
Sally learns best by doing X, while Sam learns best by doing Y. (Show cartoon Sally doing X and cartoon Sam doing Y). Most apps will try to teach Sally and Sam the same way, but the TommyTeaches app is smarter than that! Tommy will be learning as he teaches. Tommy will learn which techniques are best for Sally and Sam individually, then tailor the lessons to... etc.
That's a straw man. I never said that the expressiveness of the language should be limited. There are plenty of languages that are just as (more?) expressive than CoffeScript without the syntactical ambiguity.
> If you take that line of reasoning too far you end up with Java.
That's the slippery slope fallacy. I am in no way suggesting that CoffeScript should have completely rigid syntax. Surely there is a happy medium between CofeeScript and Java. There are plenty of languages that live there.
Isn't this precisely the problem? Why make a better Javascript then make the same mistakes as the original? One of the main goals is for Coffeescript to be more readable that Javascript. Having ambiguous syntax and so many different ways of doing things means that people will write code in all of these different ways.
Your rebuttal is a long list of what you SHOULD and SHOULDN'T do, but there are two problems:
1. Not everyone will agree with you.
2. People will write it the "bad" way anyway.
Ultimately this means less readable code, especially when you have to read someone else's code.
If you're creating a subpar user experience, then it's your fault. You can blame the webview all you want, but your users are going to blame you.
This isn't a solution to the problem. Your approach carries the risk that you never find the answer (given the preconditions). I don't think this qualifies as "good" critical thinking, since you don't actually have a solution.
I don't recall when this kind soul made this document public, but I believe it was in a similar discussion on hacker news and I've had it bookmarked since.
I have also done my own tests, and the iOS numbers are similar (depending on the device of course).
It has been fantastic (though I have the 3rd gen model).
The background are really distracting (and not very aesthetically pleasing). There is not enough contrast with the light colored links. These two things combined make the whole sight difficult to read.