Apps optimize

What makes a developer "senior"?


In many industries, a senior level position is based mostly on the length of time that person has been working and maybe a standardized test or two. But what exactly defines a "senior developer?" This is something that I have been wrestling with for the last few weeks. The more I go through the hiring process (I am helping to hire people -- I am not looking for a job), the more I have to ask myself this question. I know some of the general characteristics, but the details are driving me a bit nuts. And, it makes a difference because job title drives not just salary but also one's future career opportunities. Someone may be doing "senior developer work," but if they want to be a software architect, it may hurt them not to have the title. On the flip side, if I am told that we are looking for a "senior developer," and the person who I think is right for the job is not one, I have not made the right decision.

Here are some of the basic qualifications that a "senior developer" should have: 10 years of experience in the programming field (although seven or eight may be enough depending on what they have been working on), a rock solid understanding of theory, and excellent debugging skills. They also should be able to: work closely with the software architect to suggest improvements within the overall vision for the project; ask questions at the architecture level and not at a low implementation level; and serve as a resource and mentor for less experienced developers. You should also be able to trust him or her to transform a set of class diagrams into quality code with little oversight. A "senior developer" should not require handholding.

But is it better to have, for example, a "senior developer" with four years of VB.Net-only experience and eight years of VB-only experience before that? I would imagine that 12 years of working with VB certainly has made that person a VB/VB.Net expert. On the other hand, someone who spent those same 12 years bouncing around Java, C++, Perl, VB.Net, and C# has had a much wider range of experiences to draw upon. Personally, I am attracted to the latter simply because it more closely resembles my own experience, but I think the former route holds many advantages as well.

Also, does someone who spent equal time on traditional client/server apps and Web-based apps have the same weight as someone who spent the same time working exclusively with Web-based apps? The client/server person has exposure to solutions to many of the problems that dog Web apps, but the Web-only person may have a unique insight into the bizarre oddities of Web development (the HTTP protocol, for starters). Again, there is a tradeoff between a specialist and a generalist, both with equal lengths of time in the industry.

I would love to be able to ignore the self taught vs. formally educated aspect, and I usually do. I have been able to simply verify that candidates have an appropriate amount of theory (I have found that this is the stuff that is easier to learn in school than on one's own), which weeds out both the self-taught folks who learned too many bad habits and the people who slept through their degree.

The last major hurdle are people who have spent enough time in the work force to be considered senior but who have never worked on anything more complicated than a simple CRUD app. This is a tough call for me. For all I know, they have been so deep in that simple CRUD app that they know their stuff inside and out, even though their project does not really express it. On the other hand, there are people with experience that is indirectly related to programming and yet very helpful. For example, I have found that my time spent as a systems administrator and doing networking has been vital to debugging many applications, particularly on the deployment end of things. How does nondevelopment experience fit into the "senior developer" position?

Leaving all of these other considerations aside, there is the matter of personality. Am I willing to put up with someone who has less than an agreeable personality but has amazing tech skills? Or do the leadership responsibilities of a "senior developer" allow for someone who is a "good fit" as a person to offset a technical shortcoming?

I do have my own idea of what makes up a "senior developer." For the sake of maintaining the integrity of the hiring process, I will not put it out in public at this time in case someone does a bit of homework and tries to game the system. But I would love to hear what your thoughts are about what makes a "senior developer."

J.Ja

P.S.: I may not be able to reply as much as I usually do because I am currently on a high alert with the baby watch. I told her that she was in trouble -- I know that if I was two or more days late on a nine-month project and did not tell the PM so they could update the Gantt charts, I would be in trouble! Just kidding, of course. But I will be looking forward to reading your feedback!

About

Justin James is the Lead Architect for Conigent.

80 comments
vvzoltan
vvzoltan

Please correct me if I'm wrong, but I think a lot of the expectations mentioned here are a bit out the scope of the "senior developer". I'm a Flash developer (yeah, a dying breed), so all my examples will relate to that but I think it should be applied generally. First of all, shouldn't we make a difference between a "senior developer" and a "senior Flash developer"? If my title says Senior Flash developer, I think at most you could expect me to be able to quickly come to grasps with other languages and/or technologies, not to already be fluent in them. My title should only imply that I know the Flash platform inside and out (I'm not just a good AS programmer, but I also have a thorough knowledge of how the Flash Player works, and anything related to the platform). This said, I wouldn't call myself a "Senior developer", because I'm only an mid/junior developer in any other language/platform. My title can only say "Senior" if it's in front of "Flash". As far as personality goes, I don't think it should matter (unless I'm an egomaniac jerk who can't comply with anything because I know best). The title still says "developer". You don't have to be social/communicative in order to develop. A PM or a team lead needs to be, in order to be able to explain/delegate/lead/manage/etc. Excuse me if this sounds a bit over simplified, I am aware of this, I just posted this in contrast with the previous comments for the sake of the discussion.

bastien
bastien

From my experience and PoV, I would have to say that leadership ability and communication are the top priorities over skills in any one area. If you know several languages, then any new language is mostly a matter of syntax but leadership is not something you can learn easily. We have this current situation at our shop where the leadership and communication are lacking. In filling in that role, its led to friction with the other team member whose job its supposed to be. Its an awkward situation, but the junior members and the clients are happy with the level of leadership I demonstrate. Sigh: if only it came with more $ instead of #$#%#@$#%

TheGooch1
TheGooch1

This article brings up several good criteria categories for selecting a candidate out of a host of applicants. I would say that its safer to layout the criteria in this format so that you can adjust it to the requirements of the position. So, if you need a VB developer who will sit in a corner and code to the specs you throw over the wall, then you might lay it out like this: Experience: 10-12yrs VB or VB related tech. VB.Net a plus. Design exp required, good self-documentation. Personality: Communicates well but keeps it brief. Education: BS or equivalent work exp( already needed for the experience category ). If you want him/her to be a project lead, then you need to test how well they work in a group. Team lead/PM experience would make this easier to judge. Do they schedule things? Do they establish milestones? Can they summarize a day's or week's worth of work in 15 minutes?

bluemoonsailor
bluemoonsailor

Here's a basic scale for rating - Apprentice/Intern - What problem? Junior - Hey, there's a problem! Journeyman - Don't bother me I'm busy working on the solution to our problem! Senior - This would have been a problem, but I fixed things before it could actually become one.

knudson
knudson

I would say that the title of "Senior" is bestowed upon a person based on their scope of involvement. While there are a lot of different titles thrown around out there, most can be consolidated into three buckets -- programmer, software engineer and architect. For this article I'm dividing up the software engineer into junior and senior to try and define what makes a person a "Senior" software engineer. Programmer - Translates detailed specifications or pseudocode into source code with little or no design involved. Basically produces a 1:1 mapping of the instructions provided and the source code result. No decisions on data sturctures or algorithms are made by this person. Scope of responsibility is limited to this direct translation. Developer/Software Engineer - Takes high level design and implements a solution. Scope of responsibility includes the analysis of the problem at hand and the ability to formulate a good quality solution that meets all of the objectives (i.e. size, speed, latency, etc.) Decisions on data structures and algorithms are made by the developer/software engineer. The developer/software engineer should be able to create accurate estimates of the work items assigned to them and should be able to manage their own schedule. Should have an expert level of familiarity with the code they write. Scope of involvement is within the features with which they have ownership. Senior Developer/Software Engineer - This person should be able to assist in the "big picture" design of a solution, and be able to articulate the integration strategies between development teams. Scope of involvement is global to the project -- they should have expert level knowledge of the areas of ownership for which they are responsible (including any team of developers who report to them) as well as the ability to quickly look at and understand code in other areas. Should be able to perform code reviews and provide quality constructive criticism to junior members of the team. Expert debugging skills -- should be able to jump into any code and determine the cause of a problem and formulate an acceptible solution. Key advisor to the architect, mentor to junior developers, depending on people skills may also be a lead/manager of a team. Should be able to identify risk elements early in the process and drive the appropriate response to dealing with it. Very limited oversight should be necessary for a person at this level -- they should be in full control of their own schedule, their team's schedules, and the feature set which they own.

Dr_Zinj
Dr_Zinj

Simple, if you think the person can do the job, even though they don't hold the title of Senior-whatever, do a conditional contract. Hire them at the lower rate conditional on their performance over the next six months. If they can hack the job, they get permanently hired and their salary jumps to the expected level. (If their performance was above and beyond expectations, pay them the differential as a bonus for the past six months) While someone who has programmed in only one language for 10 years is probably an expert in that language, without other forms of experience, they probably have holes in their skills. A programmer 'ought' to have the majority of their experience in programming in that language, but if they have a couple of other languages they have worked with, especially if translating code from one language into their primary or vice versa, then they are probably even more valuable in that they have a broader understanding of how things can be done differently; which means they are going to be better at finding alternate solutions to otherwise insolveable problems. Programmers with application user-level experience or support experience are also more valuable than a 'pure' programmer in that they usually have a better understanding of what a business is really looking for in the way of functionality.

CodeRipper
CodeRipper

I'm the Chief Software Architect in my company. For me, a senior developer should have sound technical skills (able to translate software architecture diagrams into coding) and also leadership skills to the extend of assisting junior developers in understanding the project development concepts and theories and also debugging. In terms of management soft skills, a person in a senior developer position should be in the process of learning and moving up to a software engineer/architect/PM level (whichever applies to the respective company). Generally, in a more loosely speaking term, my senior developers are my "assistants". They "may" not be able to design the whole software architecture framework, but could at least translate the framework into codings and explaining the framework fluently in laymen terms. Just my 2 cents.

hsteeman
hsteeman

I think there's no single definition of a senior developer. It depends on the situation, but in general it's not only about technical skills. I think the 2 most important things are: 1) in which way do you solve most problems (any problem) 2) how can you cooperate with other people?

Tony Hopkinson
Tony Hopkinson

does not make you a senior developer. Knowing when to use it, when not to, how to cope with the tipping point from one to the other. How to explain those decisions and be understood. There several other traits that are exhibited by senior developers, one of them is recognition of ignorance, so may be you don't need Flash to be senior.

wizard57m-cnet
wizard57m-cnet

on this post...all the participants left the room, only thing left is chirping crickets.

rclark
rclark

The only real definition of Senior anything is responsibility. Does this person have the ability to tackle problems, get solutions implemented, using the resources we have available without involving me more than I have to be to communicate project status. If you want a good one long term, you don't look for McGivers, you look for people with a long history at one company. The theory being they would have run his tail off if he wasn't good...

kovachevg
kovachevg

Your description is short, pithy, and right-on. I've rarely seen s.o. put it so well. More formally, a senior person steps back, evaluates the big picture, and comes up with solutions that solve not only the immediate but also the potential problems. However, if one said it my way he would appear to be political. Your style is much more down-to-earth and thus more natural. I love people who make things simple, even when things are so complex. Thumbs-up, pal!

Justin James
Justin James

Now, how do I find out which bucket they fall into before hiring them? ;) J.Ja

Justin James
Justin James

Now, how do I find out which bucket they fall into before hiring them? ;) J.Ja

doug.cronshaw@baesystems
doug.cronshaw@baesystems

I would expect a Senior Developer to have working knowledge and demonstrable experience of at least two programming language groups. (Those groups would be (i) Fortran-based, including BASIC; (ii) C-based, including Java, C++ & C#; (iii) Algol-based, including Ada, Pascal & Delphi; (iv) COBOL and its derivatives; (v) Assembler; (vi) Web-based script languages such as HTML, XML, CSS & JavaScript; and (vii) others sufficiently different not to be included in the previous groups.) Done this way, an estimation of future usable skills can be derived from current working knowledge of another member of the same group since it is usually easier to transfer to programming in a language which shares concepts. (It cost me almost no effort at all to pick up Delphi and Ada from a thorough working knowledge of Pascal, and I performed a similar transition to programming in Visual Basic from twenty years of previous Fortran experience.) "Assembler" might seem an odd group to consider as a collection of programming languages because of the instruction-set specificity of most assembly language. Here again, though, some of the quirks of assembly language programming for one instruction set tend to get used in other assembly languages. You need to be a lot more aware of the differences in the use of directives, order of operands, etc. to be able to switch smoothly between programming in several assemblers. [It has to be said that I would be suspicious that someone who had only programmed in one language for 10 years was not an expert in that language - despite their exposure - and that the reason that they were still doing developments using that sole programming resource was because they weren't expert.]

Justin James
Justin James

I like the idea of conditional contracts, but they are very rare in the current corporate culture. Heck, trying to negotiate a benefit package outside the "one size fits all" like having additional vacation time, or lower health insurance premiums, are hard enough! Whether we like it or not, HR tends to not have much wiggle room for a variety of factors, and as a result, conditional contracts are just not going to happen for most companies. It's one reason why "contract-to-perm" is so popular, it acheives the same thing without allowing someone to be an actual employee. J.Ja

rclark
rclark

Over the years there have been many, many languages. Many more paradigms, packages, and forevermore new next best things. I have found that concepts in general translate. The more I see, the easier it is to learn new ones. But there are gotcha's also. You expect the person who designed the language to do things like other languages and then they go left turnsey on you.

D.W. Odom
D.W. Odom

I agree with your comments for the most part, but most medium/small companies highest position is a Sr Programmer/Analyst, ie Sr Developer. I personally have been programming since the late 70's yet the highest "Job Title" as a developer/engineer has been the Sr Programmer/Analyst. Hiring managers can loose quality people if all they look at is the "Job Title" on the resume. "Job Titles" generally designate their last held position, but do not necessarily accurately describe what job function(s) they performed. For example, at a company I held a job title of Sr Programmer for more than five years, but the company decided to also utilize my skills in other areas. For example, at this company I was filling the position of IT Manager for the last two years. Even though I held this position, I was never offically given the job title. So the description of my job will be different than the job title. You cant say your Job Title was IT Manager on your resume, unless you lie, which is grounds for termination. Hiring managers need to pay more attention to the descriptions than the "Job Titles". In reference to the original article, it appears that the author prefers someone who is book smart, not real world smart. At some companies this is acceptable, but at smaller companies, you need someone that can troubleshoot a production system that has just crashed, and get it back up ASAP. They cant wait for someone who can only figure things out by a "pre-printed checklist". Just my opinion :-)

CodeRipper
CodeRipper

Your second point is very true indeed. During my years of under employment I've learnt that, no matter what background you are from (technical or non technical), people skills are very important for you to move forward. We technical people are normally introverts that do not speak much. I've tried and spent a long time to get out of my own shell, and finally, brushing up one's people skill does makes a lot of things easier. And also it makes the person more receptive to new ideas. I believe people skill is very important for technical to climb higher in their career path.

Justin James
Justin James

I agree that any "senior" developer should have those traits (I would not hire one without them!), but it is really hard for me to justify to HR a "senior" salary without some concrete item (work history, experience, education, skill set, etc.). J.Ja

vvzoltan
vvzoltan

Anyway, I just gave it a try, maybe some people out there have a fresh look on this :)

rclark
rclark

Just a figure of speech. By the by. Some of the best long term senior people tend to be women for some reason. May be a glass ceiling, or may be that they have the fortitude to stick it out, but some of the best senior people I've ever worked with are women.

bluemoonsailor
bluemoonsailor

Actually this is a summarization of something I learned at IBM of all places. Back in the mid-80's they called it "Completed Staff Work". Funny how the more things change, the more they stay the same! ;-) Steve G.

Tony Hopkinson
Tony Hopkinson

One of the keys being you can apply your skill(s). Given programming is the skill, if they can't pick up another language to at least being productive nad competent within a month, then you'd be right. I've seen people with lots of languages and lots of claims to being expert in them, who in my merely competent opinion shouldn't be allowed to program a VCR. :( How about a guy who claims 7 years in Delphi Client Server Database applications, doesn't know what a transaction is? His resume made mine look like a primary school report card, mine isn't bollocks though. Judgements based on number of years, number of languages etc are as useful as number of certs. If you've got a lot of applicants, you can chop it down to a manageable size. Always bear in mind the pecentage of those who can, will be near enough the same in both piles, for all but the really high end jobs.

Justin James
Justin James

Doug - I agree about language variety. I really like it when there are not just 2 (or more) "families" involved (like you describe), but more than one paradigm (static & compiled, dynamic & interpreted, functional [compiled or interpreted]) too. For me, the time I spent in Perl and Scheme, while rarely relevant to my current C# work, still informs my thinking significantly. J.Ja

Realvdude
Realvdude

The pitfalls of a contract, is that there has to be exact measures of fullfillment and requirements, otherwise ending a contract may give way to litigation. If an employee is not measuring up, you can fire them, and if the requirements are beyond what they expected for the compinsation, they can quit.

normhaga
normhaga

I have tried the conditional contract as an employee. It is very hard.

Tony Hopkinson
Tony Hopkinson

will look for the left turn, becuase he knows it must be in there. A less experienced one will invent a turn method with a left/right property

Wayne M.
Wayne M.

I think D. W. Odom captured a point that I tried (poorly) to make. In general, I would not use the titles on a resume to filter people out. I expect the title in the job request or advertisement to filter those who submit a resume for consideration. The only exception is if the most recent title is clearly out of line with the desired position, but even then I will scan the work done in that position before deciding. Past titles are pretty arbitrary, so I am willing to give a pretty broad range of interpretation to reported titles.

ryan.bost
ryan.bost

I agree totally with your first two paragraphs, but need to clarify your last one. Anytime anyone mentions book smart vs real-world smart, the perceived notion is that one can't have both. I completely disagree with this perception. I was formally educated, have a degree, and continue to increase my knowledge through books and the web. I also have 10 years of experience applying my knowledge in real world situations. I feel that both types of "smarts" are a must for anyone in a senior level position. And as far as someone who can only figure things out by a "pre-printed checklist", they should be on the help desk and not in a senior level position. Advanced troubleshooting skills are a prerequisite for any senior IT position.

Tony Hopkinson
Tony Hopkinson

In the main we put together systems to interact with people, bit hard to do, if you can't interact with them yourself.

Justin James
Justin James

That is indeed true, a poorly done multi-threaded app is worse performing that a poorly done single threaded app, and chews up CPU even worse! I feel that to squeeze more performance, or even maintain existing performance, developers overall are going to need to become much, much more "senior" overall. This fantasy that programming is "magic" neess to be dumped too, there is little creativity in properly *engineering* a piece of code. Indeed, the "creative" programmers typically are the ones who are smart enough to figure out a kludge, but not knowledgable enough to know of a standard approach to the same problem. J.Ja

Tony Hopkinson
Tony Hopkinson

really comes into it's own with more hardware. Not to mention we've both seen multi-threaded designs, which are less efficient than single threaded, especially if they are squeezed into less than optimal hard ware.

Tony Hopkinson
Tony Hopkinson

It says. you don't have to write this correctly, you don't have to optimise it, you don't have to go for the best design, just put some more horses under the hood. However in general economic terms, it gives those in power just about everything they want. Cheap to make a margin, short lived to make a another sale, de-skilled to take out the arcane, and guarantees overall a constant drive for more product as opposed to better product. Small business Blade rack anyone? Assembly language, optimisation with anything is dying art. The fact that is more of an art than a skill being a 'big problem' in the eyes of the guys with the cash.

Justin James
Justin James

Throwing hardware at problems is increasingly less effective. to put it simply, clock speed has stalled over the last few years. The only thing that is getting the CPUs faster is multiple cores. I would not expect core speeds to break 4 gHz any time soon, 8 core CPUs will be common before that happens. The only way to have the software make use of this is multithreaded development. Luckily, this coincides with the evolution of Web based apps, so most coders can let Apache, IIS, or their J2EE container handle the overt multithreading; even then, though, counting on faster clocks to speed apps up just does not work like it used to. J.Ja

normhaga
normhaga

While I agree that is most often less expensive to throw faster hardware at a problem than it is to use low level languages, the throw hardware attitude creates it own set of problem. The bloatware issue is a big part of this. As a developer you have to responsibility to use the available resources wisely. At a hardware level you do not have the opportunity to use much high level code. At a high level you may have to work around a bug in the development library, which contrasted to the low level, you may find the bug in the code; both are expensive. There are many issues to consider - development, maintenance, lifespan, etc. But, assembly language programming is a dying art.

Tony Hopkinson
Tony Hopkinson

cheaper to throw more hardware at a problem. Very rare I get the opportunity now, last the last thing you want to do is dive that deep into other people's code. That's a resource consuming operation.

Freebird54
Freebird54

developer who drops to a lower level language to make a better left turn at higher speed? I know that's getting rarer - but I can't count the number of programs I've done that include a 'business logic' in a higher level code, and the grunt work done in C, and critical bits in assembly.... No - ignore this - that's giving away my age!

Freebird54
Freebird54

a job that included the following: 1. List processing/cleanup - including conversion from up to 30 different formats incoming. Some of them exceeding 17 million records (speed counts) 2. Preparing such data for merge runs 3. creating the merge objects 4. creating tools for the conversions and cleanups (speed counts - both creating and running!) 5. creating standards for the finished products of the processing and conversions 6. creating one-shot data entry programs specific to a given project. Must be incapable of creating bad inputs (?) 7. Oh - and manage 3 people doing the same things at a similar level.. 8. - and specify, deploy, and manage a network company wide :) What's the job title for that? And how do you put it on a resume? You can't really say that you were the IT department - especially as there was a manager 'above' me...

Justin James
Justin James

I think you completely missed the point of my post. I was not saying that the example you gave and the example I gave were the same thing, not in the slightest. But they have the same purpose, which is to work around the heavy reliance of keyword driven candidate filtering. For someone to list "assumed the duties of project manager" when their "official job title" was "developer" (or whatever) is to make sure that his PM skills are seen by someone looking for a PM. At the same, basic level, the "familiar with..." trick is to get your resume in front of someone who might read it and say, "while this person is only 'familiar' with tech XYZ, they have everything else I need", when without that keyword bait, the resume may have been missed. Indeed, concepts like this are some of the things I am currently working through on my project, how to dump the reliance upon keyword based searching, or improve it significantly. J.Ja

kovachevg
kovachevg

If you take the time to read the post I replied to, you will see that the person who wrote it took up the duties of a project manager on a regular basis. I am sure he did NOT mean that he "read a book about it 3 years ago". The point I made is that you can claim the skill set even though you do NOT have the title and you can do it in a legitimate way. The goal is NOT to play the system but to trick the mind set. I only hope you can see difference.

Justin James
Justin James

... you see resumes filled with "familiar with XYZ technology" which means that the person read a book about it 3 years ago... J.Ja

kovachevg
kovachevg

The web has increased access to job positions exponentially. Every average Joe can submit a resume for a job available online. Thus it became necessary to screen as many resumes as possible electronically. Come on, guys, you know how this works. The first thing you need to do with 3000 resumes for a single position is to reduce the stack to a manageable size. Smart screeners/HR people know there is a decent chance a good person may accidentally be screened out. But what are the consequences? Let's say that in a stack of 3000 resumes there are 20 that really strike the tone and the experience level. If you killed 2 or 5 because of an inefficient process, so be it. After all, you only need 7 to 10 max. I know, it is not fair, but the reality is than an HR person has his deadlines. He is focused on the needs of his company to fill in a position so that work can get done and he knows the same job can be done by different people. So, what do you think he is gonna do, go blind on paper work? Bottom line is, if you have the senior experience but not the title, either get creative or skip the job post. When I say creative, do NOT read "lie". For example, "regularily fullfilled the duties of a project manager". Now you've accomplished 2 things - you did NOT lie, and you got that job title in your resume. Alternatively, ask for a title. If you truly fullfil dual roles at your company, it shouldn't be a problem. It costs the company close to nothing to attach an extra title to your profile :).

Justin James
Justin James

For the same reason I can't figure out what makes someone a "senior developer", I have no idea what someone else's previous titles mean either! My last job, my title was "Senior Programmer/Analyst". I always joked that the "senior" part was meaningless; as the only true developer there, I had no one to be "senior" to! And I was the *entire* IT department anyways. My current job title is "Technical Analyst"; HR still does not even have a job description for it, and my duties are constantly shifting. J.Ja

Justin James
Justin James

You are, unfortunately, 100% right. That's why developers who know what they are doing without being spoonfed are so important! If it is going to be written once and in a hurry, a developer who is out to lunch is either writing too slow or too shoddy, and probably both! J.Ja

rclark
rclark

Justin: You are going to run into more slash and burn coders in the upper development ranks. Lets face it. Most software doesn't have a shelf life today. Use to be that a long lived piece of code would last maybe 3 to 5 years. Now it's lucky if it actually makes it into production before it's obsolete. This instant development/integration/deployment model lends itself to slash and burn coding. If you know it's not going to be around long, why spend the time to document the system.

Justin James
Justin James

"Book smart" vs. "real-world" is a non-issue. I beleive that someone forced to spend years studying theory in school is more likely to know the theory than most self-taught people. But I do not beleive it is the only way. That is one reason why I like people who spend a lot of non-work hours with programming, whther it be personal projects, working on FOSS, reading magazines at a level of Dr. Dobbs, MSDN Magazine, etc. That's the kind of activity that teach theory outside the classroom. I am also well aware that most classroms do not teach much theory, either. The point is, if I want someone to do a coding job, I want them to understand that just because the program produces the right output given the right input does not mean that it was coded right! In other words, I do not want to spend more time doing code reviews than I do laying out the architecture, at least not for a "senior" developer. I have met too many people claiming to be "senior" who do not know the *underlying* difference between pass by ref and pass by value; I need a "senior" person to know the difference, and choose the right one for the situation! J.Ja

D.W. Odom
D.W. Odom

So are saying that you feel that unless you have formal education (ie a college degree) you shouldn't be in a sr level position? I may be misreading what you are attempting to say, but this is what I am seeing.