fazlerocks

honestly? teaching or coaching.

been thinking about this a lot lately and realized the skills that made me good at building products, breaking down complex problems, explaining things clearly, helping people think through decisions… those transfer really well to education.

I actually did that early in my career (2013/14/15), wrote content on frontend tech like bootstrap for sites like sitepoint. published multiple books which helped me get my o1 visa :D

there's something appealing about work that's fundamentally about humans helping other humans grow. way harder for AI to replace the relationship part of learning

been mentoring junior devs and it's honestly the most fulfilling work i do. if tech gets fully automated, at least i'd be doing something that actually feels meaningful

we've shifted to focusing way more on problem-solving ability during interviews rather than just coding skills

still do technical screens but now we give people access to AI tools during the process - because that's how they'll actually work. want to see how they break down problems, ask the right questions, and iterate on solutions

honestly the candidates who can effectively use AI to solve complex problems are often better hires than people who can code from scratch but struggle with ambiguous requirements

the key is testing for engineering thinking, not just programming syntax

we've tried a bunch of different approaches and honestly the best feedback comes from getting people in a room (or zoom) together

widgets are fine for quick "this button doesn't work" stuff but for real UI feedback you need context… what were they trying to do, where did they get confused, what did they expect to happen

we do weekly design reviews where everyone can see the same screen and talk through flows in real time. way more valuable than async comments scattered across different tools

the trick is making it feel collaborative instead of like a critique session. when people feel heard they give way better feedback

the best "payment" is often just updating them on how their help changed your trajectory. a simple message years later saying "that advice you gave me led to X" means everything

also - helping the next person who reminds you of your younger self. pay it forward instead of trying to pay it back directly. most mentors get more satisfaction from seeing the ripple effect than getting something back personally

This is actually a really cool direction, using LLMs to interact directly with Android UIs could solve the brittleness problem that's been killing traditional automation.

Like just telling it "navigate to settings and enable dark mode" instead of writing fragile selectors… that's the dream :D

But the current implementation has some issues that make it tough for real use ~

2-5 second latency per action is brutal. A simple login flow would take forever vs traditional automation.

The bigger thing is reliability… how do you actually verify the LLM did what you asked vs what it thinks it did? With normal automation you get assertions and can inspect elements. Here you're kinda flying blind.

Also "vision optional" makes me think it's not great at understanding complex UIs yet… which defeats the main selling point.

That said this feels like where things are headed long term. As LLMs get faster and better at visual stuff, this approach could eventually beat traditional automation for maintainability. Just not quite ready for production yet.

We're building tools that could genuinely make people's lives better, but instead most companies are laser-focused on "how many jobs can we eliminate?" The whole conversation around AI safety isn't even about keeping people employed… it's about making sure the AI doesn't turn on us.

Investors want to hear about efficiency gains and cost savings (aka layoffs). Customers want solutions that work. Trying to balance building something useful while not contributing to the dystopia is genuinely difficult.

What keeps me going is focusing on problems that actually matter and being selective about who I work with. Not everyone can do this, but if you have some leverage, use it to push back on the worst impulses.

Been messing around with the different memory files and honestly it's pretty useful once you get the hang of it.

I mostly use:

Project ./claude.md - team stuff like our weird API naming conventions, how we structure components, deployment steps that always trip people up

Local ./claude.local.md - my dev URLs, test accounts, personal shortcuts. Stuff I don't want to commit to the team file

User ~/.claude/claude.md - code style preferences, how I like explanations (brief vs detailed), tools I always use

The recursive thing is neat - it picks up memories from parent folders so you don't have to duplicate everything.

That # shortcut is way faster than editing files manually. Still forget about /memory command half the time tho.

Main thing I learned is being specific helps a lot. 'Use our error handling pattern' vs actually showing the pattern makes a big difference.