nostrapollo

First off, congrats on the launch! Construction is a tough market to build in. My personal view after being in it a for a few years is that there is no shortage of MVPs. In fact there is an MVP for every problem at every level (or at least it feels that way) but construction is /vast/ and the rough edges that seem juicy at first, in practice are optimizations rather than bottlenecks for constructors.

I hope you succeed because it would be great to have a standard API for this data, but I would advise on one of two directions: become the standard by being close to 100% accurate at finding symbols (one symbol doesn't seem to cut it in our testing) or make a great, comprehensive workflow for a small subset of the market and become standard that way.

In both cases, you cannot do a broad 'market test', you need to spend many hours with a specific sub-set of users in construction.

Disclaimer: I'm a co-founder of Provision.

I'll live on, posthumously

We're mirroring to Gitea + Jenkins.

It's definitely some extra devops time, but claude code makes it easy to get over the config hurdles.

Something sus about these posts that promote OpenClaw specifically, even on X when ClawdBot was first popping up - an unusual number of people were promoting it all without specific information on why it was useful. All the usual suspects were also promoting it (the 'dev influencer' accounts). Is this a new(?) tactic on hyping up a github repo for engagement?

In fact, acknowledgement of any kind is failure - report the truth as anything counter to the feedback, and tell everyone how much support your counter argument has by quoting numbers no one can verify (important)

Also credit to Chris for creating this!

Personally a huge fan of Alfred, and was waiting for this integration since ChatGPT came out. It's very much an Alfred style plugin but great for the mini-prompts I use everyday.

Not affiliated with any of this, but love Alfred

Hard to tell from my phone but are there any sources for the ‘exodus’ numbers? I don’t get the same impression that this post is laying out.

That’s a good point, but they could have done that regardless of having ownership, no?

I think there’s fair reason to believe that VR is compelling, simply from personal experience the imagination runs wild the first time you try the quest or similar. Not sure why there’s so much confusion about the promise of meta vr. I cannot imagine a future where desk based workers aren’t using VR.

I’m assuming $1.89B doesn’t give them much though, if any power to influence

I find the 75% of respondents claiming to use frontend unit tests surprising, in many cases where I could find the time to actually write tests for frontend it was almost exclusively for design system components and those projects are rare

Non-researcher here, but does this imply that China is doing significantly more research than the other countries mentioned? I'd imagine it's either that, or the 'legal' article access systems aren't as accessible?

Love the idea, and great effort put in! My initial impression is the same, overwhelming UX. There's a lot of information and there with very little visual hierarchy, it's hard to decide where to look first.

I find https://refactoringui.com/ has some digest-able design stuff for us developers. I'm not affiliated with them, but I've been the same boat with product design.

For me the key was understanding what roles spacing, color, and font-weight play in building a hierarchy.

Edit: spelling.

I agree, my summary of the post: "Frontend is engineering too" which I 100% agree with, however the notion of not splitting up systems into functional goals is a mistake.

User-facing applications just have different goals from an application consumed via API. Practically when you split up a system into a client facing application and an API application, from my experience and reasoning, it's always been because it results in a far easier to manage development process.

The simpler you can make your system the less likely it will be to fail by any measure. So breaking systems up into smaller systems is just easier and simpler. One such division that is really easy is the backend and frontend.

Model View Controller type frameworks are a great practical example of why breaking systems up makes them much easier to construct.

Thanks for the thoughtful reply. Your comment about cynism sparked a certain honesty - I'm probably being too pessimistic about publicity. I suppose it's also linked to personal ego and wishful thinking on the recognition front.

PS thanks for being a prolific contributor to hacker news!

I am two years into being an 'inexperienced tech lead', and I think there are some good pieces of advice in the other comments. But I think the most important thing seems to be having some structure to your progress in all of the mentioned categories. When dealing with your team have an objective in mind for not only the conversation or meeting but for the takeaways you want your team to have. Take note of what assumptions changed your mind for certain decisions. Assume you're wrong and need to experiment to be right.

More practically: I write down feedback that is given to me regarding leadership style and write down things that I think about at the 'moment of impact' (assumptions, reasoning, and metrics for success/failure of decision) when decisions are being made. Read over these notes often enough that you are aware of those things when they happen again. Anecdote: Developers often want time to create a quality feature and if they are frequently pressed for time due to business requirements, they are unhappy and the product suffers, often in less than obvious ways. It was only really obvious that this was a problem when we tried other ways of planning and prioritizing because the assumption was that development pressure was a given for a tech company, turns out that some development work can be offloaded by better planning and prioritization based upon better thought out business objectives. These learnings came about because we kept took notes of decisions that were made, and could refer back to them as crucial points of pain/cost/failure.

If you don't have some structure to your approach, you'll find it difficult to call out specific changes that need to happen.

There's a lot more that could be said. Tech leads are often interfaces for other parts of the business so respecting the context of other's roles and aligning incentives is more important than proving your job is being done 'correctly'.

Here's a guide: https://restoreprivacy.com/firefox-privacy/

If the assumption is that browsers track because it benefits the company commercially, it would be really cool if a company produced a browser at a premium that didn't do all of the above - this model must exist already? Privacy for a price sounds like a bad precedent to set though.