adchurch

13 ms·

61.
Weave (YC W25) is hiring a founding product engineer(ycombinator.com)
1 points by adchurch 2y ago
62.
by adchurch 2y ago
You're totally right! And we do not account for it at all. We don't give any insights into product decisions, just engineering output. If engineering output is high but business results are bad, that indicates there's a probl
63.
by adchurch 2y ago
> Let me just ignore my natural distain to the whole thing (as a engineer and a manager) I totally get this - that's how I felt initially, but I was shocked to find that the vast majority of orgs are using bad metrics like LOC or co
64.
by adchurch 2y ago
Different companies will have different outputs just by the nature of their stage & situation, but the numbers are still relatively comparable (e.g. across different teams). > How do you measure the impact of refactoing? The metric d
65.
by adchurch 2y ago
LOL - I shudder at the idea of a manager making HR decisions based solely on this one metric! To be clear we're not claiming this is 1 number to holistically evaluate an entire engineer. Rather we're giving a much more accurate pi
66.
by adchurch 2y ago
> Metrics are harder on software engineers This is exactly the problem we're hoping to solve :') > the good ones delete code Our algorithm gives lots of credit for deleting old code! > the best ones make sure useless code
67.
by adchurch 2y ago
Check out our main landing page: https://workweave.dev/ Let me know if you have any questions that aren't answered there!
68.
by adchurch 2y ago
> How did you come up with those magic correlation numbers? Evaluated on a proprietary data set of manually labelled PRs > Is this generally just sniffing surface quality and quantity of written code... Somewhere in between the two :)
69.
by adchurch 2y ago
Wouldn't this be considered a very high performing engineering team with a very poor product team? We're only evaluating engineering - not the product decisions behind that engineering.
70.
by adchurch 2y ago
Not at all! The algorithm is calibrated with real human effort. So find/replacing something 1000 times will have nowhere near the same value as adding 1000 lines of new code. And given 1000 lines of new code, you'll get the same v
71.
by adchurch 2y ago
Yeah maybe "expert engineer" is the wrong framing and it should be "oracle engineer" instead - you're right that we're not accounting for context switching (which, to be fair, is not really productive right?) H
72.
by adchurch 2y ago
Startups will naturally have higher output than enterprises for this reason - we'll show people benchmarks accordingly. > Is it productive if I have tried many changes in branches and none of them made it to prod? Our metric measure
73.
by adchurch 2y ago
Our algorithm gives lots of credit to removing old lines of code! But to your broader point, I think there certainly is information about effort at the code level. Consider for example these two PRs: https://github.com/PostH
74.
by adchurch 2y ago
This metric approximately measures functionality added, so the way to game it would be to add lots more functionality. This metric has no opinion on the nature of that functionality (i.e. it's not evaluating product decisions). So it d
75.
by adchurch 2y ago
Our metric is approximately "hours of work for an expert engineer." Here are some example open source PRs and their output metrics calculated by our algorithm: https://github.com/PostHog/posthog/pull&#x2F
76.
Show HN: Weave - actually measure engineering productivity(app.workweave.ai)
22 points by adchurch 2y ago|39 comments
77.
by adchurch 2y ago
Glad to hear it! :))
78.
by adchurch 2y ago
It's worth mentioning that GitHub only allows us to act on your behalf in repos you install the app in. But when you install the app you'll see it's only requesting read permissions to metadata => it can't take any ac
79.
by adchurch 2y ago
Totally fair - I'll look into removing that because we don't need it. But fwiw we don't act on your behalf, we just pull data about PRs/reviews! Thanks for the feedback :)
80.
by adchurch 2y ago
Awesome, glad to hear it! Let me know if you have any other questions or feedback :)
81.
Show HN: WorkWeave, a tool to make every engineer a 10x engineer(app.workweave.ai)
17 points by adchurch 2y ago|8 comments
82.
by adchurch 4y ago
> The problems described in the "Routing" section are trivially automated. You do not even need a separate data loading library because react-router-dom ships one. I'm not sure which problems you mean; fwiw the routing sec
83.
by adchurch 4y ago
Imo it's a question of prioritization - time spent fiddling with a Webpack config is time that could have been spent on something that will more immediately benefit a user. That's the big advantage we saw for switching to Next.js,
84.
by adchurch 4y ago
Yep - the metric was First Contentful Paint, which is basically the time-to-skeleton in our case :)
85.
by adchurch 4y ago
Sure! Here it is: https://gist.github.com/a-churchill/9a55fffaae97b347de5885e7...
86.
by adchurch 4y ago
I explained it a bit more here: https://news.ycombinator.com/item?id=33319806 Let me know if this still doesn't answer your question though!
87.
by adchurch 4y ago
In our experience, using Next.js reduced our complexity, because it has out-of-the-box implementations (and simple configuration) for lots of stuff we had to manually hack around with CRA as our project grew
88.
by adchurch 4y ago
One nice thing about Next.js is you don't need to use SSR unless absolutely necessary - it will statically generate all your pages by default (which is similar to but not the same as SSR - it runs once at build time rather than on ever
89.
by adchurch 4y ago
> I'm curious where the majority of the win came from? Great question! The boost can be explained by JS vs. raw HTML+CSS performance. In the past, we sent a dummy loading screen but we then had to download tons of JS + run that to e
90.
by adchurch 4y ago
> Any chance you guys measured this speed difference? No, but we actually can get some comparison, since as I mentioned we host preview apps on Vercel! I did some quick tests right now, and it looks like based on logs, the API request to

More ›