• Write Pseudocode
  • Pseudocode means writing out the logic of your program in plain language instead of code.
  • Example (finding the maximum number in a list):
    1. If the list is empty → return an error.
    2. Otherwise, set the first number as largest.
    3. Loop through the other numbers.
    4. If a number is larger than largest → update largest.
    5. Return largest.
  • Test pseudocode with sample inputs. Once it makes sense, turn it into real code.
  • Use pseudocode from the start for new tasks, or switch to it when stuck.
• Rubber Ducking
  • Rubberducking is explaining your problem out loud to someone - or even to an object (like a rubber duck).
  • The process of explaining forces you to think clearly, and you may find the answer yourself.
  • Writing down the explanation can also be helpful, although speaking is often more effective.
• Check Your Syntax
  • If your program won’t run at all, the problem is often a syntax error (typo or incorrect structure).
  • Sometimes the error message will be helpful, but not always.
  • Strategy:
    • Comment out sections of your code until it runs.
    • Add the code back one piece at a time to find the exact issue.
  • Fixes might be small (like a missing character) or require checking the documentation.
• Compare With Working Code
  • If you have a working version (such as an older copy or an example from the documentation), compare it to your broken code.
  • Use a diff tool such as Meld or Prettydiff to highlight differences.
  • Even small differences (like uppercase vs lowercase letters) can break code.
• Debugging
  • When code runs but doesn’t behave as expected, it has a bug.
  • Debugging is the process of testing guesses (hypotheses) about what went wrong.
  • Steps:
    • Form a hypothesis (“Maybe this only fails with negative numbers”).
    • Test different inputs to check if it’s true.
    • If true → refine the hypothesis. If false → form a new one.
    • Use the process of elimination: narrow down possibilities until the real issue is found.
  • Tracing (Stepping): run the code line by line while watching variable values.
  • Most bugs originate from a single incorrect value that propagates throughout the program.
  • Many programming tools provide built-in debuggers to help with tracing.

• Validate Your Syntax
  • Browsers don’t show errors when HTML or CSS is invalid - they just skip the broken parts.
  • Use the official validators:
    • HTML Validator
    • CSS Validator
  • Watch out for common mistakes:
    • Don’t use the same id for multiple elements.
    • Use class when you need to style multiple elements.
  • You can usually ignore warnings about invalid attributes if you know they are safe.
• Check Your Indentation
  • Even valid HTML/CSS can break if indentation is inconsistent.
  • Bad indentation makes it harder to see the real structure of your code.
  • Always use consistent indentation (2 spaces, 4 spaces, or tabs).
  • Most editors automatically indent when you press TAB.
  • Many editors also have tools to re-indent files automatically (e.g., in Sublime: Ctrl+Shift+P - type “reindent”).
• Use Developer Tools
  • Right-click in your browser - Inspect - open the Elements tab.
  • Verify that elements are present in the DOM as expected and inspect the applied styles.
  • In the Elements tab, you can:
    • Add or change CSS rules.
    • Disable rules temporarily.
  • This helps you test fixes quickly and find exactly what’s wrong.

• Check the Console
  • Open Developer Tools - Console tab in your browser.
  • It shows:
    • JavaScript errors.
    • Missing resources (like a file not loaded).
  • If you’re using external libraries (e.g., jQuery), switch to the unminified version for clearer error messages.
• Check Your Syntax
  • Use a validation tool like JSHint to catch mistakes.
  • Always end statements with a semicolon.
  • Beware of Automatic Semicolon Insertion (ASI):
    • JavaScript sometimes adds semicolons automatically.
    • This can change how your code runs.
    • Example: return on one line and the value on the next may break because JS inserts a semicolon right after return.
• Check Your Indentation
  • Inconsistent indentation can create logic errors.
  • A line might look like it’s part of a loop (because of spacing), but actually isn’t.
  • Always use consistent indentation (4 spaces or a tab per level).
• Debug Your Code
  • Use console.log() to print variable values and see what’s happening.
  • For more complex debugging:
    • Open the Sources tab in DevTools.
    • Step through your code line by line.
    • Watch how values change as the program runs.

• Carefully Read Exception Messages
  • When Python shows an error, read the full message.
  • It typically indicates the file, line number, and type of error.
  • Example:
    • IndexError: list index out of range - you tried to access an element in a list that doesn’t exist.
• Check Your Syntax
  • Use Python’s pep8 tool (either through the command line or via the online version) to find potential syntax problems.
  • Python enforces indentation, so you can’t run badly indented code.
  • The standard is 4 spaces for each level. Most editors will do this automatically when you press TAB.
• Debug Your Code
  • For small problems: use print() to show the values of variables.
  • For bigger problems:
    • Use pdb (Python Debugger).
    • Or use your IDE’s debugger to step through the code line by line and watch variables.

AI can be a helpful tool when you’re stuck, but it works best if you ask clearly. Think of it like asking a tutor or mentor - the quality of the answer depends on how well you explain the problem.

Tips for Writing Good Prompts

• Be Specific
  • ❌ “My code doesn’t work.”
  • ✅ “I’m looping through a list in Python and get IndexError when I reach the end. Here’s my code…”
• Include Context
  • Say which language, framework, or tool you’re using.
  • Explain what you expected vs. what actually happened.
• Share the Error Message
  • Copy the full message. Example:
  • TypeError: unsupported operand type(s) for +: 'int' and 'str'.
• Show Minimal Code
  • Share the smallest snippet that still shows the problem.
• Ask for Explanations, Not Just Fixes
  • ❌ “Fix this for me.”
  • ✅ “Why is this error happening, and how can I fix it?”

When to Use AI

• To understand error messages.
• To brainstorm debugging approaches.
• To see alternative code examples.
• To learn why a fix works, so you avoid the same mistake in future.

Use AI as a learning partner, not just a shortcut. It should help you understand problems, not just copy and paste solutions.

What Is the Command Line?

• Many tools run in a shell (the program that interprets commands).
• The most common shell is Bash.
• The terminal is the window where you type commands.
• Different emulators (e.g., ConEMU on Windows, Terminator on Linux) exist, but commands work the same.

Check Spelling

• The first word you type is always the command. Everything after it are parameters (extra instructions for the command).
• If you see command not found, it usually means there’s a typo.
• Commands are case-sensitive: ls (list files) is not the same as LS.
• Watch out for similar-looking characters:
  • Capital I (like in Internet): I
  • Lowercase l (like the letter L): l
• To avoid typos, press the Tab key to auto-complete commands and filenames whenever possible.

Check Your Directory

• Use pwd to show your current directory.
• Use ls to list the files there.

Use Built-in Help

• Most commands: add --help.
• On Linux/Mac: use man (e.g., man ls).
• Some commands use subcommands, e.g., Git:
  • git add, git commit
  • git help add or man git-add for details.

If Stuck in an Editor

• Less:
  • Scroll with arrows or PgUp/PgDn.
  • / to search, n for next match, q to quit.
• Vim:
  • Starts in normal mode.
  • i = insert mode (edit text).
  • Esc = back to normal.
  • Shift+ZZ = save and quit or :q! = quit without saving.

If Stuck in a Long Operation

• Ctrl+C = stop.
• Ctrl+Z = pause - then fg (resume foreground) or bg (resume background).
• To force stop: kill -9 %1.
• Or just close the terminal.

If a Port Is Already in Use (Django/Flask)

• Mac/Linux:
  • lsof -i tcp:8000 - find PID.
  • kill -9 PID - stop process.
• Windows:
  • Launch an administrator cmd shell by right-clicking the Command Prompt icon in the Start menu and choosing Run as administrator.
  • Run netstat -o -b -n to list processes.
  • Use taskkill /f /pid 1736 (replace with correct PID).

Write Down Your Problem First

• Describe clearly what the issue is.
• Note everything you’ve already tried.
• Include your code (as a snippet or link, e.g., GitHub).

Where to Ask

• Stack Overflow
  • Search first - your question may already be answered.
  • If not, create an account and post.
  • Be clear, detailed, and follow the guidelines.
  • Well-written questions often get fast answers. Poorly written ones may be downvoted.
• Discord (Code Institute Channels)
  • Search first - someone else may have already asked the same question.
  • Best for module-related questions.
  • Often answered quickly.
  • It can also lead to useful discussions for other students.

No One Can Learn For You

• Real learning means facing what you don’t understand.
• You must reflect: “I expected X, but I observed Y. Why?”
• This self-check is essential. If you skip it, you may collect answers but not actually learn.

Learning Is a Social Experience

• We often learn because we want to join a community and share knowledge.
• Coding is a skill-based field - you prove yourself by showing what you know.
• But coding can also feel lonely. Communities (like Discord) help by:
  • Giving reassurance - everyone struggles.
  • Offering motivation - seeing peers succeed.
  • Building confidence - belonging to a group.
• Sometimes asking for help is less about fixing one bug and more about connecting with others.

Balance Both Perspectives

• Strive to solve as much as you can on your own.
• Additionally, utilise the community for support, motivation, and collaboration.
• Help others, too - everyone benefits when the community grows stronger.