September 15, 2015 at 8:41 am
When I saw the title "Who's a good developer?", my mind connected to the old Bob and Tom radio show's pet loving "Who's a good boy?" or "Who's a good dog?" done in that speaking-to-dog voice. Oddly coincidental, a developer who doesn't crap all over everything or chew stuff up would be preferred. Also, they need to take a swat from a newspaper occasionally to keep them on track, right? :laugh:
September 15, 2015 at 8:54 am
jschmidt 17654 (9/15/2015)
When I saw the title "Who's a good developer?", my mind connected to the old Bob and Tom radio show's pet loving "Who's a good boy?" or "Who's a good dog?" done in that speaking-to-dog voice. Oddly coincidental, a developer who doesn't crap all over everything or chew stuff up would be preferred. Also, they need to take a swat from a newspaper occasionally to keep them on track, right? :laugh:
My manager sometimes uses a rolled-up newspaper when I start following a scent for more than two acres/databases. Can't follow every interesting scent and still be a decent guard dog...
September 15, 2015 at 9:10 am
Sean Redmond (9/14/2015)
Hi Steve,There are several metrics that can be used:
1. How fast can an everyday problem be solved? Does a complex query take the DBA 30 minutes to do or 2 days?
2. How accurate/thorough is the work done? This is measured in code-reviews: after how many code-reviews, were changes made that made a difference to the data-output (rather than, say, to the speed or efficiency of the query)?
3. How efficient is the work done? Likewise, it is measured in code-reviews.
4. How extensive is the body of knowledge of the DBA? This is measured in how often a DBA must look something up. For example, if asked to implement, say, log-shipping, could it be done there-and-then or would the DBA need to go and read up about it first?
5. How complete is the body of knowledge of the DBA? About what does the DBA not know about? I know of Service Broker but never implemented it. There are surely many things that I don't know about. A complete checklist of the all features available within the SQL Server spectrum would be the way to go to measure that what is not even known about.
6. How interested is the DBA in learning more about technology? This can be measured yearly in new skills practiced and mastered.
All the best,
Sean Redmond.
Everything you've listed is a highly subjective measurement. A code review is not a code review. The choice of "how often" or "how interested" is both highly variable and elusive from person to person (either interviewee or interviewer)
September 15, 2015 at 9:11 am
David.Poole (9/15/2015)
Who would you choose for the long haul, a technical whizz with low social skills or someone of slightly above average competence who fits well with a team?
The latter, but that's subjective for me as well.
September 15, 2015 at 9:12 am
n.ryan (9/15/2015)
"Who's a Good Developer" is quite an open question and is best answered by answering the question "What do we want this person to do?"For example, there are roles where a very methodical, accurate approach is the best even if this results in a slower development process compared to others. There are roles where frankly you don't give a damn about the quality of the code as long as it works according to certain metrics and is completed quickly (i.e. cheap) - you may not want to go back and edit this code later but there are projects where this isn't the primary issue. There are other roles where you have particularly hairy problems when you want a developer who can approach these problems from various angles, often unexpected ones, and produce clever solutions.
However, in general and as already noted above, you want somebody who fits in the team and company ethos, who is enthusiatic for the job and is not afraid to learn or to embrace new concepts and ideas. I'm sure we've all seen "dinosaurs" who have pretty much refused to do anything other than the way they've always done it even when shown better or more efficient ways to do it.
A great question, and a good answer. I like it, though it's certainly hard to measure this. I think when we find someone that fits, and is enthusiastic, we're working within a wide band of what we accept.
September 15, 2015 at 9:14 am
xsevensinzx (9/15/2015)
I don't believe you can measure quality without experience (i.e.: working with the person). It's silly to think you can with just an hour or two with someone during the interview process, so why try so hard?We all have to make tough decisions. Is this someone who can do the job or not? Is this someone who is going to fit on our team or not? Etc. Everything can change when you actually do hire the person and put them on the team.
What I do believe is that not all DBA's, developers and so forth are created equally. Sometimes you get lucky and find a rockstar. But most of the time, I feel you have to create them. My job as a leader is to build good people to the best of my knowledge.
So, I tend to look for people who seem like they have their head on straight and who are both looking to learn and able to be trained. That way if they are not the best, we can help them get closer to being amazing through education and training because ultimately what we do is not brain surgery.
My approach is similar. I have tended to look for people that I think get along with the team. Not freinds, or even similar thoughts, but they get along. Their skills at answering a few questions help me understand how they think, since I ask open ended questions that invite other queries, but ultimately it's a bit of a gut feel, understanding I'll make some bad choices.
September 15, 2015 at 9:16 am
eric.notheisen (9/15/2015)
The first one is easy: ask yourself this question, "Which developer would I turn to when needing to solve a complex problem in a crisis?"
The second question is also easy: "Who is the most reliable developer in terms of meeting requirements, bug free code and good analysis?"
The third question: "Who lives the team/company vision most of the time?"
Good questions after you get some experience with someone. Easier to answer from close contact than from far away.
September 15, 2015 at 9:17 am
Iwas Bornready (9/15/2015)
It is easier sometimes to identify the bad developers. As for good, not as easy.
I'd like to think so. Not sure that's easy anymore.
September 15, 2015 at 9:17 am
malcolm-342909 (9/15/2015)
"I suspect you'll find it to be a very abstract idea. Perhaps it's like pornography, where you know a good developer when you see them, but if so, then have you always been able to tell a good developer right away? In an interview?" PMLS, maybe an autocorrect on photography? Either way cheered me up no end
:hehe:
September 15, 2015 at 12:09 pm
Thank God my last recruiter wasn't that shallow...
I think you have the wrong end of the stick. If you have someone so objectionable that even the most affable member of staff gets ranty then the objectionable person reduces productivity by more than their particular talents can increase it. Let's suppose you do have a highly talented individual. At best they can sustain the workload of two, probably less.
If you are recruiting to fill a position in a development team with strong personalities you need to be sure that the person you recruit will cope in that team. If not then either you don't retain them and you have to go through an expensive recruitment process again or worse still the person gets so beaten down that they can't reach the the potential that their talents should allow them to aspire.
I have no problem recruiting people more talented than me (yes I know that's not hard) because my job is to set direction and remove blockers and sadly not get down deep into the technical details try
September 15, 2015 at 12:25 pm
n.ryan (9/15/2015)
"Who's a Good Developer" is quite an open question and is best answered by answering the question "What do we want this person to do?"For example, there are roles where a very methodical, accurate approach is the best even if this results in a slower development process compared to others. There are roles where frankly you don't give a damn about the quality of the code as long as it works according to certain metrics and is completed quickly (i.e. cheap) - you may not want to go back and edit this code later but there are projects where this isn't the primary issue. There are other roles where you have particularly hairy problems when you want a developer who can approach these problems from various angles, often unexpected ones, and produce clever solutions.
However, in general and as already noted above, you want somebody who fits in the team and company ethos, who is enthusiatic for the job and is not afraid to learn or to embrace new concepts and ideas. I'm sure we've all seen "dinosaurs" who have pretty much refused to do anything other than the way they've always done it even when shown better or more efficient ways to do it.
And those "dinosaurs" may only be in their 30's. Not all gray hairs are unwilling to learn new things.
September 16, 2015 at 12:17 am
Steve Jones - SSC Editor (9/15/2015)
Sean Redmond (9/14/2015)
Hi Steve,There are several metrics that can be used:
1. How fast can an everyday problem be solved? Does a complex query take the DBA 30 minutes to do or 2 days?
2. How accurate/thorough is the work done? This is measured in code-reviews: after how many code-reviews, were changes made that made a difference to the data-output (rather than, say, to the speed or efficiency of the query)?
3. How efficient is the work done? Likewise, it is measured in code-reviews.
4. How extensive is the body of knowledge of the DBA? This is measured in how often a DBA must look something up. For example, if asked to implement, say, log-shipping, could it be done there-and-then or would the DBA need to go and read up about it first?
5. How complete is the body of knowledge of the DBA? About what does the DBA not know about? I know of Service Broker but never implemented it. There are surely many things that I don't know about. A complete checklist of the all features available within the SQL Server spectrum would be the way to go to measure that what is not even known about.
6. How interested is the DBA in learning more about technology? This can be measured yearly in new skills practiced and mastered.
All the best,
Sean Redmond.
Everything you've listed is a highly subjective measurement. A code review is not a code review. The choice of "how often" or "how interested" is both highly variable and elusive from person to person (either interviewee or interviewer)
Hi Steve,
Yes, everything here is subjective, until standardisation and comparison comes into play, at which point baselines are established and can be used as a point of reference. I should have mentioned that I had a departmental setup in mind. The DBA sets themself as the standard and comparisons are made on that. By code-review, I meant double-checking. We have a policy that all reports and queries that leave the department are double-checked by a member of the DBA-team. This usually means re-doing the query in question. What kind of changes, if any, were sent back? How long did the double-check take them? These are all measurable things and can be used both to measure progress over time as well as industriousness and thoroughness.
It is not too different from the DB-server. This SP is running slow. Slow is subjective. Once baselines and acceptable guidelines are set, then one may decide definitively as to whether it is running slowly and under what conditions. Likewise with DBAs or developers — queries of certain level difficulty, say a 4-join query made with could-be-cleaner-data with various exclusions and conditions and, in all, returns 100K-ish rows back. Something like that is most measurable. Does it take the interviewee or employee 10 minutes, 30 minutes or 2 days? And how accurate are they to tthe test result that you have generated?
I had more continuous assessment in mind. However, once stats and test-queries have been compiled on the members of a team, there is no reason why an interviewee can't be tested. In an interview, it is the interviewer who decides how often often is and how interested interested is.
September 16, 2015 at 6:05 am
Sean Redmond (9/16/2015)
Steve Jones - SSC Editor (9/15/2015)
Sean Redmond (9/14/2015)
Hi Steve,There are several metrics that can be used:
1. How fast can an everyday problem be solved? Does a complex query take the DBA 30 minutes to do or 2 days?
2. How accurate/thorough is the work done? This is measured in code-reviews: after how many code-reviews, were changes made that made a difference to the data-output (rather than, say, to the speed or efficiency of the query)?
3. How efficient is the work done? Likewise, it is measured in code-reviews.
4. How extensive is the body of knowledge of the DBA? This is measured in how often a DBA must look something up. For example, if asked to implement, say, log-shipping, could it be done there-and-then or would the DBA need to go and read up about it first?
5. How complete is the body of knowledge of the DBA? About what does the DBA not know about? I know of Service Broker but never implemented it. There are surely many things that I don't know about. A complete checklist of the all features available within the SQL Server spectrum would be the way to go to measure that what is not even known about.
6. How interested is the DBA in learning more about technology? This can be measured yearly in new skills practiced and mastered.
All the best,
Sean Redmond.
Everything you've listed is a highly subjective measurement. A code review is not a code review. The choice of "how often" or "how interested" is both highly variable and elusive from person to person (either interviewee or interviewer)
I had more continuous assessment in mind. However, once stats and test-queries have been compiled on the members of a team, there is no reason why an interviewee can't be tested. In an interview, it is the interviewer who decides how often often is and how interested interested is.
I've had similar debates with other senior level DBA's in my area. I personally am not senior level in anything remotely database area related due to my years of experience, but I am doing the job of a senior level database professional. So, I do rely a lot on my local community and those around me even here.
I totally understand why you would want to know if someone can do something right now versus having to look it up. If you're supporting a mission critical system, time is important. If someone can start recovering the system right now, then they are saving a lot of time compared to someone having to Google the answer. This is a critical aspect to the position that as a interviewer, you must gauge especially if that systems downtime is extremely critical to your clients.
I get it.
But, a lot of those mission critical processes and so forth can be taught too. If those processes are critical, can someone be taught how to do a point-in-time recovery before you have to rely on them to do so? I think they could. It's not exactly rocket science.
Don't get me wrong, this is not me saying there is no need for extensive experience for a job. This is just me saying that in my experience working in the software development industry, that you can go a long way with a candidate that you feel you can develop into a rockstar even if they fail a lot of subjective assessments in the interview process.
September 16, 2015 at 6:21 am
I don't think that was David's point. There are clever folks who like to whinge about all the work they are given, who complain about everyone else, who are unhygienic or similar, or who try and introduce clever patterns or whatever into the middle of a perfectly serviceable project. This is disruptive and counter-productive - most of us have seen that sort of thing. Mercurial or thorough, you need people that can follow the style of an existing project and get the job done with minimal disruption.
Absolutely. One of the better developers I worked with in a previous role was technically very good, and you could be very confident that he could fix pretty much anything you gave him. However, he was deeply, deeply unpleasant to work with. I hated having to approach him for anything (everybody did).
September 16, 2015 at 8:40 am
A good developer works towards keeping designs and implementations as simple and understandable as can be. And provides solutions that are complete as based on what is actually important. There must be a personal drive to be assertive and resists the temptations of trying to solve everything in one tool (a programming language for example). A good developer can structure data efficiently and have that structure capture the essential information within the data.
Entirely separate there are technical skill levels and practical experience. But neither of these makes a technical capable developer a good developer. Some can be quite new to the field and still be good developers!
I have worked with all kinds in my professional life and honestly most will fail these rather simple criteria. Many rather like to code and view all aspects of the job trough that "set of glasses". Problems that can be broken down at a procedural level end up being solved by using ever more code and language features.
While using language features is fun as an exercise, it is often completely at odds with quality control and maintainability over time. To combat the fallout of this preventable problem, ever more code and hacked language features are used. Without the proper understanding of what wend wrong in the first place.
Viewing 15 posts - 16 through 30 (of 32 total)
You must be logged in to reply to this topic. Login to reply