What Web Development Is Actually Like

Walk me through last Tuesday. What happened?

So I get into the office around 8:45. We're hybrid, three days in, two remote. Tuesday is an in-office day. I open Slack and there are already 30-something messages in the product channel. Chloe, our product manager, she joined about three months ago from a consulting firm and she communicates almost entirely in frameworks. Like she'll say "let's align on the problem space" when she means "let's talk about this." She'd posted a revised requirements doc for the loan application flow at 11 PM the night before. I'm reading it and the changes aren't small. She wants to restructure the multi-step form so that borrowers upload their documents before they see the loan terms instead of after. Which, from a user flow perspective, flips the whole thing around.

The release was Thursday. As in, 48 hours away. We'd been building toward this release for three weeks. I'd already written and tested the components for the original flow. Amit, our tech lead, the guy who's been at the company since the seed round and knows every line of the codebase, he was on PTO. Visiting his parents in New Jersey. I pinged him on Slack and he replied with "your call, I trust you." Which is either the best or worst thing a tech lead can say when you're staring at a requirements change two days before ship.

What did you do?

I sat at my desk for probably ten minutes just thinking. And this is the part of the job that people don't see. They think coding is typing. It's not. Most of the work is deciding what to do before you type anything. I pulled up the original flow in the staging environment. I pulled up Chloe's revised spec. I opened the React component tree in VS Code and started mapping out what would actually need to change. The form is built with a custom stepper component that Amit wrote. Five steps. Each step is its own component with its own validation logic. Chloe wanted to swap steps 2 and 4, basically. Which sounds simple if you don't know how state management works.

Step 4 had dependencies on data collected in step 2. The loan terms calculation pulls from the borrower's revenue and time-in-business, which get entered in step 2. If you move the document upload to step 2 and push the business info to step 4, the terms calculation breaks because it's trying to read data that hasn't been entered yet. You either refactor the state management so the terms calculate lazily, or you restructure the validation to handle the new order. Neither of those is a two-hour fix. More like a day and a half if nothing goes wrong, which things always do.

So did you ship it or push back?

I called Chloe. Not Slack, not email, I called her. And I said, look, I can do this, but if we change the flow now, we're pushing the release to Monday and we need to re-run QA on the entire form. She asked why it was complicated. I tried to explain the state dependency issue and I could hear her eyes glazing over through the phone. So I switched tactics. I said, "Think of it like a warehouse. You can't put the shipping label on a box before the box is packed. The order of operations matters." She got that immediately. Which makes sense because, you know, that's basically what I learned in six years of logistics before I ever wrote a line of JavaScript.

We compromised. We shipped the original flow on Thursday as planned. I'd build the revised flow as a fast-follow for the next sprint. Chloe was fine with it once she understood the tradeoff. The problem wasn't that she made a bad request. It was that she didn't have the technical context to know what she was asking for. That's not her fault. It's just what happens when product and engineering speak different languages. My job, increasingly, is to be the translator.

You mentioned the warehouse background. How does that show up?

All the time. When I was at the distribution center, I was a logistics coordinator. I managed the flow of product from receiving to shipping for a warehouse that processed about 3,000 orders a day. The job was sequencing. What goes on the truck first? What has to be picked before what? Where's the bottleneck today, and is it the pickers or the packers or the dock? I thought in throughput. Still do.

When I look at a React application, I see a conveyor system. Data comes in from the API, gets processed through components, renders to the screen. When something is slow, my instinct is to find the pinch point. Is the API call taking too long? Is the component re-rendering unnecessarily? Is there too much data flowing through a part of the system that can't handle it? That's exactly how I used to diagnose slowdowns on the warehouse floor. Sprint planning feels like shift scheduling to me. You've got a fixed amount of labor hours, a list of work that needs to get done, and you're fitting puzzle pieces together. The vocabulary is different. The thinking is the same.

Weston, our UX designer, he sits next to me and he draws wireframes on paper before he touches Figma. We get along because we both think about flow. He thinks about how a user moves through a page. I think about how data moves through a system. When those two things align, the product feels right. When they don't, you get a form that's technically functional but makes people feel lost.

Tell me about the standing desk spreadsheet.

OK so this is, I'll admit, kind of ridiculous. It started because my back was killing me after about a year of coding full-time. In the warehouse, I was on my feet all day. Walking, lifting, moving. Then I switched to sitting at a desk for 8 to 10 hours and my lower back just, like, revolted. So I bought a standing desk converter from Amazon for $180. Attempt number one. It wobbled. My monitors bounced when I typed. Scored it a 3.4 out of 10.

Lori, my girlfriend, she's a physical therapist, and she kept telling me my setup was wrong. She'd come into my office and adjust my monitor height and make me stand on this anti-fatigue mat she ordered. She doesn't understand what I do at all, by the way. She once asked if I "make apps" and I said sort of, and she said "cool" and that was the end of that conversation. But she understands ergonomics. So she became my unofficial consultant and I started tracking every desk setup like it was a warehouse efficiency report. Attempt #14 is the current champion. UpLift V2, motorized, 60-inch bamboo top, dual monitor arm, cable tray underneath. Stability score: 9.6. Lori approved the monitor height. Total investment across all 14 attempts is probably $4,200, which my coworkers think is insane, but my back hasn't hurt in eight months.

How's the money in frontend at a startup?

I'm at $118,000 base. That's my third raise since I started at $82,000 four years ago. I also have equity, but I'm honest enough to admit I don't fully understand what my options are worth until there's a liquidity event, and our company is Series C so that could be years away or it could be never. The equity is a number on a spreadsheet and I don't count it as real money. What I count is the $118K.

When I was a logistics coordinator, I topped out at $52,000 after six years. No equity, obviously. The health insurance was worse. The ceiling was visible from day one. My manager had been there 14 years and made $61,000. That was my future if I stayed. When I taught myself React during COVID and got my first dev job, I took a pay cut to $82K because, well, actually that was a raise. And then the trajectory from there has been steep. Four years in and I'm at $118K. If I move to a bigger company, or go senior, I could be at $140K to $160K within two years. That kind of earning curve doesn't exist in warehouse logistics. It just doesn't.

What's the hardest part of the job that people don't see?

Ambiguity. Everything is ambiguous. The requirements are ambiguous because product managers describe what they want in human language and code runs on precision. The timelines are ambiguous because nobody knows how long a feature will take until you're halfway through building it and discover a dependency nobody accounted for. The feedback is ambiguous because when a designer says "it doesn't feel right," you have to figure out what "feel" means in pixels and milliseconds.

In the warehouse, a box is either on the truck or it's not. A shipment is either on time or it's late. There's a clarity to physical work that I genuinely miss sometimes. In web dev, you can build something that works perfectly, passes every test, matches the design exactly, and someone will say "I don't know, can we try it a different way?" And you go back and try it a different way. That's the job. That's most of the job, actually.

What's yours?

How much of the job is managing your own psychology. Nobody tells you this when you're learning to code. They teach you JavaScript. They teach you React. They don't teach you what it feels like to stare at a bug for three hours and make zero progress. The doubt that creeps in. Am I actually good at this? Did I get lucky? Does Amit see through me? Imposter syndrome is this term that gets thrown around a lot, but it doesn't capture the specific flavor of it for career changers. I was a logistics coordinator for six years. I knew I was good at that job. I had evidence. Inventory accuracy, on-time shipment rates, numbers. In web dev, the feedback loop is murkier. Your PR gets approved, but you don't know if it got approved because it was good code or because the reviewer was busy and just clicked the button.

There are days where I close my laptop and I genuinely can't tell if I accomplished anything. Not because I was lazy. Because the thing I worked on, a state management refactor that took me seven hours, is invisible. It doesn't look different. The user will never notice it. My product manager will never see it. But the code is cleaner and the next person who touches it will have an easier time. That's the work. And some days it feels meaningful and some days it feels like I spent eight hours rearranging furniture in a room nobody visits. I don't tell Lori about those days because she'd just look at me and say "so it's like when I do manual therapy on someone's shoulder and they don't feel the difference until next week." And, yeah. She'd be right. But it's still lonely in the moment.

How does a music theory professor end up writing code for an insurance company?

Money. I mean, it's more complicated than that, but if I'm honest, it started with money. I was an adjunct at a small liberal arts college outside Minneapolis. Music theory. I had a master's from the University of Minnesota. I loved teaching. I loved the material. I could stand in front of a room of 18-year-olds and explain counterpoint and voice leading and actually make them care about it. But adjunct pay was $2,800 per course. I taught four courses per semester, no benefits, no office, no guarantee I'd be invited back the next year. That's $22,400 a year before taxes. Dennis, my husband, he's a middle school band director. He works longer hours than I do and he made about $48,000 at the time. We had a mortgage. We were, like, making it work, but barely.

A friend from grad school had gone into QA testing at a tech company and she mentioned they were hiring contractors. No experience required, they'd train you. $22 an hour. I did the math. Even at $22 an hour, 40 hours a week, that was $45,000 a year. Double my adjunct salary. For clicking through software and writing up what was broken. I applied on a Thursday and started the following Monday.

And you went from QA to development?

Over about three years, yeah. QA taught me how to think about software from the user's side. What breaks, where, and why. I was good at it because of music, actually. Music theory is pattern recognition. You learn to hear when something is off. A wrong note in a chord progression feels wrong before you can name why. Testing software was the same thing. I'd click through a workflow and something would feel wrong, the button was in the wrong place, the loading state was missing, the error message didn't match the error. I could feel the dissonance before I could articulate it.

After about a year of QA, I started looking at the code. The developers would fix the bugs I reported and I'd read their pull requests to understand what they'd changed. I started teaching myself Python on nights and weekends. Then JavaScript. Then SQL. The company offered tuition reimbursement, so I took two community college courses in database management. After three years of QA, I applied for a junior developer position on the internal tools team and I got it. That was eight years ago. Now I'm a mid-senior fullstack developer. Same team. The claims processing dashboard I help maintain is used by about 800 adjusters across the company every day.

Tell me about the Wednesday with the search bug.

This was about three weeks ago. I get a message from Ted, my manager. Ted is a people-pleaser. He starts every sentence with "that's a great question" even when you haven't asked a question. He forwards me an email from a claims adjuster named Phil. Phil is somewhere in our Kansas City office. He says the search function on the claims dashboard is returning results from 2019 instead of 2024. He searched for a policyholder name and got claims from five years ago. No recent ones.

This is a problem. 800 adjusters use this search every day. If the search is wrong, adjusters are looking at the wrong claims, making decisions based on outdated data. That's a compliance issue. Ted's email said "when you get a chance" which in Ted's language means "drop everything."

What was causing it?

So the search runs on Elasticsearch. We have about 4.2 million claims records indexed. The search is supposed to return results sorted by most recent first, filtered to active and recent claims unless the adjuster specifically asks for historical ones. I opened the Elasticsearch dashboard and started looking at the index. And this is where it got weird. The index mapping had been changed. The field that stores the claim date had been remapped from a date type to a text type. Which means Elasticsearch was no longer treating it as a date. It was treating it as a string. And when you sort strings, "2019" comes after "2024" because, well, it doesn't, actually. But the sort was broken in a different way. The relevance scoring was off because the field type change messed up the boost weights we'd applied to recent claims.

The question was: who changed the mapping and when? I checked the deployment logs. Three weeks earlier, Bryan, our solutions architect, had run a reindexing job as part of a performance optimization. Bryan is the kind of guy who diagrams things on a whiteboard that nobody else can read. He's brilliant, but he works in his own head and doesn't always communicate the details. The reindexing script he'd written had a configuration file that specified field mappings, and the claim date field had been set to "text" instead of "date." Probably a typo. One word in a YAML file. That one word had been silently corrupting search results for three weeks.

Three weeks? Nobody noticed for three weeks?

That's the terrifying part. The search still returned results. It didn't break in an obvious way. It didn't throw errors. It just quietly returned the wrong results. Adjusters were seeing claims, just not the right ones. Most of them probably thought the system was being slow or that the policyholder didn't have recent claims. Phil was the first person to actually say "these dates are wrong" out loud. Or in an email, anyway.

Roshani, our QA lead, she's been at the company for 19 years and she catches everything. When I told her about it she was genuinely upset. Not at Bryan. At the process. We had no automated test that verified the Elasticsearch field mappings after a reindex. The deployment went through without anyone checking that the output data was still correct. Roshani said, and I'm paraphrasing, that we'd built a system that could fail silently for three weeks and that was worse than a system that crashed. I agree with her. A crash is loud. A silent corruption is a trust problem.

How did you fix it?

Two parts. The immediate fix was re-running the reindex with the correct mapping. That took about four hours because reindexing 4.2 million records isn't instant. I wrote the corrected YAML config myself, had Roshani review it, and we ran it in staging first to verify. Then production. While it was running, I wrote a post-deployment test that queries the index, checks the field types on every mapped field, and fails the deployment if anything doesn't match the expected schema. That test now runs automatically after every deployment. It would have caught this in five seconds.

The second part was the conversation with Bryan. Ted handled it, because Ted handles all the people stuff. I wasn't in the room but I heard it was gentle. Ted's not confrontational. Bryan felt bad. He didn't know the mapping was wrong. The script had worked in his local environment because his local index was small enough that the sort differences weren't visible. On 4.2 million records, the behavior diverged. That's a thing people outside of development don't understand. Code can work perfectly in testing and break in production because the scale is different. The data is different. The real world is messier than your laptop.

You compare debugging to ear training. Can you explain that?

In music theory, ear training is the practice of learning to identify intervals, chords, rhythms, just by hearing them. You listen to a note and you name it. You hear a chord and you know it's a minor seventh before you think about it consciously. It becomes instinct. You train your ear to feel dissonance.

Debugging is the same process. After 11 years of reading code, I can scan a function and something will feel off before I can explain why. The indentation is wrong, or there's a variable that's declared but never used, or the logic branches in a way that leaves an edge case uncovered. I feel it. Like hearing a wrong note. Then I go back and figure out the theory, meaning I trace the logic and find the actual bug. But the initial signal is almost always a feeling. Dennis thinks this is hilarious. He says I left music but music didn't leave me. He's probably right. When I read a well-structured codebase, it has the same satisfaction as reading a well-structured score. Everything is where it should be. The patterns resolve. When it's bad code, it's like listening to a student arrangement where the voice leading is all wrong. You can feel the friction.

How's the money in enterprise dev?

I'm at $112,000 base. No equity because it's not a startup. But the benefits are solid. Health insurance is good, 401k match at 5%, three weeks PTO plus holidays. It's stable money. I've gotten raises every year, usually 3 to 5 percent. When I was an adjunct, I made $22,400. When I started in QA, I made $45,000. First dev role was $68,000. So in 11 years I've gone from $22K to $112K. My college friends who stayed in music, the ones who got tenure-track positions, some of them make $75,000 to $85,000 now. The ones who are still adjuncting make what I made. I try not to think about that too much because it makes me angry, not at them, but at the system that pays people with master's degrees less than what I made clicking through software in my first QA contract.

Do you miss teaching?

Every week. I miss the moment when a student hears a tritone resolve to a major third and their face changes. I miss the beginning of a semester when everything is possible and the syllabus is this beautiful map of where we're going. I miss standing at a piano and playing a chord and asking a room full of people "what do you hear?" Dennis and I still play together at home. He plays trumpet, I play piano. We do it Sunday mornings while the coffee brews and it's the best hour of my week. But teaching music for $2,800 a course with no health insurance and no job security was not a career. It was a hobby that pretended to be a career. Development is a career. I just wish the career I loved could have also been one I could afford.

What's yours?

The emotional weight of maintaining a system that other people depend on. 800 adjusters use the dashboard I help build. When the search is wrong, an adjuster in Kansas City might pull up the wrong claim history and make a decision that affects someone's insurance payout. That's real. That's someone's car accident or house fire or medical bill. I think about Phil sometimes. He noticed the bug. What about the adjusters who didn't notice? How many claims were processed using data from the wrong year? We did an audit after the fix and found 14 claims that were flagged for review because the adjuster may have been looking at outdated information. 14 real people whose claims might have been handled differently.

Nobody talks about this in web development because most web dev content online is about building to-do apps and portfolio sites. It's about the craft of writing code. It's not about the fact that your code touches real people's lives and when you screw up, the consequences aren't a broken button on your personal website. They're a claims adjuster in Kansas City making a decision about someone's house fire with data from five years ago. That weight sits with me. It makes me more careful. It also makes me tired in a way that has nothing to do with how many hours I worked.

Film school to bootcamp to agency dev. Give me the short version.

I was at Tisch for two years. Film production. I loved it. I still love film. But halfway through sophomore year I sat down and did math I should have done before I enrolled. I had $47,000 in student debt from two years. Two more years would put me near $100,000. The median starting salary for a film production graduate is, like, you don't want to know. It's bad. And that's if you get work, which in film means months of nothing between gigs. I was 20 and I could see the math didn't work. So I left.

Moved back in with my mom in Queens for about a year. Worked at a juice bar. Felt terrible about myself, honestly. Then a friend from high school mentioned he'd done Flatiron School and gotten a dev job. The bootcamp was 12 weeks, cost $17,000. I know that sounds like a lot, but relative to NYU tuition it was a rounding error. I applied, got in, and for 12 weeks I basically didn't sleep. JavaScript, React, Ruby on Rails, Git, the whole pipeline. It was the most compressed learning experience of my life. Way harder than film school, and I don't say that lightly. By the end I had a portfolio with three projects that all kind of worked and a resume that was 80% fiction and 20% hope.

How'd you land at the agency?

Applied to maybe 150 jobs. Got responses from about 12. Interviews with 5. Offers from 1. That one was Pablo's agency. Pablo is the founder and CTO. He built the company from his apartment six years ago. Shopify Plus builds for DTC brands. Skincare companies, candle companies, beverage brands, that kind of thing. When I interviewed, he looked at my portfolio, said "this is fine," and then spent 45 minutes asking me about film. He wanted to know what I saw when I looked at a webpage. I told him I saw composition. A hero section is an establishing shot. The call-to-action is where you direct the viewer's eye. White space is pacing. He hired me on the spot. I think the film background is actually why I got the job. Not the bootcamp. The bootcamp got me in the door. The film thing got me the offer.

Tell me about the Thursday with the candle company.

So we're building a site redesign for this premium candle company. They're called, I'll just say the brand starts with an H. Nice candles. Like, $68 for a single candle kind of nice. The project is a $40,000 Shopify Plus build. Custom theme, product pages, the whole thing. I've been working on it for about five weeks alongside Delia, the senior dev who mentors me. Delia has a dry sense of humor and a cat named Semicolon, which tells you everything you need to know about her personality.

Thursday at 2 PM we have a client review call. The founder, Heather, is on the call. Pablo is on. I'm on. Delia's on but she has her camera off, which is Delia's default state. Milo, our backend dev, is technically on but he always has headphones and I think he was half-listening to a podcast. We share the screen. We show the homepage. I'd built this hero section with a slow parallax scroll and a product carousel that I was genuinely proud of. The carousel had this smooth snap behavior with a custom easing curve. I'd spent two days on the animation alone.

Heather looks at the screen for about five seconds. And she says, "I love everything except the homepage."

Ouch.

Pablo muted himself and sent me a Slack message that just said "here we go." Which, if you've worked at an agency for more than a week, you know exactly what that means. It means the next 40 minutes are going to be an exercise in extracting what the client actually wants from what they're saying, because those are usually two different things.

Heather didn't hate the homepage. She hated the hero image. Specifically, she felt the candle in the hero shot was too centered and the negative space on the left made the brand feel "empty." Her word. So we spent 40 minutes discussing the placement of a candle in a photograph. Pablo asked careful questions. "When you say empty, do you mean there's too much space, or that the space doesn't feel intentional?" Heather said "both" and then described a feeling she'd had while looking at a competitor's website. She couldn't name the competitor. She couldn't describe the layout. She just remembered a feeling.

After the call, Pablo and I sat in the office for another 20 minutes. He showed me a website, a completely different brand, and said "I think this is what she means." It was a layout where the hero product was offset to the right with a text block on the left. Asymmetrical. The kind of thing that film school would call a Dutch angle, or at least the layout equivalent of one. I rebuilt the hero that evening. Moved the candle right, added a text overlay left, adjusted the parallax speed. Sent it to Heather the next morning. She responded in four minutes: "This is perfect. This is exactly what I meant." Two days of carousel work, mostly intact. Three hours of hero rework. That's agency life.

How does the film school background show up in your actual code?

Constantly. I think about a webpage the way I'd think about a shot composition. Where does the viewer's eye go first? What's the visual hierarchy? In film, you learn that every frame should lead the eye somewhere intentional. A bright object in a dark scene. A character positioned at a rule-of-thirds intersection. A leading line that draws you deeper into the frame. Web design works the same way, but most developers treat the UI like an afterthought. They build the data layer, they build the logic, and then they slap some Tailwind classes on it and call it done.

I get frustrated by that. Delia teases me about it. I'll spend 30 minutes adjusting the spacing between a headline and a subhead because the rhythm feels off. She'll look at my screen and say "it's two pixels, Kieran." And I'll say "it's the wrong two pixels." She rolls her eyes but she also doesn't override me, because she knows the client will notice even if they can't explain why. Component architecture, to me, is like film editing. Each component is a scene. The way they transition into each other, the pacing, the rhythm of information, that matters as much as whether the props are typed correctly. Milo thinks I'm pretentious about this. He's probably right. But the clients keep saying the sites "feel" different from what other agencies build, and I think that's why.

What's the money situation for a junior agency dev?

I make $72,000. In Brooklyn. So after rent, which is $1,650 for my share of a two-bedroom with my roommate Jenny, and my student loan payment, which is $380 a month for the NYU debt, and the income-based Flatiron repayment, which is about $200 a month, I'm not exactly living large. Jenny's a bartender. She makes more than me on a good weekend, which she reminds me of regularly. Every evening she asks "did you make any websites today?" and every evening I say yes and she says "cool" and pours herself wine.

The agency pays market for a junior in New York, maybe a little below. Pablo is upfront about it. He said when he hired me, "I can't pay FAANG money, but I can teach you more in a year here than you'd learn in three at a big company." Two years in, I think he was right. I've built 11 Shopify stores. I've talked to clients directly. I've learned to translate between what people want and what technology can do. At a big company, I'd be a cog writing unit tests for a component library. Here I'm building entire experiences and learning what clients care about, which is never the code. They care about how the page makes them feel.

The git branch names. How did that start?

It's dumb but I love it. My first week at the agency, Delia told me to name my branches something descriptive. So I made one called feature/homepage-hero and she said "boring, but fine." The next one I named feature/psycho-product-grid and she laughed for the first time since I'd met her. Pablo saw it in the PR list and said "what is this." Delia said "it's a Kieran thing." And it stuck. Now everyone on the team knows that if they see a branch with a horror movie in the name, it's mine. fix/rosemarys-baby-null-check was a real one from last week. There was a null check missing in the cart component that was causing the page to crash when someone removed the last item. Rosemary's Baby felt right because the bug was lurking and nobody saw it coming. Milo submitted a PR last month on a branch called feature/jaws-api-refactor and I almost cried. He's learning.

You said $47,000 in student debt from two years. How does that feel now?

Bad. It feels bad. I don't regret going to Tisch because it gave me the way I see things, and that's genuinely the most valuable skill I have. But $47,000 for two years of something I didn't finish is a weight. I'll be paying it until I'm 36 at the current rate. The Flatiron debt is smaller and I'll have that done in three years. So by the time I'm 29, the bootcamp is paid off. By 36, NYU is paid off. Ten years from now I'll be clean. Which is, like, fine. But it means my twenties are basically the decade of paying for my early twenties. Jenny doesn't have student debt. She went straight to bartending after high school. She owns a car. I take the subway and think about compounding interest.

What's yours?

How personal the client feedback feels when you're junior. I know, intellectually, that when Heather says "I love everything except the homepage" she's not saying she hates me. She's talking about the work. But I built the work. That carousel was mine. The easing curve, the snap points, the way the product images fade in from the edges. I spent two days on it. And she dismissed it in five seconds because the hero image was too centered. She didn't even scroll down to the carousel.

Delia is great about this. After that call she messaged me and said "carousel is still in. She didn't even see it. That's a win." Which is true but also kind of devastating? The thing I was most proud of, the client literally didn't look at. And I'm learning that this is the norm. The stuff you obsess over, the interaction details, the pixel-perfect spacing, the animation curves, clients either don't notice or they attribute it to something vague like "it just feels premium." Which is the goal, I guess. Make something that feels good without anyone knowing why it feels good. It's invisible craft. Like, in film, the best editing is the editing you don't notice. Same thing here. But when you're 26 and you have $47,000 in debt and you spent two days on a carousel that nobody scrolled to, the invisibility stings a little.

Pablo pulled me aside after the Heather call and said something that stuck with me. He said, "The client's job is to feel things. Your job is to interpret what they feel. My job is to make sure they pay us for the interpretation." It's the most honest description of agency work I've ever heard. And it's not cynical, actually. It's just clear. The work serves the client, not your ego. That's hard to internalize when you're young and you want to be noticed for what you built. I'm getting better at it. Ask me again in a year.