July 20, 2013 at 2:55 pm
Comments posted to this topic are about the item Hiring Heterogeneously
July 20, 2013 at 4:11 pm
I found the opposite to be true in some cases. You really really need to be careful that you don't end up with a "Tower of Babel" when hiring Developers and Architects.
--Jeff Moden
Change is inevitable... Change for the better is not.
July 20, 2013 at 5:15 pm
The world is a richer place for the diversity we have, and varying opinions, thoughts and ideas. We don't all get along, but many of us can work together with mutual respect, considering each others' viewpoints as we work to build solutions to the problems we face.
Oh so true ... so true in more than just SQL Server
July 22, 2013 at 6:14 am
Hiring too many people that are too similar, who may think alike, who may view problems the same way can lead to an environment that doesn't grow and expand, that loses it's creativity over time.
I have lived through this at my last job. When I started we all had different approaches and thinking styles, though compatible, so as not to be a disaster. Productivity was high, every quarter someone came up with some new method or innovation which jumped the business process ahead leaps and bounds.
Over time every new hire was almost identical to the last, until the entire group was of one mind. Productivity dropped steeply, there were no new innovations to processes for several years at a time. The mantra quickly became, and I quote "If it can't be control+C'd it can't be done".
July 22, 2013 at 9:07 am
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
July 22, 2013 at 9:19 am
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.
July 22, 2013 at 9:57 am
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.
cksid - It can be very frustrating and it can be a major rub to the new employee. However, one of the cardinal rules is that you don't fix what isn't broken. This is followed quickly with, However, when you are already changing something for another business reason then you can implement your new way of doing things.
So I agree with Steve that if the new solution can be proven better, implement it when the business dictates that process change. And let the new employee who found the new way of doing it be involved with the change. The one who finds the answer should be acknowledged as the source of the find, it is part of the recognition of a job well done.
🙂
Not all gray hairs are Dinosaurs!
July 22, 2013 at 11:14 am
I'm a 60 year old unemployed person who enjoyed working in engineering. I can't break the habit of working. I create projects to work on. It was starting one of my projects that I saw would give me a chance to learn SLQ.
My two impression are SLQ is amazingly and deceptively simple. SQL shows how simple concepts evolve into something with much complexity. This is a natural quandary within SQL.
I enjoy working with and being around young people. I've seen how young people grow being around older workers. Older workers trend to level out emotional component in an organization. Too many older people get too hung up being in their comfort zone. They need their ideas to be questioned.
There is an natural order. The natural order is groups have more skills and experience to drew on to solve problems. Much experience is earned over time. The gift of youth is seeing opportunities in new ideas. Nothing feds creative people than being around a multitude of ideas and experience in an open environment where being difference is expected and like think is discouraged.
July 23, 2013 at 2:06 am
"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."
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":-P
For fast, accurate and documented assistance in answering your questions, please read this article.
Understanding and using APPLY, (I) and (II) Paul White
Hidden RBAR: Triangular Joins / The "Numbers" or "Tally" Table: What it is and how it replaces a loop Jeff Moden
July 23, 2013 at 9:36 am
mikej 14403 (7/22/2013)
My two impressions are SLQ is amazingly and deceptively simple. SQL shows how simple concepts evolve into something with much complexity. This is a natural quandary within SQL.Nothing feeds creative people more than being around a multitude of ideas and experience in an open environment where being different is expected and like think is discouraged.
Mike - Thanks for the insight, shared wisdom like this is wonderful and a light to those who are on the road to maturity in the field.
I agree that SQL is both simple and complex, and as with many other IT tools there are those who can bend it to do some very amazing things. The idea of "we have always done it this way" is only temporal. In reality we all have done things this way until there was reason to change, then we either changed or fossilized. But that choice is up to use as individuals.
But each choice to resist logical and valuable change costs many much more then they think.
Again I appreciate what you have said and look forward to your future contributions.
M.
Not all gray hairs are Dinosaurs!
July 23, 2013 at 11:47 am
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
Change is inevitable... Change for the better is not.
July 24, 2013 at 4:52 pm
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. :unsure:
Sorry to sound so fatalistic, but I've been in some really crappy departments.
July 25, 2013 at 12:06 pm
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":-P
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
August 15, 2017 at 6:54 am
Four years down the road, and we now find ourselves in a society even more divided by identity and tribalism. However, I will say that those of us who work in the field of IT, or other branches of engineering, we tend to be more logical and reasonable than the general public, because we work in the realm of measurable facts and proven best practices. Despite being in the industry for two decades, I love to be [proven] wrong, because it expands my knowledge and makes me a stronger professional. That's what you should look for when interviewing candidates, someone who loves to expand their knowledge, even if it means occasionally admitting to yourself or others that your old way of doing things is not the best way.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
August 15, 2017 at 7:23 am
Eric M Russell - Tuesday, August 15, 2017 6:54 AMFour years down the road, and we now find ourselves in a society even more divided by identity and tribalism. However, I will say that those of us who work in the field of IT, or other branches of engineering, we tend to be more logical and reasonable than the general public, because we work in the realm of measurable facts and proven best practices. Despite being in the industry for two decades, I love to be [proven] wrong, because it expands my knowledge and makes me a stronger professional. That's what you should look for when interviewing candidates, someone who loves to expand their knowledge, even if it means occasionally admitting to yourself or others that your old way of doing things is not the best way.
Well, except for those running Google!
Dave
Viewing 15 posts - 1 through 15 (of 29 total)
You must be logged in to reply to this topic. Login to reply