You Can't Give Anybody That Much Power Over Your Belly

There was a time when I was living with my mom, trying to figure out how I was going to make a living.

I couldn't find a job. I tried getting into a union. I looked into different trades. I was reaching out to people, asking questions, trying to find somebody who could point me in the right direction.

But nothing was working.

One of the biggest problems was that I didn't have many connections. I didn't know people who could make a phone call and get me in somewhere.

So I was basically waiting for somebody to give me an opportunity, and that opportunity wasn't coming.

Eventually, I started looking into building websites.

I came across a free course that taught you how to build a website in a week. I took the course, finished it, and kept learning.

But learning how to build a website was only part of the problem.

I still needed somebody willing to pay me to build one.

So I started looking for potential customers.

I researched local businesses, put together a list of contacts, and started reaching out.

Within about 30 days, I landed my first paying client.

It was a $200 website.

Now, $200 wasn't a lot of money. But that wasn't what mattered to me.

What mattered was that somebody was willing to pay me for something I knew how to do.

I didn't need an employer to hire me. I didn't need somebody to recommend me for a position.

I learned a skill, found somebody who needed it, and got paid.

That changed how I looked at opportunities.

I Was Getting Paid Before I Became an Employed Developer

One thing I want to make clear is that I was already getting paid to build websites before I landed my first professional developer job.

I didn't start my career by getting hired at a software company.

I started by learning something useful and finding people who would pay me to do it.

But I still wanted to become a professional software engineer.

I wanted to work on larger projects, learn how engineering teams operated, and gain experience building software inside established organizations.

So I went through Coding Temple and later joined i.c.stars, a four-month technology training program in Chicago.

After completing that program, I landed my first developer position at Red Foundry, where I was building mobile applications.

I was finally doing what I had been working toward.

I was contributing to real projects, working with other developers, and gaining professional engineering experience.

I even helped train another employee.

But eventually, I started noticing some things that didn't sit right with me.

There were periods when I wasn't being assigned much work. Some workplace interactions felt passive-aggressive. I remember having my competence questioned during standups and sometimes feeling excluded from conversations during meetings.

I didn't know exactly what was happening behind the scenes.

Then I was let go.

The explanation I received was that they didn't have projects that matched my skills.

Now, I can't tell you exactly why that decision was made. I can only tell you what I experienced and what I was told.

But it reinforced something I had already started learning before I became an employed developer.

You can't give any man or woman that much power over your belly.

When I say your belly, I'm talking about your ability to eat, pay your bills, and take care of yourself and the people who depend on you.

Think about it.

You can spend years developing a skill. You can show up every day, do the work, and contribute to a company.

But somebody else can still make a business decision that eliminates your position.

And you might have absolutely no control over that decision.

That's the part that bothered me.

Accenture Reinforced the Same Lesson

Later in my career, I worked at Accenture for more than three years.

That experience exposed me to enterprise software engineering on a completely different level.

I worked with teams around the world, contributed to enterprise systems, and participated in a major migration project.

I learned a lot from that environment.

But eventually, downsizing happened.

Once again, I was reminded that being a capable engineer doesn't necessarily mean you're protected from business decisions.

A company can have financial priorities, organizational changes, or other reasons for reducing its workforce.

And those decisions can affect you regardless of how much experience you have.

Now, I'm not against working for somebody.

There are good companies out there, and there are valuable things you can learn from working with experienced teams.

Some of the skills I use today came from those experiences.

The problem is when your entire ability to earn a living depends on one organization continuing to employ you.

Because when that organization makes a decision you don't control, your income can disappear with it.

Creating Opportunities Instead of Waiting for Them

Over time, I started thinking more seriously about how to create opportunities for myself.

If I know how to build software, why should an employer be the only organization willing to pay me for that skill?

There are nonprofits that need better systems.

There are small businesses spending hours every week moving information between spreadsheets.

There are organizations dealing with inefficient workflows, reporting problems, and administrative work that could be improved with technology.

Those organizations have problems.

And if I have the skills to solve those problems, there's an opportunity to create value.

But there's something you have to understand.

Knowing how to code and knowing how to turn that skill into income are two different things.

You can know JavaScript, React, Python, or whatever technology you're working with.

That doesn't automatically mean you know how to find a customer, understand their problem, explain the value of your work, or convince somebody to pay you.

Those are skills you have to develop too.

And the first thing you need to understand is what you're actually capable of offering.

Start by Understanding Your Value

A lot of developers describe themselves by the technologies they use.

They'll say something like:

"I'm a full-stack developer. I know React, Node.js, MongoDB, and TypeScript."

That's fine when you're explaining your technical background.

But think about it from a business owner's perspective.

What does that actually tell them about what you can do for their organization?

Not much.

Now, suppose instead you explain that you help nonprofits reduce manual administrative work by building software that connects their existing processes.

That's a different conversation.

You're no longer just describing programming languages.

You're explaining a problem you can solve.

And that's where I think developers need to start, especially if they want more independence in their careers.

Before you start chasing clients or trying to build a business, take inventory of the work you've already done.

What problems have you solved?

What systems have you built?

What processes have you improved?

Who benefited from your work?

And what results came from it?

You may discover that you've been developing valuable skills for years without fully recognizing how those skills translate into business value.

Your First Exercise: Take Inventory of Your Work

We're going to use AI to help analyze your experience.

The objective isn't to have AI invent accomplishments or tell you how great you are.

We want to identify the problems you've solved, the skills you've developed, and the kinds of organizations that could benefit from your experience.

Open your preferred AI assistant, copy the prompt below, and paste your résumé underneath it.

Remove personal or confidential information that isn't necessary for the analysis.

AI Prompt: Identify Your Professional Value

You are a career analyst who specializes in identifying the business value behind a person's technical experience.

I'm going to provide my résumé. Help me understand which skills and experiences could translate into professional or business opportunities.

For every position, project, or client engagement, identify the business problem, what I did to address it, and the result. Label any inferences rather than presenting them as facts.

Identify recurring technical skills, business problems, responsibilities, and industries throughout my experience.

Identify my two or three strongest marketable skills, supported by evidence.

Identify valuable work my résumé may be underselling.

Create a statement using the format: "I help [WHO] with [PROBLEM] to achieve [RESULT]."

Create three variations for small businesses, nonprofits, and larger organizations.

Finish by asking me three questions that would help sharpen the analysis.

Don't flatter me or invent accomplishments. Keep the analysis grounded in my actual experience.

What You Should Have When You're Finished

You should have a written inventory of your experience, the business problems you've solved, and two or three skills that could potentially create professional opportunities.

You should also be able to complete this sentence:

I help [WHO] with [PROBLEM] to achieve [RESULT].

Don't worry about making the statement perfect right now.

We're going to refine it as we work through the next Field Notes.

The important thing is that you start understanding your value beyond a job title.

Because when you understand the problems you can solve, you can start identifying people and organizations that need those solutions.

That doesn't mean you'll never work for somebody again.

It means you have options.

And that's the point. You want to depend on your mind and your ability to create value, not somebody else's permission to earn a living.

Up Next: How I Found My First Paying Client

When I earned that first $200 building a website, it wasn't because somebody discovered me.

I had spent time watching YouTube videos, researching local businesses, building a contact list, and figuring out how to approach potential customers.

I even wrote myself a phone script because I didn't want to get somebody on the phone and start fumbling over my words.

In the next Field Note, I'll explain the process I followed, the activity goals I set, and why communication matters just as much as the technical skill you're trying to sell.

Read Field Note 002: How I Found My First Paying Client Before I Ever Had a Developer Job.