<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Platform Engineering on Antoine Boucher</title><link>https://antoineboucher.info/CV/blog/tags/platform-engineering/</link><description>Recent content in Platform Engineering on Antoine Boucher</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Sat, 30 Dec 2023 10:00:00 -0400</lastBuildDate><atom:link href="https://antoineboucher.info/CV/blog/tags/platform-engineering/index.xml" rel="self" type="application/rss+xml"/><item><title>My journey in software engineering</title><link>https://antoineboucher.info/CV/blog/posts/software-engineering-journey/</link><pubDate>Sat, 30 Dec 2023 10:00:00 -0400</pubDate><guid>https://antoineboucher.info/CV/blog/posts/software-engineering-journey/</guid><description>&lt;p&gt;This site’s bio sums up the slice of the field I care about most: &lt;strong&gt;backend&lt;/strong&gt;, &lt;strong&gt;platform&lt;/strong&gt;, and &lt;strong&gt;DevSecOps&lt;/strong&gt;. This post is a longer look at how I think about that journey — not a timeline of jobs, but the ideas that kept showing up once I stopped treating “shipping features” as the only scoreboard.&lt;/p&gt;
&lt;h2 id="from-features-to-systems"&gt;From features to systems&lt;/h2&gt;
&lt;p&gt;Early on, progress often feels linear: tickets closed, endpoints added, screens shipped. That work matters. Over time, though, the interesting problems sit one level up: how services talk to each other, how failures propagate, how a change in one team’s repo affects everyone else on Monday morning. Backend engineering stops being “write the handler” and becomes “design something that stays understandable when you’re not in the room.”&lt;/p&gt;</description></item></channel></rss>