Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm going to start off by saying that I'm in my second year as a Software Engineering major at R.I.T in New York. I had no experience programming in high school and ever since attending college I have been programming my ass off. I have had some struggles trying to think things through from a logical programming stand point and I was curious, for all of you professionals and people that have been programming from an early age:

How do you approach situations? Do you get implementation ideas from past experience or does it just come to you?


migration rejected from May 10 '15 at 12:19

This question came from our site for professional and enthusiast programmers. Votes, comments, and answers are locked due to the question being closed here, but it may be eligible for editing and reopening on the site where it originated.

closed as off-topic by Ixrec, Snowman, MichaelT, durron597, GlenH7 May 10 '15 at 12:19

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions seeking career or education advice are off topic on Programmers. They are only meaningful to the asker and do not generate lasting value for the broader programming community. Furthermore, in most cases, any answer is going to be a subjective opinion that may not take into account all the nuances of a (your) particular circumstance." – Ixrec, Snowman, Community, GlenH7
If this question can be reworded to fit the rules in the help center, please edit the question.

It is generally the combination of past experience,skill,exposure and creativity which culminate into problem solving.

If you are looking at the extent or time taken this would wary based on task complexity,skill,pressure among other factors.

Don't worry it does get better the more you are at it.remember the 10000 hour rule .

+1 for the 10,000 hour rule. Truth. – Matt G. May 4 '11 at 15:55

I would argue that implementation ideas never come out of thin air. Experience counts for a lot. And not necessarily even your own experience. Having mentors, be they teachers, people on forums (or SO for that matter) or even books/code can be a big help in your own development and give you something to draw upon when trying to find inspiration.

If you struggle to come up with logical solutions, don't stop. Keep going. Don't hesitate to completely screw up. As long as you figure out why you screwed up, you've already won half the battle.

And don't hesitate to look for inspiration in "unlikely" places. For example, I didn't really comprehend functional programming for a long time. But it all fell into place when I studied lambda calculus. But also the other way around: There were parts of linear algebra I only fully started to comprehend when I started programming CG applications and physical simulations.

So long story short, for me my current work is massively influenced by past experience, but also by all the other stuff I read/learn every day from a wide variety of resources.

  1. Yes, past experience is always critical (this isn't unique to programming). Every brilliant mind has stood on the shoulders of giants (including themselves, which turns this metaphor into contortion). Da Vinci, both as an artist and as an inventor, made baby step progressions on his work over and over again until perfection.

  2. Due to the above, don't be afraid to fail (and fail big!). Sometimes failures in design and performance are disguised as "prototypes". Code Complete argues that you should always make at least one throw-away prototype of everything you build. Take this to heart.

  3. Don't undervalue mentorship and learning from others. Be smart about who you learn from (it's easy to learn bad habits), and don't make that horrible mistake of taking a job straight out of college where you won't be able to receive advice and training from others. If you're the only developer at a company, you have no one to learn from. If you absolutely have to do this, demand a large training budget (two 3+ day conferences per year) and use it.

  4. Speaking of standing on the shoulders of giants, remember that every problem you solve has, at some point, been solved by someone else. I find this unnerving, but the best ways to avoid reinventing the flywheel pattern are as follows:

    • Learn design patterns
    • Use StackExchange. No really... it's by far the best tool on the web to share programming knowledge
    • Read. Code Complete and The Mythical Man-Month are two great books to read early in your career (or knock recruiter's socks off by reading it in college). Books from O'Reilly Media with "Cookbook" in the title are specifically targeted helping you avoid reinventing what other developers have already done thousands of times.
Your advice is generally good, but you get a +1 for excellent book recommendations. – Adam Crossland May 4 '11 at 16:33
  1. Work on visualizing the problem, use whiteboard and pen-and-paper to draw your data, algorithms, classes, whatnots.
  2. Do this repeatedly, then you will be able to do it in your head.
  3. That's when you start to lose sleep because you can't get out of the programming mindset.

Welcome to our world. ;-P


I think that over time, and especially after working in the same type of problem domain, you can begin to envision your implementation as the rules are being described to you. Even though I can get a rough idea of what I think the implementation will be I always reduce it to pen and paper (or white board) first. I draw diagrams for myself and talk with other developers to get their ideas as well. Like @Bart said, don't be afraid to make mistakes and re-write huge chunks of code. I don't think I've ever kept the first go at something ever.


First thing primarily is you get better in programming by doing a lot of coding or I should put is doing more problem solving.

As for how to approach a situation, Things I'd do normally.

  1. Flowchart (Having a flow chart comes in handy during the implementation aspect)
  2. Prototype ( I like to create a prototype and having a prototype helps me visualize most of the valid test cases, prototype has helped me quite a few times and my customers also like the prototype of the actual implementation)
  3. Implementation ( once the first two are in place implementation is usually straightforward)

I am not considering all the corner cases I just gave my perspective on how I would go about approaching a problem. I would also like to reiterate again that good design comes with more practice. that's why they always say Practice makes it perfect


When brainstorming a solution I have found it very useful to use yellow stickies. Each yellow sticky represents a process or decision. (For decisions turn them 90 degrees). This lets you move them around, rearrange the order of operations, insert missing steps, remove redundant steps... etc.

The stickies make it easy to quicky visualize a solution.


Getting experienced at problem solving through programming is just an ongoing cycle of learn/do/fail (or in my case, do/fail/learn). Eventually, your pattern matching will kick and and you'll say, "hey, this problem is similar to that other one" and the gods will smile.

your forget the good old "do/fail/learn/fail/wait..what?" ;) – Bart May 5 '11 at 0:05
Ah, yeah forgot the "i foreswear programming/grudgingly come back to the keyboard 12 minutes later" step, too :) – Kevin Hsu May 5 '11 at 5:20