Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
Possible Duplicate:
When should you call yourself a senior developer?
I often see offers for senior programmers and the rule of thumb seems to be that you need to have worked three years to become one. Duration doesn't mean much so what exactly is expected of a senior programmer? What should he be capable of doing? As an added question, when does a developer cease to be considered as a junior?
There is (much) more to Software Development than cranking out code.
This leads to: Responsibility
A Junior Developer is still learning the language and frameworks on a daily basis, and thus should be focusing on this. A mentor (or experienced colleagues at least) is expected to guide him, especially the design decisions, and to check on him regularly (and not only his work), nudging in the right direction and sometimes helping out to smooth the path (for example doing the tricky work or handling the configuration/deployment).
On the other a Senior Developer is expected to be autonomous. That is to say, the boss will hand him a feature to implement and let it up to him, entirely, knowing that the Senior Developer will know when to ask for help or review. The Senior Developer should also be able to tell his boss when he'll be done with the task, and actually take responsability for doing so.
The difference therefore is not so much in expertise in the language, but in experience (in general) and reliability.
Difficult, difficult question. Not helped by the fact that I know many people with the title Senior Developer who I would trust less than an enthusiastic Junior. Indeed, I have held that title way longer than I've deserved it.
However, here's the line as I think it should be:
A Junior Developer is expected to need mentorship. That's not to say that a Senior doesn't need peer-review; that is a dangerous attitude. But no question should be considered stupid, coming from a Junior, unless they asked the same question yesterday.
A Junior Developer should focus on development, not on the process of development or the business needs behind the development - although they should be aware that a Senior will need to be involved in those things and be learning about them.
A Junior Developer should not be as responsible for his work as a Senior. Again, I guess this comes back to mentorship. There should always be someone above him, checking his work, and taking responsibility for anything that goes wrong.
A Junior Developer hasn't been there and made all those mistakes. This means he can't be as knowledgable about gotchas and edge cases that come up time and time again. You should not send a Junior Developer alone into a meeting with the business about a requirement, where the technical input is supposed to be "have you thought of this situation?"
The key roles of a senior developer are mentoring and guidance.
It is not so much about how good a programmer you are, but about how well you can communicate ideas and guide team members through their work. Knowledge and experience alone don't necessarily make you a good mentor or guide. But of course you need both to give valuable impulses.
A junior developer is someone who requires guidance and mentoring to contribute to a team. The basic difference between mentoring and exchange among peers is symmetry.
Duration doesn't mean much so what exactly is expected of a senior programmer?
Among other things, good judgement.
When you hire a senior developer from outside, some other company has paid the cost of acquiring good judgement.
The senior developer SHOULD know what works and doesn't work. There are twenty different ways to solve every problem, but he/she should know the best route. And also the obvious technical proficiency with the given technology. But moreso the senior developer should also be correlated as the senior problem solver.
Programming is no different than any other profession.
First, I think 3 years is a good amount of time not to be considered "junior" any more. But there is no way I'd consider someone with 3 years experience a "senior" developer. There is so much to learn beyond syntax that you cannot possibly cover in depth in 3 years. I'd say it takes 3 years just to get enough exposure to different problems to become familiar with a single framework. So for instance if you work with WPF for 3 years, it's possible to become a senior WPF developer (as long as you weren't doing the same narrow set of tasks for those 3 years). But a senior "overall" developer no.
To me a senior developer is someone who can take a feature from requirement to delivery. He or she should be able to also provide guidance to junior developers. What does it take to do something like this? For a standard, Line-of-Business, Multi-Tier, Database-backed application this involves knowledge of UI, cross-server communication, data access, and SQL (or an O/RM if you're going that route).
Learning can be concurrent so if you're working with say WPF and WCF extensively for the same 3 years, you can become quite skilled at the two of them. But there is also only so much you can learn at once. Also it all depends on what kind of training/mentorship you're receiving as you're learning.
Not to sound like a broken record, but I'm going to bring it back to the Dreyfus Model of Skill Acquisition (you'll see me referring to that a lot on here). Repetition is not enough to go from novice to mastery. You have to do applied practice which gradually includes attempting skills that are increasing in challenge. For instance in WPF you would start with creating basic User Controls and eventually graduate to writing fully templated, lookless controls.
There are a number of factors that determine a developers skill level. Time alone is the least important indicator.
Example:
When I started programming with Ruby on Rails, after three weeks I had my first small website, after another three weeks a prototype for a customer, after another six weeks a fully working website online. During this time the experienced Rails developers at the company I worked were a great help to get things right. Though learning the language and the framework was the smallest part.
After a few months of experience with Rails and permanent contact with the Rails community (mailing lists, forums...) I knew Rails inside out. I knew all the 'best practices', I knew what's the best way to do things, not only how to get it run. I knew all the tools that are important and I was able to compare advantages and disadvantages of those tools under certain circumstances. This included experience with various areas of web programming, like full text search in databases, security, online payment systems, REST, CRUD, version control and all the other buzzwords of the web business.
So when a customer asked, if we could implement a certain feature, I was able to tell him what we could do about it, instead telling him that I must see, if it is possible at all. I knew what tools I could use and how much afford I would have to put into writing my own code.
If a new programmer implemented something, I could have pointed out security risks like sql injections. If he wanted to implement a feature I could have told him what tools to use and if other developers in the Rails community regarded them as reliable or if he would have to expect problems.
It's tough to say. On the one hand Senior Developer is just someone who worked x years at a company long enough to get the title of Senior. Some people with the title of "Senior" developer were impressed by stuff I did my first year of work and their code was a total steaming pile of garbage. But because they had x years of experience the company hired them to senior developer. Still they did not care about designing software, just throw in tons of if statements in one or two giant methods, awkward variable names, and get it done. Then have it be so complex that it was a nightmare to debug.... Even in my current company there are senior developers that I work with which just throw all the code in a code behind for an ASP.NET page and duplicate the same code for each separate page.
At other companies Senior Developers are expected to know UI design, object oriented design, good coding practices, how to estimate time, etc.... There was one company where I couldn't even get a role as a mid level developer because my object oriented skills were too weak. At both of my previous development roles no senior developers were doing object oriented design really. The only thing I know of software layering/domain layering/object oriented design I read from books. Overall the Senior Developer who had to practice that all the time and became proficient in it is way better than one with no experience at all.
Overall the lesson of the story is that your mileage varies. Some people get the role just for having x years of experience, even if it is 1 year of experience x times. Different companies have different standards. I want to find one where a Senior Developer is expected to write great, clean, well designed, maintainable software and then work up to a Senior Developer role there so that I will be a real Senior Developer and not just someone with x years of experience who got the title Senior. Unfortunately there are a lot of places that Senior = x years of experience regardless of skill........
Know what not to spend time doing.
