What I do is study problems, design systems to solve them, and build those systems myself. On any given day I have multiple terminals open, each one a different project requiring an entirely different set of skills: data analysis, software engineering, product design. Most of that goes well beyond my job description. I do it because it needs doing and because I can. I also have a manager who recognized that before I did, and gave me the room to prove it.

The closest I’ve come to a name for it is AI systems builder. It’s not perfect, but it’s closer to the truth than any title I’ve been given. And it took a long time to get here. The path didn’t look like a path while I was on it.

I’ve always been this way. I spent over a decade cycling through careers: law, journalism, teaching, data science, restaurant management, nonprofit human rights work. As a kid, I kept discovering I was good at things without trying very hard. That sounds like a gift, but it was also a trap. I never had to push through difficulty, so I never learned how. I just moved on to the next thing that came easily.

That pattern carried a cost I didn’t talk about. Every year I watched people I’d started alongside build something: a practice, a title, a reputation, a trajectory that made sense to other people. I kept starting over. At first, people around me thought I was on my way somewhere. She’s figuring it out, she’ll land. But it took so long that I could feel their confidence fading. The question behind their eyes shifted from “where will she end up?” to “will she ever get it together?” That was painful, because I was asking myself the same thing. I had faith in myself longer than most people did, but even that was dying. I could learn so much, do so much, and still get nowhere.

The shame of being almost-good-enough at a dozen things and not able to point to a single one and say this is mine. It’s a specific kind of loneliness, being surrounded by people who know what they are and not having an answer when someone asks you the same question.

Early on, while I was still doing nonprofit work, I read David Epstein’s Range. It was the first time I’d encountered the argument that breadth wasn’t a deficiency. For a moment, I felt like maybe I wasn’t broken. But that feeling didn’t hold. Every time I changed direction after that, it still felt like failing. A book can tell you the pattern is valid. It can’t make the pattern stop hurting.

The first time I tried data science, I quit. I’d done a bootcamp, and one of the assignments, writing a KNN algorithm from scratch, destroyed me. I finished it eventually, but the experience left me feeling completely out of my league. Another thing I was almost good enough at. I went back to restaurants and bars, work I genuinely liked, and tried not to think about it too much. Then COVID shut that down too.

Somehow I ended up back in data science. I honestly don’t remember the moment I decided on a master’s program. I just know that when I came back, I wanted to be stronger. My bachelor’s was in Asian Studies. Not a single math class on the transcript. So I enrolled in community college, took the required calculus courses, aced them, and got into the Statistics Masters Program at Texas A&M University.

That was the first time I proved to myself I could go deep. Not because it came easy, but because I decided to do it anyway.

I graduated with the goal of becoming a data scientist. Around the same time, I started an AI book club and finished the deep learning specialization on Coursera. Machine learning engineering went from an interest to an obsession. And something shifted in me that had nothing to do with credentials or career planning. I stopped caring about being behind, about following a path, about what other people thought. For the first time I was just genuinely passionate, and that was enough to keep moving.

Then I landed a contract role at Meta, a job that required my weaknesses rather than my strengths. The role was data labeling analyst, reviewing code used to train Llama. I was honest in the interview: my background was in statistics and data science, not software engineering. They brought me on anyway.

The plan was to use this job as a bridge. By day I reviewed MLE code at Meta. By night I studied to become one: textbooks, research papers, Python, object-oriented programming. I ground through LeetCode, voluntarily, which is how you know something had fundamentally changed. For the first time in my life, I was choosing difficulty, and I loved it.

The two tracks fed each other. Every script I reviewed at work, I studied closely, looking at what made code robust, what made it fragile, what patterns held up under pressure. I had a knack for reading systems even when I couldn’t yet build them fluently. The breadth I’d accumulated turned out to be exactly the right lens for evaluating training data quality. I was learning as the model learned.

I didn’t stay in that lane long. I started taking the lead on different workflows, then reached for coordination, then project ownership. I just kept seeing what needed doing and doing it.

An unexpected opportunity came up: an interview for a DevOps and data engineering role. I’d been studying engineering on my own for months, but this was the first time I had to prove it in a room. I didn’t get the job. But I walked away knowing the ceiling I’d assumed was there didn’t actually exist.

If you read the earlier posts on this blog, you’ll see someone who was all in on becoming a machine learning engineer. That was real. I meant every word of it.

Then I watched the ground shift under the field I’d just fought my way into.

AI tools got good. Really good. I started building with them and realized something uncomfortable: the models already knew more than I did. I wasn’t just racing other engineers to get good enough. I was trying to outrun a machine that would always be faster, and I was starting from behind. The bottleneck would no longer be who could write the code. It would be who could see the problem, design the solution, and get people to actually use it.

That recognition felt like another pivot, and pivots still felt like failing. But this time I had something I’d never had before: enough depth to trust my own read. Statistics gave me intuition for what these models were actually doing under the hood. The MLE work gave me fluency with the ecosystem. I wasn’t guessing. I could see exactly how and why the field was shifting. That understanding is what gave me the confidence to step off the MLE track instead of doubling down on it.

I leaned into project management. When I looked back, I realized that nearly every role I’d held across that decade of wandering was management in some form: running a classroom, running a restaurant floor, coordinating a nonprofit. I hadn’t noticed the pattern because I was too busy feeling ashamed of it.

I moved into a project coordinator role, and for the first time I treated a role as a craft. A lot of that is because of my manager. She’s someone who gets things done exceptionally well on her own, which made it mean something when she chose to trust me with real responsibility instead. She mentored me, advocated for me, and gave me room to grow into work that was well beyond my title.

Then in early 2026, AI tools took another leap. Meta integrated AI across nearly every workflow. The gap between what I could imagine and what I could build essentially disappeared. So I stopped worrying about roles and titles and did what I’d always done, I solved problems. Except now, for the first time, I could also build the solutions myself.

My manager was running a large workforce and had no shortage of problems. She’d surface one, like no visibility on contractor performance across the program, and trust me to figure it out. I designed an evaluation system from scratch: real-time dashboard, clean data model, the right metrics, low enough friction that people used it without being asked. Another gap: QA work buried in Google Sheets, invisible to leadership. I built an add-on, partnered with data engineering, and connected it into Meta’s data ecosystem. The tool spread to other pillars on its own. I kept expanding it.

Full ownership, no title. And from the start, I was designing these systems with AI in mind, not as an afterthought but as part of the architecture. LLM integrations, automated pipelines, bots. It’s not about using AI to make things run faster. It’s about rethinking the entire design so that AI and humans work together in ways that help both do better work. Every decision I made, from the data model to the prompt design, drew on something from a phase I once dismissed as aimless exploration.

AI collapsed the distance between understanding a problem and building the solution. Before these tools, I would have specced those systems out for an engineering team and waited. Instead, I made a different bet: master the tools and think harder about product. I put myself in founder communities, not to start a company but to absorb the mentality. See a problem. Own it end to end. Ship it. Iterate. That bet paid off.

AI gave generalists execution speed they never had. But speed without judgment is just noise. The reason these tools work for me is that I spent years building the judgment first: the statistical thinking, the data intuition, the product instinct, the management experience. AI removed the bottleneck that kept people like me from acting on what we could already see. The depth is what made the seeing worth anything.

Breadth got me to the door. Depth gave me the foundation. AI gave me the speed to use both at once.

That’s why I call myself an AI systems builder, for now. It doesn’t fit perfectly. Maybe nothing ever will. But it’s closer to the truth than any title I’ve been given, and I’m done waiting for a label that captures all of it before I let myself claim any of it. I spent years resigned to a landscape that rewarded specialists and didn’t have a category for people like me. I’m still adjusting to the fact that it shifted in my direction.

I think back to reading Range all those years ago, how I wanted to believe it but couldn’t quite let myself. The validation I was looking for didn’t come from a book. It came from the work finally catching up to the pattern.

If you’re where I was, feeling behind, trying to pick a lane, embarrassed that nothing you do fits a clean title, here’s what I’d offer. At some point, you do have to go deeper into something. If you’ve been exploring long enough, you already know what feels right. Let yourself commit to it.

The fear is that depth closes doors. That choosing one thing means losing everything else. But that’s not how it works. Specializing is never-ending. You can always go further, and every time you do, it opens lateral doors you couldn’t have seen from the surface. Going deep into statistics opened data science. Data science opened machine learning. Machine learning opened AI systems. Each commitment revealed more than it foreclosed. There has never been a shortage of things to be curious about. If anything, depth is what finally gave my curiosity somewhere to land.

Right now, I’m fine-tuning a YOLOv8n model to detect tennis balls. I collected my own dataset and recently finished training the first solid version. The model is performing well on the validation set, with best weights showing over 92% recall and over 96% precision. I’m now doing error analysis to see where it struggles—especially in tricky or real-world conditions—so I can keep improving it before deploying to the HAiLO AI accelerator. Spending this much time on error analysis has been helpful. It’s forcing me to notice edge cases and understand model training better.

Lately, I’ve been deeply involved with hardware: programming movement using omnidirectional wheels, testing encoder DC motors, and troubleshooting all the unpredictable behaviors that come with real-world components. I recently hit a milestone that felt like a real turning point: I built a motion controller that actually works. We cheered when the robot completed each direction we programmed for it from forward movement to strafing right. I also wrote a centralized logger so I could track what each wheel was doing in real time. 

class MotionController:
    def __init__(self):
        """
        Initialize the motion controller.

        - Sets up the logger for the motion control module.
        - Claims GPIO control for the motor-related pins.
        """
        # Set up the logger
        motion_logger = Logger(name="motion", log_level=logging.INFO)
        self.logger = motion_logger.get_logger()

        self.chip = lgpio.gpiochip_open(0)  # Open GPIO chip 0
        self.stby = STBY  # Pin that enables/disables motor driver

        # Motor pin groups for each wheel (IN1, IN2, PWM)
        self.motors = {
            "FL": FRONT_LEFT,  # Front Left
            "FR": FRONT_RIGHT,  # Front Right
            "RL": REAR_LEFT,  # Rear Left
            "RR": REAR_RIGHT,  # Rear Right
        }

        # Direction patterns for movement
        self.patterns = {
            "forward": {"FL": 1, "FR": 1, "RL": 1, "RR": 1},
            "backward": {"FL": -1, "FR": -1, "RL": -1, "RR": -1},
            "strafe_left": {"FL": -1, "FR": 1, "RL": 1, "RR": -1},
            "strafe_right": {"FL": 1, "FR": -1, "RL": -1, "RR": 1},
            "rotate_left": {"FL": -1, "FR": 1, "RL": -1, "RR": 1},
            "rotate_right": {"FL": 1, "FR": -1, "RL": 1, "RR": -1},
            "diagonal_fr": {"FL": 1.0, "FR": 0.5, "RL": 0.5, "RR": 1.0},
            "diagonal_fl": {"FL": 0.5, "FR": 1.0, "RL": 1.0, "RR": 0.5},
            "diagonal_br": {"FL": -0.5, "FR": -1.0, "RL": -1.0, "RR": -0.5},
            "diagonal_bl": {"FL": -1.0, "FR": -0.5, "RL": -0.5, "RR": -1.0},
        }

        # Claim GPIO control over all motor-related pins
        self._claim_output_pins()

This phase has been messy. I’ve spent hours debugging motors that turned out to have a single miswired pin or a loose ground connection. But I’ve also started to feel like I’m building something real. I refactored the codebase into cleaner modules: navigation, detection, sensors, strategy, etc.

Integration is next: connecting the object detection model to the robot’s control logic and sensor input so it can start making actual decisions. I’m planning to use bounding box size and location to estimate object distance and direction, while using ultrasonic sensors to avoid collisions or stop at just the right distance.

│   ├── core/                        # Core functionality of the robot
│   │   ├── __init__.py              # Marks this folder as a package
│   │   ├── navigation/              # Navigation and motion control logic
│   │   │   ├── __init__.py          # Marks this folder as a package
│   │   │   ├── encoders.py          # Encoder-related logic
│   │   │   └── motion_controller.py # Controls motor movement and direction
│   │   │
│   │   ├── detection/               # Object detection (YOLO) logic
│   │   │   ├── __init__.py          # Marks this folder as a package
│   │   │   ├── vision_tracker.py    # Tracks and handles object detection
│   │   │   └── yolo_inference.py    # YOLO inference for real-time object detection
│   │   │
│   │   ├── sensors/                 # Sensor control and integration
│   │   │   ├── __init__.py          # Marks this folder as a package
│   │   │   └── ultrasonic_sensor.py # Ultrasonic sensor for distance measurement
│   │   │
│   │   ├── strategy/                # AI decision-making logic
│   │   │   ├── __init__.py          # Marks this folder as a package
│   │   │   ├── movement_decider.py  # Decides robot movement strategy
│   │   │   └── __init__.py          # Marks this folder as a package
│   │   │
│   │   └── streaming/               # Streaming and remote access components
│   │       ├── __init__.py          # Marks this folder as a package
│   │       ├── camera_streamer.py   # Manages camera feed streaming
│   │       ├── performance_monitor.py # Monitors system performance in real-time
│   │       └── stream_client.py     # Handles communication with streaming services

A big part of what’s kept me going is how much this project is teaching me about how I learn. Early on, I used large language models to help generate basic test scripts and wire up examples. That was helpful, but surface-level. Now, I often start high-level—thinking through design choices like class structure, logic flow, and how I want the code to behave. Then I’ll use large language models to help scaffold that vision into actual code. Having that kind of sounding board has made me more deliberate and confident in how I architect things.

As the project grows, I’m realizing that I need systems not just for the robot—but for myself. I’ve added internal documentation, a structured to-do list by subsystem, and a dev_notes.md file that helps me track what I’m working on and why. This is on top of taking notes in my physical notebook. Writing things down keeps me sane when I feel like I’m drowning in tiny problems with no clear next step.

This robot is still a work in progress, but it already represents something bigger to me. It’s not just a machine I’m building—it’s a way for me to prove to myself that I can handle complexity, learn what I don’t know, and keep going even when I feel lost or overwhelmed. 

This week, I:

• Developed an AI Assistant:
  • Set up an AI assistant using Ollama and FastAPI.
  • Integrated RAG with FAISS for document retrieval and built a Streamlit UI to interact with the assistant.
  • Improved retrieval and response accuracy by refining context handling and prompt structure.
• Explored LLMs and Conversational AI:
  • Compared Mistral, Mixtral, and Llama models for RAG and conversational AI use cases.
• Optimized RAG Document Storage:
  • Explored scalable methods for storing and organizing RAG documents using SQLite and MongoDB.
• Worked on Tennis Ball Bot:
  • Completed tests on the wheel motors and rotating cylinder fins motor of the Tennis Ball Bot.
  • Learned how to stream the object detection feed from the bot using FastAPI and Cloudflare.
• AWS Setup:
  • Ran instances on EC2 to host the AI assistant I built with RAG.
  • Learned how to configure security settings, adjust volume sizes, and configure other essential instance settings to ensure proper deployment and optimization.
• Machine Learning & Systems Design:
  • Finished week 1 of Machine Learning in Production from DeepLearning.AI.
  • Read Chapter 3 of Designing Machine Learning Systems.
• Leetcode & Study Group:
  • Resumed Leetcode practice by joining a local study group.
• Python Debugging:
  • Finally learned how to use a Python debugger to troubleshoot and step through code more effectively.

This week, I:

• Completed more work on the Tennis Ball Bot:
  • Learned enough Prometheus and Grafana to set up a working dashboard.
  • Collected more data for the Tennis Bot.
  • Finished a couple of sets of annotations.
  • Learned about IMU and ultrasonic sensors.
• Customized an LLM locally using Ollama:
  • Set up a basic RAG pipeline.
  • Used MLflow to track model training.
  • Explored the differences between popular LLMs available through Ollama (Llama 3.3, Mistral, DeepSeek-r1, and others).
  • Gained insight into the computational demands of running an LLM locally.
• Created an AWS account and increased the EC2 instance quota:
  • Realized that learning AWS will be a larger endeavor than expected.
• Completed a lecture on Markov Decision Processes.
• Read up to 60% of Life 3.0.
• Completed Foundations of Convolutional Neural Networks from DeepLearning.AI.
• Listened to at least three AI/Neuroscience podcast interviews.
• Hosted the first session of Weekly ML/AI Interview Prep.

This is my first time writing a summary of what I’ve accomplished over the past week, and I plan to make it a weekly habit. It’s a great way to track my progress and reflect on what I’ve learned. Looking back, I noticed that I wasn’t as motivated to read this week but felt more engaged when learning through building. Making this list also helps me recognize the effort I’ve put in—something I tend to overlook. My default mindset has been, “I’m not doing enough” or “I can’t learn fast enough,” but I need to reframe that perspective.

Failing the Python portion of my technical interviews in December was both embarrassing and disappointing. However, it turned out to be an invaluable first technical interview experience. The interviewers were all incredibly talented and kind, and I walked away with a clear understanding of where to focus my efforts—an important win.

Out of four interviews, one focused on traditional data structures and algorithms (DSA), while another was a pure Python assessment. I could have performed significantly better in both had I done one crucial thing: practice.

I’m not sure how common it is to absorb a lot of knowledge through reading and watching videos and assume that’s enough, but that’s exactly what I did. I spent two weeks cramming as much as I could about DSA and Python programming. I completed numerous Leetcode problems, but not nearly enough to truly internalize the patterns and implementation strategies. Instead of reinforcing what I learned through repetition and testing myself, I continuously sought out new concepts. This was my biggest mistake—I should not have considered myself prepared until I had thoroughly tested my ability to apply what I learned.

This time around, I’m taking a different approach—learning at a slower pace. Not having an immediate deadline is helpful. Since my preferred way of absorbing knowledge is through reading (followed by watching videos), I decided to read Fluent Python by Luciano Ramalho in its entirety while re-evaluating my Leetcode strategy. Unlike before, I’m prioritizing hands-on practice and assessment, making them just as—if not more—important than passive learning. Additionally, I’ve introduced a structured review process. Initially unsure of the best approach, I’ve settled on writing about the exercises I complete, incorporating teaching as part of my learning workflow.

Study Plan:

Read Fluent Python Chapters → Complete Exercises → Review/Teach

So far, I’ve completed Chapters 1, 2, 3, and 5 of Fluent Python. After finishing Chapter 3, I asked ChatGPT to generate exercises:

“I want to work on exercises to reinforce what I learned from Fluent Python, Chapters 1–3. Give me short exercises/assignments.”

Chapter 1 covers The Python Data Model, Chapter 2 covers An Array of Sequences, and Chapter 3 covers Dictionaries and Sets.

Here’s one of the exercises along with my solution:

Exercise 1: Understanding __repr__ and __str__

Write a class called Card representing a playing card with a rank (e.g., ‘Ace’, ‘2’, ‘3’, …) and a suit (e.g., ‘Hearts’, ‘Clubs’). Implement the __repr__ and __str__ methods so that:

• __repr__ returns a formal representation: Card('Ace', 'Hearts').
• __str__ returns a user-friendly representation: 'Ace of Hearts'.

Learning Objective:

Understanding the difference between __repr__ and __str__.

class Card:
    def __init__(self, suit='Spades', rank='Ace'):
        self.suit = suit
        self.rank = rank
    
    def __repr__(self):
        return f"Card('{self.rank}', '{self.suit}')"
    
    def __str__(self):
        return f"{self.rank} of {self.suit}"
    
    def __iter__(self):
        return iter((self.rank, self.suit))

# Example usage:
card = Card('Hearts', 'Four')
print(card)  # Four of Hearts
print(repr(card))  # Card('Four', 'Hearts')

suits = ['Spades', 'Clubs', 'Hearts', 'Diamonds']
ranks = ['Two', 'Three', 'Four', 'Five', 'Six', 'Seven', 'Eight', 'Nine', 'Ten', 'Jack', 'Queen', 'King', 'Ace']
deck = [Card(suit, rank) for suit in suits for rank in ranks]

print(deck[:10])
print([str(card) for card in deck[:10]])

Expected Output:

Four of Hearts
Card('Four', 'Hearts')
[Card('Two', 'Spades'), Card('Three', 'Spades'), Card('Four', 'Spades'), Card('Five', 'Spades'), Card('Six', 'Spades'), Card('Seven', 'Spades'), Card('Eight', 'Spades'), Card('Nine', 'Spades'), Card('Ten', 'Spades'), Card('Jack', 'Spades')]
['Two of Spades', 'Three of Spades', 'Four of Spades', 'Five of Spades', 'Six of Spades', 'Seven of Spades', 'Eight of Spades', 'Nine of Spades', 'Ten of Spades', 'Jack of Spades']

This was an excellent starting exercise because, right away, I had to write a class—something I struggled with during my interview.

The exercise directly reinforces the main concept of Chapter 1: Python’s special methods. These methods are enclosed with double underscores (e.g., __repr__, __str__). As someone who initially learned Python for data analysis and machine learning, I had only encountered __init__, so I hadn’t realized how fundamental special methods are for object-oriented programming. These methods aren’t meant to be called directly by users but instead define how objects behave when used with built-in Python functions. For example, __len__ allows an object to return its length when passed to len(obj), rather than requiring obj.__len__().

So, what’s the difference between __repr__ and __str__?

• __repr__ provides an unambiguous string representation of an object, ideally one that could be used to recreate the object. Without it, printing an object would return a default type reference instead. According to Fluent Python, __repr__ should “be unambiguous and, if possible, match the source code necessary to re-create the represented object.”[^1] In my implementation, repr(card) returns Card('Four', 'Hearts'), which satisfies this requirement.

• __str__ returns a human-readable, user-friendly string representation of an object. In my implementation, str(card) returns "Four of Hearts".

I also included __iter__ in my class because I planned to reuse it for later exercises.

ChatGPT provided me with six exercises, which you can find here on my GitHub. While I’ve completed them, I haven’t written up my reflections yet. I’ll be posting more as I review my solutions and continue my reading.

I started this blog with the intentions laid out in my first post. However, getting started felt daunting. Months after writing that first post, I was listening to an interview with Daliana Liu on Super Data Science when she said something along the lines of, “If you’re one of those people with drafts lined up but are too afraid to publish, you should just do it.” I felt like she was talking directly to me. Her message was clear: the most important thing is to start. It’s okay to put out an imperfect product and improve over time. Another point that stuck with me was to write with intention—but that intention doesn’t have to be perfection or gaining thousands of followers. Writing is a way to process thoughts, reinforce learning, and build clarity. I’ve spent too many years not creating because I felt inadequate in a world already saturated with content.

With that in mind, I’ve decided to use this blog as a learning log, at least for now. Managing the knowledge, skills, and concepts I’ve been absorbing has been overwhelming. It often feels like I’m learning a lot yet not making any significant progress. Writing it down will help reinforce my learning and allow me to see tangible growth. I rarely recognize my own progress unless someone points it out or I force myself to take a step back and give myself credit. Another benefit is simply getting comfortable with taking up space online—imperfectly.

To be honest, I have over a dozen tabs open right now. I just finished a long-winded conversation with ChatGPT about my skills, progress, and next steps. I know I need to update my resume. I installed FastAPI, only to immediately switch directions and start learning Apache Airflow instead. My mind felt so cluttered that I finally sat down to write this—to get clarity before moving forward.

Another approach I’ve taken is keeping a real notebook with grid paper to jot down my thoughts, ideas, questions, and project progress. Since starting this, I’ve been able to capture so much more of what’s going on in my mind, helping me revisit essential problems and stay on track. I might expand on this in a future blog post.

But today, I want to set a foundation for my learning log by reflecting on my journey and laying out my roadmap—however dynamic it may be.

I spent years working toward a Master’s in Statistics, expecting to become a statistician or researcher. After a few failed interviews, I landed a role as a Coding Data Labeling Analyst at Meta. I found it hilarious that they hired me for a job requiring my weaknesses rather than my strengths. However, I quickly realized there was no good reason for coding and engineering to be a weakness. I became obsessed, and suddenly, the possibilities expanded.

An unexpected opportunity to interview for a DevOps/Data role lit a fire under me, and I started learning fast. Though I didn’t ultimately get the job, the experience gave me a much clearer understanding of what I like, what I know, and what I need to learn. Before that, I never thought I could be the kind of person who participated in coding interviews or aimed for engineering roles. I never even thought DevOps or data engineering would interest me. I was so wrong.

Preparing for that interview meant hours of watching YouTube videos on data structures and algorithms, reading Ace the Data Science Interview and Cracking the Coding Interview, and completing courses on CI/CD and testing. By the time I was done, the outcome of the interview didn’t even matter as much—I wanted the job, but I also walked away knowing I had leveled up. If I could do that, I could do more.

Now, I want to join the innovative AI and MLE engineers shaping this incredible era of AI potential. To do that, I feel like I need to learn everything—and that excites me.

Every day, I log off work and dive into my ever-changing, massively ambitious, self-made ‘curriculum,’ assisted by ChatGPT. My decisions are shaped by a mix of passion, interest, and the need to build essential skills. I’m also working on a challenging computer vision and robotics project (which I’ll probably write about in another post). There are skills I need now for roles I can realistically reach and skills I need to start learning for the roles I see myself growing into.

To get us up to speed, this was my most recent message to ChatGPT:

“I think I might not be focusing my immediate skill progression correctly. I’m advancing Python skills, completing the Deep Learning Specialization, reading Fluent Python, completing Leetcode DSA, and reading Reinforcement Learning and papers in the LLM, RL, and Agents space.”

I left out that I’m also working on a robotics project, leading a local AI book club, and reading Chip Huyen’s AI Engineering.

I can’t even keep track of everything I’m doing, so it’s time to refocus again.

I’m reading:

• Reinforcement Learning: An Introduction – Because RL fascinates me, and understanding its theory will help me work on practical implementations in AI.
• Fluent Python – Because I need to level up my Python programming skills to write cleaner, more efficient code.
• AI Engineering – Because it offers an eye-opening perspective on AI deployment and the challenges beyond model training.
• Research papers on LLMs, Agents, and RL – Because I want to understand the research trajectory and anticipate where the field is heading.
• Life 3.0 by Max Tegmark – Because my AI Book Club picked it for the month, and it adds a philosophical dimension to AI discussions.

I’m taking:

• Deep Learning Specialization (Coursera, DeepLearning.ai) – Because mastering deep learning concepts is foundational to my career in AI.
• Machine Learning in Production – Because understanding how to deploy and scale AI models is just as critical as training them.

I’m building:

• A robot that detects and picks up tennis balls autonomously – Because it’s a fun challenge, and collaborating with mechanical engineers pushes my practical programming skills.

I’m practicing:

• Leetcode problems – Because strong algorithmic skills will prepare me for technical interviews.
• Python exercises generated by ChatGPT – To reinforce my understanding of advanced Python concepts from Fluent Python.
• Git and GitHub – Because version control and collaboration are fundamental for working in AI teams.
• Docker and WSL – Because containerization and system environments are essential for ML and deployment.

And somehow, it still doesn’t feel like enough.

Additionally, I need to start building skills in ML production and data engineering.

I’ll start with:

• Apache Airflow – To gain experience in workflow automation and data pipelines.
• GitHub Actions – To automate software workflows and CI/CD.
• Data Pipelines (maybe on AWS) – To work on scalable data infrastructure for AI applications.

Then eventually:

• LLM Engineering – To understand and contribute to the next wave of AI advancements.
• FastAPI – To build high-performance APIs for deploying AI models.
• Agentic AI – To explore autonomous AI systems and decision-making models.

Every time I write out a plan, I feel an immediate sense of comfort. If I just follow it, execute, and refine it occasionally, I’ll inch closer and closer to my goals. And for now, that’s enough for me.

What Can You Expect Here?

1. Machine Learning Techniques and Tools

My passion for machine learning compels me to delve deep into its intricacies. To solidify my understanding, I often employ the Feynman Method, which allows me to simplify complex concepts. By sharing what I learn, I not only reinforce my knowledge but also hone my professional writing and editing skills. Expect posts that include:

• Explorations of various algorithms and techniques
• Hands-on tutorials and project write-ups

2. My Career Journey

Transparency is vital to me as I navigate my transition to a machine learning engineer role. This path is undoubtedly challenging, but I am eager to share my experiences with you. Look forward to posts covering:

• Steps I’m taking to build my skills and portfolio
• Reflections on both my successes and challenges

3. Neurodiversity in Tech

As someone who identifies as neurodivergent, my late ADHD diagnosis has profoundly influenced my learning and working style in technology. This newfound awareness has allowed me to better understand my mind and discover effective strategies for managing it. While I may only occasionally dedicate full posts to my ADHD experiences, I will weave this perspective throughout my writing, covering topics such as:

• How neurodiversity shapes my problem-solving approach
• Strategies for maintaining focus and productivity in a fast-paced tech environment
• Celebrating the strengths arising from diverse cognitive styles

4. Ethical Considerations in AI

My background in human rights and democracy advocacy informs my approach to technology. I am committed to using AI to enhance society for all. Currently, I host a book club in LA where we explore different AI books each month, fostering meaningful discussions about their implications.

Machine learning and AI extend beyond technology; they raise critical ethical questions. As I navigate this landscape, I will discuss:

• The societal impacts of AI
• The responsibilities of machine learning engineers in ensuring fairness and transparency
• Philosophical considerations surrounding the technology we develop

I am genuinely excited to witness groundbreaking advancements in AI and eager to share my reflections with you.

5. Curated Resources

I understand how overwhelming it can be to sift through the multitude of available resources, especially for those building self-discipline and optimizing productivity on their own. I’ll curate materials tailored for individuals like myself—those dedicated to deep understanding, possibly navigating ADHD, and pursuing their goals without a formal degree program. Expect:

• Reviews of books that have significantly shaped my understanding of machine learning
• Recommendations for online courses and learning platforms designed for self-directed learners

Why I Started This Blog

Reading A Brief History of Intelligence revealed the interconnectedness of my diverse interests, including mental health, productivity, pedagogy, machine learning, technology, neurodivergence, mindfulness, consciousness, and humanity. These themes converge around the concept of intelligence, which I find endlessly fascinating—especially regarding the brain and consciousness.

My passion for learning and sharing insights motivates this blog. Documenting my journey not only fosters my reflection and growth but also connects me with others who share similar interests. As I pursue this career path without a formal research degree, I aim to create tangible evidence of my efforts. I’ve always valued community-building, finding joy in bringing people together around both shared and contrasting interests. Establishing a blog that nurtures such a community resonates deeply with me, allowing me to connect with others who share my passions.

Whether you are a fellow learner, an experienced professional, or simply curious about artificial intelligence, I hope you find valuable insights here. Together, let’s navigate this fascinating landscape, celebrate our diverse perspectives, and cultivate a supportive community.

Thank you for visiting Cognitive Curiosities! I’m excited to share my journey with you and look forward to where this adventure takes us.

Until next time,
Kathy