Career Change to Web Developer at 40

You taught high school English for 16 years. Why leave?

The pay ceiling is what finally did it. Sixteen years. A master's degree. $58,000. That's what suburban Atlanta pays a veteran English teacher with a graduate degree and a decade and a half of classroom experience. I did the math one night after grading 130 five-paragraph essays about The Great Gatsby. If I stayed ten more years, I'd maybe hit $66,000. Maybe. That number was going to determine whether my daughter Maisie could go to a state school without drowning in loans, and the answer was not great.

But the money was only part of it. The behavioral stuff was getting worse every year. My last year teaching, a student threatened me in front of the whole class. Just stood up and said what he was going to do, very specifically, while 28 other kids watched. I reported it to admin. Their response was "document it." Not suspend him. Not call his parents in for a meeting. Document it. Write it down. Add it to the file. I documented it. I also documented, privately, in my own notebook, that I was done. My divorce from Phil had finalized six months before that, and something about being a single mom making $58,000 while getting threatened in a room full of teenagers clarified things. I wasn't scared of changing careers anymore because the thing I was supposed to be scared of leaving had already gotten bad enough to leave.

How did you get into coding?

General Assembly's immersive software engineering bootcamp. Twelve weeks, full-time, in person in Atlanta. $15,000. I paid for it with savings from the divorce settlement. Phil and I split the house equity, which gave me about $40,000, and I used $15,000 of that on the bootcamp. That felt terrifying. You don't spend $15,000 on something you're not sure about when you're a single mom. But I also knew that $15,000 invested in a teaching career would buy me exactly nothing I didn't already have.

My bootcamp instructor was a guy named Wendell. Quiet, patient, had been a developer for 12 years before he started teaching it. On day three, I built a small web page that actually worked in a browser. I clicked a button and something happened on the screen because I told it to happen. That sounds silly. It's not. After 16 years of teaching, where you pour energy into people and hope something sticks months or years later, the immediate feedback loop of code was intoxicating. Wendell pulled me aside after week four and said, "You're good at this." He was the first person who said that. Not "you're doing well for a beginner" or "you're keeping up." Just: you're good at this. That sentence carried me through the next eight weeks.

Walk me through the money.

Teaching salary: $58,000. Bootcamp cost: $15,000. Three months of no income during the bootcamp. I burned through about $8,000 in savings covering rent and groceries while I wasn't working. So the total investment was roughly $23,000 before I earned a single dollar as a developer. My first dev salary was $65,000 at the ed-tech company where I still work. They make a learning management system for corporate training. So I went from being a teacher who used bad software to being a developer who builds the software teachers use. The irony is not lost on me.

After one year, I got a raise to $78,000. That's $20,000 more than my peak teaching salary. I have been teaching for 16 years and coding professionally for two. Two years of coding pays more than 16 years of teaching. I try not to think about that too hard because it makes me angry about what we pay teachers in this country. But for my own life, the math works. Maisie is 14 now and when she asks about college, I don't get the same knot in my stomach I used to get.

How does the teaching brain show up in your dev work?

Documentation. I write the best documentation on my team and it's not close. Sixteen years of writing lesson plans, breaking down Hamlet's motivations for 15-year-olds who would rather be on their phones, explaining the difference between a thesis statement and a topic sentence for the four hundredth time. That rewires your brain. You learn to take a complex idea and break it into steps that someone with zero context can follow. That's exactly what documentation is. When I write a README for an internal tool, I write it the way I'd write a lesson plan: what's the objective, what do you need to know first, here's step one, here's where people usually get confused, here's why.

The other thing is code reviews. Reviewing someone's pull request feels exactly like grading an essay. I can tell within 30 seconds if someone understood the assignment or if they just got something to work without understanding why it works. Those are two very different things. In English class, a student could write a five-paragraph essay that technically had a thesis, three body paragraphs, and a conclusion, but said absolutely nothing. In code, someone can write a function that passes all the tests but is structured so badly that the next person who touches it will want to scream. I spot that instantly. Cass, the senior dev on my team who's 25 and mentors me, says I give the most useful code review comments on the team because I explain what's wrong and why it matters, not just that it's wrong.

Tell me about the age dynamic with Cass.

It's weird and we've both acknowledged that it's weird, which makes it work. Cass is 25. She's been coding since she was 16. She has a computer science degree from Georgia Tech. She knows things about system architecture and database optimization that I won't understand for years. She's my mentor in every technical sense. I'm 43 and I've been alive long enough to be her mother, which is a thought I try not to have but occasionally have. She teaches me about React hooks and deployment pipelines. I teach her about communicating with stakeholders who don't know what a deployment pipeline is.

We had a moment about six months in where Cass gave me a code review note that was a little blunt. She wrote "this is wrong, fix it" on a pull request. I wasn't offended, I've heard worse from 16-year-olds, but I told her that a little context helps. Explain why it's wrong. Explain what "right" looks like. Not for my ego. For my learning. She thought about it and said, "You're right. I review code the way people reviewed mine when I was learning, which was badly." After that, her reviews got better. Not just for me, for everyone. Sixteen years of giving feedback to teenagers taught me what useful feedback looks like, and that skill transferred directly into a room full of developers who are smart but not always good at communicating with each other.

What was the biggest technical struggle?

JavaScript. Specifically, asynchronous JavaScript. In the bootcamp, Wendell explained promises and async/await and I nodded like I understood. I did not understand. The concept of code that doesn't execute in the order you wrote it was so counterintuitive that my brain physically rejected it. I come from English. In English, you read left to right, top to bottom, and the words mean what they say. In async JavaScript, you write something on line 5 and it might execute after line 20 because it's waiting for something to come back from a server. My English teacher brain said: that's not how reading works. My developer brain, which was about three weeks old at the time, said: this is how reading works now.

It took me about three months to actually understand it. Not fake-understand it by memorizing patterns, which is what most bootcamp grads do. Actually understand it. I sat down one weekend with the MDN Web Docs and a notebook and I wrote out what was happening at each step of every async operation like I was diagramming a sentence. Subject, verb, object, dependent clause. Except the subject was a fetch request and the verb was .then() and the dependent clause was a callback function. When I explained it to myself in English-teacher language, it clicked. Wendell would have laughed at my diagrams. They looked like something I'd put on a classroom wall between the periodic table of literary devices and the poster about semicolons.

What's your relationship with the product you build?

This is the part that gets me out of bed. The company builds a learning management system for corporate training. The LMS my school used was Canvas, and I spent 16 years fighting with Canvas. The search didn't work. The grade export was broken. The interface looked like it was designed by someone who had never taught a class. I would submit help tickets and nothing would happen. I used to say, out loud, in the teachers' lounge, that whoever built Canvas had never been a teacher. Now I build an LMS. I'm the person I used to yell about. And because I spent 16 years as the frustrated end user, I catch things that my teammates miss. I'll look at a feature and say, "A teacher would never use this because the button is in the wrong place and you have to click four times to do something that should take one click." My manager Bertram calls that "the Justine test." If Justine says a teacher wouldn't use it, we redesign it. Sixteen years of suffering through bad ed-tech software turned out to be the most valuable credential on my resume.

What's yours?

Imposter syndrome that doesn't go away. Two years in, $78,000 salary, good performance reviews, Bertram says I'm on track for a promotion. And I still feel like I'm faking it. Every standup meeting, I'm mentally preparing for someone to ask me a question I can't answer and the whole room to realize I don't belong here. It doesn't help that half my team has computer science degrees and can talk about Big O notation and data structures in their sleep. I can't. I learned to code in 12 weeks. They learned over four years. That gap doesn't close as fast as the bootcamp brochure implied.

The thing nobody tells you about career changes at 41 is that you carry your old identity like a shadow. I still think of myself as a teacher who codes, not a developer who used to teach. That distinction matters. Maisie told one of her friends that her mom is a software developer. The friend said, "I thought your mom was a teacher." Maisie said, "She was. Now she codes." The simplicity of that, coming from a 14-year-old, was better than anything I could have told myself. She doesn't see the imposter. She just sees someone who changed. I'm trying to see what she sees.

Twenty years in hotels. What made you leave?

The pandemic was the match, but the kindling had been stacking up for years. I started as a front desk clerk at 22. Worked my way up over 20 years to operations manager at a 400-room Marriott property in Phoenix. I managed 60 staff across housekeeping, front desk, maintenance, and guest services. I made $72,000 with full benefits. That's decent money for Phoenix. But you earn it. Holidays, weekends, 6 AM calls about the HVAC going down. I was on call essentially always. My wife Darla used to joke that Marriott was my first wife and she was my second. She was joking. Mostly.

Then March 2020 happened. Occupancy went from 85% to 9% in two weeks. We laid off 45 of our 60 staff. I was one of the 15 who stayed, running a ghost hotel with a skeleton crew. That period showed me something I'd been avoiding for years: my entire career existed at the mercy of forces completely outside my control. A virus I'd never heard of could erase 20 years of work in 14 days. The hotel industry recovered, eventually. But that feeling didn't go away. I started thinking about what else I could do, and the answer came from a weird place. The hotel's booking website broke during the pandemic and I watched our corporate IT team fix it remotely. I thought: that person just fixed a problem from their couch. I want that to be my life.

How did you learn to code?

Self-taught. Eighteen months of nights and weekends while I was still working the hotel job. I started with freeCodeCamp because it was free and I wasn't ready to spend $15,000 on a bootcamp before I knew if I could actually do this. The first month, I built a simple webpage. The second month, I learned CSS and made it look decent. By month three, I was deep into JavaScript and questioning every life decision I'd ever made. JavaScript is the point where casual curiosity either becomes commitment or you close the laptop and go back to your old life. I didn't close the laptop.

After freeCodeCamp, I moved to The Odin Project, which is also free but more structured. It's project-based, so you build real things instead of doing exercises. I built a restaurant website, which was ironic given that my agency now builds websites for restaurants. Then I started building things on my own. A booking tool. A dashboard for tracking hotel metrics, because that's what I knew. I'd get home from the hotel at 7 PM, eat dinner with Darla, and code from 8:30 to midnight. Every night. For 18 months. Darla never complained. She said, "You've been unhappy for five years. If this fixes it, stay up as late as you want." That kind of support is not something everyone has and I don't take it for granted.

Walk me through the money.

Hotel salary: $72,000 with full benefits, health insurance, 401k match, the whole package. I spent about $200 total learning to code. Domain names, a few Udemy courses on sale for $12.99 each, a month of hosting to put my portfolio online. That's it. The learning was essentially free. The expensive part was the opportunity cost. Eighteen months of nights and weekends is a lot of hours I could have spent doing other things, but those other things weren't going to get me to $85,000 with weekends off.

My first dev salary was $68,000 at the agency where I still work. So I took a $4,000 pay cut from my base salary, and I lost the benefits package, which was probably worth another $8,000 to $10,000 a year. Real talk: the first year was financially tighter than what I left. But after 14 months, they bumped me to $85,000 and the title went from junior to mid-level. The agency owner, Mitchell, told me the raise was partly for my code and partly because I was the only developer on the team who could run a client meeting without someone from sales in the room. Twenty years of guest-facing hotel work trained me to talk to people who are spending money and want to feel heard. That skill is rare in developers and Mitchell knows it.

How does the hotel brain show up in your dev work?

Client communication. That's where 20 years of hospitality plugs straight into web development. When a client emails at 5 PM on a Friday saying the site is broken and they need it fixed immediately, most developers see a technical problem. I see a guest standing at the front desk with a problem. The words are different. The emotional dynamic is identical. They're upset. They feel unheard. They want someone to acknowledge the problem before solving it. So I respond the way I'd respond to a guest: I hear you, here's what I'm going to do, here's when you'll hear from me next. Then I fix it. My lead developer Esteban is ten years younger than me and technically better at every language we use. But he told me once that he learns more from watching me on client calls than from any technical tutorial. Because the technical part is code. The client part is people. And code doesn't get upset.

The other thing is scope creep. In hotels, every guest wants a late checkout. Every single one. And the answer is always some version of "I'll see what I can do," which is hotel-speak for "probably not but I'm going to make you feel like I tried." Scope creep in web development is the same thing. The client wants one more feature, one more page, one more revision. And the answer has to be honest but diplomatic. Not "no," because that kills the relationship. Not "yes," because that kills the timeline. Something in between. I've been negotiating that space for 20 years. The context changed. The skill didn't. Esteban says I should teach a class on client management. I told him I've been teaching it, just not on purpose. Every client call is a lesson.

You build sites for restaurants and hospitality companies. Does that feel strange?

It feels like an unfair advantage, honestly. The agency builds custom web applications for restaurants and hospitality companies. Reservation systems, menu platforms, staff scheduling tools, guest feedback dashboards. I spent 20 years on the other side of those tools. I know what a restaurant manager actually needs from a reservation system because I've used one at 11 PM on a Saturday when the system crashed and 40 people had reservations they couldn't confirm. I know what a hotel ops manager needs from a scheduling tool because I built schedules for 60 people every week using software that was clearly designed by someone who had never managed a shift in their life.

Mitchell hired me partly because of this. He said most of his developers build for hospitality clients by reading requirements documents. I build for hospitality clients by remembering what it felt like to be the person using the thing. That's different. When we pitch a restaurant client and they start talking about their pain points, I'm nodding before they finish the sentence because I've lived every problem they're describing. Beverly, my former hotel GM, still texts me every few months saying "we miss you." I tell her I'm still in hospitality. Just from the other side of the screen now.

What was the hardest part of the self-taught path?

The loneliness. A bootcamp gives you a cohort, classmates, an instructor, a structure. Self-teaching gives you a laptop and a search engine. For 18 months, I was learning alone. No one to ask when I was stuck. No one to tell me if my code was good or terrible. I'd build something, stare at it, and have no idea if it was professional-quality or embarrassing. Stack Overflow was my classroom. YouTube was my instructor. GitHub repos from strangers were my textbook. There was a night around month 10 where I spent four hours debugging a React component that wasn't rendering. Turned out I had a typo in a prop name. Four hours for a typo. I almost closed the laptop for good that night. Darla brought me a beer and said, "You've handled worse." She was right. A typo is not a 400-room hotel with a burst pipe on Christmas Eve. Perspective helps.

The other hard part was the interviews. I applied to 73 jobs. Got callbacks from 11. Got to the technical interview stage at 6. Bombed 4 of them because whiteboard algorithms are not what self-taught developers are good at. I can build you a full web application. I cannot reverse a binary tree on a whiteboard while three people watch. Mitchell's agency didn't do whiteboard interviews. They gave me a take-home project: build a restaurant landing page with a reservation form. I built it in a weekend. It was the best take-home project he'd ever received, his words, because I didn't just build a page. I built the page the way a restaurant owner would actually want it. Because I know what restaurant owners want. That's what got me the job. Not algorithms. Domain knowledge that you can't learn in a CS program.

What's yours?

The physical transition. People talk about career change as a mental and financial challenge. Nobody talks about what happens to your body. For 20 years, I was on my feet 10 hours a day. Walking the property. Checking rooms. Moving through the lobby, the kitchen, the conference floor. My Fitbit averaged 14,000 steps a day. Now I sit at a desk for 8 hours. In my first six months as a developer, I gained 18 pounds. My lower back started hurting in a way it never did when I was moving all day. My sleep changed because I wasn't physically tired anymore, just mentally tired, and those are different kinds of tired. Darla bought me a standing desk for our anniversary. I use it about half the day. I started running three mornings a week. But the truth is, I traded a job that wore out my body from overuse for a job that wears out my body from underuse. Both have a cost. Nobody warned me about that one.

The other thing is the social recalibration. In hotels, I talked to 50 people a day. Guests, staff, vendors, maintenance crews. The job was built on human interaction. In development, I can go an entire morning without speaking to another person. Slack messages don't count. I mean actual human conversation. Esteban and I sit six feet apart and sometimes communicate entirely through pull request comments for three hours straight. For a guy who spent 20 years greeting people in a lobby, the silence of development is something I'm still adjusting to. I've started scheduling coffee with Mitchell once a week just to have a face-to-face conversation that isn't about a deployment. He thinks we're doing project check-ins. We are. But I'm also just making sure I still remember how to talk to people in a room.