leobakerhytch
Joined 12 years ago
Joined 12 years ago
For less of a time commitment, Git from the inside out [2] is a really nice explanation of the internals, from initializing a repo and the files that creates in the .git directory, all the way to pulling from and pushing to remotes.
[0]: https://wyag.thb.lt/
[1]: https://news.ycombinator.com/item?id=19386141
[2]: https://maryrosecook.com/blog/post/git-from-the-inside-out
All in all, very cool product, and congrats on making a living from it!
This is all the more reason to delegate responsibilities, rather than tasks (as argued in Little Tasks, Little Trust [0]), so programmers actually get the necessary experience with UX, design, interacting with customers, etc., and exposure to the consequences of what they build, in order to grow into full-fledged product engineers.
I fear though that such roles, and consequently such engineers, are few and far between.
> Explosives were used to deploy the parachute, so care had to be taken that there were no late detonations. [0]
Precisely what you guessed it to guessed it to be.
[0]:https://mobile.twitter.com/girlandkat/status/133551478006118...
I doubt there are too many people in tech making this mistake, but without numbers there’s a good chance you fall prey to people’s inaccurate perceptions or explanations for their own behavior.
On the other hand, without those first-hand accounts, it’s all too easy to tell a mistaken story about your numbers. In particular, your users’ sentiment towards their time spent in your app is a guess, unless they tell you.
I think timescale is another crucial dimension to evaluating time-in-app, and whether it’s a positive indicator for your business.
For instance, driving up engagement has doubtless been good for Facebook’s financials in the short- to medium-term. Arguably though, that relentless focus has led to the present political climate where they’re fighting off regulation. Whether that’s an existential threat is yet to be seen (one can only hope), but it certainly casts the metric in a different light.
As you say, it comes down to the fact that there is no silver bullet metric; there’s no substitute for thinking about and dissecting the data you collect.
It’s fair comment, though, that undifferentiated ‘engagement’ is rarely a good metric.
I’ve used Typeform’s webhook feature a number of times to good effect, whereby you receive one POST request to whatever endpoint you specify upon each form submission. This may have changed, but when I last used it that was the only way of getting your data out of their system, which was admittedly frustrating. A lot better than nothing though.
Used it for all kinds of things: quizzes hooked up to a loyalty program, to award the user points for all correct answers; satisfaction surveys after ordering a product; writing and photography competitions (again hooked up to the loyalty program); an in-depth annual user survey; etc.
The rare occasions I discover a new channel, it’s almost always from some source other than the algorithm: a referral from a friend, this site, another YouTuber, etc. My viewership of the same repetitive roster of videos absolutely tails off until I find something new from elsewhere.
For example, in months of being subscribed to my mechanics [0] (who does incredibly engrossing and relaxing restorations of mechanical stuff), not once was I suggested a video from Baumgartner Restoration [1], an art conservator who produces videos with a similar attention to detail and high production value.
Thematically this should be an easy recommendation for YouTube to make, but evidently the content is just different enough that it scores as a false-negative. After finding the latter channel independently, my viewing time absolutely rose for a while.
In theory, YouTube ought to be able to detect and learn from this signal of non-algorithmic discovery of new content. Yet, here we are.
It would take a pretty monumental effort to build, but I think a huge step forward could be made with a VCS that has knowledge of code structure, and the relationships between source files.
Large scale refactoring is such a fragile affair with git. Conceptually though, it should be possible to cleanly and concisely represent such operations as renaming functions, reordering arguments, widening type parameters, etc.
Stability of the programming language in question is of course highly desirable, if you were to build such a system. The pace of change of Go would be much more conducive to success than that of JavaScript (or TypeScript).
I’m also much stricter with going through the slight awkwardness if I didn’t catch the name first time (even asking to spell it out to be 100% sure). Then afterwards, I’ll write down the name in Notes with something memorable about the person, and where I met them. 99% of the time, I never look at this again. Just like that, name remembered.
Then, I’ll manage not to use a person’s name next time I see them, even when I know it. Oops.