Did you know that git commands split into porcelain(used usally by the dev) and plumbing(used by git itself under the hood) commands. E.g git add, git commit, git log those are all PORCELAIN commands. E.g of a PLUMBING command is git cat-file -p <hash>, this command shows: 1. tree(git's way of storing a directory or blob(git's way of showing a file) 2. parent 3. author 4. committer Git doesn't store diffs, it stores full snapshots of every file on each commit. It's smart enough to deduplicate unchanged files, so identical content across commits only gets stored once. Verified it myself with git cat-file, same file, same hash, across commits.

3 years ago I had 47 open tabs, notes in 5 apps, and zero projects finished. Today I ship production code. The shift? → One place for all notes (Notion) → One roadmap, not 12 courses → Build > Consume (even ugly projects count) The devs who make it aren't the smartest. They're the most consistent.

I'm curious about the DevOps path and wanted to ask the community: 1. How long does it realistically take to become a DevOps engineer? I know it depends on background, but what's a realistic timeline from beginner to job-ready? 2. What should I actually learn? There's so much out there it's overwhelming. What's the core stack/skills that matter most? Things like: - Linux & networking fundamentals - CI/CD (Jenkins, GitHub Actions, GitLab CI…) - Containers (Docker, Kubernetes) - Cloud (AWS, Azure, GCP) - IaC (Terraform, Ansible) - Monitoring (Prometheus, Grafana) - Scripting (Bash, Python) What would you prioritize? What did you learn first, and what do you wish you'd learned earlier? Any advice, roadmaps, or personal experiences would be really appreciated ..thnak you all

What was the most broken part of your post-mortem process? Not the incident itself, the aftermath.For me, the worst part is always the "How did we miss this in staging?" question. It's never a simple answer, and trying to explain environmental drift or non-deterministic race conditions to a VP who just wants a "yes/no" feels like a losing battle. I end up writing a doc that's half technical narrative, half political damage control, and neither half is actually useful the next time something breaks. Curious whether this is universal or just a me problem. Maybe your team has actually figured this out. I genuinely want to know if anyone has a process that doesn't feel like reconstruction work after the fact.

Where are you from? I'm from Guinea Tell us something about you? I have a bachelor's degree in Software Engineering and I currently live in the USA. What do you hope to achieve here? to acquire many skills, network, share and build great things together. Which platform brought you here? It was my friend Nicodeme who told me about your platform. It's a pleasure to meet you here.