Tuesday, May 23, 2017

I've become worse, not better, at programming

Once in a while I like to take a peek at reddit's cscareerquestions and look at
the topics there. On a recent travel, I found an interesting question:
What makes someone a bad programmer?
In looking at the answers, I realized some of those apply to me now, but didn't
apply to me in the past. So what happened?
To begin with, my mainstay project is Lily, a programming language, and I've
been working on it for about 6 years now (give or take a couple months). Over
the years, the language has evolved but a majority of the work has been mine.
Solo developer projects are supposed to be awesome and consistent, right?

The symptoms

Closures

If I had to trace it back to something, it would be the implementation of
closures. Closures work by having the lowest-level closure function create a
pool of cells, and pass those to upward cells. The problem comes in needing to
make sure that functions are getting fresh values.
Suppose there's a var 'someval' that's closed over. One way to make sure that
the value is always up-to-date is that any read of 'someval' should be prefixed
by an access of the closure. Any assignment should be followed after with a
write to the closure. This ensures that all accesses of 'someval' will have the
same actual result.
This is implemented as a transformation that walks through opcodes. When I first
wrote it, opcodes didn't have a consistent format, so I had to write custom
iteration code and it wasn't pretty. But it was good enough to work.
Nowadays I've normalized most of the opcodes, but there are still a few strange
outliers. The closure code takes jumps into account and supposedly fixes their
destinations.
Getting closures to work at all was a battle, and still today there are cases
where closures crash out the interpreter. I've resolved to fix those at some
point in the future, maybe.
I think difficulties in closures stem from how I'm inherently very bad at doing
math in my head. Often times, extending the interpreter for a new opcode
involves prodding existing opcodes to see if I move by +3 or +4, and repeated
compiles with different adjustments to see if I can get it to work.

Release cycles

The last release was in October of last year, roughly half a year ago. I try to
make releases once every 3 months since that's enough to get whatever I feel
like doing done. But this one has been an open window, and there's a 1.0 blocker
I should get to.

The roadmap

I never sat down to get an idea of where I want the project to go. This was
good at first, because I had some terrible ideas of what I wanted to do. But now
the issue tracker is barren compared to a few ideas that I have.
I've often used the excuse that nobody's around, so it doesn't matter. But
seeing a project in this state is likely to turn people away. Right now I'm
focusing on writing a new binding tool that I can later use for documentation
extraction so I can have nicer documentation.

The documentation

It's bad enough that I don't use it, yet I've never bothered to write something
until recently (nearly 6 years in) to have a pretty doc generator. Right now,
the pink and the "it came from markdown" make the documentation so bad I just
grep the builtin package for keywords or try it to see what happens.

The underlying causes

Fires everywhere

With an interpreter, there's a large enough playground that something always
needs critical attention. One fire is left to rage while another gets attention.
A better strategy would have been to never let these fires grow. Better testing,
more coverage would help. But some metrics are difficult to test for, which goes
back to me just being lazy.

Documentation, I guess

I like writing, so the core ended up with a whole lot of documentation. Some is
certainly out of date, because I've neglected to comb through it recently. In
recent other project, I hardly comment at all since few others read my work.

Communication

I'm generally antisocial, so cutting away from email/etc. for a few days is
standard practice. I set up an IRC channel which I don't visit often, a discord
I'm off most of the time, and a subreddit that's empty. Most of my social media
comes through shitposting on reddit.
I also don't blog much.

Resigned

Somewhere along the line I resigned myself to "this is the way it is". I came to
accept that some areas aren't going to be that great because it's me alone. I
should have been better about spending time on a section before leaving it. But
if I do that, what do new people end up doing?
I wasn't always like this. I used to chart out how much memory that the
interpreter was using. I used to have better test coverage.

I don't like this anymore

The worst part is that I used to have some measure of pride in what I did. Now,
well, something breaks and I fix it. Done. I don't bother blogging about much of
what I do since I don't find it exciting, and it's not new. I used to be
excited at seeing new features activate and now I hit a random crash once in a
while and I just sigh.
I keep pushing on in hopes because giving up would be such a massive loss of
work. Yet at the same time, I wonder if working on this project is making me a
worse coder, instead of a better one.

12 comments:

  1. > I keep pushing on in hopes because giving up would be such a massive loss of
    work

    While I'm not really qualified to give advice here, I'm going to do so anyhow :)

    You should be working on something that you enjoy and that helps you grow as a developer. If neither of boxes are being checked for you with Lily, you should either figure out a way to change that (e.g., by going back and fixing closures, even at the cost of breaking compatibility), or you should move on to another project.

    ReplyDelete
  2. > With [any enterprise software project], there's a large enough playground that something always needs critical attention. One fire is left to rage while another gets attention. A better strategy would have been to never let these fires grow.

    Fixed for you ;) Seriously though, this is trouble I've seen on many projects: "shortcuts" that create needless technical debt and hampers later progress.

    ReplyDelete
  3. FB, sounds like you are burned out. Find a Frankenstein project in some other project, and renew your energy. Maybe? Good luck...

    ReplyDelete
  4. Every creator hits a hard spot during any significant undertaking. Take a deep breath, realize your next few weeks (or months) will be spent fixing those elusive bugs which cause your interpreter to crash. Make some progress every day, even when it's really hard.

    Don't give up.

    ReplyDelete
  5. Just give up. Find another goal that excites you, there should be many althoght difficult to spot. 6 years is enough for a project.

    ReplyDelete
  6. About your statement about comments - I write in Ruby mostly and I use a lot of comments. Reason being mostly so that I remember lateron why I used to go that or this way.

    Your side project is not giving you enough fun apparently. It happens sometimes.

    See if you can try to re-arrange it. Perhaps you can make it fun. Or if that fails, perhaps you have to call it quits and move on to projects that are more fun. Avoiding burn-outs is a skill that has to be trained/learned. It took me some failed projects to get somewhat better (I still have some problems with some projects but it's not nearly as bad as it was ~5 years ago).

    PS: ALWAYS be wary of "the big rewrite will fix it all", that killed about 3 projects of mine so far and I still all into that habit.

    ReplyDelete
  7. Take a vacation, at least one month to do (code) whatever other things. You may have more fun when you get back.

    ReplyDelete
  8. Man I've started like 6 projects in the last few years and I only half finished a couple. Don't worry, with the programming that you do at your free time the road is more important than the destination. Find a maintainer for your project (ask the people that sends you PRs) and try another thing maybe in a new language (I'm in love with D right now, trough I'm also hearing the call of Nim).

    ReplyDelete
  9. Read some Kahneman and Tversk; Overconfidence effect - you didn't get worse, you got better. But your ability to honestly evaluate your ability caught up with you at a faster pace than you skills improved.

    ReplyDelete
  10. Hello! I would just like to point out that it's really amazing you had the grit and determination to stick with your project for six years. You have no clue how many projects I've abandoned after just a few days or weeks.

    You're a little burned out and there's many ways out -- other commenters have talked about this. But to me, what stuck out is your stick-to-it-iveness! A rare quality among developers and one you should count among your strengths.

    ReplyDelete
  11. leave the project for as long as it takes. do something different. and when that fire returns, start hacking on Lily again.

    ReplyDelete