Break Problems Down

Question

Break Problems Down

Steve Jones - SSC Editor

SSC Guru

Points: 736212
More actions
November 17, 2018 at 11:30 am

#378633

Comments posted to this topic are about the item Break Problems Down

Viewing 8 posts - 1 through 7 (of 7 total)

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

Jeff Moden SSC Guru Points: 1004340 More actions · Answer 1

Good article and reminder on one of the fundamentals of how to successfully determine a solution for virtually any problem. Granny used to say "You can only peel one potato at a time". In code, a lot of us call it "Divide'n'Conquer".

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

Jonathan AC Roberts SSCoach Points: 18354 More actions · Answer 2

Jeff Moden - Saturday, November 17, 2018 5:00 PM
Good article and reminder on one of the fundamentals of how to successfully determine a solution for virtually any problem. Granny used to say "You can only peel one potato at a time". In code, a lot of us call it "Divide'n'Conquer".

And when eating an elephant take one bite at a time.

call.copse SSCoach Points: 18050 More actions · Answer 3

Yes. It's always worked for me. Internally I might be panicking, thinking how on earth can I get this done? when given a new major requirement or something we've never done. When you break it down though, there are only ever one or two novel aspects. You can easily assess the nub of what you need to achieve with those. The rest is just breaking it down, to things you've tackled plenty - and smiling and looking in control even when super stressed....

jasona.work SSC Guru Points: 50117 More actions · Answer 4

My troubleshooting mantra has largely been "always check the basics, even if you're *sure* the problem's not there." Because all to frequently, it's going to be, it's going to be something you assumed couldn't be the problem, that is the problem.

As you get better and better at troubleshooting, you'll get faster and faster at verifying the basics are all correct.

erb2000 SSCommitted Points: 1697 More actions · Answer 5

Great advice! In C it's called printf and people would joke about me using the "printf debugger". It's especially useful to minimize timing changes when debugging a race condition. "It works when I put a halt in and use the debugger."

Frank W Fulton Jr SSCommitted Points: 1599 More actions · Answer 6

Back in the Day when we used Punch Cards, Terminals and Teletypes, we would actually create flow charts for how we expected the programs to flow. Then we would write Pseudocode, and step through it several times keeping track of the variables, etc.. Next we would chose the best language to use from what was available PL/1, COBAL, FORTRAN, PASCAL, and my personal favorite Assembly.
Today most people (myself included) usually sit down and start writing code in the company standard language and keep adding functions till we have it all working, and then we check to see if it works right.

Jeff Moden SSC Guru Points: 1004340 More actions · Answer 7

Frank W Fulton Jr - Tuesday, November 20, 2018 7:24 PM
Back in the Day when we used Punch Cards, Terminals and Teletypes, we would actually create flow charts for how we expected the programs to flow. Then we would write Pseudocode, and step through it several times keeping track of the variables, etc.. Next we would chose the best language to use from what was available PL/1, COBAL, FORTRAN, PASCAL, and my personal favorite Assembly.
Today most people (myself included) usually sit down and start writing code in the company standard language and keep adding functions till we have it all working, and then we check to see if it works right.

If I haven't actually drawn a flow chart, the first thing I do is write comments as if they were a flow chart. Then I fill in the space between the comments with code to do what the comments say. I test each section of code as I write it to ensure that it's working correctly and with the right amount of performance so that I don't have to go back to it once I add the final semi-colon to indicate that section is done.

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