A better method to hire devs.

All that's required is to create a malicious software package under a hallucinated package name and then upload the bad package to a package registry or index like PyPI or npm for distribution. Thereafter, when an AI code assistant re-hallucinates the co-opted name, the process of installing dependencies and executing the code will run the malware.

Aboukhadijeh explained that _Iain "automated the creation of thousands of typo-squatted packages (many targeting crypto libraries) and even used ChatGPT to generate realistic-sounding variants of real package names at scale. He shared video tutorials walking others through the process, from publishing the packages to executing payloads on infected machines via a GUI. It’s a clear example of how attackers are weaponizing AI to accelerate software supply chain attacks."

Defining seniority is a very tough thing. Though in my opinion a lot of being a “senior” is in soft-skills, when it comes to the technical hard-skills, a lot comes down to Fingerspitzengefühl. The longer you work with a language, framework or codebase, the more you develop this kind of intuition of what the correct approach is. The gut feeling of “something feels off” slowly turns into a feeling of “this is what we should do”.

Bad #UI
experience: I was trying to send a friend some money via #CashApp
, but could not verify my identity. Here’s what their tech support found out:

“...from the documentation you have provided, we see that you have a legal one letter name. While we understand that is the name chosen and legally granted, we regret to inform you that we cannot proceed with the request at this time.”

I sent a response thanking them for figuring out the problem, and I wouldn’t try to get verified -- or use CashApp -- again.

I also sent them the URL for “Falsehoods Programmers Believe about Names”

Names are changing and diverse. They are so different that a validator for them seems irrelevant.

What do they have in common?

• read the reference. It's official documentation.
• they know your tools really well.
• read the error message: Really Read the Error Message and Try to Understand What’s Written. [...] The best engineers can infer a ton of information from very little context. Just by reading the error message, you can fix most of the problems on your own.
• break down problems
• are not afraid to get their hands dirty: they read a lot of code and they are not afraid to touch it. They never say “that’s not for me” or “I can’t help you here.” Instead, they just start and learn.
• always help others: great engineers are in high demand and are always busy, but they always try to help.
• write
• keep learning constantly: Part of the reason is that they keep learning. Somewhat related, the best engineers don’t follow trends, but they will always carefully evaluate the benefits of new technology.
• Don't care about status
• have a reptation
• have patience
• never blame the computer
• don't be afraid to say "I don't know"
• avoid guessing: ask questions, read the reference, use a debugger, be thorough.
• KISS
• Final Thoughts

One commit for one goal. It avoids "maintenance PRs".

Show elements in an input?

✨ Chrome: DevTools Settings > Preferences > Elements > ✅Show user agent shadow DOM

✨ Firefox: about:config > set devtools.inspector.showAllAnonymousContent to true

From a designer that ask for help. They design their prototypes on Figma.

Hyping yourself is about accurately explaining the value that you contribute. It’s about saying, “Here are all my accomplishments; here is what I’ve been up to; here are the ways that I’ve been growing and will continue to grow.” You demonstrate to others why you’re worth it and you show up with the receipts to back every claim you make.

Keep a Hype doc for it.

A Hype Doc is a running list of all your accomplishments and successes. It’s a place where you keep track of your growth, and regularly jot down the things you’re proud of doing.

It includes: technical work completed, projects led or contributed to, mentorship and development, leadership opportunities, blog psots and talks revelant to your work, involvment in recruiting and interviewing, valuable contributions to discussions, kudos and feedback from others, significant moments of growth or learning.

Update it regularly (weekly?), it should be easy to edit and can be shared to managers.

Compiling Rust with GCC?

Follow up: https://blog.antoyo.xyz/development-rustc_codegen_gcc-2

I didn't read but it can be useful someday.

What is a computer club?

a computer club is where a group of people hang out and do computer together
Doing computer is whatever you want...on computers, together.

the political economy of computing is awful. have you read palo alto? me neither. we should read it. we deserve better than the darpa-funded visions of xerox parc technologists

Rules

• Hang ou in real life
• reject corporate sponsorship
• computer club is a collective project

Guidelines

• computing is political
• the recurse center social rules foster collaboration and psychological safety
  be inspired by permaculture, small web, diy culture, computing as a medium through which better things are possible
• try to host computer club's stuff on your own computers in the place that you live
• be open to interdisciplinary computing
• be open to different histories and "skill levels" with computing

There is also a list of computer clubs and a list of tools

Technically this whole site is already about me.

After seven years working as a Network Technician, I switched careers to be a web developer.

#blog https://ryantrimble.com/blog/1

I.

Most things fail because nobody cares.

II.

Let’s start with what doesn’t work: copying success. Everyone trying to make the next Facebook creates a wasteland of social networks nobody wants.

III

Here’s the core principle: people give a shit about things that meaningfully change their lives.

IV

Solving real problems isn't enough. You also need to solve them in a way that resonates emotionally.

V.

Why didn't someone do it sooner? Because the obvious solution was previously impossible, illegal, or insane.
The sweet spot? When something just became possible, legal, or sane enough to try. That’s why timing matters more than ideas. Being too early is the same as being wrong.

VI.
Communicate why anyone should care. Focus on outcomes.

VII.

Making something people care about often means making something people already care about, just better.

VIII.

The most successful products are often worse in most ways but radically better in one way that matters.

IX.

Sometimes, making something people care about means removing things people hate.

X.

Finally, there’s the hardest truth: you have to give a shit yourself.

XI.
Hit 6/8 (from III. to X.). More is overkill. Less is self-sabotage.

making something people give a shit about doesn’t mean making something perfect. It means creating something meaningfully better in a way that touches people’s lives.

In the end, people don’t care about products, features, or specifications. They give a shit about their lives being better. Everything else is just details.

(XII.)

creating something people give a shit about isn't enough – you have to remember why they gave a shit in the first place.

How to destroy softwares on the long term?

Avoid, at all costs, arriving at a scenario where the ground-up rewrite starts to look attractive

Aim to be 90% done in 50% of the available time

Think about pathological data

Edge cases are our entire job.

There is usually a simpler way to write it

Write code to be testable

It is insufficient for code to be provably correct; it should be obviously, visibly, trivially correct