The Problem Solver

  • JustRightOfCenter (8/31/2015)


    @Jeff Moden, I am a "developer" (21 years experience, 20.5 years SQL experience). No excuses here. I say if you are currently in this kind of situation then find a new employer. Of course, that is only if you actually know your stuff, which it sounds like you do because otherwise you probably wouldn't realize that the situation you describe is unacceptable. 😉

    Good to make the acquaintance of a fellow "old salt". Welcome aboard.

    To be sure, it's not my employer that has a problem. We've been practicing the notion of "DevOps" long before the term was invented. We just call it "Team Work". I'm a DBA that sits right in the middle of the Web Developers so that we can bounce ideas off each other at the drop of a hat... any hat. Good bunch o' Joes I'm working with.

    The current batch of horrors is coming through on a 3rd party app. The other things I mentioned were either for previous companies that I worked at (and now you know why some of the are in the "previous" category) or some companies that I'm helping out as a "consultant". I will admit that when I got to this current company, they were just getting over the idea of "code first" from a 3 or 4 year development. 10 minute timeouts multiple times during the day were the rule rather than the exception when I first got here. The relatively "new group" of folks really get it and, together, we've not only repaired a wealth of sins but have prevented committing the same sins. If I had to say, this is probably the best group of Developers (including the Dev Manager. the Enterprise Architect, the VP of Infrastructure, the CIO, every one on their teams, and the PMs in all that) that I've ever worked with and it's not just a honeymoon, either. We've been working together for nearly 4 years now.

    The really great part is that we're able to churn out a whole bunch because it's a very rare occasion when any new code breaks even in QA or UAT never mind Production.

    --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.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • Andy Warren (8/31/2015)


    Jeff,

    I wonder if the life of a DBA isn't different than most because of the complexity compared to other systems. I'm not an Exchange/Sharepoint/whatever/whatever guy, but it sure seems more like those systems don't require (or get) the kind of low level tuning that we sometimes need to do. If (big IF) that's the case, then as the outlier we get stuck with the expectation that we're like those systems (set it and forget it) and once they realize it's not that easy, they want it to be that easy and start thinking about text files and NoSQL.

    As far as problem solving though, I still see the challenge as being that of harnessing the potential of a problem solver. Somewhere between "do whatever you feel like doing" and "don't change anything" is a place where the PS is happy and useful and the business is getting the right ratio of gain to pain.

    Heh... except for the fact that no one let it get huge where I work, SharePoint would be a huge pain for me. I don't know who wrote installed it or what they were thinking but it has such lovely features as 3 separate jobs that run once each minute to kill some form of inactive sessions. We have just one SharePoint system left and I'm working on replacing that functionality so I can kill the database.

    The reason why we don't "have to" spend much time on Exchange/SharePoint, etc, is because we simply elect not to. The one time I did spend some time on a major fix, it would have violated the support agreement if I didn't get the SharePoint team involved and get "written approval". The process took months. When they finally did say it was Ok, they also said they'd incorporate the fix into the product. Ok... so wait a minute... I just spent how much of my company's time to fix something that shouldn't have been broken in the first place?

    When I was the Director of MIS for a small but nationwide telephone company, someone asked me about my habit of hiring nearly over zealous people. My answer was and still is that "It's much easier for me to guide someone that's extremely motivated than it is to create the motivation".

    I agree that it's sometimes a bit of a chore to harness and control one, but I'll take a motivated problem solver over a "Yes Man" any day.

    --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.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • Jeff Moden (9/3/2015)


    When I was the Director of MIS for a small but nationwide telephone company, someone asked me about my habit of hiring nearly over zealous people. My answer was and still is that "It's much easier for me to guide someone that's extremely motivated than it is to create the motivation".

    I agree that it's sometimes a bit of a chore to harness and control one, but I'll take a motivated problem solver over a "Yes Man" any day.

    Boy, I couldn't agree more with that. Attitude is so very important. If someone has passion for what they do and wants to get better at it, I'll take that any day over someone who doesn't care enough to learn anything new. Teaching new skills is vastly different than trying to motivate someone.

  • Ed Wagner (9/3/2015)


    Jeff Moden (9/3/2015)


    When I was the Director of MIS for a small but nationwide telephone company, someone asked me about my habit of hiring nearly over zealous people. My answer was and still is that "It's much easier for me to guide someone that's extremely motivated than it is to create the motivation".

    I agree that it's sometimes a bit of a chore to harness and control one, but I'll take a motivated problem solver over a "Yes Man" any day.

    Boy, I couldn't agree more with that. Attitude is so very important. If someone has passion for what they do and wants to get better at it, I'll take that any day over someone who doesn't care enough to learn anything new. Teaching new skills is vastly different than trying to motivate someone.

    I second, third, fourth, and fifth that motion/notion! Unfortunately those people (zealous ones) are often not available/in short supply.



    SDG

    The truth is incontrovertible, malice may attack it, ignorance may deride it, but in the end, there it is.
    - Winston Churchill

    Quick. Accurate. Inexpensive. Pick TWO

  • Andrew_Steitz (9/4/2015)


    Ed Wagner (9/3/2015)


    Jeff Moden (9/3/2015)


    When I was the Director of MIS for a small but nationwide telephone company, someone asked me about my habit of hiring nearly over zealous people. My answer was and still is that "It's much easier for me to guide someone that's extremely motivated than it is to create the motivation".

    I agree that it's sometimes a bit of a chore to harness and control one, but I'll take a motivated problem solver over a "Yes Man" any day.

    Boy, I couldn't agree more with that. Attitude is so very important. If someone has passion for what they do and wants to get better at it, I'll take that any day over someone who doesn't care enough to learn anything new. Teaching new skills is vastly different than trying to motivate someone.

    I second, third, fourth, and fifth that motion/notion! Unfortunately those people (zealous ones) are often not available/in short supply.

    Zeal can be a very powerful attribute, so long as it's focussed and channeled productively in the right direction. That's the role of a manager.

    "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

  • Eric M Russell (9/4/2015)


    Andrew_Steitz (9/4/2015)


    Ed Wagner (9/3/2015)


    Jeff Moden (9/3/2015)


    When I was the Director of MIS for a small but nationwide telephone company, someone asked me about my habit of hiring nearly over zealous people. My answer was and still is that "It's much easier for me to guide someone that's extremely motivated than it is to create the motivation".

    I agree that it's sometimes a bit of a chore to harness and control one, but I'll take a motivated problem solver over a "Yes Man" any day.

    Boy, I couldn't agree more with that. Attitude is so very important. If someone has passion for what they do and wants to get better at it, I'll take that any day over someone who doesn't care enough to learn anything new. Teaching new skills is vastly different than trying to motivate someone.

    I second, third, fourth, and fifth that motion/notion! Unfortunately those people (zealous ones) are often not available/in short supply.

    Zeal can be a very powerful attribute, so long as it's focussed and channeled productively in the right direction. That's the role of a manager.

    Heh... precisely. Fortunately (or, more likely, unfortunately) there are as few good managers that know how to do such a thing properly as there are motivated problem solvers. 😛

    As a bit of a side bar, I'm helping another small company find a decent Application DBA with some good system skills to back that up. I can, once again, personally vouch that there are a ton of people out there that have wonderful looking resumes for the last 10 years and they actually know close to nothing. People that claim the ability to performance tune code that know virtually nothing about about indexes. People that think that WHILE Loops are the holy grail of reducing contention. People that don't know the difference between a FULL OUTER join and a CROSS JOIN. People that are "expert T-SQL programmers" that don't know what a CROSS APPLY is, how to do a pivot/cross tab, don't even know how to count from 1 to 10 without using a loop (some can't even do it with a loop), and have no clue about the idea of SARGability just to name a few of the things that supposed "senior" people with "experience" all the way back to SQL Server 2000 are nearly totally clueless about. Of course, all of these people want 6 figures even though their "knowledge" isn't that of even the most rank "junior".

    Sorry... I get totally disgusted every time I help someone try to find a decent DBA/Developer. Where are the people that actually care enough about their career to actually try to find out what they don't know before they need to know it? Skaters... :Whistling:

    --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.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • Jeff Moden (9/4/2015)

    Sorry... I get totally disgusted every time I help someone try to find a decent DBA/Developer. Where are the people that actually care enough about their career to actually try to find out what they don't know before they need to know it? Skaters... :Whistling:

    HR and clueless hiring managers allow the "skaters" to thrive. "Well, we have no idea what any of the skills mean so we are just going to use automated matching between the list of buzzwords we say we need and the list of buzzwords on your resume." So the skater gets hired and when they prove themselves useless, HR won't let you get rid of them because it means more work for them.

    On the flip side, you have hiring managers who use their senior dev/architect to grill prospects regarding their technical prowess. Unfortunately the senior dev/architect might have (often has) an ego issue and asks obtuse questions about stuff that is rarely used and can be learned in 30 minutes or less just to show how smart they are. Happened to me once. Not only that but the architect asked me to write some pseudo code on the whiteboard to solve a specific problem so I did. He then told me how I failed to account for something and wrote a counter example. In actuality my pseudo code was correct and his counter example actually was wrong. As a result of his ego I was offered a lesser position which I gladly refused. 😉

    Both examples above provide great support for the try-before-you-buy concept of either a 6-month-contract-to-hire or a 6 month probationary period for direct hires (because they need "benefits) where HR does not require a 2,000 page report of all the reasons the employee should be let go along with proof that you gave the skater plenty of opportunity to improve. IMO, potential employees who have a problem with this have something to hide, like ineptitude.



    SDG

    The truth is incontrovertible, malice may attack it, ignorance may deride it, but in the end, there it is.
    - Winston Churchill

    Quick. Accurate. Inexpensive. Pick TWO

  • Jeff Moden (9/4/2015)Sorry... I get totally disgusted every time I help someone try to find a decent DBA/Developer. Where are the people that actually care enough about their career to actually try to find out what they don't know before they need to know it? Skaters... :Whistling:

    They're the ones who already have jobs and aren't looking, Jeff. 🙂 Totally agree about the drive to solve problems being something that you can't really train, though. We had a need for someone to step up in a DevOps position (really just a developer to work more closely with the Ops team - yes, teamwork). No developer wanted to do it. They wanted to code the app, work the backlog, and just keep on doing that. The idea of working together with the Ops team to come up with the best solution for everyone and improve the whole product wasn't of interest.

    I worked with one guy who was driven to improve things - often to his own (and sometimes a co-worker's) detriment because of extra hours put in. If he hadn't been driven to solve the problems, they'd never have been eliminated, but it was hard at times. I know I've been driven to do that as well - something builds up to the point where it's painful and has to be addressed. That's usually because we put a stop-gap measure in place first, with warnings, but it "just worked" for long enough that it was like boiling a frog. Sadly, no official time is allocated to solve the issue and that means working on it instead of vacation or working extra hours to solve the issue. Of course, it feels a lot better once the problem is solved, but never fun to go through.

    As for solving the "right" problems - that does come from having a good manager if the person lacks the wisdom/knowledge to know what needs to be solved. Changing a reporting solution from going through boxes of paper for a couple of lines (daily) into an online report - worth solving. Tweaking that still further for sub-millisecond response? Not cost-effective for the number of times it's used.

  • I remember working with a Dev Lead who would grill people on their knowledge, but mostly to figure out where that knowledge stopped or to see how deep/wide their knowledge was. He was pretty sharp so could keep going for quite some time until he'd reached the point where the candidate didn't know where to go next. It wasn't about the small things so much as figuring out what they knew and if they knew how to apply that knowledge. I vaguely remember one candidate who started off answering one of the basic questions with something like "This is a book question." and acted like he was above the basics. Our lead then proceeded to grill him to see whether he actually knew more than "the book questions". While he did know quite a bit, he wasn't a good fit for the team and it turns out he didn't know quite as much as he thought. 🙂

    I think Sean McCown had a "Tales from the Interview" that was pretty amusing with one candidate exclaiming over and over about one question being "an interview question" until Sean finally reminded him that he was, in fact, in an interview.

  • I tend to agree with Yet Another DBA. As well as feeding problem solvers we need to ensure that they do not overwork themselves as often these problems that they are given to resolve are critical.

    To keep them interested yet allow for spells of reduced pressure I find that back burner problem solving and resolution investigation projects that are useful but not yet business critical are excellent tasks for such people. This allows them to keep problem solving and keep providing value to the business without wasting time.

    Psychoanalysis techniques tend to be deem me primarily a creator and a secondarily a problem solver so I can empathise but I am not quite in the same boat.

    Gaz

    -- Stop your grinnin' and drop your linen...they're everywhere!!!

  • I tend to believe myself as a "scale-out problem solver", I mean I'm not going for that 10 millisecond query unless the circumstances around it are dumb enough to justify the extra work to myself. However I might have said in the past "when this is done I expect a daily load to be done in less than 2 minutes". That was around 4 weeks before go-live with some things still need fixing. I later also said "well I guess with 2:20 min on average we're close enough for the moment." When I said the first one they were smiling and grinning and when I said the second one (it was believed to run around 15 Minutes instead) the only one grinning was me because I was close enough so there won't be any discussions about it.

    I have been my own boss for almost 10 years and still in consulting so I have a rather good feeling about what is actually really critical to the customer right now and what I'll keep reminding them about until I get a shot at it. By doing so I also have reassurance to myself that I've told them waaaaaay back this was going to happen and I had no time to fix it so we're in the crap now.

    Of course when crap is there you still might get that code review on your software during christmas time but I grant any manager the doubt once about not understanding the difference between changing the code and changing the design (even my team lead vouched we have not touched the SSIS Code in months, still review) so yes I absolutely do sell magic at a high daily rate and the response is amazingly well!

    I think the CIO won't question my code ever again (even tho I think he still does not exactly understand how I did that magnitude 4 faster thingie on them 😉 ) and to keep him and his colleagues happy we'll soon start replacing some old license hog IBM Software with a combination of PowerBI and Master Data Services, the latter so the dear CIO can simply use his tools of work to change a few bits here and there if needed in this reporting solution. I literally spat the idea of PowerBI & MDS out in like 2 minutes of talk on the way grabbing some coffee, last week I was sitting in this meeting of 5 people and being about the only person asides the presenter who knows what he's talking about because it sounded so familiar to that little chat I didn't follow up on in weeks. Don't have to (just) fix everything, replacing or enhancing for the better does it for me aswell..

    • This reply was modified 5 years, 4 months ago by  DinoRS. Reason: typo
  • Ha!  I was exactly the same as a child!  This article rings true on every point.  I have such a hard time NOT fixing things that could use improvement.  I am going to save this as a reference, to remind myself not to get off track.  Thanks for reposting!

  • Sounds like an interesting book.

  • Jeff Moden wrote:

    Sorry... I get totally disgusted every time I help someone try to find a decent DBA/Developer. Where are the people that actually care enough about their career to actually try to find out what they don't know before they need to know it? Skaters... :Whistling:

    I've found that too.  And employment agent companies who claim to be good at evaluating candidates are mostly completely unable to evaluate anyone, anyway.

    And it doesn't apply only to DBAs and Database developers.  Trying to recruit someone with decent competence in an every-day procedural lanaguage with no database knowledge required is just as disgusting; a typical candidate claiming many years of experience of advanced use of C++ or Java used to disgust me (unable to write the infamous "Hello World" program) almost every time way back when (between 1996 and 2006) and before that I had to cope with people who claimed serious research experience in functional and/or logic languages but didn't know what a CUT was in Prolog nor even how to write Hello World in any functional language.  I also discovered that for procedural language knowledge I couldn't trust most universities - 1st class honours or summa cum laude made no difference, and nor did a prof's report that the candidate had made a major contribution to a big C++ project;  fortunately for the functional language side we were collaborating on research with a lot of universities, and we could rely on reports from the people we were working with (and sometimes just recruit people we were already working with)  - otherwise recruitment would have been a total nightmare.

    Tom

  • I consider myself very fortunate. My father (Professional licensed engineer), saw my potential and from the age of about 6 had me help him fix things around the house; in the beginning he would explain what and why, then send me off to get a tool he needed. This was the 1960’s - By the time I was 12, I was doing the actual work and he would still be explaining the what and whys, and he would go get the tool I needed.  Toaster, Washing Machine, TV, Car didn’t matter we would fix it together.

    To this day, I still try to fix things, but I have learned when it comes to Women – just listen, don’t try to fix it.

Viewing 15 posts - 31 through 45 (of 46 total)

You must be logged in to reply to this topic. Login to reply