Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase ««12

Hiring Heterogeneously Expand / Collapse
Author
Message
Posted Tuesday, July 23, 2013 11:47 AM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: General Forum Members
Last Login: Today @ 1:52 PM
Points: 36,015, Visits: 30,304
Steve Jones - SSC Editor (7/22/2013)
cksid (7/22/2013)
It can be frustrating to be the new person who comes in with new ideas and sees antiquated ways that can be changed. When you ask 'Why do you do it this way, when this way is faster, less time...? and prove that it is faster/better, you get the same answer again and again 'We've always done it this way.' and they won't change!

Christy



the trick here is to give reasons why, and show how others have already thought of these things. I've learned to appreciate the new person re-examining the problem, and if they can prove it's better, that's good. However by the same token, I have to be able to justify the current way to keep doing it.


I've found that it has to do a whole lot with 2 things... the first is how the idea is presented and the second is the perceived ROI.

On the first subject, asking "Why do you do it this way, when this way is faster, less time...?" is taken by many (whether right or wrong) as a either a full frontal assault on their talent if they wrote it or a really stupid question if they didn't. A question of this nature is pretty much out of line even in "grownup" shops where people have pretty thick skins. Questions of this nature are frequently dismissed from new folks as "here's the new guy/gal that thinks they're smarter than everyone else" even if they are. I was hired into my current job to make such improvements as "faster, less time" but, even with everyone knowing that, you just can't ask the question quite that way. In fact, such questions should actually never be asked because the answer is so obvious... "They didn't know any better at the time they wrote the code".

Don't get my wrong. I hate the attitude of "because we've always done it that way" or "we've never done it that way before" but that's mostly due to a simple lack of knowledge possibly spawned by a lack of motivation to get smarter. It's become a "safe" attitude for a lot of shops. And that's the key. It's difficult to motivate someone by hitting their egos and "tired/true" methods with a bat. You have to respect their "metal" or you aren't going to be of much help at all even if you're a freakin' genius.

Rather than asking questions that have such a high potential of alienating you (which renders you useless, for the most part, and will certainly increase the "great divide" between Developers and DBAs), do it in a mentor-like fashion making sure that you're a friendly, helpful mentor instead of an (perceived to be and perception is reality to many) arrogant pulpit thumper. Instead of belittling someone by asking them "Why do you do it that way when this way is much faster, less time...", ask them "Can I show you a little trick that I think you'll like?" If they say "yes", turn it into a thoughtful teaching session (be a mentor). If they say "no, I don't have the time" or just plain "no", respect the metal and leave it alone for that moment. Instead, do the same as if you were going to do the mentoring thing. Improve the code, measure the performance/resource usage/ease of maintenance of both methods, and then bring it back to them when their hair actually isn't on fire.

Notice also that I didn't say you have to take any crap from anyone. Crap will happen just because it's the nature of the beast because there's a conflict between current methods and the "right" methods. People will make ad hominem attacks even if you haven't. Be prepared to disarm such arguments with good code and a mentor-like attitude. Don't be equally as arrogant.

There's another hurdle to overcome and that's ROI. Some companies have the idea that performance doesn't actually matter especially when it comes to overnight jobs. For example, it might not matter to a boss if a particular job takes 6 minutes or 6 hours so long as the job finishes be 8 in the morning. They just don't understand that the server could be doing other equally important things during those 6 hours or that you may not have to buy additional hardware/licenses to get the job done as the system scales. Even though I'm a bona fide speed freak that likes to see everything be optimized, I can let things like that go (for now) because it's usually not the only fish in the pond and you have to remember that regression testing and fallout from such changes is expensive. Will that 6 hour code become a problem in the future as scalability grows? Absolutely but (and unfortunately) ROI is sometimes based on "urgency". Some people actually believe that if it's not an "urgent" problem, there's no ROI in "fixing" something that isn't broken (yet) and it can take quite a while to change that perception. All performance problems are based on ignorance, IMHO, whether it's based on "bad" code or simply using the wrong tool. It takes "training" to overcome that and you have to be the incredibly patient trainer to make a real difference.

The bottom line is that change for the better frequently comes slow because of the very attitude you mention and the sensitivities of the human element. You absolutely have to remember that you can't always make the right point up front. Sometimes you have to "Give people the opportunity to fail" (notice I didn't say "Make them fail") before you can show them a better way. The other thing that you have to remember is that "A person forced against their will, is of the same opinion still". Not all "new ideas" are "good ideas" and even Microsoft(almost all companies... I don't mean to pick on just MS) has proven that in virtually ever piece of software they've ever published. Especially as a new person, you have to understand that many Managers, DBAs, and Lead Developers have been badly bitten by "new ideas". You need to help them lead rather than push them into a corner.

Drop the bat... stop thinking about frustration... respect the metal... become a mentor. Although it won't seem like it at first, you'll make a much bigger impact and in much less time.


--Jeff Moden
"RBAR is pronounced "ree-bar" and is a "Modenism" for "Row-By-Agonizing-Row".

First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."

"Change is inevitable. Change for the better is not." -- 04 August 2013
(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #1476733
Posted Wednesday, July 24, 2013 4:52 PM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Friday, November 01, 2013 8:34 AM
Points: 1, Visits: 10
Companies run lean, and it seems to me it's more often than not--difficult for analysts to get beyond the simple everyday operational tasks, and take the time to think about who they are working with and what strengths members bring. If you ask me, sad as it is to say, it's everyman for himself, and good luck with getting a sense of teamwork (at least in the world of IT). Thank God for Google, because it is the only constant source of diverse ideas.
Sorry to sound so fatalistic, but I've been in some really crappy departments.
Post #1477318
Posted Thursday, July 25, 2013 12:06 PM


SSCrazy Eights

SSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy Eights

Group: General Forum Members
Last Login: Today @ 7:47 AM
Points: 8,296, Visits: 8,750
ChrisM@Work (7/23/2013)
Not everyone can be a superstar-expert-architect that decides how the system is built. Not all architects should spend time coding basic insert/update/delete code or adding clustered indexes to tables. We need a variety of talent levels that can get complete different types of tasks. There is tedious administrative work, supporting roles, necessary, though unexciting work like reviewing security, logs, audits, and more.

Maybe every architect should be capable of coding some basic stuff, and adding clustered indexes to tables; and maybe he should do it from time to time, just to ensure that he really retains the ability. Necessary work like reviewing security, logs, and audits isn't just tedious administrative stuff - and if you have it done by someone who thinks of it that way it will not be done properly: you will not have security, your audits will be worthless, and amazing things that should cause immediate diagnostic action followed by remedial work will be missed in the logs.
Are these talent levels or job choices? The person working on security is just as likely to be a superstar expert as the architect, or the lead developer who's right now adding clustered indexes to tables (because the choice of cluster keys is pivotal). Most of the devs I work with view architecture as "necessary, though unexciting"

Devising a new architecture for something to replace the way it has always done can be quite exciting. Applying a well-known architecture (or system design pattern) to meet some requirement that isn't too different from things that have been done before using that architecture/pattern is what is often necessary, though unexciting; but if that "not too different" turns out to be just a little optimistic that too can become quite exciting, and if you have decided to shoot for a 5-fold improvement in efficiency of the software the changes to the architecture can be pretty exciting in that case too.

I tend to agree that what the article suggests is about talent levels and responsibilities is actually about job choices - and I would go further and say that when someone in a senior position makes job choices that divorces him completely from basic DBA of Developer activities he risks rendering himself useless and ineffective as a system or application architect or as a database expert. If real security is required, a real security expert is needed - and the system architect had better be able to understand what that security expert says, the security expert had better understand how privileges, capabilities, and permissions work in the database, at the app's UI, between app components, in filestore, and between the users, and both of them should understand how to change those things - which they won't if they don't understand for example how the database GRANT primitive works because detail like that is so far below their altitude than they obviously don't need to deal with such details, the junior DBA can do all that, or they don't understand how the app is used, that's up to the junior guys who directly use it. So the architect has to be a generalist - he must of course be an expert in system architecture and design or in application architecture and design or in both, but he must also be a jack-of-all-trades because he can't have that expertise without understanding what the developers and DBAs and users are doing.


Tom
Post #1477660
« Prev Topic | Next Topic »

Add to briefcase ««12

Permissions Expand / Collapse