Beefy Boxes and Bandwidth Generously Provided by pair Networks
Do you know where your variables are?
 
PerlMonks  

How do you code?

by bastard (Hermit)
on Jan 12, 2008 at 22:45 UTC ( #662119=perlmeditation: print w/ replies, xml ) Need Help??

A reasonably productive all-nighter+ got me thinking about this. How does everyone write code? I'm not asking about programming styles as much as how does the idea->incubating->coding->completing process work for everyone?

I've noticed that generally for myself its feast or famine. I'll hit dry spells when everything I write is forced and feels unnatural, and the other times when I can't stop myself and ignore sleep and most other life basics for days at a time. Often i'm fearful that i'll lose the groove and forget things that are stuck in my head. Most of the time, i'll end up with an idea that i'll toss around in my head for anywhere from a few days to more than a year, then something will switch... and boom, a prototype pops out in next to no time.

Other times i'll get side tracked with technology issues like trying to get a Centos5 Xen instance setup and configured so perl and apache mysql and dbix::class all play happily together while avoiding the annoying 5.8.8-5+ rebless of overloaded objects performance hit issue getting in the way. Or realizing that I should be using something like Catalyst as the true core to an application and subsequently re-organizing it.

When getting back into a project that had to be shelved for a few days or more I've found it can take quite a while to re-assemble a "working mockup" of the application in my head as a sort fo model I write code off of. On a number of occasions I've caught myself doing this nearly subconsciously in the hours and days preceding when I sit back down at the computer to work on the next piece.

I suppose on some levels how one gets the project done is dictated by the circumstances.

So how do you get your coding done (and under what circumstances)? Does your personal coding happen differently thatn stuff done for an employer?

As a corollary for extra credit, how many projects does everyone take on at a time. How many shelved? (i usually have 2-3 active and many more shelved) I've always wondered (and though yes many times) if my approach of having multiple projects active at the same time is detrimental to the process via too many distractions. (ex. working on a centralized customer service center for the subscription management and billing to automate the actual provisioning and billing of the other currently in progress services. I jsut can't force my mind off of the multiple subjects many times.) I apologize if any of this is a bit rambling. I promise to get some sleep soon.
dratsab

Comment on How do you code?
Re: How do you code?
by exussum0 (Vicar) on Jan 13, 2008 at 05:05 UTC
    I'm a stickler for clarity on what's being done - so horrid variable names, weird layout of methods and functions tick me off. When the juice isn't lose, I wind up writing code somewhat resembling what I want, and then cold stopping. I don't try and pretty it up in hopes I got it right, like Tetris. I just stop. I sleep on it until I figure it out.

    Then I solve the problem.

    When the juice is all over the place, I write unit tests against interfaces to a degree, write some skeletal code and then fill it up. It helps me understand how things are laid out.

    I try not to be to split across projects. Once I pass two, I start to get confused, or worse, neglectful.

Re: How do you code?
by starbolin (Hermit) on Jan 13, 2008 at 07:55 UTC

    I absolutely hate it when the boss comes to me and says that one project or the other is priority and that I shouldn't work on anything else. I just don't work well that way. I like to have two projects going especially if one is hardware and one is software. Gives a nice break for the old brain. I have to get up from the chair and move around so I like to find things outside the realm of coding in which to contribute.

    The feast or famine cycle is the same with any act requiring creativity. It's the same whether I designing circuits, coding perl or making little metal widgets. It takes some time to get your head around the problem. Then there is a burst of creativity followed by a period where you just feel 'dumb'.

    I started on the hardware end of things where we had a daily journal and had to turn in a copy of our notes at the end of the week. So note taking is ingrained into my work habits. I even keep journals at home. The notes assist in coming back to a task after some interruption. I find as I get older that notes are indispensable in those situations. Some days I'm very glad I took copious notes. Other days I'm very disappointed that I didn't take enough notes.

    There is always discussion about bottom-up verses top-down methods, but I switch back and forth between the two depending on my state of mind. On days when my brain feels 'thick' its nice to have a structure to work within. One other days, especially after looking at a problem for a while, the code starts coming out and you can't stop it.

    I had a boss once, we worked together at two different companies and got along famously, that insisted that no projects ever be 'rewritten'. He claimed that rewrites took to long and the product was always inferior. Yet you look at a crappy piece of code long enough and you just have to dig in and fix it. I rewrote several of his projects. He never knew until it was too late.



    s//----->\t/;$~="JAPH";s//\r<$~~/;{s|~$~-|-~$~|||s |-$~~|$~~-|||s,<$~~,<~$~,,s,~$~>,$~~>,, $|=1,select$,,$,,$,,1e-1;print;redo}
Re: How do you code?
by apl (Monsignor) on Jan 13, 2008 at 15:12 UTC
    While I have a primary project I'm on, I do tasks for three other managers as needed. If I'm not motivated to work on one task, there's always another.

    The downside to this is being told by three managers that each task had the highest possible priority. [This happened once; I then conferenced them together and asked for them to rank the tasks. They answered simultaneously "*You* know what's important!". *sigh*

    Generally I write a program from the top down, with dummy low-level routines. Once I can see the scope of the task, the details generally become easy to implement.
Re: How do you code?
by dsheroh (Parson) on Jan 13, 2008 at 17:23 UTC
    I tend to code in fits and starts as well, although I experience it more as a question of motivation rather than inspiration these days. A friend once described me as "obsessed with whatever happens to be in front of him at the time", which is fairly accurate - it can be hard for me to get started working on a project (whether personal or professional), but, once I write the first dozen lines of code, I can roll with it for a good while unless something else pulls me away. The same applies for switching between high-level design and coding, so I may be fine doing one, then stall when I need to switch to the other.

    I tend to design on paper/whiteboard (lists of database fields, class diagrams, etc.) and keep a high-level TODO file in each project's root ("complete module X", "add method Y to class Z"), but have never really made notes on what I've already done beyond moving the TODO items into a Changelog. This sometimes led to forgetting the details of how to use bits when I came back to it, but, once I started doing decent automated testing, I was pleasantly surprised to discover that I could easily refresh my memory of how to use a chunk of code by looking at that chunk's tests. Yet another win for testing!

    As I work freelance and generally work from home, the only differences between personal and professional coding are that work on client projects gets logged in my billing system and requires me to consult the client for design clarifications/changes.

    I currently have five projects at least semi-active, four for clients and one of my own. ("Semi" in that two of them are for the same client and he keeps switching off between having one active and the other on hold.) In general, I don't find multiple projects to be that much of a problem, but, in this particular case, two of the client projects are both relatively large and that's making it hard for me to get much done on any of them, because knowing there's a big project that I need to get done and am not making satisfactory (to me) progress on makes it hard to get motivated to work on anything else - and two such big projects means that, even if I'm working on one, I'm not making progress on the other. Live and learn, I guess.

Re: How do you code?
by sundialsvc4 (Abbot) on Jan 13, 2008 at 18:43 UTC

    I try to stick to the principles that allowed Charles M. Schulz to create more than 18,000 "Peanuts" comic-strips entirely by himself over the course of 50 years. He did it by consistently producing at least 7 strips a week during every one of those 2,600 weeks. And while it may be said that he did this at the cost of having gotten to do much of anything else, such as “retire,” he got to where he was -- to where he chose to be and wanted to be -- entirely through self-discipline.

    Computer programming is engrossing, consuming work. It is also very high-pressure, and the pressure is all the more high because “every one of those weeks, or days,” is not the same. There are days when thoughts flow like water, and days when they flow like frozen tar.

    So what I try to do is to write something every day. And for the most part I like to stick to a fairly consistent schedule. That schedule definitely involves keeping “about 9-to-5 hours,” offset by enough of an interval to avoid wasting time in the rush-hour crowds. (I also don't work from my home.) I've been known to stop in the middle of a subroutine. I try to end the day's work with "a note to myself" about what to do tomorrow, and often the next day I completely disagree with that little note. I am careful not to take work home with me, and some of my worst work has been done too-late at night.

    The music varies. Sweet-flowing idea days get rewarded with classical or good bluegrass. Tar gets pummeled with Bon Jovi. High-quality comfortable noise-canceling headphones are worth the investment. Your desktop is not a drum.

    I use a source-code control system (of course) and commit my work to it several times a day; usually two or three. I've been known to come in on a Tuesday and throw-away just about everything that I did on a Monday. Some days' thoughts are definitely clearer than those of other days.

    I take long walks at lunchtime. (I don't know of any programmer worth his or her salt who doesn't like to take long walks at lunchtime...) Some of my best ideas come during those walks. I keep a notepad and a number-two pencil.

    As far as overall work-scheduling is concerned, I use a very old beaten-up copy of Microsoft Project, back when they called it that. You've always got to have many things going on at once, and if you can keep them all in your head then you are better than me. That's also where the number-two pencil comes in. When an idea pops in, capture it immediately. Be sure to write clearly and completely. Once you've done that, you can't lose it. Your subconscious mind is thinking about things all the time. When ideas come to the surface they seem crystal-clear at the time but they don't stay around long.

Re: How do you code?
by igelkott (Curate) on Jan 13, 2008 at 20:44 UTC
    Just to add a little breadth to this discussion, I'll answer from the perspective of someone who has programming only as a peripheral work area.

    My programming process is forced and chaotic. I have little time to concentrate on any particular project but yet have several to work on simultaneously. I often start with a half-baked idea, manage to get part way through and then get pulled back into my "normal" work so far that I nearly forget where I was going with the program. The worst I've done is to get a "brilliant" idea, write the code, think of a good name and find that it clashes with another program ... which does about the same thing ... written by me several years earlier. OK, I've only done that a few times but even once is too much.

    Just for the record, despite the bad habits, I'm a reasonably skilled programmer (for a non-professional) but certainly not great. I can complete my projects without serious bugs and some of my DB-backed web applications have been in use for several years (albeit only on an intranet). Of course, this isn't to brag (I'm not that foolish) but just to express that even bad habits can produce usable good (but with much more effort).

    As the crazies or alcoholics can tell you, admitting the problem is half the battle ... or so I hope since I don't really know if I'll ever manage to find the time and will-power to make up the second half. ;-)

Re: How do you code?
by DarkLord1 (Novice) on Jan 14, 2008 at 02:55 UTC

    This is an interesting meditation. I, too, often wonder about and "stew" over my development "process."

    Most often, for me, I have as many as 3 different coding tasks in my queue. Sometimes with a couple of more "shelved." But, for me, I am sufficiently compulsive to solve a problem that I rarely can handle more than a couple (may be 3 at most) on my mind. So I'm not nearly as "multi-tasked" as your meditation suggests you find yourself in.

    The nature of my work (and the 2 or 3 other folks that I work with) is mostly putting out "fires"...i.e., we find ourselves or our colleagues facing some daunting task and we decide to tackle it. Time is normally "of the essence" and sophistication, ellegance, etc. are largely irrelevant. So we tend to try to solve the problems in the most direct, easy, and easily tested and proved ways possible. That, at least for me, creates the format of my approach.

    My approach is simply one of (A) think about the problem for a few days, (B) prototype, quickly, the tough parts, (C) code the solution, and then (D) do final tests of the solution...usually with a lot of debugging and fixing of mistakes.

    The hard part for me is normally step (C): coding. The size of our solutions are usually in the realm of a few hundred lines of code and, for me, that normally means about 2-3 days of almost non-stop coding. It is exhausting; and it seems that it consumes my "day job" (which is not normally about coding or implementing solutions...I am a systems engineer who spends most of his time guiding others and handling the politics of our projects).

    So these interludes of intense programming are always a bit of a shock to my system and I think the efficiency of my coding suffers because of it...especially during the latter stages of the coding when I'm at my tiredest and my thinking is more dominated by lack of sleep and deprived body.

    Recognizing this tendency, I tend to do a lot of module building in the beginning while I'm fresh and then spend more of the latter stages tie'ing them together to form the overall architecture in the latter stages. This works pretty well for me...but the mistakes and challenges that crop up in the latter stages tend to be real "bears!" They generally involve mistakes in the solution's fundamental logic and program flow: even though the pieces are all working correctly. In a tired state, finding the fundamental logic or control errors is daunting. Thank goodness for some good debuggers (especially the native Perl debugger) that allow some pretty methodical flow tracing.

    DarkLord1 Looking for Redemption in the Monastery
Re: How do you code?
by misc (Pilgrim) on Jan 14, 2008 at 15:15 UTC
    Yeah, I know it..
    coding 40hours+...

    Let's say I've got no problem to code 7 days the week, sleeping from 4AM to 10AM and sitting on front of the screen the rest of the day/night.
    I've also made the experience I get really productive after one or two 16 hour days without a break.
    I only need self-discipline to eat and drink enough in such times.

    However, I try to do things besides hacking, therefore usually I'm hacking perhaps one or two months a year in such a manner.

    The rest of the time I do force myself to spend time with my hobbies like climbing, my studies in philosophy, making some music, painting, ...
    Therefore I normally sit around 2 hours a day at the pc.

    If I do some work for a customer, because I need the money (I'm self-employed), I've got a great excuse to spend the whole day in front of the screen again.

    I always hadve ideas in my mind about new projects, and there are around 5 on the stack I'm working on.

    But I've made the experience I do the best results when I program in one language over several weeks, e.g. doing some hacks in perl and javascript in one day has never shown up great results.

    And yes, there's a difference to me between hacking for fun and doing some work fo a customer:
    If I do program for fun, I can do whatever I want - there's no pressure, and I can, e.g., if need a threaded server, play around with threads in perl some days and look for the optimized solution.

    On the other hand, if I have to write a threaded server for my work, I have to force myself to look for the shortest solution (instead of having an optimized and elegant solution, having the solution done as fast as possible), what I don't like.

    Programming is a kind of art and expression to me - so possibly I'll never get completely professional, I just love hacking too much - Just playing around with an aspect of a project for some days instead of just getting it done in some hours...
Re: How do you code?
by samizdat (Vicar) on Jan 14, 2008 at 15:28 UTC
    I'm a rabid INFP (Meyers-Briggs: (I)ntrovert - I(N)tuitive - (F)eeling - (P)erceptive), so I have to have motivation that gets me in the gut. I can't just apply myself to a dull boring "normal" work project without having a 'higher purpose' in mind that gets me up in the morning and keeps me driving long after the kids are in bed. in my case, I have a vision for using technology to help kids grow up smarter and more self-motivated.

    I know I have to 'ace' my low-level work-related projects using the least amount of my precious time, so I drive myself to analyze things at the highest level possible so that I don't have to go back in and spend time fixing things. In our work at {insert name of big computer co in RR, TX}, much of my job involves discovering dependencies and requirements from other existing software systems and standards -- as well as new requirements that hide behind some bull-puckie buzzword like 'persistent storage' -- that aren't always spelled out except in the memories of guys who've moved on to other projects, so roping in all of those is 90% of the work in a successful project.

    I'm also a big fan of pacing, and I generally stop when I make my first major blunder and pick up where I left off in the morning after a good night's sleep and some off-topic rumination, such as on my Higher Purpose. This presupposes that I'm ahead of the game and not coding features at the last-last-last moment. That crunch will come no matter what I do, by the nature of projects where Marketing always wants it all yesterday, but if I'm consistently applying myself for maximum effect from the beginning, most of my aw-sh!ts have already been surmounted when it does hit.

    It's also essential to be able to deal with those "while you have bandwidth" projects that magically show up to fill your time by making sure you get complete SoWs before getting stuck with work you need to apply major time to. I just got asked to configure an NTP server for our test lab, and before I knew it there was a bunch of Active Directory work included and oh, by the way, it's all in a VMware partition and you need to set that up, learn it, and deliver to that target. Sheesh!

    Don Wilde
    "There's more than one level to any answer."
Re: How do you code?
by Moriarty (Abbot) on Jan 15, 2008 at 10:20 UTC

    I started off with BASIC which lends itself to a "top-down" approach, but these days I tend towards the XP style.

    Because of my job, I can't hang around and wait for the juices to flow, I have a job to do and it needs to be done now! As a result, I tend to try and tackle the task in small sections, get the first bit working and then add the next. Sometimes it can be hard work, other times it comes easy.

    While I know that this isn't exactly the XP formula, it's as close as I'm going to get.

Re: How do you code?
by naChoZ (Curate) on Jan 15, 2008 at 16:54 UTC

    I'm the type that tends to what-if things to death. What if this oddball condition happens and I don't handle it in a clever enough way. What if someone wants to use this function in a curious way. What if someone else might know a better way to do this... what if what if what if... And of course the worst one... What if someone looks at my code...

    For me at least, this becomes a death spiral of utter lack of productivity. It's a conscious effort for me to strangle that voice in my head and just write some code to get the job done, even if I know it's crap. But I'll litter my code here and there with some TODO comments so I remember where my weakspots are and maybe an idea of how I wanted to fix it at some point.

    The other thing that I do fairly religiously is keep my code tidy at all times. It's just easier for me while I'm coding and I find myself having to rethink an approach to a problem or something, I don't have to mentally parse my own code. Consequently, in vim I type vip= a LOT. (I have equalprg set to run perltidy for me.) And at the same time, I find that I also code faster this way. I'll code a block without worrying a lick about style, then just vip= and it's immediately pretty.

    As far as handling and maintaining multiple projects, I just try to divide my time up appropriately, giving myself a fixed amount of time to work on one, then move to the next. When getting close to my time limits, I'll start doing things like writing empty subs with just pseudo code comments and writing as much as I can while my mind is on that particular project. When I'm thinking several steps ahead and I have time to code two of those steps, I'll try to leave myself so that I'll know what the rest of my thought process was. This makes it easier for me to get my mind back on the track of that particular project when it's time for more coding on it without having to recreate the whole thing in my head every time.

    --
    naChoZ

    Therapy is expensive. Popping bubble wrap is cheap. You choose.

      Wow! I know what you mean with your words:

      "I'm the type that tends to what-if things to death. What if this oddball condition happens and I don't handle it in a clever enough way. What if someone wants to use this function in a curious way. What if someone else might know a better way to do this... what if what if what if... And of course the worst one... What if someone looks at my code..."

      "For me at least, this becomes a death spiral of utter lack of productivity. It's a conscious effort for me to strangle that voice in my head and just write some code to get the job done, even if I know it's crap."

      I recently finished a project to analyze and determine a variety of statistics on the formation and growth of "warm pixels" on a focal plane to a sensor that we have had on-orbit for a while.

      The analysis results were, of course, the important point...but the analysis code took me a couple of months of hard work to complete and was the victim of an almost endless string of "oh that's great! Is the growth occuring in clusters or individual pixels", "are the pixels getting warmer, colder or stable?", "...yada,yada, yada."

      The total code ended up being about 700 lines of Perl code (voluminous...but unfortantely more the result of endless adding, adding, and adding new "features" rather than a meaningful design). Towards the end I had some time to sort of look back over the work and the code and realized just how much of a toll the total process of trying to code for maintainability, and for worrying about "what if some of our other folks wanted to use this and chose to this or that." Such endless worries, and worries about trying to guess and account for all the possible wierd use scenarios tend to make my code overly complex and often far more serpantine that I'd like.

      DarkLord1 Looking for Redemption in the Monastery
Re: How do you code?
by Perimus (Novice) on Jan 16, 2008 at 00:09 UTC

    I sometimes visualize meters over my head like a character from The Sims. The most important being level of concentration. I try to identify the things that negatively affect that meter and manage them. For me, distractions as simple as a five minute random conversation with a passerby can scramble the stack in my brain and cost me a good 30 mins of productivity. Too many consecutive interruptions and I'll get too tense to easily regain focus.

    I dedicate the early part of my day to eliminating distractions. Handle the e-mail, phone calls, voice mails and co-workers that just want to chat, and review assignments to my employees. Then I shut the door and let my office manager redirect anybody that comes knocking. I wouldn't hear them anyway with the headphones.

    All distractions aside, I lay out goals for the day's work and get to it. Having set goals gets me focused before I even get started. The rest of the day usually flies by.

    On the bad days, when the focus or creativity just isn't there, I find something productive but relaxing to do. I'll try out a CPAN module I saw and wanted to mess with, or spend a few hours with an O'Reilly book.

    If I'm pathetically awfully unproductive, I'll compose long winded forum posts and go home to play Team Fortress 2.

    sundialsvc4 touched on this, but I try to never mix home life and work life. I don't entertain myself at work, or work much at home, because then when I'm at work I'm subconsciously trying to talk myself into playing games, and when I'm at home I feel guilty if I relax too much because maybe I should be working instead. It's a guaranteed recipe for a period of burnout.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://662119]
Approved by almut
Front-paged by Old_Gray_Bear
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others musing on the Monastery: (8)
As of 2014-10-23 08:36 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    For retirement, I am banking on:










    Results (125 votes), past polls