> You know when you are solving a given technical problem. With practice your solutions become more refined with increased performance.

Whether those are common definitions, someone who lasts a company for years gets to be a “senior developer”.

I knew an “architect” who was the first developer at a startup, who had been there for over a decade and as the company grew, he got promoted as newer people cane in. He made every mistake in the book of an “expert beginner”. Writing bespoke unmaintainable ORMs and logging frameworks, and treating a database as a queue, etc.

I was optimizing assembly language in middle school by counting clock cycles in the 80s on my 65C02 (ie the 74 in my username).

Was I a “senior developer” in 8th grade because I knew how to make my assembly language programs 33% faster by reading a writing from the 1st page of memory and using branch instructions instead of JMP instructions?

I was writing inline x86 assembly in the early 2000s when I looked at the decompiled assembly and I knew I could squeeze some performance out of it.

You know what I didn’t know because I thought I was so smart and didn’t learn from other people?

I didn’t know the ecosystem of my chosen platform so I would know what I shouldn’t write at all and just pull down from Nuget or the package manager of the platform I was using.

I didn’t know when I should build versus outsource because it didn’t add business value and wasn’t what gave us an “unfair advantage”.

I didn’t know how to mentor junior developers to be a force multiplier.

I didn’t know how to make choices that was best for the team or the business.

I didn’t know how to talk to end users to solve XYProblems.

I didn’t have the social skills to know how to “disagree and commit”.

Writing the wrong thing “optimally” is not the definition of a senior developer.