A Letter to the Developer Starting Out

This is a letter to every developer starting out, written the way I wish someone had written to me. It closes the Workshop Bench series. Four posts looked at training from the outside. Why it matters, what it promises, where it happens and how to choose it. This one speaks to you directly.

Dear developer,

You’ve walked into the workshop. The tools on the wall look unfamiliar. The people at the benches look impossibly sure of themselves. The work looks bigger than anything school prepared you for. I want to tell you a few things that took me years to understand.

You Are Allowed Not to Know

Nobody expects you to know everything. They expect you to learn. Those are different jobs, and only the second one is yours.

Say “I don’t know” early, and keep saying it until it stops hurting. Then add three words that make it powerful. “I’ll find out.” A developer who admits a gap and closes it is worth more than a confident guesser. Confident guesses end up in production. Production remembers.

The people at the other benches felt exactly what you feel now. Every one of them. They don’t talk about it much, because the feeling faded and they forgot how loud it once was. Trust me that it fades for you too.

Your Hands Learn Slower Than Your Head

You’ll understand an idea long before you can use it well. You’ll read about indexes and nod along. Then you’ll design one, and it won’t help, and you won’t know why. That gap between understanding and skill is normal. It’s where every craftsperson lives for years.

The only bridge across it is repetition with attention. Do the thing, look at the result, ask what happened and do it again. Keep a test server you’re allowed to break. Break it every week. Every disaster you cause on purpose is one you’ll handle calmly when it happens for real.

Choose People Over Perks

When you choose a job early in your career, the salary and the perks will shout the loudest. Listen to them, but listen for something quieter too. Who will stand beside your bench?

A team with one patient senior developer is worth more than free lunches. Ask in the interview how new people learn there. Ask who reviews code and how. Ask what the last person in your role is doing now. The answers tell you whether you’re joining a workshop or a factory.

Use What You Know to Lift Others

One day, sooner than you think, you’ll know something a newer person doesn’t. What you do in that moment says more about you than any certificate.

Both panels start with the same sentence. The ending is your choice, every single day. Some people use knowledge as a wall, to show how far above everyone else they stand. The better ones use it as a ladder and hold it steady while someone else climbs.

The second kind of person is remembered for decades. Ask any senior developer who shaped their career. They won’t name the smartest person they worked with. They’ll name the kindest smart person.

Keep Your Promises

Someone will invest in you. A manager will approve a course. A colleague will spend an afternoon explaining a design. A company will give you time to learn. Treat that investment like the promise it is, as the second post in this series described.

Show up fully. Bring something back. Pass it on. And when the day comes to move on, as it will, leave well. Hand over your work, write down what only you know and say thank you. You’ll meet these people again.

Leave the Bench Sometimes

Your workshop teaches one way of doing things. Go and see others. Attend a meetup, travel to a conference when you can, talk to people who solve your problems differently. The journeymen of the old crafts walked for years for that privilege. You can take a short bus ride to a user group.

Find a mentor too, and earn them by coming back prepared. Show what you tried before you ask. People love helping someone who does the work.

Don’t Let Your Training Age

Here’s the part nobody warns you about. What you know today has an expiry date. Not all of it, but more than you’d like.

Nobody turns into this candidate overnight. It happens one skipped year at a time. A version you never learned, a feature you never tried, a new tool you dismissed as a fad. Then one day the job description reads like a foreign language.

The cure is cheap and steady. Learn a little every week, forever. Read the release notes when a new version ships. Try one new feature on your test server. Ask the newest person on your team what they’re excited about, and listen like it matters, because it does.

Take Care of the Person at the Bench

Craftspeople protected their hands. A carpenter with a damaged hand couldn’t work, no matter how much they knew. Your version of that is your health, your sleep and your curiosity. Guard all three.

Our industry celebrates late nights. Some will happen, and a few will be exciting. But a career is long, and the developers who last are the ones who learned to rest. Tired people make the mistakes that cause the next late night. It’s a loop, and the only exit is to step out of it on purpose.

Protect your curiosity too. It’s the engine of everything in this letter. When work stops feeling interesting, don’t push harder. Find a small corner of the craft that still makes you wonder, and spend an hour there. Curiosity comes back when you feed it.

And be kind to yourself on the bad days. Everyone ruins a piece of wood now and then. The master who taught you ruined plenty. What matters is that you pick up the next piece.

The Question Every Manager Asks

If you lead people one day, someone will ask you a worried question. What if we train them and they leave? It’s a fair question, and the answer is uncomfortable.

Some will leave. Train them anyway. The bigger risk is the people you don’t train, who stay. They’ll keep building the same systems the same way, year after year, and the whole workshop will age with them. A company of trained people who could leave is stronger than one of untrained people who never will.

One Day You’ll Stand Beside the Bench

This is the part of the letter I care about most. Today you’re the apprentice. You’ll sweep the floor, ruin some wood and ask questions that feel foolish. Somebody patient will answer them.

Years from now, you’ll look up from your own bench and see someone new walk in. They’ll have the same nervous face you have today. Remember this feeling then. Walk over. Show them where the tools hang. Tell them it’s fine not to know.

That’s how the craft has survived for centuries. Nobody owns it. Each of us holds it for a while, adds a little and hands it on. The bench you stand at was warmed by everyone who stood there before you.

The Case Against This Letter

You could argue that advice letters are easy to write once you’ve made it. The writer survived, so the advice looks wise. Plenty of people followed the same advice and still had a hard road.

That’s true, and I won’t pretend this letter guarantees anything. Careers depend on luck, timing and circumstances nobody controls. But none of these habits costs much, and none of them hurts. Asking questions, learning daily and treating people well make a hard road shorter. On a lucky road, they make you someone others are glad to travel with.

What to Remember

It’s fine not to know. Ask, practice, break things on purpose and keep learning a little every week. Choose a team with someone patient at the next bench.

Keep your promises, leave well when you leave and one day walk over to the nervous new person. Show them where the tools hang. That’s the whole series in two sentences.

With warm wishes for your first day at the bench,
Pinal

The Workshop Bench series

1. Developer Training: The Day School Ends and Learning Begins
2. Employee Training Is a Promise Both Sides Keep
3. Learning from People: Conferences, Meetups and Mentors
4. Every Way to Learn, and Which One Fits You
5. A Letter to the Developer Starting Out (this post)

A career is not a ladder you climb alone, it is a bench you pass on.

Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.