The Unwritten Rules of Being a Good Techie

The Unwritten Rules of Being a Good Techie

No one gave me a handbook when I started. No orientation covered this. No mentor sat me down and explained the things that actually matter.

I learned technical skills from books and courses. I learned loops and conditionals. I learned algorithms and data structures. I learned frameworks and libraries.

But the things that have kept me employed, respected, and sane? Those were never written down anywhere.

They are unwritten rules. The kind that experienced people know and beginners have to discover the hard way. I learned some early. I learned most late. A few I am still learning.

Let me share what I wish someone had told me.

Rule 1: You Are Not Your Code

This is the hardest rule to learn. And the most important.

When someone criticizes your code, it feels personal. You wrote those lines. You solved those problems. You stayed up late making it work. The criticism feels like a criticism of you.

It is not.

Code is code. You are you. Good developers separate the two. They can hear that their solution has problems without feeling attacked. They can accept feedback without defensiveness.

I have seen talented people become impossible to work with because they could not make this separation. Every code review became a fight. Every suggestion felt like an insult.

Do not be that person.

Rule 2: The Best Solution Is the One That Gets Shipped

I have spent weeks making code perfect. Elegant abstractions. Clever optimizations. Beautiful structure.

And then the project got canceled. Or the requirements changed. Or no one used the feature.

Perfect code that never ships is worthless. Good code that solves real problems is valuable.

This does not mean write bad code. It means know when to stop polishing. Know when good enough is actually good enough. Know that shipping teaches you more than perfecting.

The unwritten rule is simple: done is better than perfect.

Rule 3: Always Leave the Code Better Than You Found It

There is a concept called the boy scout rule. Leave the campground cleaner than you found it.

Code works the same way.

Every time you touch a file, leave it a little better. Fix a confusing variable name. Add a comment that explains something unclear. Remove a comment that is now wrong. Break a long method into smaller pieces.

Small improvements add up. A codebase that everyone improves a little becomes a codebase that is a joy to work in. A codebase that no one touches because they are afraid of breaking things becomes a nightmare.

You do not need permission to make things better. Just do it. Carefully. Respectfully. But do it.

Rule 4: Blame Is Useless. Understanding Is Everything.

Something broke. The site is down. The customer is angry. Everyone is looking for someone to blame.

Do not participate in this.

Blame does not fix problems. Blame does not prevent future issues. Blame just makes people defensive and scared. When people are scared, they hide mistakes. When mistakes are hidden, nothing improves.

Instead of asking “who did this?” ask “how did this happen?” Instead of “whose fault is this?” ask “what failed in our process?”

The unwritten rule is this: focus on the problem, not the person. The problem can be fixed. The person is probably already feeling bad enough.

Rule 5: Say “I Don’t Know” Early and Often

I wasted years pretending I knew things I did not.

I would nod along in meetings. I would agree to timelines I was not sure about. I would start work on things I did not fully understand. All because I was afraid to say three words.

I don’t know.

Here is what I learned. Saying “I don’t know” early is respected. Saying it late is embarrassing. Saying it never is dangerous.

When you say “I don’t know,” you open the door to learning. You invite help. You prevent mistakes. You build trust.

The best engineers I know say “I don’t know” more than anyone else. Not because they are less knowledgeable. Because they are honest about the limits of their knowledge.

Rule 6: Help Without Being Asked

The unwritten rule that separates good teammates from great ones.

When you see someone struggling, help. When you notice a knowledge gap, fill it. When you find a bug that is not yours, fix it or report it.

Do not wait to be asked.

I remember a senior developer who noticed I was stuck on a problem. He did not wait for me to ask. He walked over, looked at my screen, and said “I have seen this before. Here is what helped me.”

That moment changed how I work. Now I look for chances to help before anyone asks. Not to look good. Because someone did it for me.

Rule 7: Document Why, Not What

Most documentation is useless. It describes what the code does. But the code already says what it does. You can read it.

What the code cannot tell you is why.

Why was this approach chosen over another? Why is this constant set to 47? Why does this look wrong but actually work? Why is this workaround necessary?

That is the documentation that matters. That is the knowledge that disappears when someone leaves. That is what you should write down.

Rule 8: Your Reputation Is Built on Small Things

No one remembers the brilliant architecture you designed. Not really.

What people remember:

• Did you show up on time?

• Did you do what you said you would do?

• Did you communicate when things went wrong?

• Did you treat people with respect?

• Did you help when someone was stuck?

These small things compound. Over months and years, they become your reputation. And your reputation is more valuable than any technical skill.

I have seen brilliant developers struggle because they were unreliable. I have seen average developers thrive because everyone trusted them.

Be reliable. Be respectful. Be honest. The rest follows.

Rule 9: Protect Your Energy

This is the rule no one told me. I had to learn it through burnout.

You cannot pour from an empty cup.

Working late every night is not a badge of honor. It is a sign that something is wrong. Skipping lunch to finish a task is not dedication. It is self-damage. Answering messages at midnight is not commitment. It is a lack of boundaries.

The unwritten rule is this: protect your energy like it is your most valuable resource. Because it is.

• Take your breaks

• Log off at a reasonable hour

• Say no to things that do not matter

• Sleep enough

• Have a life outside of technology

The people who last in this industry are not the ones who work the hardest. They are the ones who work sustainably.

Rule 10: Teach What You Learn

You learned something today. Maybe it was small. Maybe it was huge. Either way, someone else does not know it yet.

Teach them.

Write it down. Explain it to a colleague. Make a note in the documentation. Share it in a team chat. Blog about it. Whatever works for you.

Teaching does two things. It helps others grow. And it solidifies your own understanding. You never really know something until you have explained it to someone else.

I started writing because I wanted to remember what I learned. The side effect was that other people learned too. That felt good. So I kept doing it.

Rule 11: The Technology Will Change. The Principles Will Not.

The framework you are learning today will be outdated in a few years. The language you love will be replaced by something shinier. The tool you mastered will become obsolete.

Do not attach your identity to any of them.

Attach your identity to principles. To curiosity. To kindness. To reliability. To the ability to learn. To the willingness to help.

Those things never go out of style. They transfer across every technology change. They make you valuable no matter what the industry does next.

Rule 12: Be the Person You Wished You Had

Think back to when you started. Confused. Overwhelmed. Unsure if you belonged.

What did you need then?

Maybe you needed someone to explain something without making you feel stupid. Maybe you needed someone to tell you that being confused was normal. Maybe you needed someone to review your code gently. Maybe you needed someone to include you in the conversation.

Now you are that person for someone else.

The unwritten rule is simple. Be the mentor you needed. Answer the questions you were afraid to ask. Create the safety you wished existed.

This is not charity. This is how healthy teams are built. This is how the industry gets better. This is how you become someone worth remembering.

Closing Thoughts

I did not know these rules when I started. I broke most of them. Multiple times. I learned through embarrassment, through mistakes, through watching people who did it right.

Now I try to follow them. Not perfectly. But intentionally.

The unwritten rules are not about being the smartest person in the room. They are about being someone people want to work with. Someone people trust. Someone people learn from. Someone people remember fondly.

That is what being a good techie actually means.

And no one ever writes that down.