After more than a 2 decades in software development (rails/web/...), for me to consider a developer to be a senior it needs to:
* Communicate: For example: can explain tech concepts to non tech people, or inform on Monday that the sprint will be unlikely to be done in time.
* Can estimate and adapt to changes. Be boring and predictable.
* Can work/collaborate/teach with other devs.
I got tired of interviewing tech people that though that to be senior is the same as to be specialist (or worse even, that it was related with the number of years).
I had colleagues with 20+ years of industry experience who couldn't communicate efficiently, extending every short call to 1h+ meetings, require long and recurring discussions for the smallest details, or define tickets that always had to be reworked. The same people were often off by magnitudes with their estimates and reluctant to suggestions to improvements in their tooling (i.e. linter plugins for their IDE when necessary).
On the other hand, I had teammates with ~5 years of industry experience who outpaced the whole team, delivered optimal quality, were empathic, held workshops for other devs, and still had enough time/power to work on things like refactors.
You think it takes 5+ years to acquire those skills?! Man, I would be driven insane in an environment like that. Such a long time and a relatively low bar.
I think the point is that some people don't acquire it within 5 or even more years. Think of a typical checked-out worker, without any specific ambition in professional life. There's plenty of people like that.
I have worked with people who have 8-10 years of experience and are still mid-level in both skill and professionalism, know that they are, and are fine with it. They get their joy from other things in life and are totally fine coming into the office and doing the bare minimum to get by and going years without raises or bonuses because of it. Again, this is a conscious choice these people are making, they're not being taken advantage of or anything.
I've promoted juniors in months. I've also had people start, stay a few years and leave as a junior. It's all about learning and what work you take on. Also, I see this often when interviewing. 5+ years of experience looking for a junior role. Usually, it's either someone who did not learn and was not promoted, or it is someone from an company that did not let people work on important things because they were junior. So they stayed that way.
What you're discussing has little to do with seniority - those are some personality traits that are great to have, but you either have it in you or not - people who are bad at explaining stuff will usually stay bad at it for the rest of life (but can still be fantastic in e.g. architecting things).
Being a senior dev is IMHO much simpler. It's all about being able to solve problems independently, without needing supervision, guidance or tutoring. If you can pass to a dev some business requirement, and know that they'll return with an optimal solution implementation, you've got yourself a true senior dev.
I was horrible at communicating succinctly in both written and oral form and bad at PowerPoints and diagrams until 2016 - at the age of 42. I definitely wasn’t comfortable talking to “the business” and customers.
I got my first dev lead job and watch how my manager - the director of IT - at a mid size non tech company was able to translate my technical designs and challenges to the higher ups. I learned a little from him through osmosis.
I changed jobs in 2018 and I started proactively working with my CTO (my manager), sales and the documentation writers to become a better communicator.
By the time a chance to interview with BigTech in the cloud consulting department (yes full time job) fell into my lap in 2020, I had no problem passing a 5 round mostly behavioral interview where I had to describe technical accomplishments, business impact, scope, etc in STAR format - over video conferencing without the use of a white board.
I was still a little rough around the edges. But three years later, I consistently get great feedback from customers about my presentations and my ability to explain concepts and challenges to technical and non technical audiences at the same time. I’m not bragging just saying that it can be learned like anything else.
On another note, being able to work independently when spoonfed business requirements is considered mid level behavior according to the guidelines at every single major tech company that I’m aware of.
Can concur, the bar for senior at tech companies is usually that you are involving in scoping requirements and work, or even possibly owning the whole project.
Yes, like any skill, communication is something you can practice and get better. The key is that it’s very hard if you can’t get out of your own head. And when it comes to communication with executives and other very busy people you really need mentorship with situational context unless you really are a natural.
I got a lot of great mentorship here that very much took me to the next level when it comes to communicating with executives and CxOs.
But part of it was also me just watching people who were good at small talk and reading articles about how to be a good conversationalist since I am on client sites and go to lunch/dinner with them.
For instance, since I work remotely, I’m constantly taking notes when I’m on client calls and even with internal people when they mention something about their personal lives - families, vacations, hobbies - so I can ask then about it later.
Heck, I even have scheduled messages on Slack to ask them how was their vacation to $x when they are scheduled to return.
Funny, this is how I (and I think most people I've worked with/for) describe a mid-level dev. "Doing the thing" is a pretty low bar but we don't really expect that from juniors, who typically need hand-holding. To be a mid-level you should be able to operate independently and provide optimal or near-optimal solutions most of the time, but your work is still going to be just focused around you. Most of what you're doing is individual tickets, refactoring, etc., nothing that influences or impacts the broader team. When your impact is beyond your individual work is when you start moving into the realm of senior, and it's part of why it takes time (not just skill) to get there.
> people who are bad at explaining stuff will usually stay bad at it for the rest of life (but can still be fantastic in e.g. architecting things).
How does that work? Explanation is fairly important there, I'd have thought.
> Being a senior dev is IMHO much simpler. It's all about being able to solve problems independently, without needing supervision, guidance or tutoring.
See, I think this may be the disconnect/product of title inflation.
In a system where you have junior engineer/engineer/senior engineer, what you're describing is probably engineer, not senior engineer. In a junior/senior system, it's, ah, a senior junior? :) A senior engineer should be a kind of force multiplier (though such is the level of title inflation that that maybe is now more staff in some places).
We typically use programmer, developer, or software engineer as synonyms as a whole, but I tend to view those titles as more junior/intermediate/senior.
A programmer can program code good enough, but that doesn't mean they are good at solving the goals business requires and communicating it.
A developer can program and develop a small enhancement with good communication. Sometimes can also break things down so other developers or programmers can work on it to.
An engineer an orchestrate an entire new project and can identify multiple areas where developers and programmers can be involved. A good engineer will do so while maintaining great communication with the users to ensure they get what they want.
An architect is someone who comes up with a plan to build something without any real care about budget, labor costs, or labor skills - both in software and in buildings.
"An architect is someone who comes up with a plan to build something without any real care about budget, labor costs, or labor skills - both in software and in buildings."
Disagree for both cases. The building architects I know surely have to work with a given budget and in software architecture likewise.
"An architect is someone who comes up with a plan to build something without any real care about budget, labor costs, or labor skills - both in software and in buildings."
Whenever I hear developers say stuff like this, they just sound junior/inexperienced.
> but that doesn't mean they are good at solving the goals business requires
I wonder if any newcomer to an organization, regardless of how senior they are, won't be in this same position. In order to solve business goals, they need to understand them properly. In order to understand them properly, they need context. The context comes from working in the organization for some time (months to years, depending on the size and the transparency of the organization).
> An architect is someone who comes up with a plan to build something without any real care about budget, labor costs, or labor skills - both in software and in buildings.
This is definitely not true. I always have to balance on time/on budget/meets requirements and the skillset of the people who are using my designs.
Whatever about a software architect (that can mean practically anything; it's very fuzzily defined) that's rather unfair on actual architect architects, who are absolutely concerned with the practicalities.
I'm my environment, senior developer needs a deep understanding of technology but more importantly a deep understanding of business and business processes. I'm in the ERP space so a senior Dev can talk business language - they Co develop and guide functional specifications with business analysts. In other words they understand hr or pay or financial processes of the company.
I wish I could assume all those other qualities as well, but while some here think good communication is easy to acquire early, my experience is the opposite - there are many 20 year veterans that cannot / should not be put in front of a client. They are wizards at technology but not at communication - presenting things to non experts, understanding other points of view, etc. You have to WANT to learn things other than technical proficiency, and even here, that's frequently derided / seen as uncool. "Manager" is of course a swear word insult so anybody who wants to learn communication or empathy or estimates or hard conversation is "no true techie" :-/
Hahah, It's the old story of the elephant and the blind men. There are so many ways to be a senior engineer, and it is, in my experience, very company dependent.
tl;dr: being a senior engineer at a startup is different than at a consulting company is different than at a large retail firm is different than at a FAANG.
This is the big difference - seniors will track and resolve a roadblock or issue that they could justifiably ignore, in particular where other people in the organization are being difficult or obstructive, giving incorrect guidance, etc.
A junior will just go "We were told it cant be done/will take 5 weeks" whereas a senior will know that's bullshit and escalate it to the right people.
After more than a 2 decades in software development (rails/web/...), for me to consider a developer to be a senior it needs to:
* Communicate: For example: can explain tech concepts to non tech people, or inform on Monday that the sprint will be unlikely to be done in time.
* Can estimate and adapt to changes. Be boring and predictable.
* Can work/collaborate/teach with other devs.
I got tired of interviewing tech people that though that to be senior is the same as to be specialist (or worse even, that it was related with the number of years).