22

First of all, this is not the generic 'make me a better programmer' question, even though the outcome of asking this question might seem similar to it. On programmers.SE, I've read and seen these get closed here, here, here, here, and here.

We all know there are a multitude of generic suggestions to hone your programming skills (e.g reading SO, reading recommended books, following blogs, getting involved in open-source projects, etc.). This is not what I'm after.

I also acknowledge the active readership on this web site and am hoping it works in my favour by yielding some great answers. From reading correspondence here, there appears to be a vast number of experienced people who are working, or have worked, programming-related fields. And most of you can convey thoughts in an eloquent, concise manner.

I've recently noticed the distinction between someone who's capable of programming and a programmer who can really think. I refuse to believe that in order to become great at programmer, we simply submit ourselves to a lifetime of sponge-like behaviour (i.e absorb everything related to our field by reading, listening, watching, etc.). I would even state that simply knowing every single programming concept that allows you to solve problem X faster than everyone around you, if you can't think, you're enormously limiting yourself - you're just a fast robot.

I like to believe there's a whole other face of being a great programmer which is unrelated to how much you know about programming, but it is how well you can intertwine new concepts and apply them to your programming profession or hobby. I haven't seen anyone delve into, or address, this facet of the human mind and programming. (Yes, it's also possible that I haven't looked hard enough too - sorry if that's the case.)

So for anyone who has spent any time thinking about what I've mentioned above - or maybe it's everyone here because I'm a little behind in my personal/professional development - what are your suggestions on learning how to think? Aside from the usual reading, what else have you done to be better than the other people in your/our field?

J.K.
  • 13,063
  • 1
  • 40
  • 56

13 Answers13

13

My suggestions on learning how to think:

  • Learn new languages. Both natural and programming languages. Have always a new language to learn on your hand. Thinking is done more a less in a language. Every language has a different "view" on thinking. More languages you know, more "mental tools", concepts, point of views and abstractions are available to you.

"Language shapes the way we think, and determines what we can think about." -- Benjamin Lee Whorf

And more importantly language determines what we can not think about.

  • Read voraciously. Read broadly. Not just about programming, but history, sociology, biology, arts, etc. Broaden your perspectives. Get fresh insights. You are not just what you eat -- you are also what you read. New ideas are more about combining two (seemingly) different ideas, than a divine flash of creativity out of nowhere.

"Chance favors the prepared mind." -- Louis Pasteur

  • Humility. You must know a lot, in order to understand how little you know. Humility helps to keep your mind open for new ways of thinking.
  • Ask why? Don't be content with how.
  • Learn mathematics. A really powerful tool, a kind of language, to work with logic and abstractions. Studying mathematics strengthens your brain. Mental equivalent of "going to gym".
Maglob
  • 3,839
  • 1
  • 24
  • 27
  • I'm not so sure on natural languages. Learning them has value, but for thinking? In a programming context? The value of words for thinking is sometimes overstated - we can have ideas that we can't express easily in words, therefore we aren't totally dependent on words for forming ideas. Also, the most relevant vocabulary (jargon for mathematics and other technical fields) is heavily shared between languages. –  Jun 09 '11 at 03:35
6

From my experience it comes down to two things:

  1. Passion, if you are interested in the craft you will learn, adapt, and be quicker to think outside of the box than many programmers who are in the field just as job. (Some of which don't have computers at home.)
  2. Some people are just born with an ability to solve technical problems. Some people naturally have the ability to abstract out a flexible solution.

Beyond this, everyone is fairly different in how they think about programming or learn new programming skills. I suggest you keep trying new things and keep what works good for you.

jzd
  • 4,166
  • 25
  • 28
5

What are your suggestions on learning how to think?

Practice. Practice. Practice.

Seriously, mental activity (i.e. thinking) is like physical activity. The more you do it, the better you get at doing it. (In fact, physical activity involves a kind of mental activity too. Top sportsmen don't just have the muscles in the right place ...)

So how would you would you (effectively) practice thinking?

(Here I'm generalizing from something else ...)

I think you would identify thinking problems that you find difficult (but not impossible), and try to solve them (think them through) and more like them.

Stephen C
  • 25,180
  • 6
  • 64
  • 87
  • I kind of support this. Anytime I'm doing something repetitive that doesn't require thought to do, I am thinking about something else. I also tend to do this when doing repetitive things that I should think about, such as driving, but somehow I feel like I drive better when I'm not thinking about it. – Earlz Feb 12 '11 at 05:37
  • 1
    @Earlz - I don't understand your point. If you are doing something repetitive, you don't need to think about it. I'm talking about practicing solving problems that *require* thinking. – Stephen C Feb 12 '11 at 06:48
  • experience trumps everything (kind of a general statement, I know) but you learn with time, I mean how often have you ran into a problem took you forever to resolve, only to run into it again and take care of it in minutes. Also its the way you approach a problem, don't focus on being stuck, always focus on what haven't I tried yet, from the simplest to the most complex – farinspace Feb 12 '11 at 19:04
  • _Deliberate_ practice. You need to learn something from each iteration. –  Feb 13 '11 at 00:08
4

You may be interested by those the following two things:

The Flow

Mihály Csíkszentmihályi, an Hungarian psychology professor, introduced the concept of the flow.

Flow is the mental state of operation in which a person in an activity is fully immersed in a feeling of energized focus, full involvement, and success in the process of the activity.

I'm lucky enough to be able to enter in the flow everyday by using an old technique I learn from my application of GTD which is the next action.

I can tell you it really makes the difference. When I'm in the flow, I produce higher quality and faster than when I'm not in that state. I'm totally focused on what I do, and therefore I think more effectively.

Mindfulness

I asked a question about meditation a while ago because I was concerned by the fact meditation could decrease my programming (and creative) abilities.

I just started Jon Kabat-Zinn method training, so it's too early for me to share with you extensive experiences, but from the few I learn so far I can tell you this is probably something you will want to do.

  • +1 Although I hate that there is a book and whole "theory" on what amounts to a common sense approach to a problem, GTD certainly has legs. – Orbling Feb 12 '11 at 01:15
  • 1
    @Orbling: oh I totally agree with you on that. But like in most books there is crap and value. What is crap and value depends on who is reading the book. The problem with GTD is that it's so powerful, it can crush you if you don't take the time to reduce your input instead of focused yourself in managing it regardless its size. That was my mistake ;) –  Feb 12 '11 at 10:04
  • The problem I have in my life is that there is so very much input, and so much to do, that I would not have time to implement any such procedure. Though I can certainly see the value in it. – Orbling Feb 12 '11 at 12:37
  • 1
    @Orbling: I think that's the key. Filtering your input is the ultimate productivity technique, on top of Covey or GTD. It requires to be very strong mentally. –  Feb 12 '11 at 12:41
  • I find it needs additional people to accomplish the tasks you filter out, lol. – Orbling Feb 12 '11 at 12:44
2

I've always believed good engineers are born, not made.

You need the mind set for it, the logical, analytical, deductive mind, combined with the tenacity and inquisitiveness required to get an overview and a structural view of a problem in an efficient manner and quickly walk from A to B, routing your mind through the solution.

There is a lot of research suggesting this skill is hugely boosted by good early exposure to such things, music too helps. After a certain point in time, your mental maps are pretty hard wired. Not in terms of what you think, but how you think.

Can you learn how to think as an adult? Well you can certainly be taught techniques for breaking up problems, but then you have algorithms to follow, you can become a very "fast robot" as you eloquently put. The intuitive understanding is probably innate.

This is by no means limited to our profession, plenty of skillsets are dominated by innate skill, rather than acquired response. People may not want that to be true, but it most likely is.

Orbling
  • 5,696
  • 1
  • 32
  • 38
2

Find an online forum on something you're passionate about. Something which has some sort of community. Preferably not programming - programming forums are usually more solution-oriented than discussion-oriented. Take a stand. Defend it. Use arguments. You can also blog, but having an opponent is better. The point is to have meaningful and written communication about something with someone. Where you exchange somewhat bigger pieces of text.

You'll learn to communicate your ideas and argument them. Since you'll have to defend your views, you'll have to support them with facts. You'll have to think about something, articulate your position, and support it; maybe even change it.

Afterwards, take that ability to analyze the issue and synthetize the opinion and apply it to anything. Even programming.

Domchi
  • 662
  • 5
  • 12
2

One thing I think of is that one needs to see things as systems, and all systems are related. Every single one in the universe. Humankind, the planets, the galaxy, the plants, sunlight, photosynthesis, insects, rocks, oceans, all interacting systems. Likewise, in time, cycles: birth, growth, decay, death, of bugs, people, civilizations, mountain ranges, star systems. The endless struggle for energy. All systems.

This is the Study of Life and Nature in the grand sense of Study. See all things related, see all things interacting. Concentrate on this when you watch the sunset and sense the depth of the forces of gravity that spin us around the Sun, pull us down to the planet's surface, and the ebbing sunlight that reddens before entering your retina at 300,000,000 meters per second and making images in your primate brain.

When you start to think of that, of how everything is related, of how the price of gold and slave labor and storms across the Pacific and industrial complexes in Japan are all related, and you take the time, really take the time to sit and think about all this, then your thinking "muscle" will really flex and grow.

Now, a lot of that will be below the threshold of expressiveness, but don't let that stop you. Your brain is more powerful than the most powerful computer. Push it. I don't think it's possible to overclock it.

I'm reminded of a black and white picture that showed albert Einstein lounging on a lawn chair on the beach looking at the ocean. The caption said: "Here sits Albert Einstein. With his brain."

The next challenge is to be able to communicate the complexity and interdependency of all things in a simple manner. This will give you something to do until you're very old.

Christopher Mahan
  • 3,404
  • 19
  • 22
2

One approach is Deliberate Practice.

Simple repetition doesn't lead to any acquisition of skills - you need to be introspective, to evaluate your performance, to identify ways to do things better.

An illustration: A close relative of mine competes in the sport of pistol shooting. During training, a lot of concentration goes on reviewing every shot, focussing on the steps that go correctly. Counter intuitively, not much focus goes into poor shots, because replaying (rehearsing) the mistake reinforces it.

Simply firing 100 shots down the range accomplishes nothing. Deliberate Practice of firing 20 shots will reinforce good habits and lead to better performance.

The same applies to programming - think about what you do. Don't do it monthly, weekly or daily - do it moment by moment, action by action.

  • Why did that defect occur in my code?
  • How might I have avoided creating that defect?
  • How might I have found the solution more quickly?
  • Which assumption of mine was wrong?
  • Did I ask for help fast enough? too fast?
  • Have I made that mistake before?
  • Is this defect isolated, or part of a pattern?
  • Is there an underlying design defect?
  • If so, can I do anything about it?

And so on ...

Bevan
  • 3,170
  • 20
  • 22
1

So you want to think

Lots of mostly great suggestions from other posters about how to think or how to learn to think: the flow, mindfulness, maths, passion, practice... so I will not go there, ground covered.

But none about why. What's the purpose?

Personally I have come to understand that before you can think you need to know why.
The single best thing to do is to listen and look. (I take both as a unit, you can't separate them)

The only way to get better at programming, whether that be gathering up requirements, transforming those requirements into detailed system specifications, matching this with design documents, implementing the code, debugging for your dear life, whether you skip any or all of those stages, whether you have five minutes to find a solution or 20 years, you need to listen and look.

Listen to what the user wants, listen to what the user tells you has happened, listen to the support person tells you they saw. Listen. Listen even if it does not make sense. Listen even if you are convinced they are so wrong. Listen and not judge.

Look for clues, not by searching but by opening your eyes. Look at reality. You cannot start searching for answers before you looked at the crime scene. You cannot find a solution until you have proven the flaw.

One single example from my experience (on bug resolution, but it could be adapted to anything really). For obvious reasons (legal and otherwise) I will keep juicy details out of this. On a safety critical system an operator reported a serious flaw. Some geographical tracking device actually lost tracking when it 'should' not have, with potential impact on lives (this 'should' was the real mistake and stalled our investigations for way too long). Fortunately, although this was found weeks later almost by chance, as there was another system in operation at a remote location for which another operator came to prove the tracking had not been lost on that system. This got us thinking again. Our main software supplier did not believe us a single second, so we had to go out and prove the matter. The only way was through graft: building a simulation to replicate the exact operational situation. We had to actually video the proof for the supplier to believe us. Eventually the simulation yielded information beyond our hopes and lead us to understand the whole problem. It did not take long to fix after that.

The only way we got through to the end was by logically connecting one remote system with another doing a similar job but not quite the same job. That's the looking for clues (Look). This was only possible by trusting the one time report and not dismissing it as a random glitch in the system (Listen), and then hearing again the second report that contradicted the first (Listen).

So when you have the right clues (having listened and looked), defined the problem area, understood the root cause or key principles, then you can think of solutions towards further understanding first (trial and error, simulations, demonstration, proof of concept, mock-up, alpha, beta versions), and eventually offer a solid solution (which sometimes can be further improved after some real life operation).

To be able to do such listening and looking takes an open mind, trust, and absolute dedication to your goals. This is the fuel you need to think, or more to the point for your thinking to be focused on the right target (often the problem is not inability to think but the lack of a well defined target to exercise your mind on).

asoundmove
  • 1,667
  • 1
  • 9
  • 10
  • +1 for your answer, studying your problem domain and listening to the users is essential. Though -1 for the "yeah right" comment, so no change. – Orbling Feb 12 '11 at 12:51
  • @Orbling: Ok, you're right, that was a little overboard. Comment removed. I don't think innate talent is right, but no need to mention it. – asoundmove Feb 12 '11 at 14:57
  • Well if you had -1 my answer instead, I would've marked yours up all the same, but it prevented it in this, fixed now. Fine to mention it as wrong if you disagree with what I said. – Orbling Feb 12 '11 at 15:10
  • @Orbling, nah I don't fancy voting -1 for anybody, I'd rather just move on... Only extreme scenarios warrant -1, just disagreeing does not. – asoundmove Feb 12 '11 at 23:43
  • I agree with you on the other sites, as they are right/wrong in the main. Programmers.SE is different from the rest as it is subjective, so the voting is basically agreement, disagreement. Whether you think it is helpful or unhelpful. I only negative vote if I *strongly* disagree with someone. At time of writing, 2.6% of my votes are downvotes. Opinions after all should be challenged. – Orbling Feb 13 '11 at 01:38
1

Go poke at something you love until you find an edge.

Deep breath,

Step over...

...

... Tell others what you've found.

Paddy3118
  • 617
  • 1
  • 5
  • 10
1

I think you need to make the distinction between different kinds of thinking.

Creative thinking - how to come up with new ideas, innovative solutions and unexpected results. There is a whole science behind this, look for Edward de Bono, creativity techniques etc. Not many programmers look into this area.

Analytical thinking - by this I mean scientific process. Look at inputs, outputs, measure what's important, come to logical conclusions. Most developers are familiar with scientific technique but then never really use it. Do so!

Critical thinking - I think this is more philosophy. Stand back and look at the bigger picture, review your assumptions, do you really do what you say your values are? Study philosophy there is a bunch of great authors and ideas out there.

Richard
  • 398
  • 2
  • 5
0

Math teaches one how to think. Application requires creativity and experience.

I refuse to believe that in order to become great at programmer, we simply submit ourselves to a lifetime of sponge-like behaviour

Good insight. Roughly stated, the requirements for "greatness" depend on your personal definition of "greatness"...and have changed over time. Today, project success is about being able to piece together concepts quickly and without delving into all of the nitty gritty details. Personal success could be defined as mastering C# like Jon Skeet.

Read coder's at work. Much more experienced coders than I discuss this in detail.

P.Brian.Mackey
  • 11,123
  • 8
  • 48
  • 87
0

Work on applying ideas and concepts from seemingly unrelated areas. To me, the brilliance of the iPod was not the engineering behind making a great MP3 player, but helping solve a huge problem the music entertainment industry was having with pirated music and the CD/Album model of selling music. Jobs probably applied more of what he learned at Pixar in dealing with the movie industry. He knew what the real problem was.

JeffO
  • 36,816
  • 2
  • 57
  • 124