[lug] File modification

[Chris Riddoch]

Bear Giles <bgiles at coyotesong.com> writes:
> Did you know the size of the problem going in?  Were you misled 
> about the size of the problem?

I knew about the size of the problem, yes.

<snip>
> Of course this is always a balancing act.  But when you're doing
> initial development the full cost of a decent algorithm is usually
> no more than the cost of an inefficient one, and it's often much
> lower because the efficient algorithm is a more natural fit to the
> problem.

This was the thought process I was using:
1) Find the first algorithm that gets the job done
2) Implement it
3) Test it
4) Turn it in.

This is the thought process I would have used:
1) Determine an appropriate algorithm
2) Implement it
3) Test it
4) Turn it in

Determining an appropriate algorithm for the job requires considering
alternatives. Considering alternatives requires... guess what, time.
Time was something I had nothing to spare. The full data set was about
500 points, I was using test cases of 5 and 10 points that I could
verify results for by hand. Debugging the first solution I could come
up with took a precious 20 minutes.

> > It *is* done, though. 
> 
> No it's not.  Can you use this program to solve problems?

Fine, then. It's a functioning piece of code that works with very
small sets of data. Can I use it to solve problems? What kinds of
problems?

It's an academic project. I think a better question is: Does it
demonstrate that I know what's involved in implementing <project>?
Yes. Does it demonstrate that I can use efficient algorithms in doing
so? Not this time. If I had spent more of my time last weekend
working, I wouldn't have needed to ask about showing file modification
times yesterday.

> If we were in industry and you reported to me, my first question
> would be how you know that the program is making any progress?

If I was in the industry right now and ran into this exact situation,
my first question would be why I'm paying so much money to work
80-hour weeks, and why I don't have anyone to delegate anything to.

> > (No,
> > you can't look at the code. It's too embarrassing.)
> 
> How will you learn?

By not making the same mistake on future projects, of course. Same way
everyone else learns. At this point, I've nearly given up on the idea
of getting any credit for having done it at all, which seems a
terrible waste... but from the tone of your email, it sounds like you
think that's fair. Maybe it is, ignoring all other factors.

> Your professor or TA can make a few comments
> on your code, but how much industry experience do they have?  Post
> your code here and you could learn what we care about in the real
> world.
> 
> > Eh, better that I learn that lesson *now* than in the industry...
> 
> And what lesson(s) did you learn?  Seriously.  The lesson you learned
> may not be the lesson we think you should have learned! >:-)

Lessons learned:

1) Start projects long enough in advance to think about proper
algorithms.
2) Remove social life so I can start projects referred to in #1 long
enough in advance.
3) Remove relaxing activities so I can sleep in between working on
projects.

But heck, I'm going to bed now. At least I won't get five hours of
sleep for the fourth day in a row. If this sounds rather flippant to
you, I can assure you that it is. I can also assure you that I
wouldn't be if I weren't sleep deprived and upset about my workload.

If I were more awake, I probably wouldn't even bother to reply.

4) Don't feed the trolls.

-- 
Chris Riddoch       | epistemological
socket at peakpeak.com | humility