iiinova — where your digital self keeps evolving

Corentin GS @corentings.dev · 14/07/2025

Go error handling is often criticized for being “too verbose.” Swipe the carousel to see why that criticism misses the point. #Golang #Go

🛡️ 7 Go Error Handling Patterns Real-world examples to bulletproof your backend

110

Corentin GS @corentings.dev · 01/07/2025

These languages won’t get you a dev job tomorrow. But they’ll teach you how to think, adapt, and face any coding challenge. Hardcore? Sure. But you don’t become a Jedi without sacrifice. #Programming #CodeNewbie #LearnToCode #SoftwareEngineering

🔑 3 Key Programming Languages for Beginners Who want to become Elite Software Engineers💡 And it’s easier than you think.

130

Corentin GS @corentings.dev · 04/06/2025

How Go's context package transforms chaotic goroutine sprawl into orchestrated control flow. From resource leaks to graceful cascading cancellations—context is the unsung hero of distributed Go systems. #golang #programming

Screenshot essay titled 'Context: Go's Elegant Weapon Against Concurrency Chaos', discussing the importance of the Go programming language's context package in managing concurrency. The essay describes how context helps coordinate goroutines by propagating cancellation signals, using an example of a microservice handling HTTP requests. It details a code snippet demonstrating the use of context with timeout and how goroutines cleanly handle cancellation. The text emphasizes context's composability and its role in preventing resource leaks in distributed systems. The overall message encourages the adoption of context in Go applications to create efficient and responsive systems.

110

Corentin GS @corentings.dev · 03/06/2025

DDD isn’t an architecture. It’s a mindset. • Business logic becomes clear • Code reads like user stories • Bugs get squashed fast • Features map to reality It’s the difference between organizing code vs. understanding the business. #cleancode

010

Corentin GS @corentings.dev · 03/06/2025

If you’re still scattering business logic across 15 files… Read this. DDD means: • Business in one place • Fewer bugs • Clearer features • Faster onboarding It changed how I code and think. #ddd

010

Corentin GS @corentings.dev · 03/06/2025

MVC shows you where to put code. DDD shows you what it should say. • One place for business logic • Domain-first thinking • Less glue code, more clarity I’d trade 5 years of patterns for 1 year of DDD. #domainmodeling

010

Corentin GS @corentings.dev · 02/06/2025

Context leaks in Go are silent killers. They don’t crash your app — they slowly drain it. Unreleased goroutines = invisible technical debt. Fix it before it breaks you. #golang #backend

A screenshot essay titled 'Context Leaks: The Invisible Technical Debt Draining Your Go Systems.' The body discusses the dangers of context leaks in Go programming, which silently consume memory and degrade system performance without raising immediate alarms. It highlights the accumulated negative effects of unreleased goroutines and dangling contexts, comparing them to toxic waste. The importance of discipline in managing contexts and goroutines is emphasized, along with practical solutions like building structured cancellation trees and using profiling tools. The conclusion stresses that context leaks contribute to system fragility, ultimately costing trust in production environments.

120

Corentin GS @corentings.dev · 02/06/2025

The truth? Rust is brilliant. But Go is a cheat code. • Idiomatic Go in 2 weeks • Real-world output day one • No fighting with the compiler Want velocity? Go wins. Rust’s complexity isn’t worth it for most teams. #programming

010

Corentin GS @corentings.dev · 02/06/2025

Most devs learn MVC first. Big mistake. You learn structure before meaning. DDD flips it: • You code business, not boxes • Features shrink from days to hours • Logic finally has a home Learn the language before the grammar. #softwaredesign

010

Corentin GS @corentings.dev · 02/06/2025

You’re not building an OS. You’re building CRUD APIs. Stop over-engineering: • Go gets new hires productive in days • Rust drops team velocity by 50% • Most apps don’t need a borrow checker Choose speed over struggle. #devlife

000

Corentin GS @corentings.dev · 01/06/2025

The most brilliant engineers I know don’t always pick the “best” tech. They choose what yields the best results quickly. • Go reads like English • Devs ship in weeks • Hiring is easy • Teams move fast Rust? It slows you down for marginal gains. #softwareengineering

000

Corentin GS @corentings.dev · 01/06/2025

Choosing Rust for CRUD services is like buying a jet to drive to work. Sure, it’s fast. But you’ll burn time, money, and team morale just trying to park it. Go is simpler, faster, and way more practical. You can use the right tool for the real-world job. #backend

120

Corentin GS @corentings.dev · 27/05/2025

Stop trying to write "perfect" code as a beginner. My early Go app: 6 layers, 3 frameworks, total mess My rewrite: Just stdlib, 10x faster Your "failures" teach more than tutorials. #coding #webdev #buildinpublic

Screenshot essay titled '3 Tiny (But Powerful) Mental Shifts To Master Backend Development' detailing the author's journey from being a college dropout in 'tutorial hell' in 2021 to successfully building a complex Go chess library and leading backend projects. The essay outlines three mental shifts: 1) Stop aiming for 'perfect' code from the start, emphasizing the learning gained from failed projects. 2) Embrace beginner's curiosity to try new frameworks, tackle challenging projects, and ask questions that foster understanding. 3) View failures as valuable data rather than defeats, learning from complexities to achieve simplicity in code. The text encourages recognizing the 'messy phase' as a vital part of the learning process.

140

Corentin GS @corentings.dev · 27/05/2025

Want to build stunning CLI tools in Go? Use Bubbletea. • Beautiful text UIs • Elegant architecture • Fun to use Make your terminal apps feel like magic. #cli #golang #opensource

030

Corentin GS @corentings.dev · 26/05/2025

Tired of "works on my machine"? Use Dev Containers. • Instant dev environment setup • Reproducible across the team • All dependencies pre-installed No more setup hell. Just code. #devcontainers #docker #devops

010

Corentin GS @corentings.dev · 26/05/2025

The best messaging system I’ve used in 2025: NATS. • Lightning-fast pub/sub • Lightweight & reliable • Supports clustering + persistence Easier than Kafka. More robust than Redis. Built for scale. #eventdriven #golang #scalability

040

Corentin GS @corentings.dev · 26/05/2025

Go-task made me ditch Makefiles for good. • YAML-based task runner • Dependency-aware • Cross-platform • Built-in variable support Cleaner builds, easier automation. Perfect for Go projects. #golang #buildtools

140

Corentin GS @corentings.dev · 25/05/2025

Debugging microservices used to be painful—until Jaeger. • Full request tracing • Visual bottleneck mapping • Instant visibility into distributed systems If you're scaling services, this is non-negotiable. #microservices #observability #devops

010

Corentin GS @corentings.dev · 25/05/2025

The single best Go code quality tool: golangci-lint. • Runs 40+ linters • Catches bugs pre-commit • Flags performance issues • Integrates seamlessly into CI/CD Set it up once. Let it guard every PR. #golang #devtools

030

Corentin GS @corentings.dev · 25/05/2025

The six #backend tools that transformed how I build production systems in 2025. After 4 years of coding 7/7, these are the non-negotiable tools in my stack. Thread 👇

120

Corentin GS @corentings.dev · 21/05/2025

Most Go devs know the syntax. Few master the model. This carousel breaks down what really matters. Save it. Share it. Level up your Go game.

Most Go developers don’t struggle with syntax. They struggle with concurrency. (And after 4 years in production, I’ve seen exactly why.)

100

Corentin GS @corentings.dev · 21/05/2025

Want to master Go concurrency? Stop memorizing syntax. After 4 years of production Go: The real secret isn't about knowing every feature - it's about knowing when NOT to use them. A thread on building robust concurrent systems 🧵👇 #golang #programming

A screenshot essay titled '5 Key Steps to Mastering Advanced Concurrency in Go' that discusses the journey of mastering concurrency in Go programming. The author reflects on their four years of experience in building production systems, emphasizing that true mastery involves understanding the mental model of Go's concurrency rather than merely memorizing syntax or best practices. Key points include the importance of understanding goroutines and the Go scheduler, the role of channels as synchronization primitives, the effective use of context for system reliability, and the necessity of thoughtful practice through projects. The essay concludes with the insight that elegant concurrent code is about using the right features at the right time, highlighting the need for a deep understanding of fundamentals.

100

Corentin GS @corentings.dev · 16/05/2025

Most devs over-engineer because they start with tools, not problems. Start with why, design with clarity, build with boring code. That’s the Fundamentals-First way.

A screenshot essay titled 'Stop Letting Frameworks Design Your System'. The body discusses how most apps fail because they are constructed backwards, with developers prioritizing libraries and structures from external sources rather than addressing core problems. It emphasizes the importance of designing systems from first principles, advocating that a successful system should prioritize simplicity, speed, and reliability.

000

Corentin GS @corentings.dev · 16/05/2025

💥 Rewrote an old Go app I built as a junior. Back then: 6 layers, 3 frameworks, benchmark-driven madness. Now: Just stdlib, clear logic, no fluff. ✅ 10x faster ✅ Half the code ✅ Zero confusion Lesson? Simplicity scales. Start with fundamentals.

Screenshot essay titled 'The Fundamentals-First Architecture Model'. It discusses a simple approach to building durable software by focusing on fundamental principles instead of trendy frameworks. The essay outlines key strategies: 1) prioritizing core principles by understanding the problem before choosing tools; 2) making design decisions explicit to avoid letting the framework dictate the structure; 3) using simplicity as an advantage by keeping code straightforward. The author shares personal experience of rewriting an old app to demonstrate the benefits of this model, highlighting how following fundamental principles leads to clarity, reduced complexity, and adaptability in software development.

100

Corentin GS @corentings.dev · 16/05/2025

Want faster, smoother Go apps? Use pools. • Lower latency • Fewer allocations • Controlled scaling Write once. Reuse forever. It’s that simple.

000

Corentin GS @corentings.dev · 16/05/2025

Most Go performance issues aren’t about your code. They’re about your setup. • No pooling = more GC • More GC = slower app • Slower app = bad UX Fix it with resource pooling. Easy win.

000

Corentin GS @corentings.dev · 15/05/2025

Spinning up a new DB connection every time? Stop. • Pools cut latency • Reduce memory allocations • Improve scalability Reuse expensive resources. Your Go app will thank you.

000

Corentin GS @corentings.dev · 15/05/2025

🚀 Want to make your Go apps faster and more scalable? Use resource pooling. ✅ Lower latency ✅ Fewer allocations ✅ Better scalability Stop wasting CPU cycles. Reuse what you can. Build smarter. 🧠💡 #golang #backend #performance

A screenshot essay titled "Why You Should Use Resource Pooling in Go" discussing the benefits of resource pooling for improving performance in Go applications. The text outlines three main benefits: 1) Lower Latency, explaining how resource pools reduce delays by reusing existing connections; 2) Fewer Allocations, emphasizing that resource pools minimize memory use and CPU workload by reducing the number of new resource creations; 3) Better Scalability, highlighting how pools help manage traffic spikes and ensure app stability. The essay concludes that utilizing resource pools makes Go applications faster, lighter, and easier to scale.

110

Corentin GS @corentings.dev · 15/05/2025

Most “slow” endpoints don’t look broken. Until they hit production. I had one running at 500ms. Not terrible… until it tanked everything under real traffic. Here’s exactly how I cut it to 50ms — and what most Go developers miss along the way. Swipe through 👇

From 500ms to 50ms A Real Fix for Sluggish Endpoints (for Go developers who want real speed, not theory)

100

Corentin GS @corentings.dev · 14/05/2025

Latency kills. Our optimization stack: • Profile first (pprof + tracing) • Read/write split with materialized views • Multi-level cache with domain-driven invalidation P50: 45ms. P95: 65ms. P99: 85ms. Every ms counts.

000

Corentin GS @corentings.dev · 14/05/2025

ORMs are great—until they aren't. One "smart" query tanked performance. We rewrote it into two dumb ones + a merge in Go. Result? 5x faster. Sometimes, less abstraction = more speed.

000

Corentin GS @corentings.dev · 14/05/2025

From 500ms to 50ms. We cut API latency by 90% using: • pprof + tracing to find real bottlenecks • Read-optimized models to speed up queries • Multi-layered caching to slash response time Don’t guess. Measure. Optimize. Repeat.

100

Corentin GS @corentings.dev · 11/05/2025

Vertical Slice + Modular Monolith = clarity. • Feature logic lives together • Business domains stay distinct • New devs onboard faster Pragmatic, scalable, and shockingly joyful to work on. Worth every refactor.

100

Corentin GS @corentings.dev · 11/05/2025

“I might change the DB one day.” So I built every Go repo with interfaces. Result? • Zero DB swaps • Endless boilerplate • Slower features Now I let each feature own its logic. Vertical Slices > over-engineered abstractions.

100

Corentin GS @corentings.dev · 11/05/2025

Clean Architecture in Go looked great on paper. But in reality? • Rigid layers • Bloated interfaces • Simple changes felt hard Vertical Slice Architecture fixed it. Sane, fast, focused. I write features, not ceremonies.

100

Corentin GS @corentings.dev · 11/05/2025

Is Clean Architecture always the answer for your #Go monolith? 🤔 I found more speed & sanity by ditching complex layers for Vertical Slice Architecture. My pragmatic journey from architectural dogma to #VSA clarity. Are you ready to slice? #Golang #SoftwareDesign #PragmaticDev

Screenshot essay titled 'Trading Layers for Slices: A Go Developer's Story of Finding Simplicity and Power in Vertical Slice Architecture.' The text discusses the challenges of strict layered architecture in backend development, particularly in Go, highlighting the author's journey towards Vertical Slice Architecture (VSA). It captures how layered approaches created complications in feature changes, while VSA allowed for organizing by feature with self-contained slices. The author notes the transformative effects of refactoring into cohesive slices, emphasizing benefits such as increased development speed, simpler debugging, and improved onboarding. The essay concludes with a call to identify progress barriers and strategize to overcome them.

110

Corentin GS @corentings.dev · 10/05/2025

Modular monoliths are back—for good reason: • Simpler than microservices • Faster for small teams • Easier path to eventual scale Don’t fall for the hype. Start with a monolith. Scale with intention.

100

Corentin GS @corentings.dev · 09/05/2025

3 modular monolith myths to ignore: • “You need complex tools” — wrong • “Modules must be perfect early” — nope • “Use event buses” — only if async is vital Focus on clarity. Not over-engineering.

100

Corentin GS @corentings.dev · 09/05/2025

Modular monoliths aren't complex. Here’s how to get them right: • Define by business function • Enforce one-way dependencies • Start broad—refine later Forget perfect architecture. Clean, simple, and evolving wins every time.

100

Corentin GS @corentings.dev · 09/05/2025

Nobody tells you this: A well-designed modular monolith can get your product to market way faster than microservices -less complexity, fewer headaches, more shipping 🚀 Don’t over-engineer. Start simple, scale smart. #SoftwareEngineering

Screenshot essay titled 'Modular Monoliths: Keep It Simple!' presenting key insights into modular monoliths. The body outlines common misconceptions, emphasizing that complex tools aren't necessary, modules don't need to be perfect initially, and direct method calls are preferable to event buses. It highlights trends showing a resurgence in modular monoliths due to their simplicity and efficiency compared to microservices. The author provides actionable steps for building better modular systems, focusing on defining modules by business functions, setting rules for dependencies, and starting with a limited number of broad modules. The message encourages avoiding unnecessary complexity in system design.

100

Corentin GS @corentings.dev · 06/05/2025

Most people wait for permission to start. I didn’t. • Dropped out—twice • Built my first game solo • Turned a school project into a career The moment you decide to follow your will? That’s when everything changes.

100

Corentin GS @corentings.dev · 06/05/2025

You don’t need school to become a great developer. What you need is this: • A real problem to solve • Relentless curiosity • The courage to take risks A pandemic, a 2D game, and some C code. That’s how I found my calling.

100

Corentin GS @corentings.dev · 06/05/2025

A C project during lockdown changed my life. I thought it’d be easy. It wasn’t. But it lit the path forward: • Learned memory management the hard way • Discovered how code could be art • Realized software engineering was it One game. A total pivot. Zero regrets.

100

Corentin GS @corentings.dev · 05/05/2025

Everyone said I was wasting my time not getting a degree. But I’ve learned: • A “safe” path isn’t always progress • Showing up daily beats raw talent • You can’t wait to stop feeling insecure Now I build real products for real users. Your turn.

000

Corentin GS @corentings.dev · 05/05/2025

I wasted years jumping to the newest backend frameworks. It made me feel “relevant.” But I never got better. What actually worked? • One stack • One big project • One deep dive into systems That’s how you level up. Every time.

000