{"id":21967,"date":"2025-11-02T14:33:25","date_gmt":"2025-11-02T14:33:25","guid":{"rendered":"https:\/\/pokecon.jp\/job\/?p=21967"},"modified":"2025-11-02T14:33:25","modified_gmt":"2025-11-02T14:33:25","slug":"most-of-what-we-call-progress","status":"publish","type":"post","link":"https:\/\/pokecon.jp\/job\/21967\/","title":{"rendered":"Most of What We Call Progress"},"content":{"rendered":"\n<\/p>\n
\n

Most of What We Call Progress<\/h3>\n

Most of what we call progress in software is just motion. New tools, new frameworks, same problems. Maybe fancier logos. Our industry always has this collective thrill that a new fancy method, framework, process will make things infinitely better. Perhaps, perhaps, perhaps.<\/p>\n

I\u2019ve watched that excitement enough times to recognize its cycles. Years ago, a colleague was setting up Apache Spark for a modest analytics job. The dataset was small. He knew the requirements intimately. In all honesty, the complexity was completely unnecessary. I asked why. His answer was what I\u2019ve heard countless times since:\u00a0<\/p>\n

\n

Because it scales.<\/p>\n<\/blockquote>\n

That moment stayed with me. Not because Spark was wrong, but because I realized how easily engineers, myself included, confuse capability with necessity. After years in management<\/a>, I still feel like an engineer. The illusion of progress often looks exactly like progress: more systems, more layers, more abstraction. It feels like forward motion until it is not. That\u2019s why I wrote a chapter<\/a> arguing you can do most analytics with a few scripts and Postgres. And damn, I love Postgres.<\/p>\n

With time, you start to notice a deeper pattern. The same optimism that drives innovation also fuels waste. Every cool modern stack eventually becomes tomorrow\u2019s cautionary tale. I talked about it here<\/a> but there\u2019s a bigger lesson to be taught. Every abstraction that promises freedom adds a little more friction. Every clever idea you once loved becomes something you later apologize for maintaining.\u00a0<\/p>\n

The difference<\/a> is not about tools. It\u2019s about perspective<\/a>. What changes with experience is not your stack. Generally speaking, it\u2019s your sense of what matters. You start seeing that progress depends less on what you build and more on how you think, how you decide<\/a>, how you work with others.<\/p>\n

After years of building, breaking, and leading<\/a> teams, I\u2019ve changed my mind on many things. It is not out of cynicism, but because experience has a way of sanding down certainty. These are a few of the lessons that stayed.<\/p>\n

\n
\"\"<\/figure>\n<\/div>\n

Clarity Over Cleverness<\/h3>\n

Early in your career, cleverness feels like proof of skill. The shorter the code, the more elegant the abstraction, the more you feel you\u2019ve outsmarted the problem and maybe, a little, everyone else. I used to believe that too. The best engineers, I thought, wrote code<\/a> you had to study twice to understand.\u00a0<\/p>\n

Unfortunately, clever code doesn\u2019t scale. Not across time, not across people. What feels ingenious in the moment becomes a small trap for whoever inherits it next including your future self. Someone will wholeheartedly say what the fuck is going on here? When you\u2019re the one debugging a late-night incident<\/a> and reading your own comments from two years ago, clever loses its charm fast. The real production code isn\u2019t a leetcode problem<\/a> to show off.<\/p>\n

At some point, you realize that simplicity is not the absence of sophistication as Da Vinci said. It\u2019s the evidence of mastery. Writing clear code, building transparent systems, communicating intent precisely. Because clarity compounds<\/a> like everything else. One clear decision enables ten more.<\/p>\n

When I teach at university, I tell them this: if your code requires an explanation, it probably needs a rewrite. It\u2019s not about intelligence; it\u2019s about empathy. You\u2019re not writing for the machine. You\u2019re writing for the person who comes next. Now that I think about it, we have AI generated code<\/a>. Add that to the fire!<\/p>\n

And the irony is, the longer you work in this field, the more you admire the opposite of what once impressed you. The truly rockstar engineers<\/a> make complexity manageable. Companies keep trying to automate apprenticeship with tooling and documentation. But no static check or framework can replace the slow transfer of judgment that happens face to face.<\/p>\n

Apprenticeship Beats Abstraction<\/h3>\n

Software is craftsmanship. You can learn it from books<\/a> or courses but not all. You can also learn it by building alongside someone who has a different experience than you. That doesn\u2019t necessarily mean number of years but sometimes it\u2019s just the stack they worked with. You watch how they think, how they name things, how they stay calm when the system crashes. Those are the kind of things that make it memorable.\u00a0<\/p>\n

I remember pairing a staff engineer with a mid-senior<\/a> once. Honestly, I didn\u2019t expect them to bond so well. It became something else entirely. They started finishing each other\u2019s sentences in code reviews. They challenged each other\u2019s assumptions, refined each other\u2019s instincts. Together, they built clean and durable services<\/a> that I was proud of.<\/p>\n

When I had to split the team, one of them moved to another group. They both hated it. Not out of resistance, but because they\u2019d built something deeper than cracking the coding bottlenecks<\/a>. They kept talking anyway. They became the bridge between the teams. So, I was happy that I did. It got two teams closer\u2026<\/p>\n

That\u2019s what apprenticeship really is. It\u2019s continuity. It\u2019s the invisible thread between people who build things the same way not because they were told to, but because they learned to see through each other\u2019s eyes. That\u2019s something that stays longer than projects, teams or companies. Those are people you refer to hiring<\/a>.\u00a0<\/p>\n

Abstraction teaches structure. Apprenticeship teaches care. And good systems, like good people, survive on both.<\/p>\n

The Humbling of Process<\/h3>\n

Good ideas start out pure. Then someone turns them into a process, and that\u2019s when they start to rot.<\/p>\n

Agile was born from rebellion, a handful of engineers tired of bureaucracy from unfit waterfall. TDD was the same. It was a call to slow down and think. Both were tools for clarity. But somewhere along the way, they became economies. Certifications, coaches, metrics. Agile died the day it became a job title. I decided I didn\u2019t want to be a scrum master<\/a>.<\/p>\n

You can follow every Scrum ritual and still move nowhere.
You can hit 100% test coverage<\/a> and still 0% confidence or understanding.
You can follow every process to the letter and still turn smart people into spectators.<\/p>\n

The more you manage, the clearer this becomes. Process doesn\u2019t save bad culture; it amplifies it. The point of the process is to make communication cheaper<\/a>, not to replace it. You can have a dozen rituals, but if people aren\u2019t trusted to think, all you\u2019re doing is project management theater<\/a>.<\/p>\n

And that\u2019s where the real danger lies when the process turns into religion. When people stop asking why and start quoting how. Dogma starts when we mistake the tool for the truth. When the ritual matters more than the result. When following the \u201cright\u201d method feels safer than thinking for yourself.<\/p>\n

After years in leadership, I\u2019ve learned that the best process is invisible when it works. It has its tenets<\/a>. And the team is guided by vision<\/a>, not ceremony. I\u2019m not saying you shouldn\u2019t have status updates. I\u2019m just saying that\u2019s not the goal. The goal is actual delivery. When you establish that, you end up with self-managing teams<\/a>. Small<\/a>, autonomous, trusted.\u00a0<\/p>\n

Process has its place. It creates safety, consistency<\/a>, and rhythm. But it should bend to fit people, not the other way around. The moment you start defending the framework<\/a> instead of the purpose, you\u2019ve already lost the plot.<\/p>\n

Experience humbles you. You start evolving your processes<\/a> and focusing on the right people. The rest follows.<\/p>\n

The Myth of Scale<\/h3>\n

Every engineer eventually overbuilds something. You think you\u2019re being smart. You\u2019re thinking ahead, building for growth and before you know it, you\u2019ve created a system ten times heavier than your actual problem. That\u2019s the trap. We keep designing for imaginary futures for scale that may never come and call it engineering. But it\u2019s not engineering. It\u2019s over-engineering<\/a>.<\/p>\n

The industry rewards it too. Nobody gets promoted for keeping things small and sane. You get promoted for complexity. For showing initiative. For saying microservices and distributed. Over-engineering <\/a>doesn\u2019t come from stupidity. It comes from ambition and fear. Ambition that wants to prove mastery. Fear that wants to look prepared. Nonetheless, the result is the same.<\/p>\n

Experience burns that instinct out of you. You stop trying to impress the invisible audience. You start building for the one that\u2019s actually there.<\/p>\n

The Boring Stuff That Matters<\/h3>\n

When you\u2019re young, you want freedom. Understandable. Dynamic languages<\/a>, no process, no linting rules. Need for speed. Yay! You want to move fast and prove you\u2019re clever enough to live without the guardrails. I was like that too. I remember arguing why I\u2019ve to put the final keyword before all the constant variables. My colleague pointed me to a convention doc and asked me to read it. If I\u2019ve better idea next time, I could have come up and defended it. Lucky for me, I did not. I quickly realized I was just too lazy to type \u201cfinal\u201d. My arguments were silly.\u00a0<\/p>\n

Then you grow up, and you start cleaning up after people like you.<\/p>\n

I saw many people hate typed languages. Extra ceremony. Slowing me down. Blah blah. Now they also see them as early warning systems. The same goes for linters, tests, even code reviews<\/a>. Most of the guardrails you once resisted linters, type checks, static analysis aren\u2019t bureaucracy. They\u2019re collective defense mechanisms. They make sure the system stays consistent when people come and go. The older I get, the more I see stability not as friction, but as freedom from chaos. They don\u2019t exist to restrict you. They exist to stop you from drowning in your own chaos.<\/p>\n

Engineering principles<\/a>, coding standards, templates, even naming conventions. Now I see it for what it is: collective memory. The small agreements that let ten people act like one. The bigger the system gets, the more those small things matter.<\/p>\n

Experience humbles your taste. You stop craving freedom and start craving stability. You realize the boring stuff such as type safety, documentation, process is what lets you take real risks somewhere else.<\/p>\n

It\u2019s not about rules. It\u2019s about focus.<\/p>\n

Leverage Over Control\u00a0<\/h3>\n

For a long time, I questioned why PMs existed. Both product and project. I used to see them as blockers, a layer between engineers and the work. Another meeting. Another update. Another person who didn\u2019t write code telling me what to do. Yeah, I was an engineer<\/a> too once.\u00a0<\/p>\n

Then I led teams<\/a>. And I realized how much of my day vanished into coordination, context-switching, and glue work that nobody saw. That\u2019s when it clicked: a good PM isn\u2019t there to control engineers. They\u2019re there to protect them. They buy them time. They filter noise so they can think. They ease up the cognitive load<\/a>.<\/p>\n

Many PMs don\u2019t do that. They live in Jira, chase timelines, and mistake movement for progress. They measure velocity, not value.<\/p>\n

But the good ones are different. They translate business<\/a> goals into product decisions. They connect dots others don\u2019t see. They make sure projects move forward when multiple teams are involved. They know why something matters, not just when it\u2019s due. And they have answers to many questions. Why are we building this? Who\u2019s blocked? What\u2019s the trade-off? What\u2019s the priority?\u00a0<\/p>\n

They absorb chaos so the rest of the team can stay calm. The bad ones make noise. The good ones build silence. And that\u2019s the irony: for years, engineers chase autonomy, freedom from meetings, managers, and oversight only to realize that the right kind of structure is what gives you freedom back. A good PM is not overhead. They\u2019re leverage.<\/p>\n

The Real Work Is Social<\/h3>\n

You can spend years thinking software is about code, tools, or architecture<\/a>. Then one day you realize it\u2019s not. It\u2019s about people. Treat them well to be treated well. Prisoner\u2019s Dilemma<\/a>.<\/p>\n

Every system that failed on my watch<\/a> didn\u2019t break because of missing tests or weak design. It broke because someone didn\u2019t talk to someone else. Misaligned assumptions. Undefined ownership. A decision left hanging too long. And sometimes edge cases.\u00a0<\/p>\n

All the things I once dismissed. Be it documentation, announcements, even meetings<\/a> turned out to be social scaffolding. Not process for process\u2019s sake, but structure for understanding. The older you get, the more you notice how fragile clarity is. You can build the best architecture in the world, but if two teams interpret one requirement differently, it\u2019s over. The code follows the conversation. If the conversation breaks, so does the code.<\/p>\n

The real work isn\u2019t technical. It\u2019s relational. You need different rules to win<\/a>.
Likability, trust, alignment, consistency<\/a>. They are invisible but they make the difference<\/a> a lot.
You can patch systems, but you can\u2019t patch silence.<\/p>\n

Experience strips away the illusion that software is a technical craft. It\u2019s human coordination disguised as code. The best engineers I know don\u2019t just fix bugs. They fix misunderstandings before they become them.<\/p>\n

It\u2019s the same lesson I\u2019ve learned in hiring. You can interview for cleverness all day and still end up with the wrong person if you don\u2019t pay attention to red flags<\/a>. The best hires aren\u2019t the ones who ace puzzles. Surprisingly, they\u2019re the ones who reduce entropy. You remember them not for what they built, but for how calmly they helped others build.<\/p>\n

The Quiet Maturity Curve<\/h3>\n

In the beginning, you want to prove yourself. You want your code to stand out, your process to be the smartest, your architecture<\/a> to be the cleanest. You want people to notice. Then you spend enough time in the industry, and you start to see what actually lasts. It\u2019s not clever abstractions. It\u2019s not a big launch. It\u2019s not the tech stack you once defended like religion. It\u2019s the simple things that keep working long after the hype dies<\/a>.<\/p>\n

Experience gradually makes you quieter. You stop trying to win every argument. You start letting small things slide because you\u2019ve seen how little they matter. You stop chasing perfection<\/a> and start chasing flow that state where people, systems, and ideas move together without friction.<\/p>\n

The engineers I respect most barely talk about technology anymore. They talk about trust, focus, and momentum. They still love building, but the thrill is different now. It\u2019s not the rush of release; it\u2019s the satisfaction of knowing things won\u2019t fall apart when you\u2019re gone. Or refactoring untested code<\/a> and make it great again! That doesn\u2019t mean they don\u2019t care about quality. They do. They just highlight it as a different problem. If you don\u2019t promote a culture of quality, you won\u2019t have quality even if you scream for it. If you end up in a good engineering org with high bandwidth and quality, there\u2019s little chance that you\u2019ll mess things up.<\/p>\n

I used to think maturity was about mastery. Now I think it\u2019s about knowing when to walk away. Knowing when \u201cgood enough\u201d really is. Knowing which fights are worth it and which ones are just noise.<\/p>\n

You spend years trying to make software bend to your will. Then you learn to bend with it. That\u2019s the quiet curve nobody tells you about.\u00a0 The one where progress stops being about moving fast and starts being about moving right. I really like my colleague\u2019s one liner: \u201cI write distributed systems that won\u2019t wake you up often.\u201d You stop idolizing tools. You start valuing ecosystems that stay up while you\u2019re asleep<\/a>. You choose PostgreSQL over the shiny new datastore, Bash over the latest task runner, and typed APIs over clever hacks, not because they\u2019re exciting, but because they keep working.<\/p>\n<\/div>\n\n
\u5143\u306e\u8a18\u4e8b\u3092\u78ba\u8a8d\u3059\u308b <\/a><\/p>\n","protected":false},"excerpt":{"rendered":"Most of What We Call Progress Most of what we call progress in software is just motion. New tools, new framewo […]","protected":false},"author":1,"featured_media":21968,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[2],"tags":[],"class_list":["post-21967","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-hatena-blog"],"acf":[],"yoast_head":"\nMost of What We Call Progress - \u30dd\u30b1\u30b3\u30f3<\/title>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/yusufaytas.com\/most-of-what-we-call-progress\/\" \/>\n<meta property=\"og:locale\" content=\"ja_JP\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Most of What We Call Progress - \u30dd\u30b1\u30b3\u30f3\" \/>\n<meta property=\"og:description\" content=\"Most of What We Call Progress Most of what we call progress in software is just motion. New tools, new framewo […]\" \/>\n<meta property=\"og:url\" content=\"https:\/\/yusufaytas.com\/most-of-what-we-call-progress\/\" \/>\n<meta property=\"og:site_name\" content=\"\u30dd\u30b1\u30b3\u30f3\" \/>\n<meta property=\"article:published_time\" content=\"2025-11-02T14:33:25+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/pokecon.jp\/job\/wp-content\/uploads\/2025\/11\/keep-it-simple-rust.jpg\" \/>\n\t<meta property=\"og:image:width\" content=\"508\" \/>\n\t<meta property=\"og:image:height\" content=\"491\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/jpeg\" \/>\n<meta name=\"author\" content=\"info@pokecon.jp\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"\u57f7\u7b46\u8005\" \/>\n\t<meta name=\"twitter:data1\" content=\"info@pokecon.jp\" \/>\n\t<meta name=\"twitter:label2\" content=\"\u63a8\u5b9a\u8aad\u307f\u53d6\u308a\u6642\u9593\" \/>\n\t<meta name=\"twitter:data2\" content=\"13\u5206\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\\\/\\\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\\\/\\\/yusufaytas.com\\\/most-of-what-we-call-progress\\\/#article\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/pokecon.jp\\\/job\\\/21967\\\/\"},\"author\":{\"name\":\"info@pokecon.jp\",\"@id\":\"https:\\\/\\\/pokecon.jp\\\/job\\\/#\\\/schema\\\/person\\\/16c9f07b1ba984d165d9aee259bda997\"},\"headline\":\"Most of What We Call Progress\",\"datePublished\":\"2025-11-02T14:33:25+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\\\/\\\/pokecon.jp\\\/job\\\/21967\\\/\"},\"wordCount\":2669,\"image\":{\"@id\":\"https:\\\/\\\/yusufaytas.com\\\/most-of-what-we-call-progress\\\/#primaryimage\"},\"thumbnailUrl\":\"https:\\\/\\\/pokecon.jp\\\/job\\\/wp-content\\\/uploads\\\/2025\\\/11\\\/keep-it-simple-rust.jpg\",\"articleSection\":[\"\u306f\u3066\u306a\u30d6\u30ed\u30b0\"],\"inLanguage\":\"ja\"},{\"@type\":\"WebPage\",\"@id\":\"https:\\\/\\\/pokecon.jp\\\/job\\\/21967\\\/\",\"url\":\"https:\\\/\\\/yusufaytas.com\\\/most-of-what-we-call-progress\\\/\",\"name\":\"Most of What We Call Progress - \u30dd\u30b1\u30b3\u30f3\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/pokecon.jp\\\/job\\\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\\\/\\\/yusufaytas.com\\\/most-of-what-we-call-progress\\\/#primaryimage\"},\"image\":{\"@id\":\"https:\\\/\\\/yusufaytas.com\\\/most-of-what-we-call-progress\\\/#primaryimage\"},\"thumbnailUrl\":\"https:\\\/\\\/pokecon.jp\\\/job\\\/wp-content\\\/uploads\\\/2025\\\/11\\\/keep-it-simple-rust.jpg\",\"datePublished\":\"2025-11-02T14:33:25+00:00\",\"author\":{\"@id\":\"https:\\\/\\\/pokecon.jp\\\/job\\\/#\\\/schema\\\/person\\\/16c9f07b1ba984d165d9aee259bda997\"},\"breadcrumb\":{\"@id\":\"https:\\\/\\\/yusufaytas.com\\\/most-of-what-we-call-progress\\\/#breadcrumb\"},\"inLanguage\":\"ja\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\\\/\\\/yusufaytas.com\\\/most-of-what-we-call-progress\\\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"ja\",\"@id\":\"https:\\\/\\\/yusufaytas.com\\\/most-of-what-we-call-progress\\\/#primaryimage\",\"url\":\"https:\\\/\\\/pokecon.jp\\\/job\\\/wp-content\\\/uploads\\\/2025\\\/11\\\/keep-it-simple-rust.jpg\",\"contentUrl\":\"https:\\\/\\\/pokecon.jp\\\/job\\\/wp-content\\\/uploads\\\/2025\\\/11\\\/keep-it-simple-rust.jpg\",\"width\":508,\"height\":491},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\\\/\\\/yusufaytas.com\\\/most-of-what-we-call-progress\\\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"\u30db\u30fc\u30e0\",\"item\":\"https:\\\/\\\/pokecon.jp\\\/job\\\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Most of What We Call Progress\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\\\/\\\/pokecon.jp\\\/job\\\/#website\",\"url\":\"https:\\\/\\\/pokecon.jp\\\/job\\\/\",\"name\":\"\u30dd\u30b1\u30b3\u30f3\",\"description\":\"\",\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\\\/\\\/pokecon.jp\\\/job\\\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"ja\"},{\"@type\":\"Person\",\"@id\":\"https:\\\/\\\/pokecon.jp\\\/job\\\/#\\\/schema\\\/person\\\/16c9f07b1ba984d165d9aee259bda997\",\"name\":\"info@pokecon.jp\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"ja\",\"@id\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/2b0549cd9f7907c092ca5fbb283baf72337f235726e4b46fa39ec0b701ac2fe2?s=96&d=wavatar&r=g\",\"url\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/2b0549cd9f7907c092ca5fbb283baf72337f235726e4b46fa39ec0b701ac2fe2?s=96&d=wavatar&r=g\",\"contentUrl\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/2b0549cd9f7907c092ca5fbb283baf72337f235726e4b46fa39ec0b701ac2fe2?s=96&d=wavatar&r=g\",\"caption\":\"info@pokecon.jp\"},\"url\":\"https:\\\/\\\/pokecon.jp\\\/job\\\/author\\\/infopokecon-jp\\\/\"}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"Most of What We Call Progress - \u30dd\u30b1\u30b3\u30f3","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/yusufaytas.com\/most-of-what-we-call-progress\/","og_locale":"ja_JP","og_type":"article","og_title":"Most of What We Call Progress - \u30dd\u30b1\u30b3\u30f3","og_description":"Most of What We Call Progress Most of what we call progress in software is just motion. New tools, new framewo […]","og_url":"https:\/\/yusufaytas.com\/most-of-what-we-call-progress\/","og_site_name":"\u30dd\u30b1\u30b3\u30f3","article_published_time":"2025-11-02T14:33:25+00:00","og_image":[{"width":508,"height":491,"url":"https:\/\/pokecon.jp\/job\/wp-content\/uploads\/2025\/11\/keep-it-simple-rust.jpg","type":"image\/jpeg"}],"author":"info@pokecon.jp","twitter_card":"summary_large_image","twitter_misc":{"\u57f7\u7b46\u8005":"info@pokecon.jp","\u63a8\u5b9a\u8aad\u307f\u53d6\u308a\u6642\u9593":"13\u5206"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/yusufaytas.com\/most-of-what-we-call-progress\/#article","isPartOf":{"@id":"https:\/\/pokecon.jp\/job\/21967\/"},"author":{"name":"info@pokecon.jp","@id":"https:\/\/pokecon.jp\/job\/#\/schema\/person\/16c9f07b1ba984d165d9aee259bda997"},"headline":"Most of What We Call Progress","datePublished":"2025-11-02T14:33:25+00:00","mainEntityOfPage":{"@id":"https:\/\/pokecon.jp\/job\/21967\/"},"wordCount":2669,"image":{"@id":"https:\/\/yusufaytas.com\/most-of-what-we-call-progress\/#primaryimage"},"thumbnailUrl":"https:\/\/pokecon.jp\/job\/wp-content\/uploads\/2025\/11\/keep-it-simple-rust.jpg","articleSection":["\u306f\u3066\u306a\u30d6\u30ed\u30b0"],"inLanguage":"ja"},{"@type":"WebPage","@id":"https:\/\/pokecon.jp\/job\/21967\/","url":"https:\/\/yusufaytas.com\/most-of-what-we-call-progress\/","name":"Most of What We Call Progress - \u30dd\u30b1\u30b3\u30f3","isPartOf":{"@id":"https:\/\/pokecon.jp\/job\/#website"},"primaryImageOfPage":{"@id":"https:\/\/yusufaytas.com\/most-of-what-we-call-progress\/#primaryimage"},"image":{"@id":"https:\/\/yusufaytas.com\/most-of-what-we-call-progress\/#primaryimage"},"thumbnailUrl":"https:\/\/pokecon.jp\/job\/wp-content\/uploads\/2025\/11\/keep-it-simple-rust.jpg","datePublished":"2025-11-02T14:33:25+00:00","author":{"@id":"https:\/\/pokecon.jp\/job\/#\/schema\/person\/16c9f07b1ba984d165d9aee259bda997"},"breadcrumb":{"@id":"https:\/\/yusufaytas.com\/most-of-what-we-call-progress\/#breadcrumb"},"inLanguage":"ja","potentialAction":[{"@type":"ReadAction","target":["https:\/\/yusufaytas.com\/most-of-what-we-call-progress\/"]}]},{"@type":"ImageObject","inLanguage":"ja","@id":"https:\/\/yusufaytas.com\/most-of-what-we-call-progress\/#primaryimage","url":"https:\/\/pokecon.jp\/job\/wp-content\/uploads\/2025\/11\/keep-it-simple-rust.jpg","contentUrl":"https:\/\/pokecon.jp\/job\/wp-content\/uploads\/2025\/11\/keep-it-simple-rust.jpg","width":508,"height":491},{"@type":"BreadcrumbList","@id":"https:\/\/yusufaytas.com\/most-of-what-we-call-progress\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"\u30db\u30fc\u30e0","item":"https:\/\/pokecon.jp\/job\/"},{"@type":"ListItem","position":2,"name":"Most of What We Call Progress"}]},{"@type":"WebSite","@id":"https:\/\/pokecon.jp\/job\/#website","url":"https:\/\/pokecon.jp\/job\/","name":"\u30dd\u30b1\u30b3\u30f3","description":"","potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/pokecon.jp\/job\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"ja"},{"@type":"Person","@id":"https:\/\/pokecon.jp\/job\/#\/schema\/person\/16c9f07b1ba984d165d9aee259bda997","name":"info@pokecon.jp","image":{"@type":"ImageObject","inLanguage":"ja","@id":"https:\/\/secure.gravatar.com\/avatar\/2b0549cd9f7907c092ca5fbb283baf72337f235726e4b46fa39ec0b701ac2fe2?s=96&d=wavatar&r=g","url":"https:\/\/secure.gravatar.com\/avatar\/2b0549cd9f7907c092ca5fbb283baf72337f235726e4b46fa39ec0b701ac2fe2?s=96&d=wavatar&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/2b0549cd9f7907c092ca5fbb283baf72337f235726e4b46fa39ec0b701ac2fe2?s=96&d=wavatar&r=g","caption":"info@pokecon.jp"},"url":"https:\/\/pokecon.jp\/job\/author\/infopokecon-jp\/"}]}},"_links":{"self":[{"href":"https:\/\/pokecon.jp\/job\/wp-json\/wp\/v2\/posts\/21967","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/pokecon.jp\/job\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/pokecon.jp\/job\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/pokecon.jp\/job\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/pokecon.jp\/job\/wp-json\/wp\/v2\/comments?post=21967"}],"version-history":[{"count":1,"href":"https:\/\/pokecon.jp\/job\/wp-json\/wp\/v2\/posts\/21967\/revisions"}],"predecessor-version":[{"id":21969,"href":"https:\/\/pokecon.jp\/job\/wp-json\/wp\/v2\/posts\/21967\/revisions\/21969"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/pokecon.jp\/job\/wp-json\/wp\/v2\/media\/21968"}],"wp:attachment":[{"href":"https:\/\/pokecon.jp\/job\/wp-json\/wp\/v2\/media?parent=21967"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/pokecon.jp\/job\/wp-json\/wp\/v2\/categories?post=21967"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/pokecon.jp\/job\/wp-json\/wp\/v2\/tags?post=21967"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}