developer vs senior developer

[rh71]

Career-wise, I'm not quite sure who fits the "senior" description, especially in the realm of web apps. I have over 15 years on the job but at the same time it's all been similar work, though I have grown skills on my own. I've worked entire projects from concept to delivery and easily work without supervision. What makes a person qualify for a "senior" title when looking for their next job, especially with salary requirements to be considered? I don't want to be in over my head nor would I want to lead other team members (as bad as that sounds for career advancement). Opinions/experience/examples on this?

 

[Spungo]

Engineering levels in general terms:
Junior Engineer = You really don't know what's going on. You can do great work, but you need a boss to guide you and tell you what you should be working on.
Intermediate Engineer = You have a rough understanding of how things work. You could probably design something from scratch as long as you had a template to follow.
Senior Engineer = You have a very good understanding of how things work. You can start projects from scratch without being given a template.

Suppose I want you to design a tank farm for an oil refinery. I need X capacity, and the various flow rates are Y. You might know a lot about math and CAD, but would you have any idea how to get this thing off the ground? What to build first? What order things should be designed? If you can get to work on this right away and delegate tasks, you know enough to be called senior. If you can roughly piece it together by looking at plans of a different tank farm, you can be called intermediate. If you have no idea what should be done first, you're junior.

Most of this should apply to programming. If I told you to make a program like Microsoft Excel, would you know how to start the project? Would you be able to tell other people what they should be doing?

 

[oMega_2093]

I'm curious about how that engineering approach applies to this matter, particularly when talking about web development. I can think on some situations where I feel I am able to put it all together without help at all, which makes me senior, but above all, makes me feel good about it

 

[smackababy]

The difference between a mid level and a senior developer, in my opinion, is the ability to do more than develop. A mid level developer should be able to take fix defects and complete adding new requirements. A senior developer should be developing those requirements, estimate time requirements, and design features.

 

[clamum]

I would also think as you raise in seniority as a developer, you're going to begin to lead other developers. I would think it comes with the territory and it just makes sense. Well, maybe not be directly in charge of them, but you'd probably be helping out junior devs quite a bit I'd think.

 

[Merad]

Engineering levels in general terms:
Junior Engineer = You really don't know what's going on. You can do great work, but you need a boss to guide you and tell you what you should be working on.
Intermediate Engineer = You have a rough understanding of how things work. You could probably design something from scratch as long as you had a template to follow.
Senior Engineer = You have a very good understanding of how things work. You can start projects from scratch without being given a template.

Ha, my first day of my first real SE job I was handed a new project of a type that I had zero prior experience with. But hey, I'm me. :awe:

 

[dave_the_nerd]

About ten years, a bunch of gray hair, $25k/yr or so, and a bunch of weird crap in their cubicle.

 

[sourceninja]

Junior devs - fresh out of school, need to learn to program
Devs - Know how to program, need to learn how to communicate
Senior Devs - Know how to program and communicate.
Project Manager - Knows how to take all the credit for the above.

 

[Spungo]

A mid level developer should be able to take fix defects and complete adding new requirements.

Another thing would be dodging problems before they are problems, and taking maintenance into consideration. A good engineer will have a lot of planned points of failure. If I'm making a bridge or something, I should know exactly where it will break if it breaks, and it should be easy to fix. I should be able to tell people exactly what to look for. Saying "check every inch of the bridge for failure" is too vague, and it's a safety concern because a task that time consuming will never be done. Also, being forced to shut down all lanes of traffic on the bridge to fix any kind of problem is unacceptable. Maybe it should be possible to do maintenance on this thing without closing any lanes of traffic. Would it be acceptable if Google had to shut down their entire website to do maintenance? What happens if someone trips over a power cable? Does it shut down their entire website, or does the software try to automatically work around the failure? A good engineer is aware of all the stupid things that can go wrong.

Imagine you make a program that has tens of thousands of lines of code, and it has this weird issue where the program sometimes crashes after 20 minutes. How do you fix this problem? Did you have any plan for handling errors and tracking down the sources of problems? Once you figured out what the problem is, will it be easy to fix? Or is the program a giant tangled mess where changing one thing breaks several other things? You're not a senior guy if fixing things is a giant problem. One thing that comes to mind is when we had to jackhammer a bunch of concrete to replace a failed power cable. You know your design sucks when replacing a cable requires a jackhammer.

 

[sm625]

If you quit, would your company be more or less screwed compared to if anyone else in your dept quit? If more, then you are a "senior" developer.