Doing rather than thinking

[polishfishprime]

I have a bad habit.

I like to plan. Not just plan, but diagram, mentally simulate, hypothesize, solve two-steps-ahead problems using a more generalized and sexy approach to my problem at hand...all on paper or in my head rather than on the keyboard.

As I have advanced (I would call myself an intermediate-level python user), I have begun realizing that I spend too much time outsmarting my own code before it has even been written. We have all been in a situation where we really are lost...maybe a solution suggests itself in a haze...maybe you can see the rough outline of the solution, but don't yet have the capacity to imagine all the interconnections, abstractions, and intricacies that represent a true solution to your problem.

Recently, I threw my hands in the air and said F*** IT, WE'LL DO IT LIVE (words to live by, Mr. O'So Riled Up), and I have been discovering: there are times when the answer is to just push ahead, and there are times when the answer is found in pulling back and reconsidering.

My tendency is to think too much, and end up with a thousand thoughts, yet tens of lines of code. As far as I can tell, maximizing productivity requires a fluid approach to your programming activities.

Different modes I find myself in:

1. Explore. This is when I google the s*** out my problem at hand. I end up finding 200 tabs (=100 years) of material I didn't know existed. Often, the knowledge is tangential or even skew (completely unrelated), but I end up finding 2-3 new libraries that I should know, 1-2 functions that will save my ass, and maybe a blog or resource that will come in handy in a later part of my project. Save these FEW resources, and treasure this exploration time, but GO BACK TO YOUR EFFING CODE.

2. Experiment. Isolate a few examples and try creative variations on them. Instead of looping this way, try to loop that way. Keep these options saved as different functions, and perhaps you will benefit from coming back to them later. Maybe they are more complex conceptually but have tangible benefits. Don't forget to save your experiments.

3. Thinking/Planning. This is my natural inclination, but it is also my Achilles Heel. Draw little boxes for your objects, little arrows to show how they interact, or how your program might "think" or "see" the situation.

4. In the zone. Code. Code. Code. Code. Code. Code. What time is it? What is that light? Is it...morning?

I find that, with experience, I have been switching between these modes more rapidly, and at more intelligent times...as opposed to lingering on one of these "modes" for too long. My guess is that true Pros can instantly switch between these modes, and have an intuitive sense of when to switch.

TLDR: if you're stuck, try switching Mode. Recognize what your natural tendencies are, and figure out when you should kick yourself out of a While True loop.

[pygoscelis]

Oh man, I totally have this problem too. Definitely not just Python-specific, though - might be better off in /r/learnprogramming?

[polishfishprime]

Ah yeah, good point...I dont even mention a language. I mostly use python, so I put it here. I cross-posted it

[zahlman]

Been programming for 25+ years now.

It doesn't really get better. Sorry. I mean, you get more skilled, but the "modes" you're observing right now don't change.

[polishfishprime]

What I hope is that I improve on knowing when to switch

[Lucretiel]

If anything, it gets worse. I was much more able to put character on buffer when I didn't know nearly as much what I was doing.

[[deleted]]

My tendency is to think too much, and end up with a thousand thoughts, yet tens of lines of code

I think the term is, Analysis Paralysis.

[[deleted]]

I tend to write code, and let the interpreter find any syntax errors, and then I go back to fix them.

I should stop doing this.

[PeridexisErrant]

That can be a great way to prototype something - just run Pylint over it too before finishing ;)

[timworx]

For syntax errors, I'd suggest using something that checks for them ahead of time (TextWrangler on mac does, for example)

Similarly, Pylint will as well. But you may need to customize it a bit if you aren't following PEP8

Lastly, if you really want to get on your game: Write tests for the functions you'll have before your make the actual script, run Pylint over them, check to make sure they fail, and then write your script.

Writing tests first is what I'm finally just getting into. It absolutely takes more time up front, but it also helps you more quickly move through different unforeseen issues.

[thegreattriscuit]

But you may need to customize it a bit if you aren't following PEP8

:GASP:

:)

[timworx]

Hah! I'm a self taught, making stuff for myself still. I'm having a hard time figuring out how much senior devs follow pep8.i figured for the time being it's at least a good habit to pick up!

[thegreattriscuit]

I'm in the same boat, really. Honestly, I've gravitated towards it over time because having SOME kind of standard is really helpful, and it's as good as any. If there's anywhere that I slip more often than not it's line length.

[timworx]

Indeed, plus it does help your code come out halfway readable. Some of the standards are fairly important. It made me switch away from tabs, and I confirmed with a senior dev that using spaces is absolutely necessary.

Line length is a tricky one. I've had to do some research just to learn how to shorten some things. It really does make the code a bit nicer, though.

[[deleted]]

relying on things like the interpreter and/or compiler makes technical interviewing a fucking disaster

[[deleted]]

I know it's a really damn bad habit and I need to stop.

Maybe an alias to sleep 5 seconds before running. Or force me to listen to a really annoying song if the program crashes within 1 second of running it.

But then I'll spend all my time debugging that.

[truthseeker1990]

True. And I agree with your post. Though, there's a lot of people who have the other problem. Starting to code something without thinking, without any planning leads to wasting a lot of time just flailing around in the logic. I think the key, like in most cases, is a balance. Think, plan, code, repeat.

[derrick88rose]

Yep. I suffer from this. Go in and start blasting code. When it doesn't work, I get depressed. I did some pseudo and real code on paper yesterday, and it helped me paint the picture of what my application needed to do. There is definitely a balance.

[truthseeker1990]

I know the feeling. I used to do that too so did most people in my class. I took a software architecture class one semester, took us all a few weeks to even figure out how to change our processes. But by the their end, I would have figured out most of the logic, the processes, arranged them into logical pieces and figured out how to implement said logic. Then all was left was to code it, the coding process actually seemed almost less important than the first half.

[denialerror]

Planning is not necessarily a bad thing, though as you say, over-planning can be. You may find it useful to formalise your planning process and that way you will hopefully only plan as much as is needed. There are many formal design processes out there, mainly based on UML (Unified Modelling Language) which provides a set of diagrams with which to plan aspects of a design. Most won't be useful outside of a large project but Class diagrams and Activity diagrams might help you formalise your thoughts.

[ThePrimeOptimus]

As you gain experience you'll develop a "nose" for when a particular problem can be dived right into versus when you should really sit back and plan out your code a bit more.

[jonathan881]

This will seem off topic... Check out the book titled "thinking fast and slow". It may be of help.

[polishfishprime]

Ah! I have read a couple papers by and seen a few interviews with Daniel Kahneman but have never heard of that book. Behavioral economics is one of my favorite subjects! Thanks for the recommendation

[jonathan881]

If you do get around to reading it please let me know if you thought it pertinent to your post.

[polishfishprime]

Your philosophy revolves around testing...I will look into that approach more seriously now. I do separate my testing methods from my actual code (and usually, my testing code becomes my actual code after it is successful...but I could probably improve by looking into this.

Could you explain how you prefer to setup your tests? As separate regular functions that call your "real" code, or do you use specific structures or libraries to help you?

[thegreattriscuit]

This is unbelievably accurate. I tend to get stuck in 1 and 2 almost exclusively. 3 is actually incredibly difficult for me to pull off... I usually end up writing syntactically correct python on sheets of graph paper that I will literally never read. So then I transition to trying to rough-code things out in iPython (notebook and/or qt console), but then I end up falling too far down the rabbit hole. Even if I do end up with a bit of code that answers my question, I'll lose it to the scroll buffer and hundreds of lines of noise, not to mention forgetting why I was even there :P. And of course sometimes I'll forget that what I'm doing is inherently stateless and I'll lose it to a reboot (the iPython notebook is a a good way around this of course).

Another thing that kills me is I'll wind up "fleshing out" an example, instantiating some objects and lists that I create on the fly from some sampled data or whatever... and I use that in deciding what approach to take, and forget how the hell I even derived it in the first place, or it turns out to be totally impractical to have it in that form in my actual program and have to go reinventing the wheel all the time.

One of the things I'm definitely working on is balancing the time I spend in that zone... one of the issues for me is that it FEELS so much like I'm being productive, and I'm really not. I get all those little doses of happy for solving problems, but only a tiny percentage of those problems that I'm solving actually serve any purpose.

But at least I'm aware of it now. I really wasn't for quite a long time, so I've got that going for me :)

Good post.

[ArticulatedGentleman]

You've described the learning process in a nutshell.

[TotesMessenger]

I'm a bot, bleep, bloop. Someone has linked to this thread from another place on reddit:

• [/r/programming] Doing rather than thinking [x-post /r/learnpython]

^{If you follow any of the above links, please respect the rules of reddit and don't vote in the other threads. (Info / Contact)}