One of the most important lessons that I think it's difficult to really internalise, is that your job is far more about managing imperfections than it is about achieving perfection.<p>It's very hard to kill your darlings as a developer, you have the whole edifice of software engineering best practice right there on people's blogs, there are infinite frameworks, libraries and languages at your fingertips. An appreciation for what's theoretically possible is always useful, but I will hire, promote, and throw money at people who can deliver a 75% solution to a problem with 90% confidence. I will struggle with people who aim for 100% solutions that never materialise.<p>I don't think that I (as a younger programmer or if I'm honest even quite recently) would want to hear this, from my future self or anyone else, but I would have been happier accepting it early in my career.
My criteria for seniority is very simple:<p>Given clear requirements, can you be left alone for a reasonable amount of time and not come up with a monumental mess? If you can, you are a senior engineer.<p>And as a corollary, if you need constant supervision, you are not as senior as you think.
My employer has the following job titles in IT-<p>* Associate Engineer<p>* Engineer<p>* Senior Engineer<p>* Principal Engineer<p>* Solutions Engineer<p>* Architects, Sr Architects, Enterprise Architects<p>And my interpretation here for Senior is probably around Solutions Engineer, bordering on, if not completely in an Architect's domain. But the thousands of Principal Engineers and downwards all have a wide range of agency for implementing the four tiers demonstrated in the article.
Becoming a SME (subject matter expert) in a certain technology (that would benefit the org) and then evangelizing that technology within the organization is a mark that I look for in a senior.
I’ve slowly been transitioning into a senior developer. It seems the closer I get, the more management/supervision I do, so the less time to work on my skills.