TL;DR - Sometimes I get an impression that there are people who got "promoted" to Senior Developer even before releasing anything to production ... Clearly the length of tenure is not the key determinant here, but neither should be the 100% memorizing of given framework's / library / language's full syntax. There are certain much important qualities that may be harder to assess, but in fact are a pure essence of Developer's "seniority". This is a post about these qualities.

If you've read my recent post, you already know I've spend a lot of time researching software development career job offers recently. Actually I was looking for more senior, manager-level positions, but out of curiosity I've also spent some time on browsing various junior-to-senior dev positions - to find out: who's hiring, what are typical expectations, how are employers advertising themselves & attracting the new talent. I had some interesting observations & one of them is a huge devaluation of the word "senior" in many of job ads I've seen.

Pre-mature "aging"

According to many (recruiters, head-hunters, intermediaries) the best determinant of "seniority" for a developer (Senior Developer, I'll be using an acronym SD from now on) is:

  • ~3 years of professional experience & ...
  • ... being familiar with 5-7 chosen acronyms/names (usual programming languages, platforms, IDEs, frameworks or libraries)

Such a state of affairs has a simple justification:

  1. modern technologies are much more approachable than 10-15 years ago - we have better IDEs, free access to documentation, countless tutorials/samples/MOOCs, even on-line mentors; a smart & motivated youngsters can learn all the syntax, conventions, even companions libs & tools for an average platform in a year quite easily (15 years ago it could have been 5+ years!); such textbook-style, dry knowledge is also the easiest to test (e.g. during job interviews)
  2. the other reasons is ... greed - head-hunters & body-leasers are struggling to fill even junior positions, not mentioning the senior ones - hence they try to push through anyone ones who sometimes have great potential, a lot of motivation, are real fast-learners, but miss relevant & deep-enough hands-on experience in "the heat of battle"

Needless to say, I totally disagree with the determinant above. This "definition" says nothing about the real qualities needed by SD, actually I can easily imagine a person who meets this definition perfectly, but knows only "the happy path" coding, has never encountered really challenging support situation, doesn't even know how her/his code is built (not mentioning the deployment ...) & has a very limited experience with so-called good practices (like automated testing, code reviewing or keeping the balance between coupling & cohesion).

Si, Señor(/a/ita)

Who is a "Senior Developer" according to myself then?

SD is an individual who:

  • knows & understands (in details) the entire software development life cycle (for the stuff (s)he builds & runs) - keep in mind that it doesn't mean "full spike" in terms of architecture (not everyone is full-stack ...), it means end-to-end in terms of development process (including production deployment, maintenance & even decommissioning)
  • understands & takes under her/his consideration not only algorithmic correctness of the code, but also such qualities as its maintainability, performance, extensibility, security, usability, etc.
  • "speaks" fluently the ubiquitous language of engineers - can vary depending on the tech, e.g. design patterns (at various scale), SOLID principles
  • has practical understanding & ability to apply/handle platform-agnostic software engineering concepts like asynchronous programming, error/fault handling, buffering, caching, logging, state management, coupling, etc.
  • has MASTERED 5 key software engineering skills:
    1. debugging (yes, I'm not joking, actually very few developers REALLY know how to debug efficiently)
    2. troubleshooting (which is obviously something much more than debugging alone)
    3. refactoring (in controlled, iterative way, w/o breaking anything)
    4. testing (not just automating, testing your work in general)
    5. documenting (again, I'm very serious about this one)
  • independently proposes & creates a robust solution when being given a specific level of control: boundaries (usually at component / module level), constraints, success criteria & key metrics; in other words: own (& take the responsibility over) the tech vision on set level, drive towards completing it
  • anticipates, assesses & (according to the result of this assessment) handles/raises technical risks/issues within her/his range of control
  • at last but not least - is able to tutor & coach at least 2 juniors on the daily basis: review their work & give feedback, elaborate on design & code practices, efficiently share both domain & technical knowledge - supposedly be an inspiration & a role model to copy from

Quite a few points, but these are just the most important ones. And yes, the bar is set quite high - some may get to SD level in 3 years - it IS possible (but not very likely & you will have gaps), 5 or 6 years is more feasible, 8-10 still fully normal, but there are many who will NEVER get to this point: some are too pigeonholed (& do nothing about it), some will never bother with full SDLC & some are too passive / insecure to either take ownership over anything or help youngsters grow.

Some may disagree the lengthy definition above & even find it more like qualities of a "Software Architect" (SA), but frankly this is another heavily devaluated term than needs re-clarification of its true meaning. Real, effective & capable SA is actually much more, but ... this is a topic for another, completely separate blog post :D

Pic: © Michael Flippo - Fotolia.com

Share this post