With problem solving being so important you would think it would be
taught. Maybe it is now, however it was not way back in the punch card
days. In the last century things were less complicated and easier to
fix, for the most part. The problem David described is a very elusive
one. I understand why it took a while to find it. However you would
think those familiar with the configuration of the system would have
been able to find the problem rather easily. Sounds like there was some
politics at play which made the problem worse.
For the most part problems are easy to identify. The bigger challenge
is having the foresight to not build problems into the system.
Most problems are obvious.
On 2015-07-31 19:37, Amy Nielsen wrote:
> I think problem solving skills are vital, because no matter who you
> are chances are that eventually something will break and you are not
> familiar with the system at all. You may know Linux, Windows, Servers,
> but what broke was internet protocol settings, which you don't work on
> normally. Using the same process for every problem will work, and then
> you can identify the information to read to learn your fix. Identify
> the actual problem, including the priority and level of impact on the
> company. Using your knowledge of what is working right, you should be
> able to come up with a theory, an educated guess. Next, assuming you
> are right, you would try out the tool or setting that will fix the
> hypothetical issue to see if it works. If not, try again. If so, then
> document everything, your knowledge, your guesses, your steps towards
> the fix. Then test it to see if everything has returned to normal
> functionality, and test thoroughly. If you still have problems, no
> worries, because every time you get it wrong you still know more, and
> either success of failure needs documentation. Some time down the road
> another person can use your information to fix their problem. When you
> don't have any ideas, it is time to consult any available
> documentation, manuals, forums are very helpful, not forgetting good
> old google. If you can reach out to a friend in the industry great.
> Most important is not knowing how to fix something, it is knowing how
> to find information because then there is nothing you can't do with
> the right book or help.
>
> On Fri, Jul 31, 2015 at 6:22 PM, Keith Smith
> <techlists@phpcoderusa.com> wrote:
>
>> why lock records on a read?
>>
>> On 2015-07-31 16:24, David Schwartz wrote:
>>
>> Here’s something:
>>
>> A while back I had a contract in a support Dept at a Big Corp in
>> town.
>> When I started, I was told, “Don’t do anything except hold
>> their
>> hands.”
>>
>> One Friday morning about two weeks into the contract, I arrived at
>> work and everybody in my Dept was gone except me. I wasn’t
>> alerted
>> ahead of time.
>>
>> Around 11:45 AM, three people appeared at my cube door: the FInance
>> Mgr (head of Dept), Payroll Mgr, and someone else.
>>
>> The FM said, “I guess you’re the only Support person here
>> today.” I
>> said, “Looks that way.”
>>
>> He said, “Look, we’ve got a problem here and I need you to get
>> it
>> fixed. TODAY. If you don’t your contract is caput. We need
>> someone who
>> can fix this crap NOW.”
>>
>> As far as SteveT’s question goes … THIS IS PURE PROBLEM-SOLVING
>> ABILITY. I had no exposure or knowledge to their system at all.
>> I’d
>> been there for 2 weeks and didn’t have a clue about their
>> software,
>> hardware, network, or anything.
>>
>> I’m like, “Well, ok. What’s the problem?”
>>
>> They proceeded to explain it to me … which I’ll summarize here
>> only
>> because some of you will get a chuckle out of it.
>>
>> Payroll starts running their check run at 11:30 AM. After about 10
>> minutes, it hangs-up. They have to abort the run, void the checks,
>> and
>> start over. It usually keeps happening. They run it specifically
>> over
>> lunch because most of the Financial Dept is at lunch, so nobody’s
>> online.
>>
>> I poked around and noticed there were a couple of people running
>> reports, including the gal in the cube next to me. (They ran these
>> reports that went to Epsons dot-matrix printers and they’d run
>> for
>> about 45 minutes.)
>>
>> BTW, this is some kind of accounting system running on a bunch of
>> old
>> DOS machines (circa 1995) hooked into a Banyan Vines LAN, sharing
>> access to files on a file server.
>>
>> I looked at how the gal in the next cube ran her reports. It was a
>> batch file that looked like this:
>>
>> runrptapp.exe xyz abc >lpt
>>
>> (I forget what devices were on DOS, but … notice the
>> right-arrow.)
>>
>> Digging around, I discovered that this app, which I’m calling
>> runrptapp.exe, opens the database file on the server, which happens
>> to
>> be the same database file the Payroll app used. It was a very
>> popular
>> database back then (i forget the name, but it’s not dBase). I
>> happened
>> to know that that particular database used FILE-LEVEL locking.
>>
>> Notice the right-arrow …
>>
>> Question: who starts off their reports first: the gal in the next
>> cube, or Payroll?
>>
>> Answer: gal in the next cube! At 11 AM, because she needs it for a
>> 2PM
>> meeting, and it usually crashes over lunch and needs to be
>> restarted.
>>
>> Did you notice the right-arrow ...
>>
>> What happens is she runs her report and the printer is fed data in
>> real-time as the report extracts records from the DB. After a
>> while,
>> it has extracted as much as it can before the print buffer gets
>> filled
>> up, and it starts to crawl along.
>>
>> Some time after she starts runnign her report (15-20 mins), the
>> Payroll Dept starts their check run.
>>
>> It access the same DB.
>>
>> Notice that right-arrow … and think, “file-level locking” …
>> and
>> “Payroll wants to run against this DB at the same time …
>>
>> hmmm …. changed the BAT file to this:
>>
>> runrptapp.exe xyz abc >temprpt.txt
>> copy temprpt.txt lpt1
>>
>> The report took about 15 seconds to run, then it started printing
>> it
>> from the local copy on the disk.
>>
>> VIOLA! PROBLEM SOLVED. sort of …
>>
>> Monday morning I had another manager wating at my door when I
>> arrived.
>> “Weren’t you told not to fix anything for these people? JUST
>> HOLD
>> THEIR HANDS, right?”
>>
>> "Well, the Finance Mgr said if I didn’t do SOMETHING he’d fire
>> me.”
>>
>> <grrr>
>>
>> The vendor had sent out their top support people, and even sent
>> their
>> DEVELOPERS, and NOBODY had been able to fix this problem. They even
>> had some support guys from Banyan come out, and they couldn’t fix
>> it
>> either.
>>
>> Turns out, the Finance Dept didn’t like this piece of software
>> and it
>> came with a 90-day money-back guarantee. They wanted their money
>> back.
>>
>> Nobody else who’d tried to fix this problem, including the SMEs,
>> couldn’t solve it.
>>
>> But silly me … it took me about 15 minutes to fix it. With no
>> subject-matter expertise at all.
>>
>> And a week later, my contract was terminated. :o
>>
>> So it doesn’t surprize me when people report they have trouble
>> finding
>> folks with good problem solving skills.
>>
>> Unfortunately, the kinds of questions I get in interviews don’t
>> go
>> into this at all. They’re mostly general stuff, trick questions,
>> and
>> things intended to get a feeling of how good you are with existing
>> tools.
>>
>> This is the problem. If people have good problem-solving skills,
>> they
>> CAN figure this shit out, no matter what.
>>
>> But if you don’t know the tools, and regardless of you
>> problem-solving
>> skills, BZZZTTT! You’re DISQUALIFIED!
>>
>> I’ve also worked at several places where we encountered LAN
>> problems,
>> and after a couple of days with their “A+ Certified,” “Novell
>> Certified," and “Microsoft Certified” experts being unable to
>> solve
>> server/workstation issues that were holding me up, I asked if I
>> could
>> “take a look”. In every instance, I’ve been able to solve
>> their
>> problems in about 15 minutes, knowing nothing about their specific
>> network, but just from my general understanding of networking,
>> LANs,
>> and that stuff.
>>
>> Yet I could not get a job in an IT Dept if my life depended on it
>> —
>> I’m not “certified” and obviously “lack the expertise”.
>>
>> This stuff drives me nuts, becuase nobody interviews in a way that
>> uncovers problem-solving abilities at all.
>>
>> It’s nearly 100% focused on identifying subject-matter expertise
>> the
>> candidate may (or may not) have in very narrow technical areas.
>>
>> This seems totally naive, but I’d think a company would want to
>> have a
>> few people on staff who are excellent problem-solvers, and just
>> loan
>> them out to projects and departments that get stuck on various
>> issues.
>> Because problem-solving skills are NOT technology-specific. (In
>> fact,
>> they seem to be relatively hard to find.)
>>
>> -David Schwartz
>>
>> On Jul 28, 2015, at 9:32 PM, Steve Litt <slitt@troubleshooters.com>
>> wrote:
>>
>> On Tue, 28 Jul 2015 20:30:31 -0700
>> Sesso <sesso@djsesso.com> wrote:
>>
>> "Companies should focus a little less on buzzwords, and a lot more
>> on someone's ability/desire to learn, ability to think critically,
>> and ablility to solve problems.”
>>
>> I have a hard time finding candidates with all 3 of the above. I
>> have
>> met many that have a strong desire to learn but lack problem
>> solving
>> skills. Now for a shared hosting company, this is fine.
>> Dedicated/Cloud infra. won’t work out.
>>
>> jason
>>
>> What are both of you meaning by "problem solving skills?" What,
>> exactly, would the work of someone with "problem solving skills"
>> look
>> like?
>>
>> How does "problem solving skills" differ from "thinking
>> critically?"
>>
>> I'm not asking out of idle curiosity, this is actually part of what
>> I
>> do.
>>
>> SteveT
>
> ---------------------------------------------------
> PLUG-discuss mailing list - PLUG-discuss@lists.phxlinux.org
> To subscribe, unsubscribe, or to change your mail settings:
> http://lists.phxlinux.org/mailman/listinfo/plug-discuss [1]
>
> --
> Keith Smith
>
> ---------------------------------------------------
> PLUG-discuss mailing list - PLUG-discuss@lists.phxlinux.org
> To subscribe, unsubscribe, or to change your mail settings:
> http://lists.phxlinux.org/mailman/listinfo/plug-discuss [1]
>
> --
>
> Amy Nielsen
>
>
>
> Links:
> ------
> [1] http://lists.phxlinux.org/mailman/listinfo/plug-discuss
>
> ---------------------------------------------------
> PLUG-discuss mailing list - PLUG-discuss@lists.phxlinux.org
> To subscribe, unsubscribe, or to change your mail settings:
> http://lists.phxlinux.org/mailman/listinfo/plug-discuss
--
Keith Smith
---------------------------------------------------
PLUG-discuss mailing list -
PLUG-discuss@lists.phxlinux.org
To subscribe, unsubscribe, or to change your mail settings:
http://lists.phxlinux.org/mailman/listinfo/plug-discuss 
(text/plain)