Has work felt “different” to you? You show up, do your work, fix what needs fixing, and get the job done, but the excitement isn’t quite the same anymore. Maybe the work has become too routine, or maybe you’ve grown in a way your role hasn’t kept up with. You catch yourself thinking, “I’ve been doing this for years, but where do I go from here?”

It’s not always about the burnouts or frustrations. Sometimes it’s just curiosity. You’ve learned a lot, built things, solved problems, and now a small part of you wants to see what else you can do. Maybe the rise of AI is making you look at your job differently, or maybe you feel ready for a new kind of challenge that does not look like your current day-to-day.

I have seen many people across different fields go through this. Developers moving into product work, designers shifting to UX research, engineers getting into teaching, or support folks building communities. Everyone reaches that point where they want their work to feel meaningful again.

The good thing is you are not starting from zero. The experience you already have, like solving problems, making decisions, working, and communicating with people, those are real, valuable skills that carry over anywhere. Most of the time, the next step is not about leaving tech behind. It’s about finding where your skills make the most sense next.

This article is about that: How to rethink your path when things start to feel a bit stale, and how to move toward something new without losing everything you’ve built so far.

Redefining Your Toolkit

When people start thinking about changing careers, the first thing they usually do is focus on what they do not have. The missing skills, the new tools they need to learn, or how far behind they feel. It is a normal reaction, but it is not always the best place to begin.

Instead, try looking at what is already there. You have probably built more useful skills than you realize. Many of us get used to describing ourselves by our job titles, such as developer, designer, or analyst, but those titles do not fully explain what we actually do. They just tell us where we sit on a team. The real story is the work behind the title.

Think of a developer, for example. On paper, the job is to write code, but in reality, a developer spends most of their time solving problems, making decisions, and building systems that make sense to other people. The same goes for designers. They do not just make things look good; they pay attention to how people think, how they move through a screen, and how to make something feel clear and simple.

Your skills don’t disappear when your title changes. They just find new ways to show up.

These are what people call transferable skills, but you do not need the fancy term to get the idea. These are abilities that stay useful no matter where you go. Problem-solving, curiosity, clear communication, empathy, and learning fast — these are the things that make you good at what you do, even if the tools or roles change.

You already use them more than you think. When you fix a bug, you are learning how to track a problem back to its roots. When you explain a technical idea to someone non-technical, you are practicing clarity. When you deal with tight deadlines, you are learning how to manage priorities. None of these disappear if you switch fields. You apply it somewhere else.

So, before you worry about what you do not know, take a moment to see what you already do well. Write it down if you have to. Not just the tasks, but the thinking behind them. That is where your real value is.

Four Real-World Paths to Explore

Once you start seeing your skills beyond your job title, you may realize how many directions you can actually take. The tech world keeps changing fast: tools change, teams change, new roles show up every year, and people move in ways they never planned.

Here are four real paths that many people in tech are taking today.

From	To	What Changes	Why It Works
Developer	Product Manager	You move from building the product to shaping what gets built and why.	Developers already understand tradeoffs, user needs, and how features come together. That is product thinking in action.
Engineer	Developer Advocate	You focus less on code delivery and more on helping others succeed with your product.	You already know the technology inside out, so turning that knowledge into clear communication makes you a natural teacher.
Back-end Engineer	Solutions Engineer	You bring your problem-solving mindset to real client challenges.	It is not about selling, it is about understanding problems deeply and building trust through technical skill.
Designer	UX Researcher or Service Designer	You shift from visuals to understanding how people think, feel, and interact.	Good design starts with empathy, and that same skill fits perfectly in research and experience design.

What many people discover when they take one of these steps is that their daily work changes, not their identity. The tools and routines might be different, but the core way they think and solve problems stays the same.

The biggest change is usually perspective. Instead of focusing on how something gets built, you begin to care more about why it matters, who it helps, and what impact it has. For many people, that shift often brings back the excitement they might have lost somewhere along the way.

Your First Steps Towards A New Path

When you find a direction that feels interesting, the next step is figuring out how to move toward it without losing your footing where you are. This is where curiosity turns into a plan.

1. Take A Look At What You Bring

Start by checking your strengths. It does not have to be anything complex. Write down what you do well, what feels natural to you, and what people usually ask you for help with.

If you want a simple guide, Learning People has a good breakdown for auditing your personal skills, including a template for identifying and evaluating your skills. Try filling it out; it’s well worth the few minutes it takes to complete.

After listing your strengths, try matching them with roles you’re curious about. For example, if you’re a developer who enjoys explaining things, that could connect well with mentoring, writing tutorials, or developer advocacy.

2. Learn By Getting Close To It

Job descriptions aren’t a perfect reflection of the realities of working a specific job. Talking with people who do that job will. So, reach out to people who already do what you’re interested in and ask them what their day-to-day looks like, what parts they enjoy, and what surprised them when they started.

And if possible, shadow someone or volunteer to help on a project. You don’t need a job change to explore something new. Short, hands-on experiences often teach you far more than any course, and many people are more than willing to take you under their wing, especially if you are offering your time and help in exchange for experience.

3. Build Proof Through Small Experiments

Do something small that points in the direction you want to go. Maybe build a simple tool, write a short piece about what you’re learning, or help a local startup or open-source team. These don’t need to be perfect, but they just need to exist. They show direction, not completion.

Blogging has always been a perfect way to share your learning path and demonstrate your excitement about it. Plus, it establishes a track record of the knowledge you acquire.

4. Shape Your Story As You Grow

Instead of going with the idea of “I’m switching careers,” try thinking of it as “I’m building on what I already do.” That simple shift makes your journey clearer. It shows that you’re not starting from zero — you’re simply moving forward with more intention.

Navigating The Mental Hurdles

Every career shift, even when it feels exciting, comes with doubts. You might ask yourself, “What if I’m not ready?” or “What if I can’t keep up?” These thoughts are more common than people admit.

Imposter Syndrome

One fear that shows up a lot is imposter syndrome, that feeling you do not belong or that others are “better” or “smarter” at something than you. A recent piece from Nordcloud shared that more than half (58%) of IT professionals have felt this at some point in their career.

Comparison is a silent thief of confidence. Seeing others move faster can make you feel late. But everyone has different opportunities and different timing. What matters is the direction you are moving in, not how fast you go.

Here’s a thought worth remembering:

People who have successfully changed their careers did not wait until they felt brave. Most of them still had doubts, but they just moved anyway, one small step at a time.

Starting Again

Another worry is the idea of starting over. You may feel that you’ve spent too many years in one space to move into another. But you are not returning to the beginning. You are moving with experience. Your habits, discipline, and problem-solving stay with you. They just show up in a different way.

It’s hard — and self-defeating — to imagine the work it takes to start all over again, especially when you have invested many years into what you do. But remember, it’s not always too late. Even Kurt Vonnegut was 47 when he wrote his seminal book, Slaughterhouse Five. You can still enjoy a very long and fruitful career, even in middle age.

Finances

Money and stability also weigh a lot. The fear of losing income or looking uncertain can hold you back. And everyone’s money situation can be wildly different. You may have family to support, big loans to pay back, a lack of reserves, or any number of completely valid reasons for not wanting to give up a steady paycheck when you’re already receiving one.

A simple way to reduce that pressure is to start with small steps. Take a small side gig, try part-time work, or help on a short project in the area you’re curious about. These small tests give you clarity without shaking your foundation.

Conversations With Industry Experts

Below are short interviews with a handful of tech professionals serving in different roles. I wanted to talk with real people who have recently switched careers or are in the process of doing so because it helps illustrate the wide range of situations, challenges, and opportunities you might expect to encounter in a career change.

Thomas Dodoo: Graphic Designer, 5 Years Of Experience

Background: Thomas has an IT background. He first got interested in tech through game development in school, but later discovered that design was what he enjoyed more. Over time, he moved fully into graphic design and branding.

Question: When you were starting, what confused you the most about choosing your path?

Thomas: I wasn’t sure if I should stay with game development or follow design. I liked both, but design came more naturally, so I just kept learning little by little.

Question: Was there a moment that made you take your design work more seriously?

Thomas: Yes, the first time someone trusted me with their full brand. It made me realise this could be more than a hobby.

Question: What skills did you carry over from development into your design work?

Thomas: My background in development helped me think more logically about design. I break things down, think in steps, and focus on how things work, not just how they look.

Adwoa Mensah: Product Manager, 4 Years Of Experience

Background: Adwoa moved from software testing to product management.

Question: When did you realize it was time to change careers?

Adwoa: I realised it when I started caring more about why things were being built, not just checking if they worked. I enjoyed asking questions, giving input, and thinking about the bigger picture, and testing alone started to feel limiting.

Question: What new skills did you need to learn to move into your new field?

Adwoa: I had to learn how to communicate better, especially with designers, developers, and stakeholders. I also worked on planning, prioritising work, and understanding users more deeply. I learned most of this by watching product managers I worked with, asking questions, reading, and slowly taking on more responsibility on real projects.

Konstantinos Tournas: AI Engineer

Background: Konstantinos started programming with zero experience. He had no technical background at first, but he developed a strong interest in artificial intelligence and worked his way into the field.

Question: What moments in your journey made you question yourself, and how did you move past them?

Konstantinos: There were many moments in my career journey when I doubted myself, mainly because I started completely from zero, with no programming background and no connections in the field. What helped me push through was the motivation I had to learn and my genuine love for artificial intelligence. Every time I questioned myself, I reminded myself where I started and how far I had come in such a short amount of time.

Question: When you feel pressure or doubt in your work, what helps you stay grounded?

Konstantinos: When I feel pressure or self-doubt, I usually take a walk in nature. It helps me clear my mind and think creatively about how I can improve my work. In programming, the work rarely stops when your shift ends; problems in the code follow you throughout the day, and overcoming them requires creativity. Walking helps me reset and return with better ideas.

Question: How do you deal with comparing yourself to others in your field?

Konstantinos: Even though I’m competitive by nature, I constantly try to learn from others in my field. I don’t like showing off; I prefer listening. I know I can become great at what I do, but that doesn’t happen overnight. Comparison can be healthy, as long as it pushes you to grow rather than discourages you.

Question: What would you say to someone who feels like they are not good enough to pursue the path they want?

Konstantinos: I started programming without a university degree and with an entirely different background. Patience and persistence truly are the keys to success; it might sound cliché, but they were precisely what helped me. In less than six months, with long hours of focused work, consistency, and determination, I managed to get hired for my dream job simply because I believed in myself and wanted it badly enough.

Yinjian Huang: Product Designer (AI, SaaS), 5 Years Of Experience

Background: Yinjian works in product design across AI, SaaS, and B2B products. Her work focuses on building early-stage products, shaping user experience, and working closely with engineering and product teams on AI-driven features.

Question: Looking back, what is one decision you made that you think others in your field could learn from?

Yinjian: Keep learning across disciplines: design, PM, AI, and engineering. The broader your fluency, the better you can design and reason holistically. Cross‑functional knowledge compounds and unlocks better product judgment.

Question: What do you wish you had known about handling stress, workload, or expectations earlier in your career?

Yinjian: Communicate early if the workload is too heavy or a deadline is at risk. Flag constraints, renegotiate scope, and make trade‑offs explicit. Early clarity beats late surprises.

Question: How do you evaluate whether a new opportunity or challenge is worth taking on?

Yinjian: I evaluate opportunities on three axes: the learning delta (skills I’ll gain), the people I’ll work with, and alignment with my interests.

Question: What advice would you give to someone who wants to grow in your field but feels stuck or unsure of where to start?

Yinjian: Growth can feel overwhelming at first because there’s so much to learn. Build a simple roadmap: start by making your craft solid, then expand adjacent skills. Find the best resources, practice relentlessly, and seek feedback on tight cycles. Momentum comes from small, consistent wins.

The Bottom Line

This whole piece is just a reminder that it’s fine to question where you are and want something different. Everyone hits that moment when things stop feeling exciting, and you start wondering what’s next. It doesn’t mean you’ve failed. It usually means you’re growing.

I wrote this because I’ve been in that space too, still figuring out what direction makes the most sense for me. So if you’re feeling stuck or unsure, I hope this gave you something useful. You don’t need to have everything sorted out right now. Just keep learning, stay curious, and take one small step at a time.

𝗜𝗻𝘁𝗿𝗼𝗱𝘂𝗰𝘁𝗶𝗼𝗻 𝘁𝗼 𝗗𝗲𝘃.𝘁𝗼 𝗔𝗣𝗜
Have you ever wanted to automate your blogging workflow, fetch your articles, or interact with the dev.to platform programmatically? The dev.to API makes all of this possible! In this article, I’ll walk you through the basics of using the dev.to API, from authentication to making your first requests, and even posting an article. Whether you’re a beginner or an experienced developer, you’ll find practical tips and code examples to get started.
𝗪𝗵𝗮𝘁 𝗶𝘀 𝘁𝗵𝗲 𝗱𝗲𝘃.𝘁𝗼 𝗔𝗣𝗜?
The dev.to API is a RESTful interface that allows developers to interact with the dev.to platform. You can use it to fetch articles, create new posts, update existing ones, manage comments, and more. This opens up a world of possibilities for automation, integration, and custom tooling.
𝗚𝗲𝘁𝘁𝗶𝗻𝗴 𝗦𝘁𝗮𝗿𝘁𝗲𝗱: 𝗔𝘂𝘁𝗵𝗲𝗻𝘁𝗶𝗰𝗮𝘁𝗶𝗼𝗻
To use the dev.to API, you’ll need an API key. Here’s how to get one:

• Log in to your dev.to account.
• Go to S̲e̲t̲t̲i̲n̲g̲s̲ &g̲t̲; A̲c̲c̲o̲u̲n̲t̲.
• Scroll down to the “DEV API Keys” section.
• Generate a new key and copy it somewhere safe. Keep your API key private! It gives access to your account and should not be shared publicly. 𝗠𝗮𝗸𝗶𝗻𝗴 𝗬𝗼𝘂𝗿 𝗙𝗶𝗿𝘀𝘁 𝗔𝗣𝗜 𝗥𝗲𝗾𝘂𝗲𝘀𝘁 The dev.to API is based on REST principles and uses JSON for data exchange. You can use tools like 𝗰𝘂𝗿𝗹, 𝗣𝗼𝘀𝘁𝗺𝗮𝗻, or any programming language that supports HTTP requests. Here’s a simple example using 𝗰𝘂𝗿𝗹 to fetch your published articles: 𝗘𝘅𝗮𝗺𝗽𝗹𝗲: 𝗙𝗲𝘁𝗰𝗵𝗶𝗻𝗴 𝗬𝗼𝘂𝗿 𝗔𝗿𝘁𝗶𝗰𝗹𝗲𝘀 curl -H "api-key: YOUR_API_KEY" https://dev.to/api/articles/me This will return a JSON array of your articles. Replace YOUR_API_KEY with the key you generated earlier. 𝗣𝗼𝘀𝘁𝗶𝗻𝗴 𝗮𝗻 𝗔𝗿𝘁𝗶𝗰𝗹𝗲 𝘃𝗶𝗮 𝘁𝗵𝗲 𝗔𝗣𝗜 One of the most powerful features is the ability to create new articles programmatically. Here’s how you can do it using 𝗰𝘂𝗿𝗹: curl -X POST "https://dev.to/api/articles" \ -H "Content-Type: application/json" \ -H "api-key: YOUR_API_KEY" \ -d '{ "article": { "title": "My First API Post", "published": true, "body_markdown": "Hello, world! This is my first post via the dev.to API.", "tags": ["api", "devto", "tutorial"] } }' This request will create and publish a new article on your dev.to profile. You can set published to false if you want to save it as a draft. 𝗢𝘁𝗵𝗲𝗿 𝗨𝘀𝗲𝗳𝘂𝗹 𝗘𝗻𝗱𝗽𝗼𝗶𝗻𝘁𝘀- 𝗚𝗲𝘁 𝗮 𝘀𝗶𝗻𝗴𝗹𝗲 𝗮𝗿𝘁𝗶𝗰𝗹𝗲: GET /api/articles/{id}
• 𝗨𝗽𝗱𝗮𝘁𝗲 𝗮𝗻 𝗮𝗿𝘁𝗶𝗰𝗹𝗲: PUT /api/articles/{id}
• 𝗗𝗲𝗹𝗲𝘁𝗲 𝗮𝗻 𝗮𝗿𝘁𝗶𝗰𝗹𝗲: DELETE /api/articles/{id}
• 𝗟𝗶𝘀𝘁 𝗰𝗼𝗺𝗺𝗲𝗻𝘁𝘀: GET /api/comments?a_id={article_id}

Check the o̲f̲f̲i̲c̲i̲a̲l̲ A̲P̲I̲ d̲o̲c̲u̲m̲e̲n̲t̲a̲t̲i̲o̲n̲ for a full list of endpoints and parameters.
𝗧𝗶𝗽𝘀 𝗮𝗻𝗱 𝗕𝗲𝘀𝘁 𝗣𝗿𝗮𝗰𝘁𝗶𝗰𝗲𝘀- Always keep your API key secure. Never commit it to public repositories.

• Respect the API rate limits to avoid being blocked.
• Use descriptive titles and tags when posting articles via the API.
• Test your requests with 𝗽𝘂𝗯𝗹𝗶𝘀𝗵𝗲𝗱: 𝗳𝗮𝗹𝘀𝗲 to avoid accidental public posts.

𝗦𝗮𝗺𝗽𝗹𝗲 𝗣𝘆𝘁𝗵𝗼𝗻 𝗦𝗰𝗿𝗶𝗽𝘁
Here’s a quick example using Python and the requests library to fetch your articles:
import requests
api_key = "YOUR_API_KEY" headers = {"api-key": api_key} response = requests.get("h̲t̲t̲p̲s̲://d̲e̲v̲.t̲o̲/a̲p̲i̲/a̲r̲t̲i̲c̲l̲e̲s̲/m̲e̲", headers=headers)
if response.status_code == 200: articles = response.json() for article in articles: print(article["title"]) else: print("Error:", response.status_code)

chapterchase

The narrative from the AI labs is dazzling: build AGI, unlock astonishing productivity, and watch GDP surge. It’s a compelling story, especially if you’re the one building or investing in the new thought machines. But it skips the part that makes an economy an economy: circulation.

An economy is not simply production. It is production matched to demand, and demand requires broadly distributed purchasing power. When we forget that, we rediscover an old truth the hard way: You can’t build a prosperous society that leaves most people on the sidelines.

In The Marriage of Heaven and Hell, the visionary poet and painter William Blake (writing during the first Industrial Revolution) put the circulatory logic perfectly: “The Prolific would cease to be prolific unless the Devourer as a sea received the excess of his delights.” In other words: Output has to be consumed. The system has to flow.

Today, many AGI narratives assume that the “prolific” can keep producing and the broad mass of customers (“the devourer”) somehow continue to buy, even as more and more human labor is displaced and labor income and bargaining power collapses. That’s not a future of abundance. It’s a recipe for a kind of congestive heart failure for the economy: Profits and capabilities accumulate in what should be the circulatory pump, while the rest of the body is starved.

So if we want an AI economy that makes society richer, we need to ask not just “How smart will the models get?” and “How rich will AI developers, their investors, and their immediate customers get?” but “How will the value circulate in the real economy of goods and services?” Not “What can we automate?” but “What new infrastructure and institutions are needed to turn capability into widely shared prosperity?”

Two versions of the future are often discussed as if they are separate. They’re not.

The Discovery Economy: Capability Is Not GDP

I’m excited by the discovery potential of AI. It may help us solve problems that have defied us for decades: energy abundance, new materials, cures for diseases. As Nick Hanauer put it so well, “Prosperity is the accumulation of solutions to human problems.” That AI can grow the store of solutions to human problems is a wonderful dream, and it should be our goal to make it come true.

But discovery alone is not the same thing as economic value, and it certainly isn’t the same thing as widely shared prosperity. Between discovery and economic value lies a long, failure-prone pipeline: productization, validation, regulation, manufacturing, distribution, training, and maintenance. The valley of death is not a metaphor; it is a bureaucratic, technical, and financial landscape where many promising advances go to die. And from that valley of death, the path follows either an ascent to the broad uplands of shared prosperity, or a shortcut to a dead end peak of wealth concentration.

If AI accelerates discovery but doesn’t accelerate diffusion, we get headlines and paper wealth, but broad-based growth takes much longer to arrive. We get a taller peak, not a wider plateau.

The distribution question begins with choke points. Who owns the discovery engines? Who controls access to compute, data, and the models themselves? Who captures the IP? Who has the channels to bring new capabilities to market? To what extent do incumbents and the moats they have built restrict innovation? Do government regulatory processes also speed up, or do they keep AI adoption at a glacial pace? Do those at the choke points use their market shaping power wisely? If those choke points are tight, the discovery economy becomes a kind of discovery feudalism: The breakthroughs happen, but the spillovers are limited, adoption is slow, and the returns concentrate.

If, on the other hand, the tools and standards of diffusion are broadly available, if interoperability is real, if licensing is designed for many routes to market, if regulatory processes can also be sped up with AI, then the discovery economy can become what we want it to be: a generalized engine of progress. There’s a huge amount of work to be done here.

Many of the questions are economic. If discovery becomes cheap, does the rest of the pipeline get cheaper, or does it get more expensive to compensate for other lost revenue? The happy dream is that a cancer vaccine becomes available at the marginal cost of production. The unhappy reality may be that the drug manufacturers conclude “We have to price this high to make up for our losses from the existing drugs that people no longer need to buy.” Even in an age of cheap discovery, it is possible that some vaccines will still cost millions of dollars per dose and only be available to people who can afford them.

The Labor Replacement Economy: Demand Is the Constraint

The other story is labor replacement. We are told that AI will substitute for a great deal of intellectual work, much as machines replaced animal labor and much of human manual labor. Businesses become more efficient. Margins rise. Output increases. Prices fall and spending power increases for those who are still employed.

But who are the customers when a large number of humans are suddenly no longer gainfully employed?

This is not a rhetorical question. It is the central macroeconomic constraint that much of Silicon Valley prefers not to model. You can’t replace wages with cheap inference and expect the consumer economy to hum along unchanged. If the wage share falls fast enough, the economy may become less stable. Social conflict rises. Politics turns punitive. Investment in long-term complements collapses. And the whole system starts behaving like a fragile rent-extraction machine rather than a durable engine of prosperity.

In a 2012 Harvard Business Review article, Michael Schrage asked a powerful strategic question: “Who do you want your customers to become?” As he put it, the answer to that question is the true foundation of great companies. “Successful companies have a ‘vision of the customer future’ that matters every bit as much as their vision of their products.”

In the early days of mass production, Henry Ford reportedly understood that if you want mass markets, you need mass purchasing power. He paid higher wages and reduced working hours, helping to invent what we now call the weekend, and with it, the leisure economy. The productivity dividend was distributed in ways that created new customers.

Ford’s innovation had consequences beyond the factory gate. Mass adoption of cars required a vast extension of infrastructure: roads, traffic rules, hotels, parking, gas stations, repair shops, and the entire social reorganization of distance. The technology mattered, but the complements made it an economy.

Steven Johnson tells a related story in his book Wonderland. The preindustrial European desire for Indian calico and chintz helped catalyze modern shopping environments and global trade networks. But there’s even more to that story. When it became cheaper to make cloth, fashion, taste, and the democratization of status display became a larger part of the economy. The point is not “consumerism is good.” The point is that economies grow because desires and capabilities change as the result of innovations, infrastructure, and institutions that allow the benefits to spread. New forms of production require new systems of distribution, experience, and exchange.

AI is at that inflection point now. We may be building the engines of extraordinary productivity, but we are not yet building the social machinery that will make that productivity broadly usable and broadly beneficial. We are just hoping that they somehow evolve.

This failure of insight and imagination is the Achilles’ heel of today’s AI giants. They imagine themselves as contestants in a race to be the next dominant platform, with the majority of the benefits going to whoever has the smartest model, the most users, and the most developers.  This is not unlike the vision of Marc Andreessen’s Netscape in the early days of the web. Netscape sought to replace Microsoft Windows as the platform for users and developers, using the internet moment to become the next monopoly gatekeeper. Instead, victory went to those who embraced the web’s architecture of participation.

Now, it is true that 30 years later, we are in a world where companies such as Google, Apple, Amazon, and Meta have indeed become gatekeepers, extracting huge economic rents via their control over human attention. But it didn’t start that way. Amazon and Google in particular rose to prominence because they solved the circulation problem. Amazon’s flywheel, in which more users draw in more suppliers with more and cheaper products, which in turn brings in more users, in a virtuous circle, is a great example of an economic circulation strategy. Not only did Amazon drive enormous consumer value, they created a whole new set of suppliers.

So too, Google’s original search engine strategy was also deeply rooted in the circulation of value. As Larry Page put it in 2004, “The portal strategy tries to own all of the information….We want to get you out of Google and to the right place as fast as possible.” The company’s algorithms for both search and ad relevance were a real advance in market coordination and shared value creation. Economists like Hal Varian were brought in to design advertising models that were better not only for Google but for its customers. Google grew along with the web economy it helped to create, not at its expense. Yes, that changed over time, but let’s not forget how important Google’s support for a circulatory economy was to its initial success.

Google also provides a really good example of mechanism design to solve problems with rights holders that have economic lessons for today. When music companies sent takedown notices to YouTube for user-generated content that made unauthorized use of their IP, YouTube instead asked, “How about we help you monetize it instead?” In the process it created a new market.

The extent to which Amazon and Google seem to have forgotten these lessons is a sign of their decline, not something to be emulated. It provides an opportunity for those (including Google and Amazon, if they recommit to their roots!) who are building the next generation of technology platforms. Build a flywheel, enable a circulatory economy. AI should not be enshittified from the beginning, prioritizing value capture over broadly based value creation.

Decentralized Architectures Create Value; Centralization Captures It

An important lesson from the internet technology revolution of the 1990s and early 2000s is that decentralized architectures are more innovative and more competitive than those that are centralized. Decentralization creates value; centralization captures it. The PC decentralized the computer industry, ending IBM’s chokehold on competition during the mainframe era. The new software industry exploded. Over the next few decades, as it became dominant, Microsoft recentralized the industry by monopolizing operating systems and office applications in the way that IBM had monopolized computer hardware. The personal computer software  industry began to stagnate, until open source software and the open protocols of the internet undermined Microsoft’s centralized control over the industry and ushered in a new era of innovation.

The tragedy began again, as those who had once flourished as internet innovators in turn began to prioritize control, raising moats and extracting rents rather than continuing to innovate, leading to today’s internet oligopoly. This, of course, is what allowed the current AI revolution to happen as it did. Google invented the transformer architecture, and then published it freely, but did not itself fully explore the possibilities because it was protecting an existing business model. So it was left to OpenAI to invent the future.

However, the AI revolution has a significant difference from the early internet. The U.S.’s current set up of large, closed models, enormous data centres for model training, and a highly concentrated cloud market has echoes of central planning, in which a small cadre of deep pocketed investors choose the winners at the outset rather than discovering them through a period of intense market competition and finding product-market fit (which involves finding products and services that users not only want but are willing to pay for at less than the cost of production!).

Market competition is important to ensuring that the economy is not reliant on a handful of firms reinvesting their profits into production. When this becomes the case, circulation can get cut off. Profits stop being reinvested and instead become hoarded, trapped within the sphere of financial circulation, from dividends to share buybacks to more dividends and less and less to investment in fixed or human capital.

If we are to realize the full potential of AI to reinvigorate and reinvent the economy, we need to embrace decentralized architectures. This might involve the triumph of lower-cost open weight models that commoditize and decentralize inference, and it also certainly entails protocols and technical infrastructure that can reduce the inherent concentrating tendencies of economies of scale and other technological moats that make concentration a more efficient mode of production.

Centralization is an advantage in a mature economy; it is a disadvantage when you are trying to invent the future. Premature centralization is a mistake.

A Manifesto for a Circulatory AI Economy

If AI labs wish to be architects of a prosperous future, they must work as hard on inventing the new economy’s circulatory system as they do on improving model capabilities. They need to measure success by diffusion, not just capability. They have to treat the labor transition as a core problem to be solved, not just studied. They have to be willing to win in the marketplace, not through artificial moats. That means committing to open interfaces, portability, and interoperability. General-purpose capabilities should not become a private toll road.

Companies adopting AI face their own challenges. Simply using AI to slash costs and turbocharge profits is a kind of failure. The productivity dividend should show up for employees not as a pink slip but as some combination of higher pay, reduced hours, profit-sharing, and investment in retraining. They must use the opportunity to reinvent themselves by creating new kinds of value that people will be eager to pay for, not just trying to preserve what they have.

Governments and society as a whole need to invest in the complements that will shape the new AI economy. Diffusion will be limited by the fragility of our energy grid, by bottlenecks in the supply of rare earths, but also by sclerotic approval processes for new construction or the approval of new innovations.

Governments must also develop scenarios for a future in which taxes on labor might provide a much smaller part of their income. Solutions are not obvious, and transitions will be hard, but if we face a future where capital appreciation is abundant and labor income is scarce, perhaps it’s time to consider reducing taxes on labor and increasing those on capital gains.

Over the next few months, we intend to convene a series of conversations and to publish a series of more detailed action plans in each of these areas. Let me know if you think you have ideas to contribute.

The Choice

We can build an AI economy that concentrates value, hollows out demand, and forces society into a reactive cycle of backlash and repair. Or we can build an AI economy that circulates, where discoveries diffuse, where productivity dividends translate into purchasing power and time, and where the complements are built fast enough that society becomes broadly more capable.

AI labs like to say they are building intelligence. They are making good progress. But if they want to build prosperity, they also need to discover the flywheel for the AI economy.

The prolific needs the devourer. Not as a villain, not as an obstacle, but as the sea that receives the excess, and returns it, transformed, as the next wave of demand, innovation, and shared flourishing.

When a performance review arrives, some product managers find themselves struggling to recall their accomplishments. They haven’t touched their “wins” document for months.

Because of this, they end up sitting with their boss and sharing vague summaries of what they’ve achieved. The lack of strong outcomes leads to underreporting their impact and losing out on promotions or raises.

Forgetting your accomplishments isn’t a memory problem. It’s a workflow gap. Keep reading to learn strategic tips to stop forgetting your wins and get the recognition you deserve at work.

Practical systems to help you remember your wins

Remembering your wins doesn’t automatically happen. The best way to ensure that it does is to build practical systems into your day to day work so that you don’t find yourself scratching your head come the end of year.

To help you you get started, this section outlines five easy approaches:

 

 

1. Develop repeatable workflow integrations

Every PM needs a way to track their accomplishments. You need to create a documentation process. The key is to create a documentation process that’s repeatable and easy to execute.

Choose a time interval

First, you’ll need to figure out a time interval that works for you. Aligning your self-reflections with sprint retrospectives is a good way to capture your personal wins. Some product managers prefer writing a daily log of their accomplishments or creating weekly status updates. Others find monthly or quarterly reports more achievable.

Create reminders

The second step is to set up reminders. Beyond adding it to your to-do list, you could put a recurring time block in your calendar. Even if it’s only for five minutes, the reminder can influence you to write out your accomplishments.

Another option is to use a Slack or Microsoft Teams bot. Both platforms let you set up a reminder and choose a default time, like every Friday at noon. You could also use an app like GeekBot to run a personal retrospective.

Pick a documentation tool

The next step is to use tools and formats that you’re comfortable using to track your progress. Avoid physical journals and use digital records. They are easier for keyword search, sharing, and exporting for reviews and job interviews.

Whether you create a Trello board or design a Notion page, choose something that you like to use. You can also create a tag system to make searches easier in the future. Some examples include:

• Milestone
• Praise
• Metrics
• Leadership
• Stakeholder communication

2. Keep copies of status updates and stakeholder reports

Product managers send progress reports to stakeholders on a routine basis. Whether it’s weekly or monthly, stakeholder updates are valuable for tracking your wins.

Your stakeholder reports contain an “activity summary” section that highlights the milestones reached and other team accomplishments. Keeping track of this section can help you realize your achievements over a period of time.

Here are a couple of ways to repurpose stakeholder reports for your use:

• Copy and paste the Activity Summary section into a “wins” document. You can keep this in a Google Doc or Notion page for your future performance reviews. You may want to add detailed notes about what happened
• If you send the progress report as an email, CC yourself and send a copy to a designated folder

3. Gather positive feedback

Collecting feedback from colleagues and stakeholders can further enhance your “wins” document. It helps provide diverse perspectives and validates your achievements. Here are a few places to look for additional comments about your work’s impact:

• Calendar — Your calendar is filled with random tasks, meetings, and other important time blocks that can trigger memories of what you’ve accomplished
• Slack or Teams channel for team wins — If your organization has a Slack channel for team wins, check if anyone has given you a shout-out and include a screenshot of it in your notes
• Slack, Teams, and email messages — Search all messages for keywords like “great work,” “thank you,” or “launched.” You can find small and meaningful actions that resulted in a positive ripple effect
• Closed tickets — Look at the closed tickets on Jira or Linear to get a list of shipped work

Another option could be sending out an anonymous survey about your performance. In her Leader Spotlight interview, Sandy Huang, VP of PM at GoodRx, points out: That’s interesting when you get anonymous feedback — people can be very transparent. We all should be self-aware, but people may see things that you just don’t even consider yourself. That was enlightening to me, and I thought, “Okay, well, that’s great. How can I do more of that?”

4. Create an achievements template

An achievements template can help you document your wins and progress with minimal effort. It’s structured for easy, regular use. Here’s an example of what this could look like:

• Date: (Enter date)
• Key projects: (List the main projects that you worked on)
• Tags: (If using a tagging system, add the relevant tags)
• Wins and accomplishments: (List what you achieved or shipped and briefly describe them)
• Feedback and praise: (Share any positive feedback or recognition that you received from colleagues or stakeholders)
• Impact and results: (Document the quantitative and qualitative results. Pair KPIs with the context of why it matters. What was the result or effect of your work?)
• Reflections: (Write what you learned this week, challenges you faced, or any other important notes that you want to remember)

Remember to keep it simple. If it turns into an overwhelming task, you won’t record your accomplishments on a routine basis.

Adjust the template to fit your needs. Make it shorter for quicker check-ins, or add questions to reflect on your performance.

Navya Rehani Gupta, Chief Product Officer at Peek, discusses that she has a personal roadmap and does her own retrospectives. She self-reflects on questions like:

• How can I further maximize my impact?
• What are the root causes of recent lowlights?
• What are some of the activities that I’m doing on autopilot that I need to take a step back from and may need to adjust?

“I’m not thinking about what went wrong, but taking a step back and thinking about what actually caused this issue that’s impacting me and my team,” said Gupta.

For your next self-retrospective, you can review the last retro’s challenges and see if you addressed them. Noting this can help you find your wins.

5. Turn raw notes into review gold

When review season comes around, you may end up with a large and messy document. Preparing for your review means that you have to turn your achievements log into clear impact stories.

There are behavioral interview frameworks that can help get your point across. Here are a few to consider using when reviewing your achievements:

• STAR (Situation, task, action, result) — Best for demonstrating your thought process and decision-making
• SAR (Situation, action, result) — Best for giving streamlined and straightforward answers
• CAR (Challenge, action, result) — Best for highlighting problem-solving and managing obstacles
• PAR (Problem, action, result) — Best for quick answers on how you solved a specific problem
• SOAR (Situation, obstacles, action, result) — Best for showcasing skills like resilience, critical thinking, and leadership

If you’re short on time, you can use AI to summarize your achievements. You can use tools like ChatGPT or Copilot to synthesize your notes. Here are a few prompt ideas that may help:

• Make a list of all projects and features shipped
• Summarize what was shipped, KPIs, highlights, and lessons
• Highlight the key wins and the impact they had on the organization

Key takeaways

It’s easier to track accomplishments when you make it a habit. You might get tempted to skip it, but you’ll thank yourself when your performance review comes around. You’ll have data-driven insights about how you’ve contributed to the organization’s success.

Getting the promotion or pay raise that you want all starts with visibility. Documenting your achievements will help propel your career further. Good luck!

Featured image source: IconScout

The post How to stop forgetting your wins and actually get promoted appeared first on LogRocket Blog.

If I were to ask you what React’s biggest source of bugs is, what would you say? You’d probably say what everyone says: useEffect. It’s the Hook with the obtuse name that allows you to do async work. That’s great, but it can cause a lot of issues. In particular, infinite loops, where we keep fetching and fetching from the server.

Now, credit where credit is due: the React team saw this issue, and they have come up with a new Hook called useEffectEvent. And I get that it’s a mouthful of a name, but it’s also a lifesaver when it comes to stabilizing your React app.

Let me walk you through a very common problem. We’ll start with the Hooks we have today, so that we can see the issue, and then I’ll show you how useEffectEvent fixes it.

Why this actually matters: Cloudflare’s errant useEffect

Cloudflare is one of the biggest deployment providers on the planet, and they have an excellent engineering team. But even they can make mistakes when it comes to useEffect. Recently, they distributed denial of service’d (DDOS’ed) their own dashboard when they errantly put an object into a dependency array. That object changed its identity with every re-render, causing an infinite loop that took down their whole dashboard.

It’s an embarrassing mistake that’s all too easy to make. This is why enhancements like the React compiler and new Hooks like useEffectEvent are so important. In the case of the compiler, they stabilize object references, which helps reduce potential bugs around object identity. And useEffectEvent removes objects from the dependency array entirely!

Setting the scene

Here is a simple component that has an editable user name:

function MyUserInfo() {
  const [userName, setUserName] = useState("Bob");

  return (
    <div>
      <input
        value={userName}
        onChange={(evt) => setUserName(evt.target.value)}
      />
    </div>
  );
}

So far, so good; we can change the user name. Now let’s say that we want to track how long the user has been logged in for, and then display it:

function MyUserInfo() {
  const [userName, setUserName] = useState("Bob");

  useEffect(() => {
    let loggedInTime = 0;
    const interval = setInterval(() => {
      loggedInTime++;
    }, 1000);
    return () => clearInterval(interval);
  }, []);

  return (
    <div>
      <input
        value={userName}
        onChange={(evt) => setUserName(evt.target.value)}
      />
    </div>
  );
}

So we add a useEffect which sets up a timer to track the number of seconds this person has been logged in. (Yeah, I get that it’s not really truly logged in; it’s demo code.)

Now this code actually works, and there are no bugs. It only runs once, on component mount, because of the empty dependency array. And it cleans up after itself by returning a cleanup function that clears the interval, which kills the timer.

It only runs once, on component mount, because of the empty dependency array. And it cleans up after itself by returning a cleanup function that clears the interval, which kills the timer.

But, in terms of functionality, it’s not actually working because we don’t display that number anywhere. To fix that, let’s add a loginMessage string that we can use to show that number:

function MyUserInfo() {
  const [userName, setUserName] = useState("Bob");
  const [loginMessage, setLoginMessage] = useState("");

  useEffect(() => {
    let loggedInTime = 0;
    const interval = setInterval(() => {
      loggedInTime++;
      setLoginMessage(
        `${userName} has been logged in for ${loggedInTime} seconds`
      );
    }, 1000);
    return () => clearInterval(interval);
  }, []);

  return (
    <div>
      <div>{loginMessage}</div>
      <input
        value={userName}
        onChange={(evt) => setUserName(evt.target.value)}
      />
    </div>
  );
}

Now, on the face of it, this looks like it should work. And in fact, it kinda does. Right off the bat, it says “Bob has been logged in for 1 second”. And then it dutifully clicks forward every second. Great success!

The stale closure problem

Whoops, actually, there is a bug. Because the function that we have sent to useEffect can “stale”:

What happens if I change the user name? Well, sure, the input changes, but the login message keeps saying the user name is “Bob”. But it’s not; we’ve changed it.

So that function that we sent to useEffect has created a “closure” which has captured the value of userName at its current value at that time (“Bob”). And it isn’t going to change, ever. And because it’s now out of sync with the real value, we would consider it “stale”. That means we have a “stale closure”.

Good news, though: React has a fix for that (it’s not useEffectEvent, bear with me). We can just add userName to the dependency array:

useEffect(() => {
  let loggedInTime = 0;
  const interval = setInterval(() => {
    loggedInTime++;
    setLoginMessage(
      `${userName} has been logged in for ${loggedInTime} seconds`
    );
  }, 1000);
  return () => clearInterval(interval);
}, [userName]);

Tada! Problem solved. Now, when we edit the userName, the login message changes! Awesome. Oh, wait. What? The login time goes back to 1 second again, each time we make a change:

Ahhh, so, every time we are creating a new closure with the new userName value we are killing the old timer (that’s good). But we are also creating a new loggedInTime and starting it at zero again. That’s decidedly not good.

Now I get that one easy fix for this would just be to track loggedInTime as state and just format the string in JSX. Fine. But, let’s just say we can’t do that.

useRef to the rescue

How can we fix this? Well, before useEffectEvent we probably would use a ref for this:

const nameRef = useRef(userName);
nameRef.current = userName;

useEffect(() => {
  let loggedInTime = 0;
  const interval = setInterval(() => {
    loggedInTime++;
    setLoginMessage(
      `${nameRef.current} has been logged in for ${loggedInTime} seconds`
    );
  }, 1000);
  return () => clearInterval(interval);
}, []);

Here we have done a few things. First, we’ve created a reference where we have stored the current value of userName, and we update the current value on every render. It’s ok to set the current value of a ref during a render because React doesn’t monitor refs like it does state.

Next, we use nameRef.current in our template string instead of userName, so we are always getting the current value of userName because it’s updated on each render. Finally, we removed the userName from the dependency array, and that got rid of the reset bug:

And now it actually works. No caveats! Except that, it’s kinda clunky, and that’s where useEffectEvent comes in.

useEffectEvent is way better

Check out this version:

const getName = useEffectEvent(() => userName);

useEffect(() => {
  let loggedInTime = 0;
  const interval = setInterval(() => {
    loggedInTime++;
    setLoginMessage(
      `${getName()} has been logged in for ${loggedInTime} seconds`
    );
  }, 1000);
  return () => clearInterval(interval);
}, []);

We use the new useEffectEvent Hook to create a getter function that returns the current value of userName. And, it can be called within the useEffect, and it will never stale. It’s really clean. Much cleaner and clearer than the useRef version.

But, it actually gets a little better than that, because it allows us to think about useEffect more generally. I mean, come to think of it, we kind of have a more generic “timer” with that useEffect:

const onTick = useEffectEvent((tick: number) =>
  setLoginMessage(`${userName} has been logged in for ${tick} seconds`)
);

useEffect(() => {
  let ticks = 0;
  const interval = setInterval(() => onTick(++ticks), 1000);
  return () => clearInterval(interval);
}, []);

Now we’ve moved all the state stuff into the useEffectEvent. And see how much cleaner our useEffect has gotten? The useEffect is just handling the timer. And the onTick is handling all the logic of what to do with that timer.

useEffectEvent is a game changer

Better still, the useEffect has no dependencies on state. And it’s state dependencies where useEffect gets into trouble (as we’ve seen). Bad dependency arrays that depend on the wrong state can cause stale closure issues, invalid resets, or even infinite loops. And useEffectEvent allows us to remove state from the dependency array. And that helps us write better useEffects.

We can even make it more generic and turn it into a custom Hook:

function useInterval(onTick: (tick: number) => void) {
  const onTickEvent = useEffectEvent(onTick);
  useEffect(() => {
    let ticks = 0;
    const interval = setInterval(() => onTickEvent(++ticks), 1000);
    return () => clearInterval(interval);
  }, []);
}

Now we have a full useInterval implementation that is super clean and bug-free.

A little challenge

If you want a fun little challenge, how would you implement a version where the number of milliseconds (currently 1000) was adjustable?:

function useInterval(onTick: (tick: number) => void, timeout: number = 1000) {
  // ????
}

So, let me show you what I came up with:

function useInterval(onTick: (tick: number) => void, timeout: number = 1000) {
  const onTickEvent = useEffectEvent(onTick);
  useEffect(() => {
    let ticks = 0;
    const interval = setInterval(() => onTickEvent(++ticks), timeout);
    return () => clearInterval(interval);
  }, [timeout]);
}

Oh, wait, that’s wrong, that’s the stale closure problem again since the counter restarts at zero every time. Shoot. Oh, right, I can use another useEffectEvent:

function useInterval(onTick: (tick: number) => void, timeout: number = 1000) {
  const onTickEvent = useEffectEvent(onTick);
  const getTimeout = useEffectEvent(() => timeout);

  useEffect(() => {
    let ticks = 0;
    let mounted = true;
    function onTick() {
      if (mounted) {
        onTickEvent(++ticks);
        setTimeout(onTick, getTimeout());
      }
    }
    setTimeout(onTick, getTimeout());
    return () => {
      mounted = false;
    };
  }, []);
}

The approach I took this time is a little different. Instead of setInterval I’m using setTimeout and adjusting the timeout on each iteration. Let me know if you can golf this down at all.

In the meantime, I hope you can see how this new Hook with a crazy name seems like a small enhancement, but is actually a huge win for React. The React team has acknowledged that there is an issue with useEffect code running amok. They clearly identified the problem; useEffects connected to state. And they have come up with an elegant solution to decouple useEffects from state.

Conclusion: React with seatbelts

It’s great to see the React team taking on the issues that cause so many problems in our React apps. With new tools like the compiler and enhancements like useEffectEvent we are able to write far more reliable and resilient React code. React sure ain’t dead, and it’s getting better with each release!

You should definitely check out React 19.2 to try out useEffectEvent for yourself to see how much cleaner and safer your useEffect Hooks can be by using useEffectEvent.

The post React has finally solved its biggest problem: The joys of <code>useEffectEvent</code> appeared first on LogRocket Blog.

Learn how to convert Markdown to PDF in .NET C# using Text Control's ServerTextControl component. This guide covers setup, conversion process, and customization options for generating high-quality PDF documents from Markdown content.