Sign in

Corentin GS

@corentings.dev
35 followers 57 following 222 posts

Teaching Go for cloud-native microservices to backend beginners. Self-taught developer with 5 years of experience. Making the practical course I wish existed.

PostsRepliesMedia
Corentin GS @corentings.dev · 14/07/2025
2. Custom Error Types Pattern: Attach rich context via structs. Use case: Precise HTTP-status mapping, structured logs, Sentry tags.
010
Corentin GS @corentings.dev · 14/07/2025
1. Error-as-Value (Idiomatic Go) Pattern: Return error as a normal value. Why it matters: Prevents panics and keeps control flow explicit in micro-services.1. Error-as-Value (Idiomatic Go) Pattern: Return error as a normal value. Why it matters: Prevents panics and keeps control flow explicit in micro-services.1. Error-as-Value (Idiomatic Go) Pattern: Return error as a normal value. Why it matters: Prevents panics and keeps control flow explicit in micro-services.1. Error-as-Value (Idiomatic Go) Pattern: Return error as a normal value. Why it matters: Prevents panics and keeps control flow explicit in micro-services.
110
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🛡️  7 Go Error Handling Patterns Real-world examples to bulletproof your backend🛡️  7 Go Error Handling Patterns Real-world examples to bulletproof your backend🛡️  7 Go Error Handling Patterns Real-world examples to bulletproof your backend
110
Corentin GS @corentings.dev · 01/07/2025
👨‍💻 Why focus on these languages? If you want to build a strong foundation as a software engineer, learning languages that teach core computer science concepts is crucial.👨‍💻 Why focus on these languages? If you want to build a strong foundation as a software engineer, learning languages that teach core computer science concepts is crucial.👨‍💻 Why focus on these languages? If you want to build a strong foundation as a software engineer, learning languages that teach core computer science concepts is crucial.
020
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.🔑 3 Key Programming Languages for Beginners Who want to become Elite Software Engineers💡 And it’s easier than you think.🔑 3 Key Programming Languages for Beginners Who want to become Elite Software Engineers💡 And it’s easier than you think.🔑 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 · 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 · 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 · 21/05/2025
True Go concurrency mastery starts with understanding the mental model. Not just writing code that runs in parallel... But knowing how and why it works the way it does.True Go concurrency mastery starts with understanding the mental model. Not just writing code that runs in parallel... But knowing how and why it works the way it does.
100
Corentin GS @corentings.dev · 21/05/2025
The basics are easy: • go func() • channels • select But mastery? That’s a different game entirely.The basics are easy: • go func() • channels • select But mastery? That’s a different game entirely.The basics are easy: • go func() • channels • select But mastery? That’s a different game entirely.The basics are easy: • go func() • channels • select But mastery? That’s a different game entirely.
100
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.)Most Go developers don’t struggle with syntax. They struggle with concurrency. (And after 4 years in production, I’ve seen exactly why.)Most Go developers don’t struggle with syntax. They struggle with concurrency. (And after 4 years in production, I’ve seen exactly why.)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 · 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
Trace First, Always Guessing is cheap. Profiling is truth. Use pprof, runtime/trace, flamegraphs Look at CPU time, allocations, blocking Slow paths often aren’t where you think 👉 Trace before you touch anything.
100
Corentin GS @corentings.dev · 15/05/2025
The Problem Your endpoint isn’t “slow.” Until it gets hit 10,000 times. That’s when the lag shows up. Here’s how I turned 500ms → 50ms. And what most Go devs forget.The Problem Your endpoint isn’t “slow.” Until it gets hit 10,000 times. That’s when the lag shows up. Here’s how I turned 500ms → 50ms. And what most Go devs forget.The Problem Your endpoint isn’t “slow.” Until it gets hit 10,000 times. That’s when the lag shows up. Here’s how I turned 500ms → 50ms. And what most Go devs forget.The Problem Your endpoint isn’t “slow.” Until it gets hit 10,000 times. That’s when the lag shows up. Here’s how I turned 500ms → 50ms. And what most Go devs forget.
100
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)From 500ms to 50ms A Real Fix for Sluggish Endpoints (for Go developers who want real speed, not theory)From 500ms to 50ms A Real Fix for Sluggish Endpoints (for Go developers who want real speed, not theory)From 500ms to 50ms A Real Fix for Sluggish Endpoints (for Go developers who want real speed, not theory)
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 · 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 · 04/05/2025
Legacy code: I am your inheritance! 🧬 This #MayThe4th, embrace your codebase's heritage. Map dependencies, document wisdom, and refactor with purpose. Every line of code has a story. #DevLife #StarWarsDay
A screenshot essay titled 'Legacy Code Revelations - Embracing Your Codebase's Heritage' discusses the challenges and responsibilities of managing legacy code. It emphasizes the value of understanding and respecting the history behind a codebase, comparing the revelation of taking over a legacy system to a dramatic familial revelation. The author encourages developers to approach legacy code as an inheritance rather than an obstacle, suggesting methods such as archaeological debugging and documenting configurations. They stress the importance of understanding past decisions, embracing purposeful refactoring, and planning modernization strategies, ultimately highlighting the narrative that every codebase represents in terms of business needs and technical evolution.
100
Corentin GS @corentings.dev · 04/05/2025
I have the architectural high ground! 🏔️ This #StarWarsDay, level up your system design: decouple like a Jedi, scale like the Empire (but better), and keep your resilience patterns stronger than beskar. #SystemDesign #MayThe4th
A screenshot essay titled 'Having the High Ground - A Jedi's Guide to System Architecture'. The essay begins with a bold quote from Obi-Wan about having the high ground, connecting strategic positioning in duels to system architecture. It discusses the importance of good architecture in overcoming scaling challenges, recommending battle-tested patterns, the implementation of circuit breakers, and ensuring system observability. It advises keeping bounded contexts clear, designing small failure domains, and building resilience. The essay emphasizes planning for future growth with horizontal scaling and caching strategies, highlighting the value of technical superiority and clear documentation. The conclusion urges to empower teams with strategic advantages.
100
Corentin GS @corentings.dev · 04/05/2025
It's a trap! 🚨 'We'll fix it later' is the biggest deception in tech. That temporary hack? Still there after 3 years. That quick fix? Now it's load-bearing. This #MayThe4th, resist the dark side of technical debt! #DevLife #StarWarsDay
A screenshot essay titled 'It's a Trap! - The Technical Debt Deception' discusses the risks of postponing technical debt resolution in software development. The text warns against common phrases like 'We'll clean it up later' and highlights how temporary fixes can lead to long-lasting problems. It compares the pitfalls to the Rebels' risky approach to the Death Star, emphasizing that shortcuts often lead deeper into technical debt. The essay lists warning signs developers should recognize, including neglecting test implementation, hardcoding, and inadequate documentation. Ultimately, it stresses the importance of addressing issues immediately rather than deferring them, suggesting that acting now is better than postponing quality, with a nod to Star Wars.
100
Corentin GS @corentings.dev · 04/05/2025
These aren't the bugs you're looking for! 🐛 This #StarWarsDay, debug like a Jedi: trust your monitoring, question your assumptions, and remember—the real issue often hides in plain sight. #DevLife #MayThe4th
A screenshot essay titled 'Atomic Essay: These Aren't the Bugs You're Looking For - A Jedi's Guide to Debugging.' The content discusses common pitfalls in debugging for developers, using references to Star Wars. It emphasizes how developers can be misled by deceptive errors and logging. The essay compares debugging to a Jedi's approach, suggesting the use of monitoring tools for accurate diagnosis. It lists potential problems that might go unnoticed and stresses the importance of a clear mindset, akin to a Jedi's focus. The author encourages programmers to pause and reconsider their debugging strategies, with a playful nod to May the 4th as Star Wars Day.
100
Corentin GS @corentings.dev · 04/05/2025
Do or do not. There is no 'try' in production. 🧙‍♂️ This #MayThe4th, channel your inner Yoda: test thoroughly, monitor wisely, deploy confidently. The Force of robust systems, strong with you it will be. #DevOps #StarWarsDay
Screenshot essay titled 'Yoda's Guide to Production Excellence,' containing humorous and serious advice for deploying backend systems, inspired by Yoda from Star Wars. The text emphasizes the importance of disciplined practices, automated testing, and observability in creating reliable systems. Key phrases include 'Try to deploy to production, I will,' and 'Your production environment is your Dagobah.' The author stresses not merging untested code or skipping performance reviews and advises on being proactive with monitoring, likening good practices to Jedi training. Overall, the message promotes respect for the production environment and thorough preparation in software deployment.
100
Corentin GS @corentings.dev · 04/05/2025
Senior devs, you're our only hope! 🌟 This #StarWarsDay, be the Obi-Wan to a junior Padawan. Share your system design wisdom, carefully review PRs, and keep the Force of knowledge flowing. #TechMentorship #MayThe4th"
A screenshot essay titled 'Atomic Essay: Our Last Hope - The Obi-Wan Guide to Tech Mentorship'. The essay humorously compares the role of senior developers to Obi-Wan Kenobi guiding junior developers. It emphasizes the importance of mentorship, knowledge sharing, and teaching with patience. Key points include the need for senior developers to explain algorithms and performance impact, conduct thorough code reviews while focusing on understanding, and document experiences to aid future developers. The author encourages seniors to take on a mentoring role, highlighting that even experienced developers like Obi-Wan started as novices. Concludes with a motivational message for May the 4th, urging mentors to support junior developers.
110
Corentin GS @corentings.dev · 04/05/2025
This is the way of the Mandalorian Developer: Test like you're forging beskar. Deploy like you're protecting a foundling. Code like your clan's honor depends on it. 🛡️ #MayThe4th #DevLife #Engineering
Screenshot essay titled 'This Is The Way - The Mandalorian Developer's Code' discussing principles for reliable system development inspired by Mandalorian culture. The text emphasizes the importance of discipline in coding and ethical practices, suggesting that great code is like beskar steel. It describes the community of developers as a tribe, highlighting coding conventions, deployment responsibilities, and best practices. Key tools mentioned include monitoring, logging, backups, and code reviews. The essay compares onboarding junior developers to taking on foundlings, stressing the importance of team support and shared practices. The conclusion underlines the importance of honoring the code, writing tests, reviewing code, and protecting production environments.
100
Corentin GS @corentings.dev · 04/05/2025
May the 4th be with you, open-source Jedis! Fork a repo, write a stellar README, and commit like an Ewok—small but mighty. Let’s keep the Force of #OpenSource strong! 🚀 #StarWarsDay
An illustrated essay titled 'May the 4th Be With You: Open-Source Dev Wisdom,' featuring whimsical and humorous references from Star Wars to convey advice for open-source developers. The essay encourages commitment to small tasks, collaboration, and providing clear documentation. It uses analogies like wielding keyboards as lightsabers and the open-source community as the Rebel Alliance. Key points emphasize the importance of writing clear issue reports and treating README files as crucial for attracting project contributors. The writer wishes to promote a spirit of teamwork and good coding practices, concluding with a positive note on contributing to the open-source community.
100
Corentin GS @corentings.dev · 04/05/2025
Screenshot essay titled 'Unlimited Power - A Cautionary Tale of System Scaling'. The text discusses the allure of unlimited computing power for developers, comparing AWS and Kubernetes to a Death Star and an Imperial fleet. It emphasizes that true power lies in efficiency, advising against overprovisioning. Key advice includes: smart resource allocation, profiling before scaling, monitoring resource use, optimizing algorithms, and wise caching to avoid excessive costs. It urges developers to be intentional in scaling decisions, checking database indexing, query optimization, caching strategies, and potential memory leaks. The essay concludes by warning that unchecked power ultimately leads to inefficiency and high costs.
000
Corentin GS @corentings.dev · 04/05/2025
When 900 years old your codebase becomes, look as good it might not! 👴 But simple design, clear interfaces, and solid error handling help systems age like Yoda, not like a broken droid. #MayThe4th #LegacyCode #StarWarsDay
A screenshot essay titled 'When 900 Years Old You Reach - The Art of Code Longevity'. The body contains a reflection on the longevity of code systems, using a quote from Yoda to explore why some systems thrive while others deteriorate. It emphasizes the importance of simplicity, resilience, and focused functionality for enduring code. The author discusses principles that contribute to longevity, such as clear interfaces, robust error handling, and documentation. The essay further notes that not all code should last indefinitely and highlights the importance of knowing when to maintain legacy systems versus sunset them or refactor technical debt. It concludes with a call to build code that endures, comparing good systems to fine Corellian brandy.
100
Corentin GS @corentings.dev · 03/05/2025
"Now THIS is podracing! 🏎️ Zero allocations, preallocated buffers, and object pools—when every nanosecond counts, optimize like you're racing pods through Beggar's Canyon! #MayThe4th #Performance #StarWarsDay"
Screenshot essay titled 'Now This is Podracing! - The Zero-Allocation Speed Run'. The text discusses the importance of zero-allocation patterns in high-performance programming, comparing it to racing pods through Beggar's Canyon. It emphasizes the necessity of eliminating overhead and minimizing allocations for optimal performance. The essay provides insights on tuning high-performance systems, using tools like object pools and preallocated buffers, and stresses the value of profiling and monitoring memory usage. It warns against premature optimization while urging programmers to optimize where necessary for critical systems.
100
Corentin GS @corentings.dev · 03/05/2025
I've got a bad feeling about this... 😰 Our digital galaxy runs on open source maintained by a handful of heroes. This #MayThe4th, sponsor a maintainer, contribute code, help with docs. Don't let the dark side of burnout win! #OpenSource #StarWarsDay
A screenshot essay titled 'I've Got a Bad Feeling About This - The Open Source Crisis' discusses the challenges faced by open source maintainers. The text describes the feelings developers experience when critical dependencies show signs of neglect, such as outdated commits and unresolved issues. It emphasizes the reliance of the digital landscape on a few unpaid maintainers who carry the burden alone. The essay lists symptoms of troubled projects, including accumulating issues and delayed responses, and highlights the precariousness of using libraries maintained by overworked developers. It calls for action, urging the public to sponsor maintainers, contribute time and skills, and recognize the importance of maintenance work. The closing remarks stress the urgent need for corporate support to ensure the sustainability of open source dependencies in the community.
100
Corentin GS @corentings.dev · 03/05/2025
Screenshot essay titled 'How I Dropped Out of College and Earned the Trust to Lead in Tech—In Just 3 Years.' The text discusses the author's journey of self-teaching backend development after dropping out of college, detailing emotional challenges and isolation. Key lessons learned include the importance of daily consistency, starting small, and the impact of sacrifice. The author reflects on overcoming insecurity without formal credentials and challenges conventional advice about career paths. The narrative emphasizes personal growth, resilience, and the unique journey towards becoming a trusted tech leader.
100
Corentin GS @corentings.dev · 02/05/2025
Every time you jump to a new framework, you reset your learning to zero. Meanwhile, FAANG engineers are still using tech from 2010 to serve billions of requests. Time to stop framework-hopping and start thinking in systems. Here's how 🧵👇
Screenshot of an essay titled 'The Framework Trap: Why Most Self-Taught Developers Never Break Through'. The text discusses the importance of mastering backend engineering fundamentals and building real-world applications instead of constantly chasing new frameworks. It highlights two key ways to become a great backend engineer: mastering systems and architecture, and building production-grade applications. The author warns against habits like tutorial hell and learning obsolete tools, emphasizing the need for a deep understanding of system architecture. The essay concludes with advice on sticking to one backend stack for at least six months, building real systems, and studying large-scale architectures.
110
Corentin GS @corentings.dev · 01/05/2025
I just dropped my 5-step playbook that took me from CRUD apps to systems handling millions of requests. Self-taught devs: this is the guide I wish I had when I started. 🧵👇
Screenshot essay titled 'From CRUD to Production-Grade: The Hidden Path Most Tutorials Don't Teach'. The content discusses the author's experience in backend engineering, emphasizing five optimization techniques for improving database performance. Technique #1 explains connection pooling, detailing how to create a configurable pool and monitor its health. Technique #2 focuses on intelligent caching, offering advice on data access patterns and cache management. Technique #3 covers asynchronous processing, suggesting the use of background jobs over synchronous operations. Technique #4 highlights the importance of proper indexing, advising on query analysis and compound index creation. Lastly, Technique #5 stresses the need for load testing to identify bottlenecks. The essay is insightful and practical, aimed at backend developers seeking performance improvements.
100
Corentin GS @corentings.dev · 30/04/2025
🧵 Another programming language lesson I wish I'd learned sooner: Start with a strongly-typed language like Go (or even C) instead of Python. Here's why this single decision could accelerate your programming journey by years:
100
Corentin GS @corentings.dev · 30/04/2025
🚀 Want to level up from CRUD apps to production-grade Go? Here's the truth: mastering concurrency is what separates hobby projects from professional systems. 5 battle-tested steps to handle 100k+ concurrent requests like a pro: 👇
A screenshot essay titled '5 Key Steps to Mastering Advanced Concurrency in Go', discussing the significance of mastering Go's concurrency model for backend engineering. It includes five main points: 1) Understanding Go's concurrency model and goroutines, illustrated by an example of a web scraper improved from 30 minutes to under 2 minutes using goroutines. 2) Mastering channel communication for safe inter-process communication, as shown by a case where crashes stopped after switching from shared memory to channels. 3) Implementing mutex to avoid race conditions, supported by an example of a game service that improved balance accuracy with mutex locks. 4) Controlling goroutine lifecycles with context to prevent leaks, improving a memory leak issue in an early service. 5) Emphasizing the importance of real-world practice alongside theory.
110
Corentin GS @corentings.dev · 29/04/2025
What is the fastest way to become the most respected developer on your team? • Use clear names • Explain the “why” • Write a killer README • Help others move faster Code is communication. If no one understands you, you’re not saying much.
100
Corentin GS @corentings.dev · 28/04/2025
Abandoned projects aren't failures. They're training reps. Every unfinished app, broken API, and messy repo makes you better. Build. Quit. Build again. That's how you win. 🚀 #devlife #buildinpublic
Screenshot essay titled 'Learn by Building: Why That Project You Abandoned Still Mattered'. The essay discusses the valuable lessons learned from unfinished projects, emphasizing that they teach problem-solving skills, stack fundamentals, personal interests, muscle memory through repetition, and resilience in the face of failure. Each section highlights how even abandoned projects contribute to a developer's growth by providing real-world experience and insights. Key points include practicing problem-solving, understanding stack fundamentals, discovering personal preferences, building muscle memory through repeated tasks, and fostering grit by tackling difficult challenges. The closing statement encourages continued building, asserting that every effort is significant.
110
Corentin GS @corentings.dev · 24/04/2025
The scariest error message isn't 'connection refused'—it's 'works on my machine.' That's when the real engineering begins." #BackendReality #DevOps
Screenshot essay titled 'From localhost to Production: The Real-World Backend Skills They Don't Teach in Coding Bootcamps'. The content discusses the challenges developers face when transitioning from local development to production environments. It presents a 'Production Readiness Checklist' that includes five key topics: 1) Configuration Management emphasizing the use of environment variables, 2) Error Handling & Logging highlighting the importance of structured logging, 3) Performance Monitoring focusing on health checks and metrics, 4) Database Optimization detailing indexing and connection pooling, and 5) Security Hardening with strategies for input sanitization and CORS policies. The essay concludes with a reminder that ensuring operational excellence is crucial for user satisfaction.
100
Corentin GS @corentings.dev · 23/04/2025
The Linux distro you choose reveals more about your coding DNA than your GitHub profile ever will. Fedora = shipping product Arch = crafting perfection Bluefin = cloud-first thinking Stop distro-hopping and pick your developer identity in 2025 👇
A screenshot of an essay titled 'The Only 3 Linux Distros Developers Need in 2025'. The body text discusses three key Linux distributions: Fedora, Arch Linux, and Bluefin. It describes Fedora as a balanced choice for developers seeking stability and up-to-date features, emphasizing its six-month release cycle. Arch Linux is portrayed as a customizable option for developers who prefer to build their environment from scratch, highlighting its comprehensive Arch User Repository. Bluefin is presented as a specialized distribution that facilitates cloud-native development and deployment, based on Fedora Silverblue. The conclusion encourages readers to choose a distro that aligns with their individual development philosophy.
100
Corentin GS @corentings.dev · 22/04/2025
Writing Go? Stop wasting memory. 4 things every Go dev should do: - Use defer for cleanup. - Tune the GC - Use pointers smartly - Initialize with nil Small changes → big performance wins. Build fast. Stay lean. 🧠⚡️ #golang #backend
Screenshot essay titled '4 Effective Memory Management Techniques for Go Developers' providing insights on Go memory management for system performance. Highlights include: 1. Using 'defer' for resource cleanup ensures proper closure of files and network connections, enhancing server reliability. 2. Optimizing garbage collection (GC) through tuning 'GOGC' and understanding allocation patterns for consistent performance. 3. Utilizing 'Nil' to minimize unused memory by initializing maps, slices, or channels only when necessary, saving memory in large applications. 4. The importance of measuring and iterating with profiling tools like 'pprof' to monitor memory usage accurately. Concludes with encouragement to apply these techniques in real-world projects.
100
Corentin GS @corentings.dev · 20/04/2025
You're not a backend developer if you can't build an API without a framework. You're a code assembler. Learn the damn fundamentals. HTTP. SQL. Raw code. Then maybe... use a framework.
Screenshot essay titled 'Stop Learning Frameworks First. Start Here Instead.' The content emphasizes that frameworks should not be the starting point for developers. It advises building without frameworks by utilizing standard libraries like net/http in Go or http in Node to understand the underlying mechanics. It encourages writing raw SQL to grasp fundamental database concepts and managing queries effectively. The essay underscores the importance of thinking in systems, focusing on inputs, outputs, data flow, and potential failure points through diagrammatic representations. Finally, it suggests adding frameworks later once a solid understanding of backend layers is established, leading to better coding practices and engineering mentality.
220
Corentin GS @corentings.dev · 19/04/2025
Too many devs treat AI like a senior engineer. It’s not. It’s a powerful assistant—but only if you stay in control. Here are three hard-earned lessons that saved me from shipping garbage code #AI #coding #devtips #programming
Screenshot essay titled 'AI Won’t Save You—Unless You Follow These 3 Rules'. The essay discusses the common mistake of blindly trusting AI-generated code and offers three essential tips to prevent this error. Tip #1 emphasizes the importance of cross-checking AI-generated advice with official documentation, suggesting bookmarking trusted sources. Tip #2 warns against skipping double-sourcing opinions and stresses verifying recommendations from at least two reliable sources. Tip #3 reminds readers that AI should be used as an assistant rather than the primary decision-maker, advising to outline problems and solutions before consulting AI. The closing remark reflects on the author's experiences and encourages others to learn from these lessons.
110
Corentin GS @corentings.dev · 19/04/2025
Using AI to think clearly & build faster isn't just a skill. It's THE skill for developers today. 🚀 But most devs treat AI like a magic box, chasing perfect prompts instead of using it effectively. This is where things go wrong. #AI #DevTips #Coding 👇
A screenshot essay titled 'Think Clearer, Build Faster: 5 Simple Frameworks to Master AI Development'. The essay emphasizes that using AI effectively is a crucial skill, warning against treating AI as a flawless assistant. It describes the author's past mistakes and introduces five frameworks to improve AI development: 1. Clarity First - define problems in simple terms, sketch solutions, and use AI as assistance. 2. Double Prompt - never accept the first answer, rephrase questions, and compare responses. 3. Source or Ignore - always verify sources and trust citations over confidence. 4. Debug Loop - run AI-generated code, report errors, and inquire about missed aspects. 5. You're the Architect - prioritize thinking before coding, leverage AI for routine tasks, and critically review outputs. The author notes these frameworks have greatly improved their workflow.
100
Corentin GS @corentings.dev · 18/04/2025
1/ 🧵 Everyone talks about tech legends like Jobs, Gates, and Musk. But a pioneer quietly shaped the digital world we live in today. Meet Ken Thompson—the unsung hero behind the systems and tools we use every day.
100
Corentin GS @corentings.dev · 18/04/2025
🚨 Your code *working* isn’t enough. Production is a different beast. Here’s a no-fluff crash course on writing resilient, production-ready backend code. Read the full Essay on Substack: 🔗 thegolangblueprint.substack.com/p/p…
Screenshot essay titled 'Production-Ready Code 101: The Shortcut Guide'. It includes three main parts: 'Myths Debunked', 'Critical Data', and '5-Pillar Survival Framework'. 'Myths Debunked' lists three common misconceptions in software production: 1) Working locally doesn't guarantee production readiness; 2) Retries are crucial to avoid cascading failures; 3) Observability involves more than just logging. 'Critical Data' presents statistics on API performance, the impact of chaos testing, and the cost of downtime. '5-Pillar Survival Framework' outlines five strategies: enforce timeouts, use structured logging, conduct load testing, simulate failures, and abstract I/O processes. Each section is visually distinct with highlights and bullet points for clarity.
100
Corentin GS @corentings.dev · 17/04/2025
This man built the digital world, but no one talks about him. With 90% of all software relying on his work, legends like Steve Jobs, Bill Gates, and Linus Torvalds stand on his shoulders. Here's the story behind Dennis Ritchie, the most underrated genius in tech history: 🧵
100
Corentin GS @corentings.dev · 17/04/2025
I thought I was falling behind as a backend dev. Turns out, I was learning what didn’t matter. This changed everything for me 👇
A screenshot essay titled "You’re Not Behind — You’re Just Not Learning the Right Things Yet" describing a personal journey of a self-taught backend developer. The author recounts their initial struggles with learning advanced concepts such as clean architecture and system design while feeling overwhelmed by tutorials and side projects. The turning point came when they faced a real production environment, leading to the realization of their gaps in debugging and system understanding. The essay emphasizes the importance of focusing on foundational knowledge rather than pursuing additional tools, culminating in the insight that they were never behind; rather, they were learning the wrong things. The author concludes by encouraging the reader to prioritize learning the right concepts at the right time.
100
Corentin GS @corentings.dev · 16/04/2025
I've been coding for 10 years. If you're still in your first 1–2 years of programming, read this: 🧵 It might save you years.
100