What Makes a Senior Software Developer?

I also had the pleasure of arguing for a team members promotion once. The domain our team of 5 worked in was pretty challenging (heavy algorithmic stuff). I spent a year trying to train up my team, and although they improved, I still felt like I had to do the hard stuff myself. With the exception of one developer. For example if a project was particularly hairy or the time frame was too short, it was either me or him doing it. And I couldn&#x27;t give him all the hard stuff so I ended doing a lot more coding than I had time for.<p>I went to my boss and said, X is carrying my team, he does more than any two other developers combined. He needs a raise, I can&#x27;t lose him! And he got it.<p>To me that&#x27;s what senior boils down, they can do the hard stuff, they keep the ball moving forward, and not get bogged down in the irrelevant stuff.

At GitLab we have the following criteria to be a senior:<p>Senior Developers are experienced developers who meet the following criteria:<p>Are able to write modular, well-tested, and maintainable code<p>Know a domain really well and radiate that knowledge<p>Begins to show architectural perspective<p>Leads the design for medium to large projects with feedback<p>from other engineers<p>Leaves code in substantially better shape than before<p>Fixes bugs&#x2F;regressions quickly<p>Monitors overall code quality&#x2F;build failures<p>Creates test plans<p>Provides thorough and timely code feedback for peers<p>Able to communicate clearly on technical topics<p>Keeps issues up-to-date with progress<p>Helps guide other merge requests to completion<p>Helps with recruiting<p><a href="https:&#x2F;&#x2F;about.gitlab.com&#x2F;jobs&#x2F;developer&#x2F;" rel="nofollow">https:&#x2F;&#x2F;about.gitlab.com&#x2F;jobs&#x2F;developer&#x2F;</a>

I like the table that 18F uses to distinguish between the federal pay scale levels[0]. I.e. Comparisons like<p>&gt; Your supervisor reviews your work from an overall standpoint to ensure its effectiveness in meeting requirements<p>Vs.<p>&gt; The results of your work are considered technically authoritative and can be used to establish best practices<p>0: <a href="https:&#x2F;&#x2F;pages.18f.gov&#x2F;joining-18f&#x2F;pay-grades&#x2F;" rel="nofollow">https:&#x2F;&#x2F;pages.18f.gov&#x2F;joining-18f&#x2F;pay-grades&#x2F;</a>

Junior Dev: knows how to do stuff ... in a way, kinda. Hopefully asks a lot of questions.<p>Mid. Dev: Knows Best Practices and how to implement them. Knows what questions to ask.<p>Experienced Dev: Understands why best practices are best practices. Can give insightfull answers.<p>Senior Dev: Pushes the boundaries of best practices and when to ignore them. Questions him&#x2F;herself a lot.<p>And then there are D. Knuth level developers which I still have to figure out.

I&#x27;m dealing with something similar to what the article talks about. I&#x27;ve been with my company for 3 years. I wa shired as a &quot;new college hire.&quot; I am ~6 years older than a typical grad and had worked in the industry prior to joining my company.<p>Ever the course of my time I&#x27;ve:<p>1. Learned C# in order to rewrite an app I wrote in Java 2. Self-organized a team to implement a UI in HTML&#x2F;CSS using a JavaScript tool I wrote myself that allowed different team members to work on components a layout and have the partials dynamically reconstructed. 3. wrote a connection pool class in C# from scratch that has been in production for 2 years without a hiccup.<p>The list goes on. I suppose I&#x27;ve been rewarded by my manager with substantial raises and he always says he notices my work but in 3 years the only responsibility I&#x27;ve had was when I took it on myself to bring coworkers together to implement the UI (which we delivered in 2 weeks as opposed to the 3 months they had blocked for it).<p>Am I wrong to feel slighted when far less capable people have been promoted to leadership positions? My boss does stuff like take me to events where I&#x27;ll meet big wigs, but I don&#x27;t care about that stuff. I just want to be in charge of producing good, maintainable code.

&gt; You follow your gut. The problem is that this approach can be prone to favouritism.<p>What&#x27;s wrong with favouritism ? If a person does his job well and helps you (the manager) do your job better AND you get along well - that&#x27;s the silver bullet right there.<p>Like it or not, this is how groups of humans tend to coagulate. All the other considerations are secondary.<p>Promote the ones you personally like (avoid idiots of course). This how you build a &#x27;gang&#x27; of friends and you get promoted yourself.<p>&quot;Moral Mazes&quot; is a great book which explains the nitty gritty details of corporate power structures (warning: I quit my job after I read this book!). It all boils down to personal relationship between people in an organisation. Technical skills and everything else are complementary but not mandatory (except geniuses - maybe in 0.1% of the cases).<p>&quot;Corporate confidential&quot; is another interesting book, which is more about the HR side of things, but it also gives some pointers about how teams are assembled

Anyone with 5+ years of writing production code should be a Senior Software developer.<p>Then obviously you can say he is an average developer or a very good developer or a genius or whatever. I don&#x27;t really get why developers should have different qualifications than other fields.<p>If you are working e.g in finance for more than 5 years you&#x27;ll be prolly a senior something, what does it matter? Of course then someone can evaluate how good you are or not at what you do but thats it.<p>Now what makes a senior developer? Well someone that can take on a project and complete it from start to finish, for me is a senior developer or developer or whatever you wanna call it. Its very vague question, usually if you understand the whole lifecycle of a program and can understand the bigger picture then you are a senior software developer.

&gt; <i>The other problem with checklists is that they only work well if you have quantifiable metrics for being a senior developer.</i><p>Checklists can combine qualitative and quantitative data in this scenario too: when judging the experience of a developer, you can incorporate how many times someone has displayed a quality in your checklist.<p>I really like Matt Briggs’ take on senior developers: <a href="http:&#x2F;&#x2F;mattbriggs.net&#x2F;blog&#x2F;2015&#x2F;06&#x2F;01&#x2F;the-role-of-a-senior-developer&#x2F;" rel="nofollow">http:&#x2F;&#x2F;mattbriggs.net&#x2F;blog&#x2F;2015&#x2F;06&#x2F;01&#x2F;the-role-of-a-senior-d...</a><p>Once you get a good feel for what qualities you’re looking for, you can measure how many times someone displays those qualities. When you’re hiring, you’re depending on the interviewee to show they’ve demonstrated those qualities; when someone’s been at your company for a while, you might depend on their team members to confirm whether they’re showing the qualities you’re looking for.<p>I think the article is right in saying that it’s mostly subjective, but that doesn’t mean you can’t break up those subjective feelings into smaller parts to judge them better.

TLDR: &quot;To me, what makes a senior developer is when you can trust them to get things done without you.&quot;<p>This is a good conclusion. I&#x27;ve seen people write some amazing code, implement innovative solutions and build something really solid, but they simply can&#x27;t take the customer&#x27;s requirements and run with them. I have to explain every single requirement in great detail.

An intermediate developer knows how to abstract things.<p>A senior knows when not to.

moving beyond entry-level is about learning to do your job without any handholding. this usually doesn&#x27;t take that long.<p>but any title progression beyond that depends on getting good at navigating the politics of your work environment. you won&#x27;t get far without people skills. banks actually do a good job of mapping out what this looks like for analysts coming in, in terms of leadership skills etc expected for different titles. technical organizations, however, tend to leave their staff in the dark about this sort of thing -- which is a political move in itself, i suppose.

I became senior developer when my financial expectations didn&#x27;t fit into regular developer salary bracket at the company that wanted to hire me.<p>No one has offered me lower position ever since.

The sombrero indicates a senior developer.

Only if &quot;Senior Software Developer&quot; meant something that is universally acceptable. In our organization we had a Program Manager who was responsible for 9 large projects each with several sub-projects. His job was to ensure they all these projects co-ordinate properly, have sufficient resources and provide leadership to ensure we eventually have a good cohesive product suite (thus the Program). Then I met a 20 something kid on flight who was a Program Manager for Microsoft. He organized campus recruitments or something like that.<p>I am small organization. We upgrade titles of our developers almost every 2 years of their service. Why ? Because firstly they all are good and we want them to stay. Also, if they want to go someplace else we want them to find a better position instead of starting bottom up again. If a person does not get an upgraded title we would like such person to actually leave our organization and find a better fit instead.<p>If a person is working 2 years and has not evolved significantly in your organization you are probably running a bad work environment. Asking such developers to show &quot;Architectural perspective&quot; and &quot;communicate effectively the technical aspect&quot; is all BS-talk. These developers are not going to work for 10 years for you, they are going to leave for some other place. There is a good chance you are losing many good capable people because of this.

These modifiers are always a touchy point with me. They aren&#x27;t applied consistently and imply greater experience and ability, when they often signify time spent at a company or political acumen. Over my 15 years in engineering, I&#x27;ve seen several engineers without senior or lead titles who provide more value than those with the modifier.<p>I prefer &quot;staff engineer&quot; for engineers who are capable of producing useful, working systems with a team. &quot;Lead&quot; should not be a modifier to a title, just an indicator who makes final technical decisions on a team.<p>On my resume I only have &quot;software engineer.&quot; If I have to negotiate a higher salary after an offer, I point to my accomplishments and not my title.

- Someone that can get hard things done and ship, preferably multiple times.<p>- Someone that can build products that run after ship and be maintained.<p>- Someone that can take something from start to finish and make it better.<p>- Someone that also knows about business and product side and that is the ultimate product not just the tech.<p>- Someone that has been developing long enough to know that good ideas and input&#x2F;feedback come from customers, team members and stakeholders.

Ability to weigh non-technical factors in technical decisions, such as time cost, cost of technical debt, potential risk and business need.<p>And the critical skill to go along with all of that is the ability to communicate those factors to different groups of people as needed.

The article fails to address the fundamental question: What is the purpose of the title? Without answering that, any definition of what makes a senior developer is meaningless.<p>In my own experience, having worked in consulting, the answer to the question is that the title enables the company to charge a higher hourly rate for a particular developer, with the client&#x27;s understanding that this developer&#x27;s time will be worth more, because she is more experienced. If the client insists that a project should include a certain number of &quot;senior developers&quot;, and if the consultancy is short that amount, then magically the most experienced junior developers will find the title bestowed upon them.<p>Outside of consulting, I have a hard time seeing any legitimate purpose to the title, unless it is formally attached to a bump in salary.

Look for the gray hair and the world-weary look in their eyes.

This post self-admittedly fumbles as do many efforts at trying to tackle this question. The question is wrong: What makes a Senior Software Dev? That&#x27;s a <i>title</i>, subject to the vagaries, needs, politics, and culture of a specific business or organization.<p>We can and should be more precise. The real question is, what are the professional skill sets? And what do they look like at varying levels of competency?<p>This post reminds me of the famous Joel Spolsky post from over a decade ago where he says the Senior Engineer is one who (1) is smart; and (2) gets things done. That&#x27;s all you need is the gist. But these should be the table stakes, not the criteria. There&#x27;s a whole bunch of acquired skills that are missing in these kind of answers.<p>It&#x27;s pretty easy to be smart and get things done. It takes years of practice to not make a mess of your work. To not build a money pit of a house whose plumbing is leaking behind the walls, whose structure is buckling. But the market is so short on these kind of professionals with real skills that we feel lucky if we&#x27;ve found one who meets this paltry criteria of smart, gets shit done, makes me not stress when I go on vacation...

A senior developer doesn&#x27;t even have to be a great programmer. They need to be good of course; they need to write code that works and is suitable for production, but I&#x27;ve heard of plenty of excellent, talented coders who can solve complex problems and rapidly stamp out a prototype, but can&#x27;t finish the job, and end up with badly tested, hard to maintain code that still needs someone else to finish up the loose ends.<p>On the other hand, a friend of mine recently retrained to become a programmer, joined a startup where he&#x27;s clearly the least experienced programmer, but he is now their lead developer, because he has the right attitude. He&#x27;s honest (unlike their previous lead who left a mess) and he listens to to and learns from other developers, and he can make sure the code is actually finished in a way that doesn&#x27;t fall apart when the customer pokes at it. He may not be the fastest or most knowledgeable, but he does deliver what&#x27;s needed, and ultimately, that&#x27;s what counts.

I got promoted <i>en passant</i> in my first job, three months after graduating. My employer was putting together a consultancy proposal including a list of team members and decided to inflate our seniority...

Not a huge fan of the blog post as it left things in a nebulous state.<p>The thought of a senior person being someone who finishes tasks on his&#x2F;her own time seems like a bad metric in the world of pair programming. As a senior developer, I prefer to get input from all of my coworkers rather than work alone. Two or more minds is always better than one, no matter how senior you are.<p>The thought of someone taking on more responsibilities than the rest also seems like a bad metric. A junior person has the potential to do just as much as a senior person. It can also create an environment where you are encouraged to work hard and not smart.<p>In software engineering, there is always 10+ ways to solve a problem, but there is typically only one or two actual correct solutions. I like to think of a senior person as the person who can evaluate all the options quickly and chooses the right one. This is a skill that takes a lot of experience to master.

I have always worked along the lines of most people here and the article. A Senior Developer is one that has amassed not only solid development experience across multiple projects but also has a solid knowledge of your product code base. Someone that can just get stuff done and leads by example. Applies best practices and is pragmatic and always add&#x27;s value to the code base.<p>I agree that titles are handed out too easily however, developers are partly to blame here. I have held numerous titles over my career but they are meaningless. Experience is built over years for learning and applying your trade and for those that want to continue doing that where do they go after &quot;senior&quot;? If developer&#x27;s were not so desperate for the title then this discussion and the questions being raised would be moot and we&#x27;d all be back coding.

A couple metrics I&#x27;ve come to look for in seniors:<p>- knows when to push back on stakeholders&#x2F;management, especially on technology decisions<p>- knows when to adhere to industry best practices, and when to ignore it because it doesn&#x27;t apply to the domain&#x2F;problem at hand<p>- fights, strongly, against cargo-cult programming<p>- actively seeks to improve the knowledge and skills of his&#x2F;her team members<p>- delivers solid, reliable, working code that can be trusted to work when they say it works<p>- is able to work effectively with peers who they disagree with<p>Promoting anyone to the senior title when they aren&#x27;t remotely close to the bar is damaging to the team and to the company overall. It&#x27;s especially damaging since if you promote the wrong seniors, they will effectively put a lock on the capabilities of your team, preventing team members they disagree with from achieving the same title, leading to a talent drain.

How do you buy a car? Do you look at fact sheets and compare, and choose the one that has the list that fits your interests best?<p>I hope not.<p>I buy cars talking to people who own that car. I read reviews. I test drive it multiple times. I do check the facts sheet, of course, but them I go and see if it&#x27;s accurate.<p>And then I compare. Most cars are identical on the surface, but there are details - this one has a softer clutch, that one looks better (to my taste), and that other is said to do wonderful mileage.<p>I usually end up ranking them, and if they tie, I go for the cheaper one.<p>That&#x27;s how you promote people. You take a few, compare them extensively (talking to others, checking facts, &quot;test driving&quot;) and choose the one you feel it&#x27;s the best.<p>So far, so good. The missing point here is WHY promote people. The author seems to forget about that.

For us, a Senior Software Engineer is someone who can finish tasks on his own and on time, and make good architectural decisions for his tasks.

They&#x27;ll tell you.

The common thing i can see about seniors developers are the length of his code.<p>A junior developer doesnt divide too much his code, repeat himself, the avg length of his code is high, etc.<p>A semi-senior developer knows how to divide his code, have a good analysis and design, knows some common patterns, try to have good practices, and repeat himself a little. (Sometimes takes bad decisions trying to not repeat without sawing his design) Normally have some methods with too much lines of code but not too much.<p>Seniors developers are embrace testing a lot, even test his tests (mutation testing), are carefull about decisions who impact on architecture, and the average of the lenght of his code is between 5 and 8 lines of code (and always simply readable). Cares a lot of dependencies and really knows how to use all of his tools. Specially when talking about refagtorings. Normally, they loved the job&#x2F;books of some of these guys: Robert Martin (uncle Bob), Sandi Metz, Kent Beck, Martin Fowler, The Gang of Four, Alistair Cockburn and&#x2F;or Alan Key.<p>Of course this seems a bit qualitative too, but its like a pattern i noticed.<p>Anyway, the preferred method here is: Developers categorize others. Between a team, or a company.

It&#x27;s a meaningless term. Senior implies &#x27;qualified&#x27; which is not an end-state. Developers are always learning, our journey does not end.

As always it depends on the organization or team.<p>I have worked on teams where the title was nothing more than a title and didn&#x27;t relate to their skill level or work ethic.<p>One of my favorite posts on the subject comes from John Allspaw: <a href="http:&#x2F;&#x2F;www.kitchensoap.com&#x2F;2012&#x2F;10&#x2F;25&#x2F;on-being-a-senior-engineer&#x2F;" rel="nofollow">http:&#x2F;&#x2F;www.kitchensoap.com&#x2F;2012&#x2F;10&#x2F;25&#x2F;on-being-a-senior-engi...</a><p>An important part of the equation is a companies engineering structure. Camille Fournier has a great set of slides about creating structure earlier rather than later and why it is needed: <a href="http:&#x2F;&#x2F;www.slideshare.net&#x2F;CamilleFournier1&#x2F;how-to-go-from-structureless-to-structured-without-losing-your-vibe" rel="nofollow">http:&#x2F;&#x2F;www.slideshare.net&#x2F;CamilleFournier1&#x2F;how-to-go-from-st...</a>

For me it&#x27;s pretty straightforward:<p>Dev 0 - For companies that hire college graduates. A developer fresh out of college who has a lot of theoretical knowledge but not practical knowledge. They might still be learning the tools of a professional software developer (source control, testing suites, the debugger, building and deploying environments, etc), technologies (Linq for .Net, Angular for a web dev, etc), techniques (dependency injection, how to write clean code, the value of good logging, etc.), and&#x2F;or how to operate in a professional environment (stand-ups, interacting with coworkers, dealing with having a manager, etc.)<p>Junior Dev - I expect you to have learned the things listed above. You should be proficient in the language or framework. You should understand the software development process and reliably write &quot;good&quot; code. Meaning correct, efficient, simple, readable, and maintainable. Junior developers are still learning design, architecture, domain knowledge, and when to break &quot;the rules&quot;.<p>Senior Dev - The best way I can explain what I look for is, &quot;I can give them any assignment and trust they&#x27;ll get it done, well, with little to no help from me.&quot; Set it and forget it. Domain knowledge is underrated as a skill but it&#x27;s a super important one. A senior developer should know the &#x27;gotchya&#x27;s of the particular type of software you make. (If you make billing software they should have a cursory knowledge of accounting as well as compliance issues). The code they write should account for not only the particular module they&#x27;re working in but the system as a whole. It will follow best design patterns, fit inside of our architecture, but won&#x27;t be so dogmatic that it sacrifices performance or maintainability. You should be able to stay in the senior role for the rest of your career if you want.<p>----<p>As concisely as I can put it: new hires will as you how to do something. You&#x27;ll need to ask junior devs, &quot;have you considered...&quot; Senior devs you don&#x27;t need to think about at all.<p>----<p>Careers diverge after the senior dev level depending on your preferences. If you want to stay pure technical and just write code all day some companies offer an independent contributor or technical expert role. If you really like the design and framework aspect of software you can move into an architecture position. If you want to explore management you can move onto technical lead which is a pseudo-management position.

The question &quot;What Makes a Senior Software Developer?&quot; would only make sense given the context of what grades of engineers are present in a company. The definition will be different for a company with just 3 levels compared to one with 6 levels. I side with more levels. This is because, while we may argue that a &quot;senior&quot; engineer should have these 10 qualities, an engineer with 6 of those qualities is still better than one with just 2 of those qualities. So it makes sense to have the engineer with 6 qualities at a higher level than one with 2 of those qualities.<p>The question then becomes what are these N traits of a good engineer. The whole process of promotion and &quot;senior&quot;ity is irrelevant to that discussion. And I think most people here would already agree on those traits.

I disagree with the article. Perhaps I&#x27;m too strict of a grader, but a developer who meets the qualitative criterion here--essentially, a developer you don&#x27;t have to manage much--is not yet a senior developer. She is on her way, but to me the distinguishing factor is the extent to which the developer can mentor junior developers.<p>If a developer meets the criterion of TFA, then she helps her manager grow the team linearly, as the manager can then focus more on others. But if a developer can effectively mentor junior developers, then the team can scale. This is not to say that a senior developer must be a &quot;manager&quot;, but a senior developer not only understands the importance of craft and can practice it, she helps apprentices appreciate the craft as well.

The definitions will vary, and imho even having these titles is useless. If you don&#x27;t know who is senior without having to print it on business cards you are in trouble. To me being a senior developer means, when faced with a hard problem I prefer to<p>- not solve the hard problem. Make it go away instead. - buy an existing solution to the hard problem. - make a simple solution to part of the hard problem<p>Making a &quot;simple solution to the whole hard problem&quot; is of course the end game, but most of us never reach that level. Seniority is basically just a measure of battle scars and cynicism (&quot;experience&quot; also a nicer ring than aggregated cynicism).

I always use the simple rule: Senior means you can finish a complex task on your own, without being told how to solve it.<p>Of course, now we have to define &quot;complex&quot;, but the salient part is being able to work independently.

Similar discussion from a couple of months ago: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=12603303" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=12603303</a>

The programmer competency matrix:<p><a href="http:&#x2F;&#x2F;sijinjoseph.com&#x2F;programmer-competency-matrix&#x2F;" rel="nofollow">http:&#x2F;&#x2F;sijinjoseph.com&#x2F;programmer-competency-matrix&#x2F;</a>

I use several levels for my team (1 is a new grad, 3 is somewhat experienced, 5 is senior, 7 is principal.) When evaluating someone, I rate them on 4 competencies (which depend on the exact role.) If they&#x27;re currently being paid at level n, but the average of their competencies is &gt;= n+1, I recommend a raise.<p>This approach still involves some subjectivity, but I find that it avoids many of the problems, such as not properly rewarding people who are fantastic on a few dimensions and weak on others.

I&#x27;ve recently been looking into this topic. Sales teams have fairly straight forward metrics for measuring performance as they can track calls made, revenue, etc...<p>Developer performance metrics are not as immediately obvious. Can anyone suggest some reading on the topic? I&#x27;d love to know how managers are tracking developer performance.

It means you need know how to architect, integrate and hack&#x2F;debug&#x2F;write&#x2F;patch whatever software, in the meantime you also need to do bitwise and shift of integers, balanced binary tree algorithm algorithms fast. The former you need for the real work, the latter you need for interview. You need cover both ends.

Could someone lay out what is, and the difference between a junior(beginner) and an intermediate developer?

Sorry for off topic, but this text is illegibly huge. It reads nicely after zooming out until 50%, or at least 67% (though that&#x27;s still a bit big). I think 55% or so is close to the text size that my task bar, tabs and hacker news also uses.

Another essay answering the same question: <a href="https:&#x2F;&#x2F;hackernoon.com&#x2F;senior-engineers-reduce-risk-5ab2adc13c97#.oebwciiom" rel="nofollow">https:&#x2F;&#x2F;hackernoon.com&#x2F;senior-engineers-reduce-risk-5ab2adc1...</a>

To me, the chain from developer to senior to lead to principal etc is mostly driven by the desire to change from being &quot;reactive&quot; to &quot;proactive&quot; and offloading other people (higher and parallel etc) in the chain.

Nobody wants junior engineers (or: get &quot;senior&quot; in your title as soon as possible):<p><a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=ccxrFmIEAmQ" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=ccxrFmIEAmQ</a>

A senior software developer is one thing.<p>A person that voluntarily and passionately stands in front of a project to ensure its success and has the capability to do so.

In my area it&#x27;s 10 years of experience and can lead a team or you work like you&#x27;ve had 10 years of experience and can lead a team.

I really like the &quot;Software Inc.&quot; simulation&#x27;s approach. Looks awfully lot like real life, although it&#x27;s a game.

If my current employer is anything to go by, absolutely nothing - at least, nothing that differentiates them from junior devs.

When they understand the difference between software engineering and software development.<p>A senior software developer understands what it means to scale and align software engineers, as a unit or team. This along with understanding that the code is not what matters but rather what the algorithmic design, innovation, invention or discovery that can be done with a particular language or code (or notation in mathematics or music).

0. someone who stands up to management.

Ideally real experience, but often just longetivity.<p>Competence and good communication skills assumed.

Senior by definition means older person. I might be wrong but in other than software industry Senior usually means 20+ years experience from the field? I think person than is valuable for development perhaps should be called something else if s&#x2F;he is young?

I have already made the mistake you are about to make.

it depends

<p><pre><code> because 99% of the available work can be done by inexperienced kids. </code></pre> Now spend some time thinking about the qualifications necessary for commenting and where you stand in that field, and what&#x27;s the difference between what you produced and what a Senior Commenter would produce.

I&#x27;m going to take a different tack: a senior developer is a developer with enough experience that if you subject her to the bullshit processes that work on lower-level developers --- things like scrums, status updates, architecture reviews, and other command-and-control measures --- she either performs badly or quits.<p>Developer seniority is developer autonomy, and autonomy must be matched to skill level and scope.

I have found it to be often nothing more than just a title unfortunately. So many developers I work with have the &#x27;senior&#x27; title but struggle to do actual development, often spending most of their time talking or &#x27;pair programming&#x27; which has completely put me off the concept as they hide behind others helping them all the time but claim they are &#x27;senior&#x27; purely because the hiring manager filled that gap. Pathetic.

You write less code and debug more code.

The answer is simple: a software developer classified as &#x27;senior&#x27; by the Government (e.g. age of 65 in Canada) :-)