update:
I've been off for a week after finishing a project and moving house, in that time this domain dropped and just prior to that appeared to get 20k+ reads which is a bit omg. Anyways many comments all over the net, and certainly on reddit (comments here) - and thus just to clarify, the entire content of this post is purely a note to myself, and to help me in those times when you can't get going in the morning or such like.. in no way am I suggesting you don't plan or do things properly whenever you can - this is literally just some ways of getting through the day. Thought I'd made that clear and most people got it ;)
end update:
This one is more for my own reference, but sharing anyways as it may help others. In numerous scenarios it is really hard to "get going" when you're trying to code, particularly under the following circumstances:
* You haven't started coding till late(r) in the day
* Emails, Blogs, Social networking have taken up more time than expected and/or distracted more than anticipated
* You've just completed a deliverable, milestone or task.
* You're tired!
All of these are virtually daily occurances in the coding world, and here are the methods I've used to get going again.. no particular order, just a list.
Under all circumstance, avoid planning!
Planning is one of those things you can't do unless you are all ready in the flow, whether this is because you've just had a client meeting, a long discussion, or read a full spec - it's not the thing to do to get your flow going, all you'll do is plan nothing, plan badly, or stare blankly at the screen / paper.
Don't read related material to get you in the flow.
This will purely serve to distract you, make you think about doing things differently, doublt what you've done or worse throw you in to planning mode - fact is you won't be planning "your" app though, you'll be planning "some" ideal app or scenario.
Pick the smallest task, whether complex or not, and just do it!
Doesn't matter what it is, so long as it's coding a little part of the app, or modifying part of it, then it'll do. It could be adding an extra field to an object or table, popping in some validation, anything small and simple. It really doesn't matter if you do it right or wrong; you're not doing it to sign off a task, you're doing it to re-aquaint yourself with your system, by the time you've been through X lines of code you'll be back in work mode and firing on all cylinders, well on your way to getting zoned.
Music, Headphones, Repeat.
You'll know the genre that suits you, personally I find repeating an album or even song fades me in to the zone and keeps me there. The repetitiveness of the tune keeps you there, because just as a phone call can distract you, so can a change in tune to something at a different tempo or worse a completely different genre.
Don't cram!
If you've only got 15 minutes before the next sizable interuption, forget it, don't do anything just chill - make a coffee, smoke, whatever. You're not wasting time you're saving your zone, you can only get zoned a couple of times a day, so don't get zoned for only 15 minutes - save it and get zoned for longer later on.
Speedcode
Why not? as nike say "just do it", if the code has 10 bugs but is finished in half the time then you've done good, that gives you loads of time to fix the bugs, and more importantly you get to those moments where you realise x,y&z need to be changed much quicker. Not only that, but would you rather have a week to go and have a list of 80 bugs, or a week to go and 2 major deliverables a week overdue..
Communicate for no reason.
Often a major focus is simply talking to somebody else on the same project as you, whether its the client or a workmate, and the more stressed they are the better, they'll not only blast you with things but their urgency / stress will often convey straight over to you and focus / zone you instantly.
Do the thing you know, not the thing you don't.
Inline with "don't plan" and "pick the smallest task", always pick something you can already do (if possible), as with everything else, the things you don't know are much easier when you're already zoned, not only that but you'll be more focussed when doing the thing you don't know so less likely to over spec / over code it.
Don't code other things!
nothing on earth will kill your project like working on something else, every minute you spend on another script or app is like an hour lost on what you should be doing, and with every minute that passes you're getting closer and closer to utter project failure - and hence why most open source projects are dead.
Remember, the key to forced coding is just to get you in the zone, and ultimately boils down to just getting stuck in there with some lines of code on your project.
Works for me anyways [most of the time] - if anybody has anything to add (constructive) then please do!
Regards - nathan
Great tips. I'm in a funk right now; I'm ready to try them out. Thanks.
snap! that's why I wrote it, 6 deliverables and 2 days to do them!!
Nice piece of advice dude. I also do a lot of these things like picking off the smaller tasks first. Also gets you a better overview of what remains to be done, since 75% of tasks get done in 5% of the time.
My main issue at the moment is that I work at the client ON LOCATION. This really kills my productivity. Advertising agencies are really noisy, sometimes like a big kindergarten with lots of noise. Gonna do that differently in the future.
I agree with all of the above and have a couple of others which help me sometimes (although nothing is 100% reliable unfortunately):
Leave easy finishing up to the next day
It's late at night and you are flowing well but are going to have to stop soon. Don't keep going until it's all done, leave yourself some "finishing up" to do. Then the next day you can get straight into it and have a headstart at getting into the zone.
Get a good rest
If you are tired then it's hard to concentrate. Sometimes the best way to deal with a fast approaching big deadline is to take a step away from the computer and get a good rest so you can come back to it and attack it with energy rather than feeling like you are banging your head against a wall.
Exercise
Seems to help recharge the batteries. Then again, I've been absolutely useless at that one on the current project so can't really make any claims...
Tea
And lots of it!
nice post, I especially like the advice about completing the smallest task first.
I'd add the following:
The planning and reading hints are only useful for people who suffer from analysis paralysis. Many people don't think enough so actually doing those things would be useful.
I also disagree about the 'don't code another thing'. Unless you can't put it down once you start I think this can be a great way to relax and rediscover what you love about development. This is especially true if what you develop can be used on your project.
My one addition - and it's very close to your suggestion of 'pick the smallest task' would be to write down on a piece of scrap paper a very short list of some things you want to try and accomplish that day. If you ever feel like you're distracted pick up the paper and read it. It reinforces focus and as with your suggestion it lets you accomplish something.
I am in the perfect situation for that and i'm going to put these great tips into practice right now. Except the fact that ATM I have no other work partner to talk to, but I do feel the need to.
For much applications programming for small sized programs, a great deal can be done ad hoc. Usually only a small percentage of the code or a few algorithms would be complicated and much of the rest could be done as you go along.
I agree with all this advice, and especially agree with headphones.
One thing that gets me in a funk is if I know I have a meeting, even 4 hours out, it kind of looms over my head all day and tends to make me not as productive.
my best advices are :
a. just do it! code the smallest thing each day to keep you on track. even the smallest bug you fix can be considered.
b. document everything you find for later. create a todo list, even when there are thousands of tasks, just write everything down, and once in a while, sort the list and prioritize it.
Always break after a breakthrough
If you are working on something you don't know the answer to or some god awful bug, once you hit the eureka moment and everything clicks into place, instantly get up and go for a walk or a tea or something. There's no better feeling than sitting down to a problem you know the answer to.
"Communicate for no reason" made me chuckle. Can't work? Interrupt someone else so they can't either. ;)
Thanks for all of these tips, I have to admit I am guilty of spending too much time on the blogs / news, but its not my fault - they show up in Thunderbird taunting me to read.
Also and to a lesser extent I had the ideology that if I work on another app / script I will get in the coding mood, but my groove when achieved just goes to the other app, then I can't put it down and get my work done.
There is some advice that I can't follow - allowing buggy software out, well not too buggy anyways, I am working on a private B2B site for my company where the users find one small issue, even typo, and will consistently call and bother our staff until fixed.
I am definitely open to advice there.
Thanks for the article and the distraction, I am following your advice and going for a coffee.
Schweet! Liking it...
Good list, reading this made me realize that I actually do a couple of these things without noticing.
I take a shower when I'm in need of some focus. Relaxes me, makes it easier to get into my zone. Coupled with music, it's a solid 1-2.
That is my entire development method. Only thing different is I tend to replay Metalacalypse seasons instead of music. I could not believe I saw it in written form.
Trying to explain how I work a piece at a time never helps, I will just refer people here.
Awesome article. screw agile development, this is Slacker Development Super-speed Methodology. ++
"Communicate for no reason."
I find this acts like exactly like a reset button. It disturbs my PA though!
Great list mate, I would add:
Go Outside
I find that if I detach myself my the computer and step outside trying NOT to think about my project then when I return to the computer I feel more apt to do the project.
It's hard to say becuase I often have those times where you would rather be doing something else than coding a project you don't enjoy much.
Howdy,
I've been in a funks before and always get myself out by
subconsciously applying many of the principles you listed. I've learned through
hard experience that the advice you write is true. Sometimes you just need to
program to get yourself in the mood to "Program", i.e. create quality software.
I want to add that testing, debugging, documentation, research and various other
design and organizational problems can be the death knell for a programmer if he
is running on empty. By simply letting programmers do what they love and get into
the mood, you can generate energy for the essential non-programming ( read:
BORING, difficult/tedious non-technical tasks).
What's interesting about this advice of "just program", a.k.a. Cowboy Coding is
that it seems to contradict modern iterative software development paradigms.
AGILE, Documentation/Feature/Test driven development,
XP,
SCRUM,
etc..
All of These models put emphasis on many non programming related tasks. Testing,
debugging, documentation, people interaction (client review, client feature
requests/change/management); and all of these models condemn programming that
isn't apart of their carefully laid development method.
What this means is the
programmer is no longer a programmer, he is now a software engineer.
The skills of a software engineer is vast. He must multitask between various
interdisciplinary skills. He must be a manager, a team leader, a customer service
representitive, a businessman and on top of this he must be a master programmer.
It's easy to see how programmers can quickly lose interst and fail to get
motivated in their projects. That's why it's so critical to let programmers just
program some days. I'm not sure the advice of "Program on your project no matter
what" is good here, because in a team enivornment I don't see how cowboy coding
can fit in. Maybe you can explain to me how a programmer could just do his own
thing in one of these development paradigms?
Great post. I think many of us suffer from the same things. I'd like to see a follow up on each point that expands on the topic and gives us more insight on why each one is effective, how to avoid pitfalls and other little tips.
Some very good points. Thanx!
:( Last tip just killed me. I closed editor immediately. Avoid planning and don't cram - it is sad, but I think these are 3 reasons I did not wrote anything for months(besides useless scripts & some code to "test something"). Thanks nathan, this short reading was a little shock for me :|
This is so relevant, i love it!
Interesting points indeed. The planning one is interesting, not that I totally agree but we all have different methods.
How to do lists, not To Do Lists at the end not the the start
Excuse the heading, I note what needs to be done at the end of the day, either on the train home or away from the computer. I need my mornings to focus and I find if I spend time, like Nathan says, planning whilst in front of the geek machine it doesn't get me into the code-flow.
It is also important to write lists of solutions not problems, even if the solution is simiply "Test something as a unit" rather that "This is broken". It is a GSD (get shit done) advice, note the way to solve something! Its about pumping the positives and not getting caught in the negatives.
Paper not screen
If you are stuck, contrainted by time and tired! Get away from the geek machine. Walk and use paper to write down a mass of ideas to solve - even if they are way off the simplest solution. There are techiques in creative problem solving which relie on a non-judgemental mind. Paper is great for a collection of brain storming ideas and disjointed flow, it connects a different part of your mind.
Thanks mate, I get back to work now!
This is the story of my life - too many distractions and always far more that I want (need) to do than I can actually get done.
I first realised the benefits of playing my favourite music to help me focus years ago when I was at university. I would put an album on (see I told you it was years ago), sit back to work on a program, and the next thing I knew was the "click" of the head lifting off the record and the music stopping. I rarely actually heard any of the music.
Today's distractions are far more than just background noise though. As you pointed out there are emails, phone calls, the need to send my troops back out farming NPC's on Evony (oops - scratch that...) and far more.
It's a constant battle to try and focus, but I agree with you that sometimes it's better to get some of the smaller jobs out of the way. If you have 10 things to achieve, 8 of them are quick fixes and 2 are going to take hours, I much prefer to get the 8 quick tasks out of the way, then I can focus on the major tasks. That is of course unless another 8 minor ones come along, which happens too often...
listen to th same song over and over? you lost me with that one!
This comment was originally posted on Reddit
Don’t plan?
This comment was originally posted on Reddit
Thank you, this is exactly what I needed today!
This comment was originally posted on Reddit
Great tips – reminded me of a post on beating writer’s block: http://www.mentalfloss.com/blogs/archives/8864Note: It’s a FUN post, not really practical for coders [eg: "Graham Greene wrote exactly 500 words per day, even stopping mid-sentence if necessary"] but a nice distraction.. just what you need when you’re battling procrastination.. :)
This comment was originally posted on Hacker News
> Speedcode > Why not? as nike say “just do it”, if the code has 10 bugs but is finished in half the time then you’ve done good, that gives you loads of time to fix the bugs, and more importantly you get to those moments where you realise x,y&z need to be changed much quicker. Not only that, but would you rather have a week to go and have a list of 80 bugs, or a week to go and 2 major deliverables a week overdue.. I can’t decide whether the article is using reverse psychology or not.
This comment was originally posted on Reddit
I can’t tell if this is supposed to be satirical.
This comment was originally posted on Reddit
He seems to be talking about planning as a bad way to start your day and I would agree. To get going tedious planning which requires a lot of thinking is not a good thing to do.
This comment was originally posted on Reddit
Pick the smallest task, whether complex or not, and just do it!…Doesn’t matter what it is, so long as it’s coding…It could be adding an extra field to an object or table, popping in some validation, anything small and simple. It really doesn’t matter if you do it right or wrong; you’re not doing it to sign off a task, you’re doing it to re-aquaint yourself with your system, by the time you’ve been through X lines of code you’ll be back in work mode and firing on all cylinders, well on your way to getting zoned.This is excellent advice!
Whenever I’m frozen, this is what I do, and before you know it I’m doing something else.
This comment was originally posted on Hacker News
But you just added all these qualifiers to planning which changed the meaning.
This comment was originally posted on Reddit
How am I supposed to know what the smallest thing is if I don’t plan? And why would I ‘get something done’ quickly with more bugs if I knew the implementation part was already much faster than debugging. It seems like I optimized the already fast part of my development process at the expense of further slowing down the already slow part of my process.
This comment was originally posted on Reddit
The problem he’s trying to solve is "getting going", not "how to write quality software": > here are the methods I’ve used to get going again He doesn’t say "don’t plan" he says don’t plan to get your momentum going.
This comment was originally posted on Reddit
I like his advice. One thing I try to do on personal projects that helps is to keep a journal. At the end of every session, I write down what I did and a couple of things that are left to do. The next time I sit down, going over the previous couple of entries helps get me back into that state and gives me a starting point.
This comment was originally posted on Reddit
I see those as properties of any kind of planning.
This comment was originally posted on Reddit
The music part would never work for me… whenever I put some music to play I get completely absorbed, and all studying, or coding, for that matter, comes to a full stop.
This comment was originally posted on Hacker News
"Why not? as nike say “just do it”, if the code has 10 bugs but is finished in half the time then you’ve done good, that gives you loads of time to fix the bugs, and more importantly you get to those moments where you realise x,y&z need to be changed much quicker. Not only that, but would you rather have a week to go and have a list of 80 bugs, or a week to go and 2 major deliverables a week overdue.."What!? Has he never read Code Complete? I’d rather be 2 weeks overdue with no bugs than on time with 80 bugs. 80 bugs means I’m really overdue by a month…
This comment was originally posted on Hacker News
I usually just go with electronica of some kind, usually Trance or Ambient (both preferably non-vocal). Others are ok too, it’s mostly a matter of preference, drum’n'bass for instance. It’s repetitive enough to not get in the way of me thinking like lyrical music does, but still pretty good to listen to.
This comment was originally posted on Reddit
Yes. When I’m studying math, I work best if I just dive right into the practice problems, then go back and review the notes as needed. Once I find a challenge and get hooked on a problem that I can’t quite answer, I’m fully focused.I focus best when I have an immediate challenge or a problem to solve. Same for coding – diving right in to stimulate myself, and then I can start thinking of solutions/designs as I tinker with the small stuff and (re)acquaint myself with the structure/API.
This comment was originally posted on Hacker News
Strange how this is different for everyone. I’m the opposite, for example.
This comment was originally posted on Hacker News
good advice
This comment was originally posted on Reddit
"The smallest thing" is the thing you notice and instantly do while scanning through the code. It starts with fixing a typo in a comment, and ends just before things that’d _make_ you plan.
This comment was originally posted on Reddit
> "if the code has 10 bugs but is finished in half the time then you’ve done good" If this fellow worked for me, I’d *greatly* prefer that he just called it a day. Writing buggy, incomplete code is far worse than writing no code at all. When there is no code, we have the job of writing code. When there is bad code, we have the job of debugging, repairing, maintaining, discussing, discarding, and finally writing good code. More and more team members get drawn into an expensive, time-wasting process.
This comment was originally posted on Reddit
then try more boring music
This comment was originally posted on Hacker News
Buggy code is better than no code at all: Producing buggy code, spotting the bugs and then either fixing them or re-writing the code with the new understanding is usually vastly more productive than setting out and drawing blue-sky "bugfree" UML diagrams. Please note that it’s not code that you’re supposed to release. It’s work-in-progress. Every great painting starts with a rough sketch, to figure out where the lines belong. So even if it’s just before closing time, let him write his sketches, so he can dream about the finished painting during the night.
This comment was originally posted on Reddit
Works great for me, but only if the music in question has no lyrics. Baroque, bebop or pretentious Philip Glass-y stuff seems to work best.
This comment was originally posted on Hacker News
Indeed, some points are interesting and logical, others don’t make sense at all ( "avoid planning!" WTF?)
This comment was originally posted on Reddit
I agree with this approach to work-in-progress code. If you are just prototyping, developing an algorithm, etc, then spending too much time designing your UML diagrams and the like is a waste – you’ll think of a radical (or not so radical) change that’ll require another hour of re-planning and two-three changes in the code.
This comment was originally posted on Reddit
Supposedly listening to music while problem solving or coding results in similar productivity, but more errors.On the other hand, http://pom.sagepub.com/cgi/reprint/33/2/173.pdf claims that music listeners (with practice) produce similar quality results in similar real time, but 1) have less actual time working (the music does distract) and 2) feel better.
I often listen to (mostly classical) music while programming, but I’ll pause it if I feel memory-impaired, or need to make an important decision.
This comment was originally posted on Hacker News
You could keep a journal, or just version control everything and read the logs.
This comment was originally posted on Reddit
i agree with him. when you’re "stopped", planning is the hardest thing to do. best to "get going" first, and once started, then you can plan. most important is to "get going".
This comment was originally posted on Reddit
I think his point is that when you’re experiencing "coder’s block" and can’t quite get into the grove, it’s best just to sit down and actually *write* something and don’t worry about the potential bugs up front. This has to be a better alternative than sitting down trying to think up the best way to go about writing it, and wasting that entire time not actually doing anything. That doesn’t mean the final product is shoddy, buggy, or bad at all. He’s just talking about the initial process, which I happen to like. It’s like overcoming writer’s block. When you can’t think of anything "good" to write, sometimes it helps just to do like a brain dump or just start writing open verse just to get your juices flowing.
This comment was originally posted on Reddit
I do the same thing. I think the act of writing the prose is as valuable as the actual notes I take. It seems to engage a different part of your brain, and makes you look at the problem in a different light.
This comment was originally posted on Reddit
Yeah, exactly. I never plan first thing. I start coding to get an idea of what I’m doing and then start planning when I get a sense of the complexity of the task. I get a lot more done that way.
This comment was originally posted on Reddit
I can do it with any music, from crazy hip hop to smooth jazz ;) I get massive energy from the music and sometimes my coworkers catch me singing while i code lol !
This comment was originally posted on Hacker News
This sounds like a rapid prototype coder, I’m pretty similar but not to the point that the code is beyond crap. When you code fast, you code crap, and you will ultimately be spending time cleaning it up later anyways (time saved now is time you’ll need later). Also, you will have extremely wasteful code, allocating shit tons of unnecessary memory, having code replication all over the place, etc. Many developers fall into rapid prototyping because of unrealistic deadlines, and the prototype becomes the production code which is absolutely not what you do in prototyping. You scrap it (or refactor), it’s merely used to realize all the complexities in a design. If you simply code fast and get rid of major bugs, you’re still left with shitty software.
This comment was originally posted on Reddit
I am sure he meant avoid future planning only when you’re tired. At the start of the article he talks about milestones which are a big part of planning. I seriously doubt he meant just jump into every project you ever do with your eyes closed hoping it turns out right.
This comment was originally posted on Reddit
Endless loop of Daft Punk => Good code
This comment was originally posted on Reddit
Agreed – when I was in grad school we called this approach "Make it work, then make it pretty." It might not always produce the most elegant solution, but then again it’s pretty hard to hit elegance consistently right off the bat.
This comment was originally posted on Reddit
The only time I can do music with lyrics is when it is songs that I am so familiar with that they don’t distract me. I’m a Tool fan, so it’s in my mix. But as a general rule I agree with you: ambient, some jazz, others. Non-vocal is preferred when coding.
This comment was originally posted on Reddit
i agree lyrics can interfere with coding. i keep a long playlist of electronic dj mixes and tracks. no need to listen to the same song or album repeatedly. there’s such a wide variety of electronica out there that is conducive to coding.
This comment was originally posted on Reddit
Where else would you keep a journal!?
This comment was originally posted on Reddit
This is correct in developer’s terms, but not necessarily in sales terms. Unless you manage yourself, you may get fired for choosing the first option (overdue with no bugs). Another good reason for working for yourself, I guess.
This comment was originally posted on Hacker News
This article is completely unscientific — but it wasn’t supposed to be! Some of the author’s points really hit home for me, a few I totally disagree with, and several even helped me get started this morning, so thanks for sharing.
This comment was originally posted on Reddit
Details, details. All middle-management cares about is whether or not the task is done. And the associated costs of your shitty code are, at least partially, shifted on to your co-workers. This gives you an even better comparative velocity! Bonus season will be good this year.
This comment was originally posted on Hacker News
I like keeping a journal, too. I start doing it for timekeeping (so I can tell my employer what I did each day), but I found it helps me, too–I know earlier when I’m wasting too much time on something, and should go about it another way.
This comment was originally posted on Reddit
I’m a big fan of paper notebooks.
This comment was originally posted on Reddit
Music works for me. I also like noisy inter cafes because the noise just blends into a nice background ensemble.
This comment was originally posted on Hacker News
There’s a better approach: instead of writing sketch code, write tests. It helps you work out what the code ought to do, and it’s actually useful at the end. "Throwaway" code has a nasty habit of being patched into a state of marginal usefulness, and then kept around for ever.
This comment was originally posted on Reddit
I never thought of this, but this is brilliant! Writing tests never happens enough!
This comment was originally posted on Reddit
I entered the work force in July, but have only put Pandora to use this past week. I love it, and I’m thinking of upgrading to Pandora one. So far, I’ve been listening to Franz Ferdinand and the like, but I’m liking your station! Thanks.
This comment was originally posted on Reddit
Music doesn’t work for me either, but I have no problems with background noise at a cafe or office or something like that. I think it has to do with background noise lacking any sort of discernible structure to focus on. That sort of background is more like white noise and easy to phase out, music gives me too much to focus on.
This comment was originally posted on Hacker News
The worst problem of listening to music is that I get the song stuck on my head after I finish coding. I prefer to avoid it.
This comment was originally posted on Hacker News
I listen to music to deafen out the environment. Its not the best solution (Which would be working in a quiet environemnt), but the "distraction" from music is a lesser evil compared to the "distraction" from working in an office.
This comment was originally posted on Hacker News
totally agree.
This comment was originally posted on Hacker News
and use a bug tracker for the things left to do.
This comment was originally posted on Reddit
dubstep, fuck yeah
This comment was originally posted on Reddit
Put communication with other people first. If you can’t code it’s because you’re preoccupied with something else. Trying to code when you know you can’t code is a great way to introduce boneheadedness into a project, unless you have extremely strict checkin policies.
This comment was originally posted on Reddit
TATFT
This comment was originally posted on Reddit
You reveal your ignorance in your claims of knowledge my friend.
This comment was originally posted on Reddit
Wow, thank you so much for the Artist listing. Usually a huge avant-garde jazz fan, but jazz can be distracting sometimes (use it mostly for planning program composition) and have been getting into Bartok and Satie lately. These are a little more up to date and aren’t as distracting.
This comment was originally posted on Reddit
Hah! Yes, thank you. That is what I meant by ‘writing tests never happens enough’ but put ten times better!
This comment was originally posted on Reddit
I’d buy that. For me, listening to music while coding is an engineering problem: how to minimize the tendency to let the mind wander without overwhelming it with new input.For me that means using music that is ambient enough without verging on elevator muzak style irritation. I ended up with instrumental hip-hop (dj shadow, etc).
This comment was originally posted on Hacker News
You have to take what he said in the context he’s talking about. He’s not talking about how to approach a project. He’s talking about how to turn "I don’t feel like doing anything" into "Hey! It’s time for bed *already*?!?"
This comment was originally posted on Reddit
I think he means just start. You probably have the capacity to write decend code off the bat. Mull over the harder stuff once you get "zoned"?
This comment was originally posted on Reddit
That’s because it’s painful. :) I’m not in the habit of it, but I’m now forcing myself to do BDD, and I have to admit I’m not enjoying it. It slows me down and I find it cumbersome, but I’m well aware of its long-term benefits, so I’m still working on it. The project is still in the early stages, so there are lots of "stories" to write. bleeeh…..
This comment was originally posted on Reddit
"avoid planning" *when you are trying to get to coding.* Good advice. The two activities should be very separate and are rarely best done back-to-back.
This comment was originally posted on Reddit
There’s nothing wrong with sketching as long as you don’t send the sketch off as final. He’s not talking about working on final production code here. He’s talking about the initial moves in developing a project.
This comment was originally posted on Reddit
>There’s a better approach: instead of writing sketch code, write tests. Different strokes for different folks. Unit testing needs to be done, but it’s not the best "starting off" option for everyone. I tend to use a more formal requirements specification rather than write tests. This suits the sort of work that I do. I realize that certain methodologies choose otherwise and that they get by fine and it makes them happy, however. >"Throwaway" code has a nasty habit of being patched into a state of marginal usefulness, and then kept around for ever. Not if you have the discipline to not do that. I always start a new project when I’m begining to work on the initial actual project. Even if I want some of that sketch code, I force myself to copy and paste it over one method at a time. That extra work and the act of throwing that code onto a clean slate really makes me consider whether or not that bit of code belongs in the actual project. I *never* take a sketch and evolve it into a real program, and I am never tempted to do so. I know what you mean though. Some people do this, but I think that those people go into the "sketching" process with a different mentality. I don’t think that it’s thought of as sketching to those people, I think it’s thought of as "I’m writing the program."
This comment was originally posted on Reddit
Foreign languages help. Ladysmith Black Mambazo works for me. Reggae also works for me, since I just don’t understand what the hell they’re saying half the time.
This comment was originally posted on Reddit
Agreed. When doing rapid prototyping, you have to have the discipline to throw the prototype away. You don’t take code from the prototype, you take ideas and methodologies. The actual project is a clean slate. As to mess and poor allocation, it depends on your experience level. Eventually, there are a lot of mistakes that you don’t really make any more. Nothing close to *all mistakes* but there’s a degree of difference between the errors that an entry-level dev is prone to and those that even a seasoned dev is prone to. With that said, there are enough mistakes that you are prone to, and there’s enough architecture that does need to be done more carefully that you do not ever use that prototype for production code.
This comment was originally posted on Reddit
Don’t plan *when you are trying to code.* You have to read the statement in context. It doesn’t work if you just skim the bullet points.
This comment was originally posted on Reddit
Actually, I usually start a new piece of code by writing down its type, which (at least in Haskell) already covers most boring bugs. Bugs, that is, that don’t tell you anything new about the code you want to write. But then, writing a test for an existing part of code is a thing I sometimes do to start out. In the end, I don’t think one needs tests until one pretends to know that one’s code is bug-free.
This comment was originally posted on Reddit
Premature optimization is the root of all evil. That doesn’t only apply to performance, but also to design. 90% of the ugliness stems from 10% of the code: Those ad-hoc parts that actually propagate their ad-hocness throughout the whole program. Do those carefully, and don’t waste time on over-designing the rest. As (hopefully) you’re doing bottom-up design, those 10% are going to be about the last ones you code, anyway, so you’re going to have thought about them in the back of your head sufficiently when you get to writing them, anyway. So don’t worry. The thing that’s needed is called "Foresight", not "DesignFactoryImlementationDelegateI". "Foresight", implements, among others, "EncapsulationI".
This comment was originally posted on Reddit
You’re kidding, right? :-) Seriously, Test-Driven Development (TDD) is a well-established (but insufficiently practised) idea.
This comment was originally posted on Reddit
Interesting. I don’t always do TDD, but that’s because of False Laziness: whenever I make the effort to do TDD, I always thank myself soon afterwards :-)
This comment was originally posted on Reddit
> I tend to use a more formal requirements specification rather than write tests. Tests == executable formal requirements. > Not if you have the discipline to not do that. Alas, I don’t. Or, more precisely, I have yet to work for an organisation that has that discipline.
This comment was originally posted on Reddit