ysavir · HackerTrans

3 дня назадdiscuss

I surprisingly had good results when I told the LLM to only communicate in ASCII memes. It did a fantastic job of summarizing the situation using relevant memes, and the humor was enough to keep things fresh. As silly as it sounds, it's worth trying when you're in that LLM burnout corner.

ysavir

5 месяцев назадdiscuss

I think the parent comment is snark. They're saying that since many Firefox users are saying "Let me turn off AI features, please!" for features they don't want at all, and few to no Firefox users are saying "Let me turn on AI features!" because few to no Firefox users want AI features in the first place, Mozilla is making AI features opt-out to "satisfy" the "want" of turning off AI features.

ysavir

6 месяцев назадdiscuss

I've seen my cats pull on a cord in order to reel in the toy at the end. I don't find that to be all too different from the cow orienting a scratcher. Should I?

ysavir

6 месяцев назадdiscuss

For what it's worth, it happens to me about 5 times each summer. But I also welcome spiders as pest control, so it's not a surprise, and I forget all about it 5 seconds later.

ysavir

7 месяцев назадdiscuss

I wouldn't call ChatGPT "brand recognition". People know the term ChatGPT, but I don't think they associate it with OpenAI or any company in particular, in the same way that people might associate Civic with Honda. Instead they'll associate it like they do the terms Bandaid, Kleenex, etc., as a catch-all term for LLM chat interfaces, regardless of who is providing the service. When OpenAI starts ads, I imagine people will start saying "oh, here's a ChatGPT without ads" and point to Claud or Gemini or whatever.

ysavir

9 месяцев назадdiscuss

That's all true, but I think the article's point still stands: React trades one set of compromises for another, and regardless of the tool used, software engineers using that tool have to do a lot of lifting to get the tool to work. It's not a question of whether react is better than backbone or vise versa, it's a question of whether we software engineers, as a group, are emphasizing the correct compromises, and what takeaways we can make from examining the compromises of today's popular tools.

ysavir

10 месяцев назадdiscuss

It depends a lot on the rate of change of the document.

Documents that experience little change don't need classes because their structure is reliable.

Documents that change often have unreliable structures, and will require frequent updates to the CSS rules to match structure changes. Using classes insulates the CSS from the document structure, mitigating the need to update CSS as the document evolves.

It also depend your development strategy. If using Vue components and writing the CSS in the same file as a dedicated, small-scoped components, it's practical to update the CSS references alongside the document changes. But when there's distance between the HTML and the CSS, or there are components in use who's structures may change unpredictably (such as from 3rd party libraries), classes provide a safer reference.

There's no need to have an ideology of using classes or not using classes. The practical approach is to assess the nature of your work, the rate of change of the documents, and to adopt practices built around those assessments.

ysavir

10 месяцев назадdiscuss

Location: Upstate New York, ~ 1 hour north of NYC

Remote: Yes, open to Hybrid in NYC

Willing to relocate: Possibly closer to NYC

Technologies: Ruby, Ruby on Rails, VueJS, React, TypeScript, Git, Postgres, ElasaticSearch, Heroku, AWS, Jira, OAuth

LinkedIn/Résumé: www.linkedin.com/in/yaniv-savir

Email: [email protected]

Seasoned software engineer with 11 years of web development and a proven success record using Ruby on Rails, Vue.js, React, and other frameworks. 10 years in startups, as small as 7 employees. Experienced mentor and coach to up-and-coming engineers, and champion of collaboration and efficient communication.

My ambitions are to build products I can be proud of. Software isn't an end, it's a means to an end, and the goal is hit our targets and win customers leveraging software. If you're looking for a level headed engineer who prioritizes a healthy and respectful work environment, a strong communication culture, and a deep understanding of the problems we're facing, reach out and say hi.

I am also open to work with technologies not listed above.

ysavir

в прошлом годуdiscuss

Location: Upstate New York, ~ 1 hour north of NYC

Remote: Yes, open to Hybrid in NYC

Willing to relocate: No

Technologies: Ruby, Ruby on Rails, VueJS, React, TypeScript, Git, Postgres, ElasaticSearch, Heroku, AWS, Jira

LinkedIn/Résumé: www.linkedin.com/in/yaniv-savir

Email: [email protected]

Fullstack dev with 10 years at fast-paced, early stage startups. 10 years with RoR, 8 years with VueJS, and at least 2 years in React and Angular each. Emphasis on communication and coordination: using our time together as a team efficiently.

ysavir

в прошлом годуdiscuss

Just as a note, as someone qualified for the position, this response convinced me not to apply. Not taking the time to let candidates know that you chose not to move forward with them demonstrates a lack of care and compassion, and I now associate that that attitude with Fathom as a business.

ysavir

3 года назадdiscuss

If you're open for alternatives, framing it in in a way like "I know you're trying to accomplish X, but due to Y, I think the outcome is more along Z". So something like "I know you're going for a soft launch, but without providing a more concrete and demonstrative user experience, the current status of the project is more of a tech demo".

This approach acknowledges what the person is trying to accomplish, and lays out the obstacles before arriving at the conclusion, which then feels more natural. The recipient is able to follow your thinking and hopefully "arrive" at the conclusion along with you. When you start with the conclusion, you risk having a jarring moment where you start with something unexpected, and that can generate friction.

ysavir

3 года назадdiscuss

As a general rule, optimize for your bottlenecks.

If you have a large sum of I/O and can see the latency tracked and which parts of the code are problematic, optimize those parts for execution speed.

If you have frequent code changes with an evolving product, and I/O that doesn't raise concerns, then optimize for code cleanliness.

Never reach for a solution before you understand the problem. Once you understand the problem, you won't have to search for a solution; the solution will be right in front of you.

Don't put too much stock in articles or arguments that stress solutions to imaginary problems. They aren't meant to help you. Appreciate any decent take-aways you can, make the most of them, but when it comes to your own implementations, start by understanding your own problems, and not any rules, blog titles, or dogmas you've previously come across.

ysavir

4 года назадdiscuss

The wording above could be improved for sure. But the intention is to shift focus away from telling somehow how to solve a problem to forming consensus on whether there's a problem at all. And that starts with the reviewer expressing a concern rather than immediately providing a solution. "Is a change needed?" should come before "this is a needed change".

A better example might be "I'm seeing this same code in various places--do we benefit from keeping them distinct?" or "you took an inheritance approach here, but I'm concerned about the long-term impacts as the codebase changes. How do you think this code compares with a composition approach?".

If in doing so you would think that I'm being sly, that's unfortunate, but there's not much I can do in how you interpret stuff. I can't control for others assuming bad faith. And if there's bad faith, there are probably communication and/or trust problems amongst the team members that are broader than code reviews, and is something that should be tackled directly.

ysavir

4 года назадdiscuss

Remember to be problem oriented rather than solution oriented. If you just tell people "I think this should be the solution" or "you should change it to this solution", you aren't working with them, you're instructing them. And a key to teamwork, especially reviewing, is a cooperative spirit, not an instructional one.

If instead of saying what you would do, or what you think they should do, you express a concern about the code, the tone is completely different. Now it's just saying something like "do you think repeating this across files will be problematic?", which allows the other person to be the determiner. If they agree they may well do exactly what you would have suggested, and if they don't, it can start a discussion that helps bridge together how various team members code. It's win/win.

It also helps people understand what you aim for when writing code, which helps them keep in mind your needs in the future (and vice-versa for you to keep in mind their needs).

comments