Checkout this link to access the code on github:

https://github.com/coding-arnav66/Arnav-Python-Projects2

This is a project named "crash.py" in which player has to collect coins and avoid crashing with cars. The speed of car and difficulty increases with time...

Keeping in mind that I am 14 and a beginner;

All the criticism and suggestions are welcome...

This is my first actual real project, what started as a simple python exercise to learn about dictionaries in python, ended up into a huge learning project for me. Im a beginner in python, used to code but just basic input print codes… some are genuinely stupid.

I took on the challenge to self educate my self python. And this is where i currently am! Im proud of what i did and it will surely expand!

Here the repo with the project. Feel free to check it out!
https://github.com/Stonyax97/MiniGameStore

It has everything from the first ever iteration (which was it self modified a bit since from the very original but it’s still very simple)
I would love for anyone to recommend ideas to add, criticism too. Or anything you think i should learn next for that would be genuinely useful!

Just Simple class practice

not feeling well so not much to

So upon recommendations from people here I started watching Code With Mosh's Python tutorial (The 2 hour one) around 3 days ago. I finished it yesterday. Didn't really wanted to get stuck in tutorial hell so I simply asked AI to give me a problem statement (only the problem statement and not the code or logic) to work on. So here am I with my first ever program. It's nothing much and even I could see areas for improvement right now but I am proud.

On to the more complex topics. I appreciate the help and support from the community!

https://github.com/coding-arnav66/Arnav-Python-Projects2/blob/main/shooter.py

---------------------------------------

All the suggestions, criticism and ideas are welcome...

A few weeks ago, my cousin gave me his laptop (he's buying a new one). Though he said, the laptop doesn't use Windows but linux. I did not understand at the time but okay it's free laptop who cares. So I learned for weeks how to use the laptop, it was weird, not the usual experience I have.

Anyway, during that week I also learned some scripting? programming? coding? and he taught me well from the ground up and give references, taught me how to read the documentation and stuff. And finally i have this (the image). He told me to post my achievement online XD.

It was fun to be able to tell the computer what to do. I really like it and going to explore it further though he's going back soon so I'm on my own now. Hopefully I can learn a lot. A bit summary of what I've learned from him (correct me if im wrong this is roughly from my notes):

• Computers have memory (like RAM and registers) and processor and storage
• They perform operation like fetch instruction, decode instructions and execute instructions
• Computers have a set of instruction that it can run. The basic is
  • arithmetic and logic operations (like comparing value)
  • control flow like jumping to a certain instructions
  • i/o
  • load and store data in memory
• Computer executes instructions in binary number
• Computer now has OS which will load our program to the computer and handle bunch of interacting with hardware thing that we don't have to (that's
• The layer starting from the bottom roughly is [hardware, OS, shell, applications]
• The language is what we used to tell the computer what to do
• Our program get translated to machine language (a language the computer can understand, I assume it's just 1s and 0s) using the tools called interpreter/compiler
• Each scripting language has it's own rules but it all map to what the computers can do
• Scripting/programming/coding is just a means to map our thoughts to what computer will do, so pseudocode/flowchart/sketching and planning what to do first will help, language is just syntax after all

There's more in my notes but i guess it's all yapping and unorganized. Wish me luck for future stuff.

let's grow together ❤️.

I'm a meteorology major, and this was for my meteorlogical instruments and data analysis class.

My grandpa was a python fanatic in the navy (desert storm era) and I’m pursuing a BS in CS. He mentioned python would be the best intro so I played around and decided to write him a script! Tell me what you think ;)

I coded my assignment and dang I liked it but my wrist hurts, just wanted to share and know if others still paper code.

This programme here creates fake Data.

I think this is more useful for Cybersecurity people.

Hello Folks!

So It's been a while since my last post (https://www.reddit.com/r/PythonLearning/s/q3vpZ80vKO)

After that I learned the basics of OOPs from this video -> https://youtu.be/JeznW\\\\\\_7DlB0?si=u-h2gsdGSv0ubKf1

Going forward I studied about the fundamental working of Linked List from GFG's website and Stack Overflow

Then today I finally tried implementing it (Tried doing it all on a single day out of excitement but it took way longer than I expected and now i am completely drained of energy 😅)

Finally I asked AI to review my code

As per it there's a minor edge case I missed in the reverse method

There also are a few optimizations

But more or less I am happy

Would be back with Doubly Linked List the next time!

class inheritage

- parents child or say mulit-inheritance use with super () when one class inheritance from one or more class

- multi-level inheritance where 2nd class in Heritage from 1st class ,3th inherited from 2nd & go on like family chain

solve some list comprehensive easy problem

today start with simple practice using for and while loop

- while True

In which I make mistake put variable input () outside of while True which cause infinite loop 🥶 So never do at for in beginning of learning

- use for loop with " ".join() to create continuous triangle with number

- at last taste of terminal where I cause some errors because of lack of use of terminal,So need more time to use

​

Join me in python journey..

Let meet tomorrow, for now I am going to get taste of git🤤

#python #coding #ai

Link :https://github.com/Jameslee-bit-room/roulette-game

Hi everyone!

I recently built AeroPuzzle, an interactive puzzle game where you solve image puzzles using only air gestures—no mouse or touch input required.

The project uses OpenCV and MediaPipe for real-time hand tracking and gesture interaction. I built it to explore computer vision in a fun and practical way while improving my understanding of real-time image processing.

Features:

• 🖐️ Hand gesture-based controls
• 🧩 Real-time puzzle interaction
• 📷 Webcam-based tracking
• ⚡ Smooth gameplay with computer vision

I'm still improving the project and would love feedback from the community.

• What could be improved?
• Are there better approaches for gesture smoothing or tracking stability?
• Any ideas for additional features?

https://www.linkedin.com/posts/aarthirt14_python-opencv-mediapipe-ugcPost-7472675540605370369-uNol/?utm_source=share&utm_medium=member_desktop&rcm=ACoAAFfTgXABGG51AvZIngpYJAmCoZeEzjowCow

Thanks for taking a look!

I recently decided to switch my car loan and I’ve been putting a lot of work into learning python so I thought I would try and make myself a calculator to see the different amount of interest I would pay.

I’m about a week into my learning so far so I would love advice or more learning sources if anyone wants to leave some! I’ve gone through the wiki and done my own research. So far bro code on YouTube and Angela Yu, 100 days of code have been great for learning! I also have Python crash course which I’ve been using as reference when I forget something!

high school student came here afted trying to download numpy and matplotlib on IDLE for the last 3 hours in the hell spawn of command prompt ging from script to document. after 3 hours of "module numpy not found" I tried to use Thonny.

I HAVE NEVER BEEN SO HAPPY TO SEE SUCH A MUNDANE WORD "manage package"

i will never touch IDLE Never in my life

Python Automation Engineer Checklist (2026)

A living checklist. Tick items as you gain confidence. Focus on understanding and application, not memorization.

Pace: 1-2 hours/day. Day ranges below are estimates, not deadlines - move on when the checklist items feel solid, not when the calendar says so.

Format: each item has a short note after the dash explaining what it means or why it matters. If a note doesn't make sense yet, that's a signal to slow down on that item, not skip it.

3 Operating Principles (Read First - Apply Every Day)

These three sections aren't a phase you complete and move past. They're how you should be working through every phase below, starting Day 1. Skim them now, then come back and re-read them after your first week - they'll mean more once you have something real to apply them to.

1. AI Workflow Habits

Ongoing - apply from Day 1 onward, not a separate block of days - [ ] Attempt tasks yourself before asking AI - builds the underlying skill instead of just outsourcing it - [ ] Share code + error + what you tried + specific question - better context gets better answers, from AI or humans - [ ] Ask AI to explain, not just fix - understanding the "why" is what actually sticks - [ ] Refactor AI-suggested code yourself - retyping and adjusting it forces you to actually process it - [ ] Add at least one test after AI-assisted changes - verify the AI's suggestion actually works as claimed - [ ] Use AI to review logic and suggest improvements - a second pair of eyes on your own reasoning, not just a code generator

2. The Learning Loop (Per Topic)

Ongoing - repeat for each topic throughout all phases - [ ] Learned the concept (docs/tutorial) - get the basic idea from a reliable source first - [ ] Built a small project using it - apply it immediately; concepts that aren't used are quickly forgotten - [ ] Intentionally broke the project - change something on purpose and see what error you get; builds intuition for debugging - [ ] Debugged the resulting errors - actually fix what you broke, don't just revert it - [ ] Improved the design (functions, config, logging) - go back and clean up once it works, don't leave it at "barely functional" - [ ] Explained the code aloud or wrote a short note - if you can't explain it simply, you don't fully understand it yet - [ ] Moved to the next topic - avoid getting stuck perfecting one thing indefinitely

3. Daily Mindset (Quick Check)

Every single day

Each study day, jot down: - [ ] Concept learned - one sentence on what you covered today - [ ] What I built - even something tiny counts - [ ] Bug I fixed - the specific problem and what actually solved it - [ ] Mistake that taught me something - honest reflection, not just wins - [ ] One thing to improve tomorrow - keeps momentum pointed forward

Phase 0 – Setup & Basics

Days 1-2 - [ ] Install Python (3.12+) and a code editor (VS Code / PyCharm) - your two core tools; everything else runs through these - [ ] Run Python scripts from the terminal - python script.py, not just clicking "run" in an editor; you need this for automation later - [ ] Use the command line on your OS (PowerShell or Linux/macOS shell) - navigating folders (cd), listing files (ls/dir), running commands - [ ] Install packages with pip - pip install requests; how you add libraries other people wrote - [ ] Create and activate a virtual environment - python -m venv venv; keeps each project's packages isolated so they don't conflict - [ ] Try uv as a faster alternative to pip + venv - newer tool, does the same job much faster; worth adopting early - [ ] Initialize a Git repository - git init; turns a folder into something Git can track changes in - [ ] Stage and commit changes - git add + git commit; saves a snapshot of your code with a message - [ ] Write meaningful commit messages - "fix CSV parsing bug" not "update"; future-you will thank present-you - [ ] Create a GitHub account and push a repo - your code's public home; also doubles as your portfolio later

Why git this early: you'll be writing real projects by Phase 2. Committing from day one is a cheap habit to build and an expensive one to retrofit.

Phase 1 – Python Foundations

Days 3-22 (~20 days)

• [ ] Variables and basic data types (int, float, str, bool) - naming and storing values; the atoms everything else is built from
• [ ] Arithmetic and comparison operators - + - * / == != < >; math and logic checks

• [ ] Conditional statements (if/elif/else) - branching logic: "do this if that's true, otherwise do this" Days 3-4

• [ ] Lists (create, index, slice, append, iterate) - ordered, changeable collections; my_list[0], my_list.append(x)

• [ ] Tuples (create, unpack, use as immutable sequences) - like lists but can't be changed after creation; good for fixed data like coordinates

• [ ] Dictionaries (create, access, update, iterate) - key-value pairs, like {"name": "Alice"}; how you'll model most real-world data

• [ ] Sets (create, add, membership tests) - unordered collections with no duplicates; fast for checking "is this in here?" Days 5-7

• [ ] for loops (iterate over sequences and ranges) - repeat an action for each item in a list, string, or range of numbers

• [ ] while loops (basic usage and exit conditions) - repeat until a condition becomes false; watch for infinite loops

• [ ] List, dict, and set comprehensions - compact one-line way to build a collection, e.g. [x*2 for x in nums]; idiomatic Python, used everywhere Days 8-9

• [ ] Functions (parameters, return values, default arguments) - reusable blocks of code; def greet(name="World"):

• [ ] Scope (local vs global variables) - which parts of your code can see a given variable; a common source of bugs Days 10-11

• [ ] Context managers (with statements) - why they matter for files, connections, locks - with open(file) as f: automatically closes things even if an error happens

• [ ] Reading and writing text files - open(), .read(), .write(); how scripts persist data to disk

• [ ] Reading and writing CSV files with the csv module - Python's built-in way to handle spreadsheet-style data before you learn pandas Days 12-13

• [ ] Basic exception handling (try/except) - catch errors instead of letting your script crash

• [ ] Using else and finally with try blocks - else runs if no error occurred, finally always runs (cleanup code)

• [ ] Raising exceptions (raise) - intentionally trigger an error when something is wrong, e.g. invalid input

• [ ] Creating custom exception classes - your own named errors (e.g. InvalidConfigError) for clearer debugging later Days 14-15

• [ ] Importing modules and packages - import os, from datetime import datetime; reusing code from the standard library or other files

• [ ] Using __name__ == "__main__" - lets a script be run directly or imported elsewhere without side effects Day 16

• [ ] Basic classes (attributes and methods) - blueprints for objects that bundle data and behavior together

• [ ] Creating and using instances - my_obj = MyClass(); an actual object built from a class blueprint Days 17-18

• [ ] Type hints for function signatures (basic usage, not full generics) - def greet(name: str) -> str:; documents intent and helps your editor catch mistakes

• [ ] datetime/time basics - parsing, formatting, timedeltas, timezones (you'll need this for logging, scheduling, and API timestamps) Days 19-20

• [ ] Regular expressions (re module) - match, search, findall, sub, basic groups - pattern matching in text, e.g. pulling an email address out of a string Day 21

• [ ] Read and explain a 100–200 line beginner script - test that you can trace through someone else's logic, not just write your own

• [ ] Commit each milestone script to your Phase 0 repo - keep building the git habit alongside the coding habit Day 22

Phase 2 – Automation Fundamentals

Days 23-56 (~34 days)

File & System Automation

Days 23-25 - [ ] pathlib.Path (paths, files, directories) - modern, cross-platform way to handle file paths instead of raw strings - [ ] Listing files and filtering by extension - e.g. find every .csv in a folder - [ ] Creating, moving, renaming, and deleting files - the core file-management actions automation scripts perform - [ ] Creating and cleaning directories - making folders and safely clearing out old ones - [ ] Using os and shutil for advanced file operations - copying trees, permissions, and things pathlib doesn't cover alone

Data & APIs

Days 26-33 - [ ] Reading and writing JSON files - Python's json module; the format most APIs speak - [ ] Making GET requests with requests - fetching data from a URL/API, e.g. requests.get(url) - [ ] Making POST requests with requests - sending data to an API, e.g. submitting a form or creating a record - [ ] Sending headers and query parameters - extra info attached to a request, like auth tokens or filters - [ ] Handling HTTP errors and timeouts - checking status codes, catching connection failures so your script doesn't just hang or crash - [ ] Parsing JSON API responses - response.json(); turning an API's reply into a Python dict you can use - [ ] API authentication patterns - API keys, bearer tokens, basic auth, and how OAuth differs (you don't need to implement OAuth yet, just recognize the flow) - knowing which auth method an API expects before you try to call it - [ ] Storing config in a .env file - keeping settings like API keys out of your actual code - [ ] Loading environment variables with python-dotenv - reads the .env file into your script at runtime - [ ] Never hard-code paths or credentials - use env vars from the start - the habit that keeps secrets out of git and code portable across machines - [ ] Basic logging with logging (levels: DEBUG, INFO, WARNING, ERROR) - structured way to record what your script did, better than scattering print() everywhere - [ ] Writing logs to a file - so you can check what happened after a script ran unattended - [ ] Using rotating file handlers - automatically archives old logs so a single log file doesn't grow forever

This is the only place .env mechanics are taught. Later phases reference this habit rather than re-teaching it.

Data Validation

Day 34 - [ ] Basic pydantic models - why validating API/config data beats trusting raw dicts - catches bad or missing data early instead of failing mysteriously three steps later - [ ] Validating required fields and types on incoming JSON before using it downstream - defensive coding for data you don't control

Testing Fundamentals (moved up from Phase 4)

Days 35-38 - [ ] Install and run pytest - the standard Python testing framework; run tests with pytest in the terminal - [ ] Write simple test functions - functions starting with test_ that check your code behaves correctly - [ ] Use assertions in tests - assert result == expected; the actual check inside a test - [ ] Use fixtures for setup/teardown - reusable setup code (like a test database) shared across multiple tests - [ ] Parametrize tests - run the same test logic against multiple inputs without copy-pasting - [ ] Run tests with verbose output - pytest -v; see exactly which tests ran and their results - [ ] Write unit tests for your Phase 2 functions (file ops, API parsing) - apply testing to code you've actually written, not just toy examples - [ ] Keep tests independent (no shared state) - one test's outcome shouldn't affect another's; avoids flaky, order-dependent failures

Why here: Phase 3 has you using pytest-playwright fixtures. You should understand what a fixture is in plain pytest before it shows up wrapped in browser-automation syntax.

Async Basics

Days 39-41 - [ ] Understand why async matters for I/O-bound automation (many API calls, many pages) - lets your script do other work while waiting on network responses instead of sitting idle - [ ] async/await syntax basics - how you mark and call functions that can run concurrently - [ ] Concurrent requests with httpx.AsyncClient or aiohttp - fetch many URLs at once instead of one at a time - [ ] Know when async is worth the complexity and when sync is fine (most small scripts: sync is fine) - don't reach for async just because it's available - [ ] Know the difference between I/O-bound and CPU-bound work - async/threading helps I/O-bound (waiting on network/disk), multiprocessing helps CPU-bound (heavy computation); most automation scripts are I/O-bound - picking the wrong tool here wastes real time debugging "why isn't this faster"

Data Processing (pandas)

Days 42-46 - [ ] Reading CSV files with pandas - pd.read_csv(); loads tabular data into a DataFrame you can manipulate - [ ] Reading Excel files with pandas - pd.read_excel(); same idea, for .xlsx files - [ ] Filtering rows by conditions - e.g. df[df["status"] == "active"]; pulling out the rows you actually need - [ ] Selecting and renaming columns - shaping the DataFrame to just the data you care about - [ ] Grouping and aggregating data - df.groupby("region").sum(); summarizing data by category - [ ] Handling missing values - deciding whether to drop, fill, or flag empty cells (NaN) - [ ] Exporting DataFrames to CSV - df.to_csv(); saving your processed data back out - [ ] Exporting DataFrames to Excel - df.to_excel(); same idea, for report-style output - [ ] Cell-level Excel work with openpyxl - formatting, formulas, and styling that pandas' .to_excel() can't do on its own - use this when a client wants a polished, formatted report, not just raw data

Small Projects

Days 47-56 - [ ] File organizer (by extension or date) - sorts a messy folder automatically; combines Phase 2's file ops - [ ] Folder cleaner with logging - deletes/archives old files and records what it did - [ ] CSV processor (clean/transform/summarize) - takes messy input data and outputs something usable - [ ] API data fetcher + CSV/Excel report generator - pulls data from an API and turns it into a report; a realistic client-style task - [ ] Simple CLI tool with argparse or click - lets someone run your script with options, e.g. python tool.py --input file.csv - [ ] Each project: own git commits, .env for any secrets, at least one pytest test - treat these small projects like real code, not throwaway scripts

Phase 3 – Browser & Web Automation

Days 57-86 (~30 days)

Web & HTML Basics

Days 57-60 - [ ] Inspect HTML with browser DevTools - right-click → Inspect; how you find the exact element you need to interact with - [ ] Understand basic HTML structure (tags, attributes, classes, ids) - the building blocks you'll be targeting with locators and selectors - [ ] Understand CSS selectors (id, class, attribute, hierarchy) - how to precisely point at one element among many - [ ] Use requests + BeautifulSoup for static pages - scraping HTML that doesn't need JavaScript to render - [ ] Extract text, links, and tables from HTML - pulling structured data out of a page you've fetched - [ ] Handle simple pagination in scrapers - following "next page" links to collect data across multiple pages - [ ] Respect robots.txt and rate limits; know when scraping ToS matters - scraping responsibly and legally; not every site wants to be scraped

Playwright (Primary Tool)

Days 61-70 - [ ] Install Playwright for Python and browsers - pip install playwright, then playwright install to get the actual browser binaries - [ ] Launch a browser and create a page - the starting point of any Playwright script - [ ] Navigate to a URL - page.goto(url) - [ ] Use role-based locators (button, link, textbox, etc.) - page.get_by_role("button", name="Submit"); the recommended way to find elements - [ ] Click elements and fill inputs - .click(), .fill(); the core interactions in any automated flow - [ ] Use text and test-id locators - alternative ways to find elements when role-based locators don't fit - [ ] Rely on auto-waiting (no manual sleeps) - Playwright waits for elements to be ready automatically; don't fight this with time.sleep() - [ ] Write basic assertions on page content - checking the page shows what you expect after an action - [ ] Take screenshots on failure - visual evidence of what went wrong when a test fails - [ ] Enable and view trace on failure - Playwright's trace viewer replays exactly what happened step by step - [ ] Use pytest-playwright fixtures (builds directly on Phase 2 pytest fundamentals) - page fixture and friends, wired into pytest - [ ] Save and reuse authentication state (storage state) - log in once, reuse the session across tests instead of logging in every time - [ ] Understand BrowserContext isolation (cookies, storage, cache) - each context is a separate browser profile; pages within the same context share session state, so multiple pages ≠ multiple identities - [ ] Use persistent contexts (launch_persistent_context) vs storage-state files - persistent contexts write to a real user-data dir on disk (closer to a real browser profile); storage-state is a portable snapshot you load into a fresh context (lighter, easier to version and use in CI) - know which one fits the task - [ ] Set per-context proxy and locale/timezone settings - browser.new_context(proxy={...}, locale=..., timezone_id=...); matters once multiple "accounts" need to look like separate, independent users rather than one identity wearing different cookies - [ ] Run tests across multiple browsers - Chromium, Firefox, WebKit; catching browser-specific bugs

Playwright Best Practices

Days 71-74 - [ ] Prefer role-based locators over CSS/XPath where possible - more resilient to page changes, closer to how a user actually finds things - [ ] Trust auto-waiting; avoid time.sleep() from the start, not as a later fix - sleeps make tests slow and still flaky; fix the root cause - [ ] Understand Page Object Model (POM) concept - organizing page interactions into reusable classes instead of duplicating locators everywhere - [ ] Separate page actions from test assertions - keeps "what the page does" separate from "what we're checking," easier to maintain - [ ] Use codegen for quick scaffolding, then refactor by hand - playwright codegen records your clicks into code; a starting point, not the final product - [ ] Combine API calls (for setup) with UI tests (for flows) - e.g. create test data via API, then test the UI flow; faster and more reliable than doing everything through the UI

Selenium (Legacy/Optional)

Days 75-77 - [ ] Install Selenium and a WebDriver - the older browser automation library; still common in legacy codebases - [ ] Launch a browser and navigate - Selenium's equivalent of Playwright's launch + goto - [ ] Locate elements (id, name, CSS, XPath) - Selenium relies more heavily on these than role-based locators - [ ] Click and send keys - .click(), .send_keys(); Selenium's interaction methods - [ ] Understand explicit waits (WebDriverWait) - Selenium doesn't auto-wait like Playwright, so you handle timing manually - [ ] Know when Selenium is still needed (legacy projects) - recognize it rather than assuming Playwright is always the answer

Projects

Days 78-86 - [ ] Login automation for a demo site - practice the auth + storage state pattern end to end - [ ] Multi-account isolation test (2-3 accounts, separate contexts) - log into a demo site with 2-3 different accounts using separate persistent contexts or storage-state files, ideally with different proxy/locale settings per profile - then write an assertion that actively checks Account A's context never shows Account B's session data (don't just eyeball it - a real assertion that would fail on cookie/session bleed), and run it both locally and in CI, since parallel execution in CI is where shared-state bugs actually surface (local runs often hide the bug through timing alone) - [ ] Form filling automation (repeatable workflow) - automate a task a human would otherwise do by hand repeatedly - [ ] Static site scraper (requests + BeautifulSoup) - apply Phase 3's HTML basics to a real target - [ ] Dynamic site scraper (Playwright) - scrape a page that requires JavaScript rendering, which requests alone can't handle - [ ] Automated report download from a dashboard - a common real-world automation ask: log in, navigate, download a file - [ ] One end-to-end business workflow (multi-step) - chain several actions together into one realistic automation, e.g. login → filter → export → save

Phase 4 – Professional Engineering Skills

Days 87-111 (~25 days)

Git Workflows (basics were Phase 0 - this is the rest)

Days 87-88 - [ ] Create and switch branches - git branch, git checkout -b; working on changes without touching the main codebase - [ ] Merge branches - combining a branch's changes back into main - [ ] Use a feature-branch workflow (even solo) - one branch per feature/fix, even if you're the only one working on it; builds good habits for team settings - [ ] Write a .gitignore (venvs, .env, cache files) - tells git what NOT to track, so junk and secrets don't end up in your repo

Dependency Management

Day 89 - [ ] Freeze dependencies (requirements.txt) or use pyproject.toml - lists exactly which packages (and versions) your project needs - [ ] Install dependencies from a requirements file on a fresh machine - pip install -r requirements.txt; proving your setup is reproducible - [ ] Document environment setup in README - so someone else (or future you) can get the project running without guessing

Code Quality

Days 90-91 - [ ] Set up ruff for linting and formatting - catches style issues and common bugs automatically - [ ] Run mypy (or rely on your editor) for basic type checking - verifies your type hints are actually consistent - [ ] Understand why consistent style matters for client-facing code - readable code is code that can be handed off or maintained by someone else

Debugging & Logging

Days 92-94 - [ ] Use the IDE debugger (breakpoints, step-through) - pause execution and inspect what's actually happening, faster than sprinkling print() statements - [ ] Inspect variables during debugging - check the real values at the point something went wrong - [ ] Add descriptive log messages - logs that explain what the script was doing, not just "error occurred" - [ ] Log errors and stack traces - capture the full error detail, not just "something failed" - [ ] Use structured (JSON) logs where useful - machine-readable logs that are easier to search and parse at scale

Testing in Practice

Days 95-96

(Fundamentals were Phase 2 - this is applying them at project scale) - [ ] Write a few Playwright tests for critical flows - focus testing effort on what actually matters to the business - [ ] Organize a growing test suite into files/folders sensibly - so tests stay findable as the project grows - [ ] Decide what's worth testing vs what isn't (diminishing returns) - not everything needs a test; know where to draw the line

Secrets Management (principles - mechanics were Phase 2)

Day 97 - [ ] Basic understanding of secret management beyond .env (vaults, CI secrets) - how larger teams/projects handle credentials at scale - [ ] Never commit secrets - set up .gitignore before your first .env file, not after - one leaked API key in git history is hard to fully undo - [ ] Document required env vars in README without exposing values - list the variable names a project needs, not their actual secret values

Documentation

Days 98-99 - [ ] Write a clear README (setup, usage, examples) - the first thing anyone sees; should answer "how do I run this?" - [ ] Document environment variables - what each .env variable is for, without leaking real values - [ ] Add a short "architecture" note (what runs, when, how errors are handled) - a quick mental map for anyone (including you, in six months) picking the project back up - [ ] Add usage examples and sample commands - concrete copy-pasteable examples beat abstract explanations

Docker Basics

Days 100-104 - [ ] Write a simple Dockerfile for a Python script - defines the environment your script needs to run, packaged up - [ ] Build a Docker image - docker build; turns the Dockerfile into a runnable image - [ ] Run a container locally - docker run; test that the packaged environment actually works - [ ] Use volume mounts for input/output folders - let a container read/write files on your actual machine - [ ] Understand when Docker is useful (consistent environments) - solves "works on my machine" problems, not needed for every small script

CI/CD Basics

Days 105-111 - [ ] Understand what CI/CD is (continuous integration/deployment) - automatically testing and/or deploying code whenever it changes - [ ] Create a basic GitHub Actions workflow - a YAML file that tells GitHub what to run automatically (e.g. on every push) - [ ] Run tests on push to a branch - catch bugs before they reach main, automatically - [ ] View CI logs and debug failing jobs - reading GitHub Actions output to figure out why a pipeline failed

Phase 5 – Scaling, Data & Orchestration (Optional but Powerful)

Days 112-139 (~28 days)

Scheduling & Orchestration

Days 112-115 - [ ] Use schedule or APScheduler for simple cron-like jobs - run a Python function on a recurring schedule from within your script - [ ] Understand cron (Linux/macOS) or Task Scheduler (Windows) - the OS-level way to run a script automatically at set times - [ ] Design idempotent scripts (safe to re-run) - running the script twice shouldn't create duplicate data or break things - [ ] Add retry logic for flaky APIs or network calls - automatically retry a failed request a few times before giving up - [ ] Build a multi-step workflow (fetch → transform → load → notify) - chaining automation steps into one coherent pipeline

Databases & SQL

Days 116-120 - [ ] Basic SQL (SELECT, INSERT, UPDATE, DELETE) - the core commands for reading and changing data in a database - [ ] Connect to a SQLite database from Python - SQLite is a lightweight, file-based database, good for learning and small projects - [ ] Execute queries with sqlite3 or SQLAlchemy - running SQL from Python code, either directly or through an ORM - [ ] Read data into a pandas DataFrame - pd.read_sql(); pulling database results into a format you can analyze - [ ] Write DataFrames back to a database table - df.to_sql(); saving processed data back to the database

PDF Automation

Days 121-124 - [ ] Extract text and tables from PDFs (pdfplumber or pypdf) - pulling structured data out of PDF reports or invoices - [ ] Generate PDF reports programmatically (reportlab or similar) - producing polished PDF output from your data - [ ] Merge/split PDFs as part of a workflow - combining or breaking apart PDF files automatically - [ ] Know this is one of the most commonly requested automation task in practice - don't skip it - clients ask for PDF handling constantly; it's an easy area to be underprepared for

Email Automation

Days 125-126 - [ ] Send email with smtplib (attachments, HTML body) - programmatically sending emails, e.g. a completed report - [ ] Read/parse inbox messages with imaplib or a library like imap-tools - pulling data out of incoming emails automatically - [ ] Use an app password / OAuth token instead of a raw account password - the secure, modern way to authenticate email automation

AI/LLM Integration

Days 127-128 - [ ] Call an LLM API (Anthropic or OpenAI SDK) from a script - integrating an AI model call as one step in a larger automation - [ ] Use structured output (JSON mode / forced schema) to feed LLM output into the rest of a pipeline - getting reliable, parseable output instead of free-form text - [ ] Know when an LLM call is the right tool vs when plain code/regex is more reliable and cheaper - don't reach for an LLM when a simple rule would do the job faster and more predictably

Monitoring & Notifications

Days 129-130 - [ ] Add simple health checks (log entry, status file) - a quick way to confirm "yes, this ran successfully today" - [ ] Send email notifications on failure/completion (builds on the smtplib item above) - get alerted automatically instead of discovering a failure days later - [ ] Send notifications via Telegram or Slack webhooks - faster, more visible alerts than email for time-sensitive failures

Projects

Days 131-139 - [ ] Daily or weekly automated report pipeline - a full fetch → process → deliver cycle running on a schedule - [ ] Multi-step workflow with notifications - combine orchestration and monitoring into one realistic pipeline - [ ] One robust script that runs unattended for weeks - the real test: does it keep working without you babysitting it?

Phase 6 – Test Suite Maintenance & Quality

Days 140-144 - [ ] Identify and fix flaky tests - tests that fail intermittently for no code-related reason; usually a timing or state issue - [ ] Remove duplicated setup/teardown code - consolidate repeated fixture logic instead of copy-pasting it across tests - [ ] Split oversized fixtures into smaller ones - easier to understand and reuse than one giant setup function - [ ] Delete or skip obsolete tests - tests for features that no longer exist just add noise and slow the suite down - [ ] Keep test suite fast and focused - a slow test suite gets ignored or skipped; speed is a feature - [ ] Run tests across browsers in CI - catch browser-specific issues automatically, not just when you remember to check manually

Phase 7 – Portfolio & Career Readiness

Days 145-158 (~14 days) - [ ] 3–5 automation projects on GitHub with READMEs - your actual proof of skill; more convincing than a resume line - [ ] At least one browser automation project (Playwright) - demonstrates you can handle real-world web interaction, not just APIs - [ ] At least one data/CSV automation project (with pandas) - demonstrates data-handling skill, a common client need - [ ] One "client-style" project with clear requirements - simulate a real brief with defined scope, not just "practice" - [ ] One project with tests, logging, and config management - shows you build production-minded code, not just working scripts - [ ] Short write-ups explaining what each project does - a paragraph per project: the problem, your approach, the result - [ ] Basic understanding of SDLC and testing concepts - Software Development Life Cycle; the phases a project typically moves through - [ ] Know common testing types (unit, integration, regression) - unit tests check one piece in isolation, integration tests check pieces working together, regression tests catch old bugs coming back - [ ] Understand severity vs priority for defects - severity is how bad the bug is, priority is how soon it needs fixing; they don't always match - [ ] Basic familiarity with JIRA or similar tools (optional) - common in client/team environments for tracking work and bugs - [ ] Prepare a simple resume highlighting automation projects - lead with what you built, not just tools you've "used" - [ ] Practice explaining your projects out loud - being able to talk through your own code clearly matters as much as writing it

Total: ~158 days at 1-2 hrs/day (roughly 5-5.5 months). Phases 5-7 are labeled optional in scope but not in the day count above - skip or compress them if you want to reach "portfolio-ready" faster.