I have lots of small lisp projects that I hack on incrementally: I'm not
really in control of my hacking time allocation - family members tend to
override it pretty much at random. I find planning and sticking to a
project quite difficult in these circumstances: one week I have plenty
of time and get a sizeable chunk of work done, but for the next two
weeks I get almost no time, and forget most of the details of the code
and the general direction I was taking the project in..
These problems can't be uncommon and I wondered if the panel has any
time/project management tips that would help? Yes, I know it's a bit OT,
as it's not specifically a Lisp problem, but Lisp seems to be more
amenable to this incremental development style than anything else, so I
thought I'd get better feedback here.
--
+--------------------------------------------------------+
|Cyborg Animation Programmer | ·····@yagc.ndo.co.uk|
|http://badbyteblues.blogspot.com -----------------------|
+--------------------------------------------------------+
John Connors wrote:
> I have lots of small lisp projects that I hack on incrementally: I'm not
Lots of Incremental Small Projects?
:)
From: Ken Tilton
Subject: Re: Managing lots of small lisp projects
Date:
Message-ID: <LAttg.19$4j7.3@fe08.lga>
John Connors wrote:
> I have lots of small lisp projects that I hack on incrementally: I'm not
> really in control of my hacking time allocation - family members tend to
> override it pretty much at random. I find planning and sticking to a
> project quite difficult in these circumstances: one week I have plenty
> of time and get a sizeable chunk of work done, but for the next two
> weeks I get almost no time, and forget most of the details of the code
> and the general direction I was taking the project in..
>
> These problems can't be uncommon and I wondered if the panel has any
> time/project management tips that would help?
You are doomed. I must sit in front of my sofwtare for hours before I
begin to become productive. Interruptions longer than three hours
require a three-day re-immersion before productivity returns.
Immersion is the word I use. Also the skipping stone metaphor. The
tendency to pop out of the water (the task) and sail thru the air
(losing the task) is terrific.
It is not a question of not knowing the code, it is a question of
spirit. Nothing can save you. Well...have you seen/read "The Shining"?
kenny
--
Cells: http://common-lisp.net/project/cells/
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Ken Tilton <·········@gmail.com> wrote:
+---------------
| John Connors wrote:
| > ...quite difficult in these circumstances: one week I have plenty
| > of time and get a sizeable chunk of work done, but for the next two
| > weeks I get almost no time, and forget most of the details of the code
| > and the general direction I was taking the project in..
...
| You are doomed. I must sit in front of my sofwtare for hours before I
| begin to become productive. Interruptions longer than three hours
| require a three-day re-immersion before productivity returns.
| Immersion is the word I use. ...
+---------------
I call it "reloading my (primary) cache", or "loading all of the
necessary context back into associative[1] short-term memory".
Once loaded, I can tolerate a *few*, *short* interruptions without
losing substantial context, but even a single half-hour total
interruption can blow the whole cache [especially if the interruption
itself requires loading new context to service].
It's a bummer, but seems to be the way (some kinds of) creativity
works. At least IME...
-Rob
[1] "Associative" in the psychological sense of being readily-
available to make connections or associations with other data
in short-term memory, not in the cache memory organization sense.
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
····@rpw3.org (Rob Warnock) writes:
> It's a bummer, but seems to be the way (some kinds of) creativity
> works. At least IME...
And at least in my recent (on-the-job) experience, the interruptions
are so common that the immersion never comes to fruition. The time in
between the interruptions -- even several hours -- cannot be
productive, as another interruption may invade at any time. I can't
commit to the immersion because I'm bracing for the next thing that
will destroy it. The time passes instead in a haze of Web surfing.
And just when it would seem better to give up entirely, I occasionally
settle into a four-day-long frenzied, unstoppable rush of writing
fresh code. It's pure pleasure -- however fleeting.
--
Steven E. Harris
From: Ken Tilton
Subject: Re: Managing lots of small lisp projects
Date:
Message-ID: <8bCtg.635$4j7.128@fe08.lga>
Rob Warnock wrote:
> Ken Tilton <·········@gmail.com> wrote:
> +---------------
> | John Connors wrote:
> | > ...quite difficult in these circumstances: one week I have plenty
> | > of time and get a sizeable chunk of work done, but for the next two
> | > weeks I get almost no time, and forget most of the details of the code
> | > and the general direction I was taking the project in..
> ...
> | You are doomed. I must sit in front of my sofwtare for hours before I
> | begin to become productive. Interruptions longer than three hours
> | require a three-day re-immersion before productivity returns.
> | Immersion is the word I use. ...
> +---------------
>
> I call it "reloading my (primary) cache"...
Perfect. :)
--
Cells: http://common-lisp.net/project/cells/
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
John Connors wrote:
> I have lots of small lisp projects that I hack on incrementally: I'm not
> really in control of my hacking time allocation - family members tend to
> override it pretty much at random. I find planning and sticking to a
> project quite difficult in these circumstances: one week I have plenty
> of time and get a sizeable chunk of work done, but for the next two
> weeks I get almost no time, and forget most of the details of the code
> and the general direction I was taking the project in..
>
> These problems can't be uncommon and I wondered if the panel has any
> time/project management tips that would help? Yes, I know it's a bit OT,
> as it's not specifically a Lisp problem, but Lisp seems to be more
> amenable to this incremental development style than anything else, so I
> thought I'd get better feedback here.
In the book "The End of the Affair" by Graham Greene, the narrator says
"so much of a novelist's writing ... takes place in the unconscious: in
those depths the last word is written before the first word appears on
paper. We remember the details of our story, we do not invent them."
I've found that if I stay sufficiently focused on one project at a time
I can solve a lot of problems and write a lot of pseudo-code in my head
while driving, walking, eating, etc... so that when the time comes that
I can actually sit in front of a computer for an hour I'm simply
translating psuedo-code to lisp or discovering new problems to work out
in my head at a later time.
of course his has only been able to work when focused on one project at
a time... also it isn't much help when one needs to be reading
documentation, manuals, etc...
Perhaps your just going to have to learn to make yourself scarce
without damaging your relationships with those around you... In "the
pleasure of finding things out" [1], Richard Feynman mentions something
along the lines that: his reputation of being unreliable is in fact
something of his own invention, created to help him find the long
uninterrupted blocks of time he needs to work...
Rob Warnock wrote:
> Ken Tilton <·········@gmail.com> wrote:
> +---------------
> | John Connors wrote:
> | > ...quite difficult in these circumstances: one week I have plenty
> | > of time and get a sizeable chunk of work done, but for the next two
> | > weeks I get almost no time, and forget most of the details of the code
> | > and the general direction I was taking the project in..
> ...
> | You are doomed. I must sit in front of my sofwtare for hours before I
> | begin to become productive. Interruptions longer than three hours
> | require a three-day re-immersion before productivity returns.
> | Immersion is the word I use. ...
> +---------------
>
> I call it "reloading my (primary) cache", or "loading all of the
> necessary context back into associative[1] short-term memory".
> Once loaded, I can tolerate a *few*, *short* interruptions without
> losing substantial context, but even a single half-hour total
> interruption can blow the whole cache [especially if the interruption
> itself requires loading new context to service].
>
> It's a bummer, but seems to be the way (some kinds of) creativity
> works. At least IME...
If I remember correctly, there was a post by Pascal B either here
(comp.lang.lisp) or on the gardeners list where he explained his
creative process as (1) imagining an s-expression based domain-specific
language to solve the problem at hand, and (2) implementing that
language.
I had a real problem with what kenny mentioned: needing several hours
just to "get back in" to whatever project I was working on. I found my
way around it by doing all my thinking on pen and paper and trying to
think and work on/in the imaginary pseudo-language for at least a few
minutes before taking the step up in complexity to actually reading
code in lisp/emacs/etc...
write it off as suddenly being able to "remember" the details of what I
want to implement/program... or simply just a "mental warm up"... I
also find it helps me remove myself from the code I've written and
recognize ideas and blocks that need to be changed...
Nick
[1]
http://video.google.com/videoplay?docid=6586235597476141009&q=feynman
>
>
> -Rob
> [1] "Associative" in the psychological sense of being readily-
> available to make connections or associations with other data
> in short-term memory, not in the cache memory organization sense.
>
> -----
> Rob Warnock <····@rpw3.org>
> 627 26th Avenue <URL:http://rpw3.org/>
> San Mateo, CA 94403 (650)572-2607
Ken Tilton <·········@gmail.com> writes:
> Also the skipping stone metaphor. The tendency to pop out of the
> water (the task) and sail thru the air (losing the task) is
> terrific.
I keep rereading it, but I don't get it. Can you rephrase it? It
sounds like you're on to something here.
--
Steven E. Harris
From: Ken Tilton
Subject: Re: Managing lots of small lisp projects
Date:
Message-ID: <tvFtg.84$gg.37@fe09.lga>
Steven E. Harris wrote:
> Ken Tilton <·········@gmail.com> writes:
>
>
>>Also the skipping stone metaphor. The tendency to pop out of the
>>water (the task) and sail thru the air (losing the task) is
>>terrific.
>
>
> I keep rereading it, but I don't get it. Can you rephrase it? It
> sounds like you're on to something here.
>
yes, a terrible, ghastly, unworkable metaphor. :)
Background: I read one of those neato "who knew?" science snippets. I
might even have misremembered it, if Google is to be trusted. maybe my
more spectacular water-skiing falls are better. What I remebered was
that a skipping stone does not really skip, it actually digs into the
water momentarily before being ejected and sailing thru the air for
rather a long time before it can ever expect to regain the water.* I
have had waterskiing falls in which I plunged head first into the water,
rolled once just under the surface and then popped back up into the air,
rinse, repeat. three sorties was my best, and I think at speeds high
enough to get more one really does just skip along the surface. Those
are great, too. The bad ones are where you end up face down at some
point and your eyelids get.... but i digress. :)
I have learned as a solo developer at home to panic when I notice that I
have been ejected from the task, and to toss my usual policy of going
with the flow and artificially force myself back to the keyboard, to try
to get myself back under the surface. by the same token, i have made my
apologies and rejected the most trivial of social obligations, realizing
that, for a while anyway, the choices are discrete: I am on task, or I
am sailing thru the air.
The metaphor does not work on the immersion side, because the skipping
stone is not meant to travel far underwater. it only works in the sense
of how hard it is for the stone to stay in the water.
kt
* It seems what I read is not that it does not skip, but that, well, it
is not the same side hitting each time; the leading edge digs in, the
trailing edge carries on and over and then the once top side smacks the
water and up we go back into the air. I might have that wrong, too,
though come to think of it it does sound as if my inept waterskiing
constitutes a successful reproduce. k
--
Cells: http://common-lisp.net/project/cells/
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
From: Pascal Costanza
Subject: Re: Managing lots of small lisp projects
Date:
Message-ID: <4hmkqnF9ovdU1@individual.net>
John Connors wrote:
> I have lots of small lisp projects that I hack on incrementally: I'm not
> really in control of my hacking time allocation - family members tend to
> override it pretty much at random. I find planning and sticking to a
> project quite difficult in these circumstances: one week I have plenty
> of time and get a sizeable chunk of work done, but for the next two
> weeks I get almost no time, and forget most of the details of the code
> and the general direction I was taking the project in..
>
> These problems can't be uncommon and I wondered if the panel has any
> time/project management tips that would help? Yes, I know it's a bit OT,
> as it's not specifically a Lisp problem, but Lisp seems to be more
> amenable to this incremental development style than anything else, so I
> thought I'd get better feedback here.
What works for me is a) having at least small test suites with the
things that I think should always work, so when I make changes to my
source code, I can quickly check whether everything still works; b)
having todo-files for each project where I write down things that I want
to do, but didn't have time for yet. The latter helps me to get back
into a project much quicker.
Pascal
--
3rd European Lisp Workshop
July 3 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
From: Ken Tilton
Subject: Re: Managing lots of small lisp projects
Date:
Message-ID: <HZwtg.28$Ph1.8@fe11.lga>
John Connors wrote:
> I have lots of small lisp projects that I hack on incrementally: I'm not
> really in control of my hacking time allocation - family members tend to
> override it pretty much at random. I find planning and sticking to a
> project quite difficult in these circumstances: one week I have plenty
> of time and get a sizeable chunk of work done, but for the next two
> weeks I get almost no time, and forget most of the details of the code
> and the general direction I was taking the project in..
>
> These problems can't be uncommon and I wondered if the panel has any
> time/project management tips that would help?
Thought of one I have actually used to good effect: simply leave a note
for myself "You are working on XXX", XXX being some specific little task
where I happen to have to stop.
(Another thing you might consider
(is something I toyed with a couple of weeks ago
(keeping a running log like this)
(the problem was...
I noticed I would be working on task A, which would raise a problem
forcing me to start task B, which coule lead to task C. I thought it
would be nice to have a cue as to what to resume doing when I finished
C, then B, then... you get the idea. Notice I used sexpr notation so I
could benefit from the editor's automatic indenting though this meant I
could not use commas. I also seeded the comments with :at 10am and with
occasional dates so I could conceivably extract a timeline later on.
Maybe reading the last ten lines of something like that would get you
back in the swim more quickly for short bursts of work.
kt
--
Cells: http://common-lisp.net/project/cells/
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
John Connors wrote:
> I have lots of small lisp projects that I hack on incrementally: I'm not
> really in control of my hacking time allocation - family members tend to
> override it pretty much at random. I find planning and sticking to a
> project quite difficult in these circumstances: one week I have plenty
> of time and get a sizeable chunk of work done, but for the next two
> weeks I get almost no time, and forget most of the details of the code
> and the general direction I was taking the project in..
>
> These problems can't be uncommon and I wondered if the panel has any
> time/project management tips that would help?
You need to assess how much time you have to develop, only take on
incremental problems that you can complete in that timeframe, and
commit your solutions to a source control system such as
http://www.darcs.org . The important thing is to finish what you're
doing, so that you don't have to remember stuff. If you only have 2
hours to develop, because you know your family is going to pester you,
then that's the scope of what you can work on. That is, at best,
enough time to fix 1 or 2 minor bugs, or add 1 trivial feature.
If you cannot get larger blocks of time to concentrate, like a solid
day here and there, then you will be unable to do any signficant "from
scratch" design. You could still make progress on software stuff by
attaching yourself to an open source project and letting others do the
heavy lifting. Look for instance at the CL Gardeners
http://www.lispniks.com/cl-gardeners/
If you have personal or career goals you are sworn to accomplish, then
you'll need to discuss this with your family.
> Yes, I know it's a bit OT,
> as it's not specifically a Lisp problem, but Lisp seems to be more
> amenable to this incremental development style than anything else, so I
> thought I'd get better feedback here.
It's certainly not more amenable than "anything else." Any scripting
language will allow for incrementality. Such as, for instance, a CMake
build. Even C++ can be developed incrementally if you don't
overengineer stuff. I call that "defensive programming" - pretty much
the only way to keep C++ workable. Avoid lofty abstractions and
refactoring for refactoring's sake. Those slow you down, and also make
your code more obfuscuated when you or someone else tries to get back
into it later.
For instance, in my Chicken Scheme CMake build I just threw out some
abstract + slightly complex stuff. It really wasn't a win over listing
everything out "the long way," like all .c files necessary for the
build and so forth. Sure it means that lists of .c files will have to
be edited in multiple places more than likely, but poring over that, is
preferrable to poring over macros that abstract all the CMake
functionality. Nowdays in CMake I'd rather see an ADD_CUSTOM_TARGET
than some fancy abstraction I've gotta look up, because
ADD_CUSTOM_TARGET is standard, in the CMake docs, and I know what it
does.
I've put many years into learning how to develop on my own, from
scratch, incrementally, using source control. I've fallen flat on my
face and gone bankrupt over it, from overengineering and
over-refactoring stuff. I'm much better at it nowadays, and tackling
stuff at the level of "a scripting problem" does help one get things
done. The reality is there's a learning curve to incremental
architectonics, given the production realities of your spare time.
I've had a number of detractors over the years; it has irritated me to
no end that they clearly didn't understand spare-time production
realities, or sympathize with them. Lucky them if all their toolchains
worked beautifully and they never tackled problems outside their well
trodden paths! Or if they had $$$$$ jobs that gave them plenty of time
to cope with the cock-and-bull that is most of the computer industry.
You ever put up with all this junk on your own nickel? It's not
pretty.
My point is, you will not avoid the mistakes, you will fall flat on
your face until you reach a combination of experience + toolchain that
works for you. Be persistent and you'll get there. I do highly
recommend Darcs. I would go so far as to say, attach yourself to an
open source project that's using Darcs (such as Chicken Scheme :-).
Cheers,
Brandon Van Every
"Mallor" <···········@gmail.com> writes:
> You need to assess how much time you have to develop, only take on
> incremental problems that you can complete in that timeframe, and
> commit your solutions to a source control system such as
> http://www.darcs.org . The important thing is to finish what you're
[...]
> works for you. Be persistent and you'll get there. I do highly
> recommend Darcs. I would go so far as to say, attach yourself to an
> open source project that's using Darcs (such as Chicken Scheme :-).
Can you elaborate on why you specifically recommend Darcs for
incremental problems? What are its advantages over other source
control systems for these kinds of problems?
Paolo
--
Why Lisp? http://wiki.alu.org/RtL%20Highlight%20Film
The Common Lisp Directory: http://www.cl-user.net
From: Pascal Costanza
Subject: Re: Managing lots of small lisp projects
Date:
Message-ID: <4hpvjdFp0efU1@individual.net>
Paolo Amoroso wrote:
> "Mallor" <···········@gmail.com> writes:
>
>> You need to assess how much time you have to develop, only take on
>> incremental problems that you can complete in that timeframe, and
>> commit your solutions to a source control system such as
>> http://www.darcs.org . The important thing is to finish what you're
> [...]
>> works for you. Be persistent and you'll get there. I do highly
>> recommend Darcs. I would go so far as to say, attach yourself to an
>> open source project that's using Darcs (such as Chicken Scheme :-).
>
> Can you elaborate on why you specifically recommend Darcs for
> incremental problems? What are its advantages over other source
> control systems for these kinds of problems?
I don't have a complete overview of source code control systems, but
what I have like about darcs is this:
- It's easy to set up and understand. This was not the case for me with
other systems (I have also tried cvs and svn).
- darcs supports cherry picking: If you make several changes, darcs
allows you to submit only some of them. Likewise, if you update your
repository from some other repository, you can also select only some of
the differences. I have found this very useful. I think this allows you
to work on several issues at a time, and depending on the available
time, choose what you want to work on. (This is probably a very vague
statement, but I cannot describe this any better than that.)
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
Paolo Amoroso wrote:
> "Mallor" <···········@gmail.com> writes:
>
> > You need to assess how much time you have to develop, only take on
> > incremental problems that you can complete in that timeframe, and
> > commit your solutions to a source control system such as
> > http://www.darcs.org . The important thing is to finish what you're
> [...]
> > works for you. Be persistent and you'll get there. I do highly
> > recommend Darcs. I would go so far as to say, attach yourself to an
> > open source project that's using Darcs (such as Chicken Scheme :-).
>
> Can you elaborate on why you specifically recommend Darcs for
> incremental problems? What are its advantages over other source
> control systems for these kinds of problems?
Darcs is based on a sound patch theory, which allows the rather exotic
ability to apply patches in any order, and remove them in any order.
In practice this is not always useful, as programming does tend to
create serial dependencies, but sometimes it is very useful. Darcs is
written in Haskell and is applying a "purely functional" notion to
source control.
Darcs is a distributed system,and this is recommended for working with
other open source developers. There is no client-server relationship
per se; rather, every repository is a fully working repository, and
sharings could best be described as peer-to-peer.
More information at http://www.darcs.org
Cheers,
Brandon Van Every
Mallor wrote:
> Darcs is based on a sound patch theory, which allows the rather exotic
> ability to apply patches in any order, and remove them in any order.
You can do this in CVS.
Kaz Kylheku wrote:
> Mallor wrote:
> > Darcs is based on a sound patch theory, which allows the rather exotic
> > ability to apply patches in any order, and remove them in any order.
>
> You can do this in CVS.
I may not be giving the Darcs sales pitch correctly, and patch
reordering isn't high on my personal list of needs anyways. I'll leave
it to others to peruse the various Darcs vs. Whatever resources on the
net.
Cheers,
Brandon Van Every
From: Giorgos Keramidas
Subject: Re: Managing lots of small lisp projects
Date:
Message-ID: <864pwg5mnp.fsf@gothmog.pc>
On 15 Jul 2006 21:36:42 -0700, "Kaz Kylheku" <········@gmail.com> wrote:
> Mallor wrote:
>> Darcs is based on a sound patch theory, which allows the rather exotic
>> ability to apply patches in any order, and remove them in any order.
>
> You can do this in CVS.
Not really.
You can play-around a bit with diff(1) and patch(1) but:
- You lose the history of the 'remote' repository
- When conflicts start manifesting, your problems get much
much much worse
On 2006-07-13 05:02:16 -0500, John Connors <·····@yagc.ndo.co.uk> said:
>
> I have lots of small lisp projects that I hack on incrementally: I'm not
> really in control of my hacking time allocation - family members tend to
> override it pretty much at random. I find planning and sticking to a
> project quite difficult in these circumstances: one week I have plenty
> of time and get a sizeable chunk of work done, but for the next two
> weeks I get almost no time, and forget most of the details of the code
> and the general direction I was taking the project in..
>
> These problems can't be uncommon and I wondered if the panel has any
> time/project management tips that would help? Yes, I know it's a bit OT,
> as it's not specifically a Lisp problem, but Lisp seems to be more
> amenable to this incremental development style than anything else, so I
> thought I'd get better feedback here.
No, these problems aren't uncommon. The term 'continuous
partial attention' attests to that. Unfortunately -- but not surprisingly
-- being productive in a creative endeavor demands nothing less
than total concentration, and often that means turning away other
demands [1, 2].
In my experience as a software developer who works out of his
home, I simply have to set some boundaries for family, friends,
and myself. Of course, saying, "I just need four hours, and then
I'll take the kids to the park," is not always conducive to creative
work either. I rarely find inspiration amenable to scheduling.
My strategies, so far, are thus:
1. Set aside regular but not too frequent 'go dark' time blocks;
during these periods, I don't talk to anyone unless it's a matter
of life or death; I might not always accomplish a lot during these
periods, but they set expectations about my availability;
2. Accept that interruptions will occur, so reduce the impact by
making re-immersion as quick and easy as possible; I do this
by leaving 'bookmarks' in my work -- simple, consistent and
reliable indicators of where I left off and what the context was;
in Lisp this often amounts to something like the following:
(error "START HERE: foo.lisp. You were adding a tax field...")
I find test suites invaluable to establishing and recalling context
(TDD, TFD, or whatever it's called these days);
3. I prefer a simple approach to managing my to-dos; priorities
don't help me much, 'cuz everyone has a different notion of what
my priorities should be, and none of them jive with mine; I like
the GTD [3] focus on small steps and which one comes next; I
also keep one big to-do list, with items tagged -- rather than
compartmentlised -- by project; and
4. I email my to-dos, notes, reminders, project log entries, ...
everything to myself, and carry my web/email enabled cell
phone everywhere.
Cheers,
Mike
[1] http://www-cs-faculty.stanford.edu/~knuth/email.html
[2] http://www.well.com/~neal/
[3]
http://www.43folders.com/2004/09/08/getting-started-with-getting-things-done/
--
Michael J. Forster <····@sharedlogic.ca>
Michael J. Forster wrote:
>
> 4. I email my to-dos, notes, reminders, project log entries, ...
> everything to myself, and carry my web/email enabled cell
> phone everywhere.
This reminds me: the very subject header contains the root of the
problem. People shouldn't work on "lots of small XXX projects."
People should work on one thing at a time. When I'm working on the
Chicken CMake build, there's never more than 1 major task in front of
me at once. I work on that until it's done, and then I move on to the
next thing. I don't write myself lotsa notes with lotsa little
separate contexts to get confused by.
When working on a mature open source project, the project itself has
tremendous persistency. Maybe there are, say, 12 things that must
happen to get a build to work. But they're there, they're in the
source pool already, all you need to do is transform them one-by-one.
In other words, projects with a lot of "valid starter code" don't
require as much thought. You massage the code into something that
works, and you do it in bite-sized chunks as often as possible. When
you finish something, you scratch your head and say, "Uuuh, what next?"
5 minutes of thinking will yield your list of possible tasks, and
another 5 minutes will decide your priorities - if you're not in the
habit of wasting your time on small potatoes.
When working on your own code from scratch, one can overdesign. Don't.
Do one thing at a time, make it work, and don't expect it to be the
perfect thing on the first go. It takes me 6 iterations to get a
design right. And typically, those 6 iterations are stretched out over
a long time, like weeks or months. Other things have to happen to
improve and validate the design, there's no quick way to reach a mature
design. So, throw mud at the wall, some sticks; throw more mud, some
more sticks....
I may make it sound like I'm a sloppy programmer. I'm anything but.
In fact I am so architectonic that in the past, it has seriously slowed
me down. But eventually I learned how not to overengineer. Relatively
speaking.
Cheers,
Brandon Van Every
Mallor <···········@gmail.com> writes:
> I am so architectonic
That's definitely the first time I've seen this word applied to a
person, let alone a building. In architectural criticism, this word
may be used to describe design details that deliberately express how
and of what they are made.
--
Steven E. Harris
Steven E. Harris wrote:
> Mallor <···········@gmail.com> writes:
>
> > I am so architectonic
>
> That's definitely the first time I've seen this word applied to a
> person, let alone a building. In architectural criticism, this word
> may be used to describe design details that deliberately express how
> and of what they are made.
I'm sure I picked up the academese at some point in college. I am not
now, nor have I ever been, a CS major.
Cheers,
Brandon Van Every
Mallor <···········@gmail.com> writes:
> I am not now, nor have I ever been, a CS major.
Same here: Architecture (of the built environment) for me.
--
Steven E. Harris
"Mallor" <···········@gmail.com> writes:
> Michael J. Forster wrote:
>>
>> 4. I email my to-dos, notes, reminders, project log entries, ...
>> everything to myself, and carry my web/email enabled cell
>> phone everywhere.
>
> This reminds me: the very subject header contains the root of the
> problem. People shouldn't work on "lots of small XXX projects."
> People should work on one thing at a time. When I'm working on the
> Chicken CMake build, there's never more than 1 major task in front of
> me at once. I work on that until it's done, and then I move on to the
> next thing. I don't write myself lotsa notes with lotsa little
> separate contexts to get confused by.
>
> When working on a mature open source project, the project itself has
> tremendous persistency. Maybe there are, say, 12 things that must
> happen to get a build to work. But they're there, they're in the
> source pool already, all you need to do is transform them one-by-one.
> In other words, projects with a lot of "valid starter code" don't
> require as much thought. You massage the code into something that
> works, and you do it in bite-sized chunks as often as possible. When
> you finish something, you scratch your head and say, "Uuuh, what next?"
> 5 minutes of thinking will yield your list of possible tasks, and
> another 5 minutes will decide your priorities - if you're not in the
> habit of wasting your time on small potatoes.
>
> When working on your own code from scratch, one can overdesign. Don't.
> Do one thing at a time, make it work, and don't expect it to be the
> perfect thing on the first go. It takes me 6 iterations to get a
> design right. And typically, those 6 iterations are stretched out over
> a long time, like weeks or months. Other things have to happen to
> improve and validate the design, there's no quick way to reach a mature
> design. So, throw mud at the wall, some sticks; throw more mud, some
> more sticks....
>
> I may make it sound like I'm a sloppy programmer. I'm anything but.
> In fact I am so architectonic that in the past, it has seriously slowed
> me down. But eventually I learned how not to overengineer. Relatively
> speaking.
>
>
> Cheers,
> Brandon Van Every
>
Hi Brandon,
I essentially agree. One of my constant battles is against getting
distracted on a new project before finishing what I am already working
on. However, I'm not sure creative thinking is that linear.
Everybody's milage will differ, but I find keeping about 5 active
projects going at once as a maximum works for me. I'm not convinced I
can actually control when good/interesting/challenging ideas occur.
Some of the better stuff I've done occured in a flash and was coded
very quickly. some of my worst was labored over for weeks and weeks.
My project work occurs mainly on the weekend and some saturday's I
just feel like working on project X, but next saturday, I might be
more in tune to the issues associated with project Y. Trying to force
myself to work on one project while my mind is more preoccupied with
thoughts regarding another project tends to be fairly unproductive for
both projects.
I do find myself fighting at times not to have more projects - this is
often a sign I need to re-examine my project list and re-evaluate the
projects progress. sometimes this makes me realise I have already
achieved most of the functionality I was after and the reason I'm
having trouble working on it further is there isn't really anything
left that will give me mroe value. sometimes this re-evaluation leads
to a project being abandoned because I no longer need the
functionality, I've found it somewhere else (somebody else has already
done it - again!) or possibly it was just poorly conceived and its
time to cut and run.
The real danger/problem is that if you get too many projects
happening, you never get to finish any of them and you basically end
up spinning your wheels, going nowhere.
The way I handle projects has developed over a number of years. Nearly
everything is managed using emacs and various emacs modes and hacked
together elisp. I've recently started integrating all my own project
management code with planner-mode and muse. There are lots of really
nice emacs packages out there just waiting for you to glue them
together with bits of elisp to create that whole project management
system you have always dreamed of. With the many utilities available
under Linux combined with emacs - you can develop a very very nice
system with indexed and searchable documents, consistent layout,
integrated version control, managed resource lists, diary, log
records, contact info, bug tracking etc etc and its all working as you
want and not forcing you to work as the system wants.
Of course, the danger here is it itself ends up as another project and
before you know it, you have wasted yet another weekend
improving/tweaking your project management system and another week
passes without any progress on your "real" projects!
At least I don't get bored and I'm saved from endless hours of really
bad unimaginative TV shows - most of which are repeats. While possibly
sounding dull, I actually enjoy this more now than 20 years ago (who
am I kidding, Saturday night 20 years ago, I would have been playing
pool, drinking beer and watching a band while slurring something
rediculous, but in my mind incredibly sophisticated and clever, to
some nice girl made even more beautiful by my undoubtably strong beer
goggles!). At least now sunday is bearable, my liver isn't rejecting
me, my ears are not ringing and I don't have to chew off an arm before
getting out of bed. Best of all, I now start each week feeling like
I've learnt something new rather than wondering how many brain cells
I've slaughtered and wasted in yet another orgy of self indulgence.
Tim
--
tcross (at) rapttech dot com dot au
Tim X wrote:
>
> Hi Brandon,
>
> I essentially agree. One of my constant battles is against getting
> distracted on a new project before finishing what I am already working
> on. However, I'm not sure creative thinking is that linear.
> Everybody's milage will differ, but I find keeping about 5 active
> projects going at once as a maximum works for me. I'm not convinced I
> can actually control when good/interesting/challenging ideas occur.
You can, but it has to be important to you. If you get more
psychologically out of flitting around than reaching milestones, then
you'll flit around. Defining milestones probably deserves to be in
this conversation somewhere. It's one of those things you can
overdesign. It is made much easier by working on a mature open source
project.
For instance, the major milestone I'm currently trying to hit is to
make the Chicken CMake build 100% reliable. In short, to ship it, and
get it out of "experimental land." That's not just for feel-good, or
just to advance the causes of Chicken and CMake. I need this for my
resume. Signature gathering is over in the Pacific Northwest and it's
time to replenish the money pump. Also there is the risk that once I
start a programming job, I won't be able to make much progress on
Chicken and CMake for awhile, so I really need this done now.
> Some of the better stuff I've done occured in a flash and was coded
> very quickly. some of my worst was labored over for weeks and weeks.
I tend to make consistent, reliable progress on dull but important
problems. I'm still waiting for the day when I have enough high
quality tools and infrastructure that I'll be working on "interesting"
stuff. I keep getting interrupted by the need to survive.
In other words, I've been coding like a software engineer, not an
artist. They are different modalities. Software engineering is how
one achieves commercial goals; it's not funzies. Possibly, people who
do "real programming work" full time for someone else all week, and
then try to keep personal projects going in their spare time, have more
trouble coughing out the boring stuff than those of us who spend most
of their time on their own projects. That is, if you've been bored at
work, you have a higher need for entertainment and funzies in what you
do with your free time. I'm not sure if quitting one's relatively dull
computer job is the answer. I did that at the height of the boom in
1998. The market changed, and I haven't financially recovered from it
yet.
It is too bad that my sense of aesthetics has driven me towards
technologies which do not have obvious commercial value. But it's
better than giving up on programming altogether, which I came close to
at one point.
Cheers,
Brandon Van Every
Mallor <···········@gmail.com> writes:
> Possibly, people who do "real programming work" full time for
> someone else all week, and then try to keep personal projects going
> in their spare time, have more trouble coughing out the boring stuff
> than those of us who spend most of their time on their own projects.
> That is, if you've been bored at work, you have a higher need for
> entertainment and funzies in what you do with your free time.
That's a great point. It generalizes even further, to more obvious
outcomes: The more programming work I'm getting done at the office,
the less interest I have in programming outside of work. Most of the
time, though, work offers surprisingly, even alarmingly little
opportunity for writing code, so it takes side projects to receive
that spare energy.
> I'm not sure if quitting one's relatively dull computer job is the
> answer. I did that at the height of the boom in 1998. The market
> changed, and I haven't financially recovered from it yet.
Thank you both for falling on this sword and being brave enough to
admit it later. I too have considered this kind of job change as a
solution (don't depend on the job as an outlet for programming
creativity), but two things conspired against seeing it through: the
opportunity to program at work pops up again, and not being absolutely
sure that I'd want to to commit my entire day to the other roles I've
considered. It's a gamble: is the stultifying tease factor of a
programming job more onerous than the occasional indulgences it
affords?
--
Steven E. Harris
Steven E. Harris wrote:
> Mallor <···········@gmail.com> writes:
>
> > I'm not sure if quitting one's relatively dull computer job is the
> > answer. I did that at the height of the boom in 1998. The market
> > changed, and I haven't financially recovered from it yet.
>
> Thank you both for falling on this sword and being brave enough to
> admit it later. I too have considered this kind of job change as a
> solution (don't depend on the job as an outlet for programming
> creativity), but two things conspired against seeing it through: the
> opportunity to program at work pops up again, and not being absolutely
> sure that I'd want to to commit my entire day to the other roles I've
> considered. It's a gamble: is the stultifying tease factor of a
> programming job more onerous than the occasional indulgences it
> affords?
Well I've got sworn goals quite beyond "getting some satisfaction from
coding," so I continue to make the hard choices. I'm going to ship my
damn games someday. The only way that will ever happen is if I mostly
stick to my guns. Really one needs a driving problem much more serious
than coding aesthetics. Coding aesthetics is transitory. It gets
destroyed on the next design pass, or else life moves on and the
project ceases to have strategic relevance. I mean, having put 1.5 man
years into my spherical hexified icosahedral planetary rendering code,
I'm unlikely to use any of it. In hindsight it only served as a large
speedbump on the way to better designs and production practices.
Another danger I'm starting to run into now, is how long can one slog
at difficult, tedious problems before getting bored with them? Getting
Chicken to handle Windows pathnames properly is not even slightly
amusing.
Cheers,
Brandon Van Every
On 2006-07-15 02:31:59 -0500, "Mallor" <···········@gmail.com> said:
>
> Michael J. Forster wrote:
>>
>> 4. I email my to-dos, notes, reminders, project log entries, ...
>> everything to myself, and carry my web/email enabled cell
>> phone everywhere.
>
> This reminds me: the very subject header contains the root of the
> problem. People shouldn't work on "lots of small XXX projects."
> People should work on one thing at a time.
[...]
Yes. I think that 'too many projects' falls under the same category
as 'too many distractions'. However, sometimes that's the job
description. Case in point: as I type this, the phone is resting on my
shoulder as I wait for a customer to relay me an error code off the screen,
while I'm also perusing the headers of an email bounce, and, all of this,
while I've been trying to grok the design of a Cold Fusion/SQL Server
app I wrote five years ago.
Just had to read c.l.l. too ;-)
-Mike
--
Michael J. Forster <····@sharedlogic.ca>