Coding is a very attention consuming exercise, how do you prepare yourself to begin a good coding session?
I use to be more calm and ready to think in a useful way after reading some insightful new posts from my rss reader.
Coding is a very attention consuming exercise, how do you prepare yourself to begin a good coding session?
I use to be more calm and ready to think in a useful way after reading some insightful new posts from my rss reader.
I don't code well when calm. Downing a Code Red or 2 gets me going so I can code.
I find listening to remixed video game music a good way to slip me into the programming mind set. http://ocremix.org/
I normally don't need any preparation at all. It's even hard for me to rest if I am implementing something and want to get it done.
Peace and quiet - I have been known to put on my over-the-ear headphones at work and forget to turn the music on. Even when I remember to hit play, the headphone wire also serves as a leash reminding me not to be distracted, jump up to make a vending machine run, look through my books for that one reference to that obscure thing from my ancient past....
Basically, find a way to put the distractions away.
Review the "big picture" on what you are getting ready to code, for example the user story or the use case. It helps refresh the mind on the overall task before getting lost in the nitty-gritty details.
I refer to the following citation, which is hanging on my office wall at work:
Mostly, when you see programmers, they aren't doing anything. One of the attractive things about programmers is that you cannot tell whether or not they are working simply by looking at them. Very often they're sitting there seemingly drinking coffee and gossiping, or just staring into space. What the programmer is trying to do is get a handle on all the individual and unrelated ideas that are scampering around in his head. (Charles M Strauss)
Actually, I don't prepare for coding. Have a good breakfast in the morning, some coffee, begin the day with browsing my favorite websites and then start coding, maybe with some music, maybe with some audiobook, maybe calm, and don't trick yourself into believing you must be coding without a break. Take the time you need, relax, and don't forget that ten seconds of thinking can save you ten hours of bugfixing.
The quick, short answer: if you think like a coder/programmer, you'll be more likely to succeed as one
The longer answer: Have you heard of 'Blink' by Malcolm Gladwell? He brings up an experiment in that book that's relevant here.
It involves the subconscious attention we pay to information we're interacting with, and the effect it has on how we act.
In his example, there were a series of students divided into two sets. One set took a test that consisted first of profile questions (age, height, etc.), followed by math questions.
The 2nd set of students had a similar test, except their profile questions included queries about race and gender. According to the analysis, these questions subconsciously reinforced stereotypes about test performance and intelligence, causing the test results to sway noticeably lower than the first group.
This may not have been an answer so much as a pleasant and mildly relevant anecdote from a book about thinking. :D
I'll start with a good read on my RSS reader and then just phase me into the challenges.
Most of the times I just have to spend a little time looking at the wall to think of how I can turn a boring task into a challenge, and there I go.
Most often anything just trickles my "interest buds" and I just have to spill it out.
And the last thing: Radio, streamed or air waves. I have to listen to Radio. The music keeps me focused and it will help me do breaks, like when the DJ talks about something interesting. Otherwise I'll be distracted by the Radio being silent, since ambient noise really does not affect me on a conscientious level.
First, if you expect to accomplish anything significant make sure you can have the next several hours potentially uninterrupted. There's nothing more destructive to a productive mind frame than getting up every twenty minutes to take out the garbage, grab lunch, answer the phone, drive to the pharmacy, etc. Getting your tea, coffee, music, and snack prepared before you start is a good idea so you don't interrupt yourself.
Second, select the task you fear the most and plan to do that one next. I've found if I put off items which seem difficult on the surface it negatively affects my mindset. They can seem to grow into a dark cloud on the horizon, but if you address them early you can turn a mountain into a molehill. Sketch out some ideas for that task on a pad, make a short list any todo bullets which can be individually crossed off, and jump on the keyboard with the simplest possible assumptions. Having a micro-plan and a sense of incremental progress always helps avoid engineering despair.
I honestly try to start and end my day trying to take care of any distractions that may get in the way of coding. Like in the morning before I start, I take care of all my emails, quick browse through my daily sites, ask any nagging questions about the code I had from the day before, etc. My morning things can usually be taken care of in a half hour to an hour. At night when I get done I try to take care of the larger distraction, larger being they take more time. One distraction I have is TV shows that I can watch on the Internet, so at night I watch them. This way I am not tempted to watch them while working.
Once you get rid of the distractions get a pop or coffee, a bag of chips or candy, put the tunes on, and start rolling out the code.
Envision the green bar! You gotta love seeing that green bar, right?
That gets me excited to write my first test case, and tests should be written before code, right?
By designing.
If you write a line of code before your design is more or less clear to you - be it just in your head, in scrappy notes, whiteboard UML, Visio UML, or a big-ass design document - then it's likely to be worse code for it.
If you know what you're going to code before you code it, the rest should be easy.
For me i read code, that is either very sad and/or beneficial because when i read code i get ideas and think of what i have done and how to better myself the next time i code.
When i do that and start coding, i have a mindset of bettering myself each time.
A little bit of internal conversation can help.
I usually start a programming session with a fresh pack of cigarettes,empty ashtray, a full pot of coffee in a carafe on my desk. I make sure my playlist is all mapped out (no surprising Rob Zombie suddenly popping out of the midst of Paganini, or vice versa), and clear at least two workspaces of all clutter.
Right before coding, I write a little summary of what exactly I'm trying to do, so I don't wander off and spend valuable time working on tangents (despite what I'd like to think, unlike Stallman my tangents are unlikely to ever become Necessary Tools).
If I still get code-block, I find it unusually helpful to go to pastecode and play around cleaning up code I find there. You're guaranteed to find a couple snippets of horrid code that, with a few clickety-clacks, will boost your confidence and ease you into the right mindset.
Prepare for the next session but ending the previous one properly. Note things down that you still need to work one, targets for the next session, tests you need to write, liberal use of TODO messages in your code.
If you have a decent ideas of where to go with the next day's work before you start, that will make you more productive. If the first 10-15 minutes is completing some tasks and doing good - not rooting around and picking up the pieces - you'll feel better and more confident and less in need of distraction and a reset.
Personally, I try to completely visualize the problem and the solution in my head. Then once I am satisfied, I will write the code once, and correctly.
I start by making a check-list of specific changes I am going to make during that coding session, then check them off as I complete them.
I think it's really valuable to have an itch. I guess many of those who read here knows that feeling. When a thought is firmly planted in your mind's front porch. Even common every day situations seems to be valuable input to your thought process. Taking a shower, going to the store etc. How to make it start itching... brainwashing helps me. =) Something else that I've discovered can be severly disrupting is annoyances in the private life like having an argument with one of your loved ones or the like. It really sucks mental resources from you in a devious way. Try to clear such stuff out of your mind if you can.
Really loud music. I do not mean deafening, but enough to block out all other noise. I find that my brain is really good at blocking one source of distraction, but the problem is when there are too many sources to keep track of. Over-ear headphones turned up a significant amount is most successful for this. I find that after a while of focusing (and this isn't just for programming, but general writing, reading, etc.) I no longer hear the music at all.
Getting a good night's sleep I think is paramount for me. I know that if I am running low on sleep my coding abilities start to drop off quite quickly let alone my ability to effectively communicate with my team.
I think it's really important to understand what you are doing. If you have to implement a complex algorithm and you have an idea of how it works, but don't understand how it exactly works then you should not start coding. Instead writing down the problem do some drawings if it can be visualized. (or transformed into a geometrical problem) Go through on or two steps on paper, then figure out how the problem can be mapped to classes and methods and once you understand everything start coding. Eventually some more questions will arise when coding and, depending on the complexity of the problem, you will eventually have to rethink some of your initial toughest; for example changes on the OPP-Model or clear up somethings about how the program should behave in certain situations.
For me it's easy as this:
Staring into space is always good - especially when some other ppl are so intent of figuring out what are you doing and it's none of their actual bus :-))))
One good first step is to accept the fact that six months from now, you're more likely to look back at the code you're about to write today and consider it absolute tripe than you are to consider it a work of genius. For some odd reason, the acceptance of this grim calculus makes it more likely that you will indeed produce something worthwile rather than tripe. It has to do, I think, with not forcing permanence and perfection on things. The best code is that which functions as a future stepping stone to the next code. Let the tool do the work; stop the internal dialog and listen to the code, it will tell you what it wants to become.
I recently discovered that playing a match or two of table football with my colleagues can help a whole lot, as a preparation before as well as a break between two programming sessions. (Fortunately my current customer has one next to my office!) Its simple: Some physical exercise, something that focuses your mind and trains your eyes and brain. At the same time it helps get your head clear of all the mails, RSS feeds and stackoverflow posts you just read.
Another thing I've discovered: Don't read and answer your mails at the start of the day, but immediately dive into a programming task, because by reading mails you just postpone (and increase) your troubles to get into your stuff.