colmanhumphrey

I kind of love this, although I feel like I'd need to try it out to understand exactly how it feels. I'd even like to see a video if Zed could make one. It would be good to understand e.g. if the issue of "who wrote that?" actually affects things in practice, or any other weirdness or limitations.

I also kind of get why it's built into an editor! I wonder how it compares to e.g. https://www.coscreen.co.

The default method of remote work, with e.g. Slack and video meetings, I think leaves a lot of potential on the table. I wonder if a flexible collaboration system like this could actually be a lovely default method for many companies.

haha, not sure I agree with this one at all, I think a name is pretty far down the list of priorities for a business. I would be extremely surprised if "customers who started trials but then didn't use the product at all, but then later wanted to, but couldn't because they couldn't find the name" is a segment that moves the needle.

From this brief note, you sound like you potentially are trialling an order of magnitude more services than the average person. I bet that gives you a ton of interesting perspective on all these products, sign-up flows, etc, but probably puts you in a very unusual position with respect to product names!

This rings true, and I guess further backs up how important it is to carefully choose your initial customers, so the product is actually good enough by the time it gets to the broader swathe of companies. At least, that's my guess — I'm the one that failed after all!

I am surprised to hear you say this given your previous experience founding a product that from a distance might look to cover some similar space to retool but in practice is quite different. My perspective: only investors ever asked us about retool, not customers. Some of them even used retool tool. Hah even just typing this out brings me back to investor meetings!

a very generous comment! Very interesting you say that, I believe we did at some point have some thoughts about targeting B2B2C, but sadly that was one of the areas we failed to fully learn about / experiment / iterate on.

oh that's an interesting perspective. I would say you're right, and maybe I didn't phrase it well. I probably should have said something more like: if you don't know how, or if you can't learn how (through iteration etc), then how can your customers. Or something to that effect.

That sounds like a very viable and valuable type of business, but it's kind of a different category of business model

If instead I had supplied a time series for eight years ending just prior to all of OP's data, you wouldn't discuss "comparing" the charts (I assume!), so it's a little unclear what the concern is with comparison.

If you just need the last few data points, of course you can either just look at OP's chart, or if you don't trust that data, then quickly get the data yourself. Again you can even create an account on slight.run and recreate the full graph if you prefer.

We are also not currently in a recession. If instead you're referring to market conditions that affected tech heavily, that was in place by Q3 2022 (e.g. https://techcrunch.com/2022/12/20/remembering-the-startups-w...), and this also lines up more closely with how the Fed has been raising rates (https://fred.stlouisfed.org/series/DFEDTARU).

It includes the Nov 1 post, you can see the data here: https://slight.run/apps/colman/job_seekers_vs_job_hiring_hac... (Vega reads 2022-11-01 into your local timezone, hence why you're possibly seeing 2022-10-31).

They claim they update it daily (https://console.cloud.google.com/marketplace/details/y-combi...) but they only update it every few months it would appear.

Of course you can manually get this data from the HN API and create a query built on https://slight.run/apps/colman/job_seekers_vs_job_hiring_hac... by adding the extra few rows manually (but unlike OP, I recommend you exclude non-top level comments).

Here is a chart going back to 2014: https://slight.run/graphs/colman/ratio_of_seekers_to_hirers_...

Not quite as drastic as yours, but still not ideal.

The underlying query and data source: https://slight.run/apps/colman/job_seekers_vs_job_hiring_hac...

I'm restricting to top-level comments here, because those seem like a better proxy than all comments (excluding some discussion on a given post for example).

exactly! It's a version of https://en.wikipedia.org/wiki/Inclusion%E2%80%93exclusion_pr...

I got 71.13647% on a first pass. So we want P(all 4 in 9) = 1 - P(not all 4), and we can split that out a few ways. To not get all four, we can restrict ourselves to three, so that's (3/4)^9, but there are four ways of doing that, so that's 4 * (3/4)^9. But that counts using singles and pairs too many times. Specifically each version of "three" can be exactly three balls, three ways of one ball, or three ways of exactly two balls ("1 or 2 or 3" = "1&2&3" or "just 1" or "just 2" or "just 3" or "1&2" or "1&3" or "2&3").

- We can then subtract 6 * P(two balls), so 6 * (2/4)^9. Now this counts singles a few times too, in fact it cancels all of them out.

- We then need to add back four singles, so 4 * (1/4)^9

Putting this together gives:

1 - (4 * (3/4)^9 - 6 * (2/4)^9 + 4 (1/4)^9) = 0.7113647

I'm surprised to read this — while the examples could be more cleanly presented, I felt like the title for this post and the initial gif on landing show what this does reasonably clearly. I do see what you mean about the PRO part.

Can’t begrudge anyone involved, but this feels kind of lame. I thought Figma really could compete long term with Adobe.

It’ll make some naive approaches work differently, but it’s overall more info: both the selection effect of what images humans share, and the surrounding context (eg what comments are people making about the image)

Bryan and Steve, who are getting https://oxide.computer/ up and running? Probably best to leave them at it! Chris has his own AI company too.

honestly yeah, I like living in density with other people around. It generally leads to more local businesses too: even if the number per-capita is the same, you get more choice, better opening hours etc.

Slight | Frontend Engineer | REMOTE | Full Time | $140,000 + equity

https://www.slight.co/, role: https://www.slight.co/jobs/frontend-engineer

Slight is looking for a frontend engineer to join us in making data operational within companies through data apps. We want data teams to build data apps to get data & graphs to their teams where they are, not where data tools want them to be.

To learn more about what we're building, see our home page (https://www.slight.co/) for an overview, and our about page (https://www.slight.co/about) for more details.

The role page (https://www.slight.co/jobs/frontend-engineer) contains details about what we're building next. Caching, scheduling and triggers; a seamless Google Sheets integration; Python and R support; flexible permissions; building out our graphs. If any of this sounds up your alley, please apply!

- Location: Remote. We only require overlap in the morning of US Eastern time (10:00 - 12:00).

- Compensation: $140,000 plus equity commensurate with an early role

How to Apply: The role page will have more details, but essentially email whatever you feel best represents you (could be a resume, could be a project description and links, could be a website, any combination that suits you) to jobs+frontend@slight.co.

Hey this is nice! I created a little app here that's quite similar but can be run without knowing SQL: https://slight.run/apps/colman/hacker_news_monthly_top_level..., and a graph to go with it: https://slight.run/graphs/colman/hacker_news_who_is_hiring_c...

One thing that's interesting: this is a sneaky case where the line hides two missing months in 2015.

That’s not the rule from the question in the link nor in the original game (the game’s rule isn’t quite the same as the classic problem, it’s even messier). Your proposed rule doesn’t uniquely extend the original, it’s just one of the possible generalizations.

Seems fine to me. Do you want to stick with your original or switch to one of the remaining 98? It’s still worth switching too, just a smaller increase in probability.

I agree, I had the same thought last year: https://twitter.com/colmanhumphrey/status/139338571650012365.... It still helps but now only a small amount: (99/100)*(1/98) ≈ 0.0101, vs 1/100 without switching

Gurobi is so frustrating. I had the same experience: blistering performance on my problems, much better than OR-Tools, but just couldn't make it work at all with the licensing. It's like they've never heard of the cloud, or had any concept that anyone would use their software in any way other than big "batch" jobs on an in-house machine. I feel like someone could make a killing just buying Gurobi and making it work in a modern way.

NextMV was practically the opposite (at the time, I'm sure it has improved now, especially since they used to be far more insistent on decision diagrams): rather bad/terrible performance, but excellent in terms of licensing and deploying the code, and they had great support too. The modern deployment made sense given they were a new/modern company. One silver lining to the terrible performance, and why I used to stick up for them at the time was that you could get somewhat acceptable results fast: if you stopped after one second, CBC might be absolutely nowhere, but NextMV's solver would at least give you something. This meant you could do things that made use of extremely fast results, like trying a configuration and checking the (approximate) solution, then trying a bunch more, all very quickly.

In the end I mostly settled on OR-Tools.

Thanks for the ping on twitter Phil!

Your search criteria make perfect sense for benchmarking. I think we could indeed add that to https://slight.run/datasets, as I think we can justify the benefit for companies searching their own internal data too. Number of columns and rows would be simple enough; depending on the DB, we could do a size range too, "I want to see our company's heaviest datasets" etc, but also useful for your benchmark use-case.

Sparsity is interesting. We can have % of empty, or MB / (cols × rows), or probably what I'd like is % empty per column, but not yet sure how to make that an easy search criteria.

I'd probably also like to search datasets by type of column ("I want to run some tests on date fields", "I want to test our new graph on data with both time and integers" and so on), which would suit benchmarking and internal data searching. We can already do name searches, but could be nice to support searching for a name within a column type — this one probably isn't as relevant to benchmarking.

Even with Slight, I sometimes try to find certain numbers or types by scrolling down the catalog opening up the expanded view, and scrolling the columns there. So it could be something to do earlier rather than later.

Slight at https://www.slight.co/, jobs at https://www.slight.co/jobs/. Full time roles, all remote. We’re currently hiring for two Software Engineer roles. Our rust focused role, https://www.slight.co/jobs/software-engineer-rust, and our more general role https://www.slight.co/jobs/software-engineer.

We're looking for software engineers to join us in empowering data analysts to empower their whole teams. To learn more about what we're building, see our home page for an overview, and our about page for more details: https://www.slight.co/about.

Compensation: $140,000 plus equity commensurate with an early role

The role pages will have more info about applying, but effectively you'll email jobs+rust@slight.co for the Rust role, and jobs+swe@slight.co for the general role.

Slight at https://www.slight.co/, jobs at https://www.slight.co/jobs/. Full time roles, all remote.

We’re currently hiring for two Software Engineer roles. Our rust focused role, https://www.slight.co/jobs/software-engineer-rust, and our more general role https://www.slight.co/jobs/software-engineer.

We're looking for software engineers to join us in empowering data analysts to empower their whole teams. To learn more about what we're building, see our home page for an overview, and our about page for more details: https://www.slight.co/about.

Compensation: $140,000 plus equity commensurate with an early role

The role pages will have more info about applying, but effectively you'll email jobs+rust@slight.co for the Rust role, and jobs+swe@slight.co for the general role.

Maybe "Gradual Scripting" could work

Slight | Frontend and Full Stack Engineers | Remote (US/ET-1 to US/ET+6) | Full-time | $140k + equity | https://www.slight.co

We’re currently a team of three and are hiring a Full Stack Engineer to join our core team:

https://www.slight.co/jobs/full-stack-engineer-core

Our stack:

- Frontend: Typescript, React.js/Next.js

- Backend: Rust, PostgresSQL, Go

Nearly every organization that collects data has built a trove of analytical work critical to operational and strategic success. But this work is often ad-hoc, under-documented and bottlenecked by needing data teams to manually rerun analyses, queries and other data-related tasks - this becomes a company’s “shadow data infrastructure”. On the other end of the spectrum, teams often wait weeks or more for quick data solutions to be converted to true applications by engineering teams.

At Slight, we’re tackling these problems by building a product focused on the interaction between data teams and domain experts during the lifecycle of a data request. Currently, we are focusing on making it dead easy for data teams to create, document, and share performant data applications. That is, we're enabling people to take queries (SQL, etc; reads and inserts) and scripts (e.g., R, Python), easily parametrize them, and get an application that domain experts can use.

Come check out our open positions and apply on our jobs page if you’re excited about what we’re building here: https://www.slight.co/jobs

If you have any more questions you can reach out directly to colman@slight.dev

Slight at https://www.slight.co/, jobs at https://www.slight.co/jobs/

Full time role, remote.

We’re currently hiring for our Software Engineer role, on the core/founding team, primarily in Rust. Please see our job posting for full details and stack.

Slight is looking for a software engineer to join us in building a product focussed on all areas of interaction between data teams and domain experts. See our about page for more on our mission and product vision.

At this early stage, you will also join the Slight Core Team. The Core Team will be comprised of individuals who collectively have deep technical expertise, proven leadership skills (or potential), and a track record and shared enthusiasm for building new technologies from the ground up.

We’re a remote-first company with a high focus on autonomy, work-life balance, and flexibility. For more information about working with us, see our values and benefits pages. We strongly encourage applications from people whose backgrounds are considered non-traditional in tech.

Location: Remote, founders on East Coast USA

Compensation: $140,000 plus equity commensurate with an early role

Remote: fully remote first. Still working out required overlap with Eastern Time, but "some”

Visa: no

Contact: Please apply at https://www.slight.co/jobs/software-engineer-core or email me directly: colman@slight.dev

Good to discuss, but I'm not 100% sure about some of the points here.

- The `h` problem is purely about moving your index finger, so I don't think it makes sense to talk about the bigram being popular. The relevant number is just how many `h`s people have to type in general

- Shortcuts staying the same: saying that there exists a variant of Dvorak created to do this too is a huge point in favour of Colemak. The point is so good that people modified a 70 year old layout to match it! How popular is this variant?

- Saying that Colemak is bad because of Vim, then saying it's good because of CapsLock/Backspace BUT that doesn't really count because you can also do this reprogramming with Dvorak: can you not also change Vim? Maybe this is much harder