
I’ve become worse at programming - kumaranvpl
http://fascinatedbox.blogspot.com/2017/05/ive-become-worse-not-better-at.html
======
Verdex_2
If you're an explorer and you live in a small valley, then you will slowly
begin to believe yourself a better explorer as time goes on. But one day you
will get to the edge of the valley and look out onto a vast landscape and
believe that you have become a worse explorer.

Checkout the volume of N-balls [1]. As the number of dimensions in a "sphere"
become higher the "volume" of the sphere becomes smaller when you compare it
to a hypercube of the same dimensional count. This is another way to saying
that as the number of dimensions increases the closer the "halfway" point of
the volume of the N-ball gets to the edge of the N-ball.

Programming (and software engineering by extension) involves a lot of
orthogonal issues. We can imagine this so be a really high dimensional space.
My theory is that whenever you're in situation that can be represented by a
high dimensional space you will learn a bit of knowledge and think you know
something. Then you'll learn a bit more and discover there's more to learn.
The more you learn the farther the horizon moves away. It will feel like
you're getting worse. Just like finding out you live in a valley.

What's really happening though is that your increase in skill is allowing you
to realize how small your world was all along. Keep learning and trying and
you'll get better. It will however, take a while.

[1] - [https://en.wikipedia.org/wiki/Volume_of_an_n-
ball#Low_dimens...](https://en.wikipedia.org/wiki/Volume_of_an_n-
ball#Low_dimensions)

~~~
debaserab2
Isn't this effectively the same as the Dunning Kruger effect (as it applies to
this situation)?

[https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect](https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect)

~~~
Verdex_2
More or less. I'm suggesting a mechanism for why something like the Dunning
Kruger effect might occur and where we are likely to see it occurring.

~~~
debaserab2
That's a very interesting way of explaining it from a perspective I hadn't
considered.

------
SadWebDeveloper
We live in a time were everything gets "community reviewed", jr devs like to
post everything they do on github/bitbucket/etc, fork someone else code and
comment on issues aka "Social Coding" just to get people to "praise them" and
to score "internet points" but historically coding has been an a "alone
skill", despite years of people advocating "pair programming" or some "agile"
shit, the most useful codebases come from devs that isolate themselves on a
topic, solve the problem and came with a solution. In the old days i used to
code "things for me" not for everyone but since the era of "Social Coding",
everyone pressure you to code for everyone and i have been only disappointed
with people bashing "my code" because it's not "unit tested", made in "go" or
"rust", etc... my advice for everyone that feels the same, is to stop
"contributing" on github and start doing things for themselves, stop listening
to the crowd and start living outside "the grid".

~~~
foobarrio
I have encountered this too. Some of most useful personal coding time is spent
to exploring something new or solving a real problem with a quick and dirty
solution. At no point do I set out to create a full polished, deliverable
thing. I don't even know if I will solve my problem or understand the new
thing! Why publish such code? A carpenter doesn't varnish and sell every
single bit of wood that is practiced or worked on nor an artist present every
single sketch.

~~~
bollockitis
Now imagine that to be hired as a carpenter you had to first prove that you
have worked on dozens of pieces of wood before anyone would even consider you.
Of course, the analogy falls apart here because we can expect most carpenters
to have produced finished products, but most finished software products are
highly complex and can take years to complete. Worst of all, these products
exist in a marketplace where cynicism reigns: "Why did you build that? We
already have three hundred of those. Quit reinventing the wheel!"

Do we complain when a carpenter builds a nice stool because there are already
enough stools in the world?

Many companies now expect a GitHub history, as if that alone determines your
value. It's no wonder people publish everything. They need to establish that
they're doing something, even if it isn't master level "carpentry."

~~~
tottenhm
> Worst of all, these products exist in a marketplace where cynicism reigns:
> "Why did you build that? We already have three hundred of those. Quit
> reinventing the wheel!"

I've been sitting on a bit of rhetoric in case that comes up, though I've been
blessed not to need it. Regardless, let me share the rhetoric -- just in case
someone finds use for it:

"Put bicycle wheels on a cement truck. Put airplane wheels on a skateboard.
Put train wheels on a wheelbarrow. The metaphor about reinventing the wheel
doesn't go very far -- because the wheel _has_ been reinvented many times, and
thank god for that. I like having trains and planes and bicycles and trucks
and skateboards and wheelbarrows. The world would be poorer if they all used
the same wheel."

~~~
Clubber
Yes, I think this very thing when people try to commoditize software
components by analogizing them to a wheel. It works in some places (I wouldn't
want to write a custom Redis or an RDBMS) but in most places, it falls down.

All the people I've heard use that analogy don't know what they're talking
about when it comes to software development. I think it comes from the "Taco
Bell" MBA types. They're the same people who think WordPress will put all web
developers out of business.

It's frustrating to see the art of software development regress so much.

~~~
mercer
> I think it comes from the "Taco Bell" MBA types. They're the same people who
> think WordPress will put all web developers out of business.

And then on the other end of the spectrum are 'programmer types' who think
WordPress is never a good solution because it's shitty for their particular
use case.

~~~
Clubber
Unfortunately most businesses these days rely on MBAs to make those decisions.
Most MBA tracks don't even offer software development courses. They offer
Accounting, Finance and Marketing, but not software development. That's funny
because all of Accounting, Finance, Marketing and especially Operations run
and rely on software systems, many designed and/or customized in house. It's a
huge gaping hole in management knowledge in the US and it shows.

[http://www.hbs.edu/coursecatalog/](http://www.hbs.edu/coursecatalog/)

------
jasode
Let me see if I understand the author's definition... in this essay he's
equating _" better at programming"_ to mean being _better at management
topics_ such as:

\- SDL (software development lifecyle)

\- technical debt

\- documentation

\- shipping mindset (e.g. "real artists ship")

However, if his Lily programming language is a _personal pet project_ , are
all those management disciplines applicable?

For many of us, pet projects are there to explore new knowledge of programming
ideas. It's an intellectual exercise and not a management one. It's the
projects at work that require discipline of meeting deadlines and reducing the
backlog of defect reports.

15 years ago, I started a "music CD database" project to catalog all of my
discs. I fiddled around with creating some database tables and some prototype
GUI screens. A bunch of other unrelated things in life got in the way of
working on it. These days, there's Spotify & iTunes which means my pet CD
project will always be "unfinished" and neglected. As a result, I can write 2
different essays: 1) My abandoned CD project proves I am a worse programmer,
or 2) My CD project was interesting to me at that stage in my life but since
I've moved on

~~~
philipov
1) A lot of the most valuable things I learn on my personal projects are how
to be better at those programming management topics (and don't forget
automated testing and reproducible research), because becoming better at
managing my own projects creates a multiplier effect on everything I do.

2) By becoming a better manager, you reduce the friction involved in achieving
your goals, and with less resistance to action, you are less likely to have
your life interfere with getting things done.

3) For example, unit tests and documentation let you come back to a project
after a long break and easily pick up again where you left off. Without them,
it might require too much effort to get back into it, and poof no more
project.

------
sparaker
The author is clearly feeling burned out and has lost motivation for his
project. Working on something for 6 years definitely shows persistence, and
persistence is never blind, there is often something fundamental that is
driving people working towards competition.

Whenever I feel like this for a project, which happens sooner or later when
you don't have users. You should take a break and redefine priorities.
Excitement fades when you are prioritizing objectives that don't bring any
real concern-able outcome.

Take a step back, see what is at the heart of your project, and see if it
still excites you, is it something worth the struggle and effort? If yes, find
a better way to do it or complete it with the way you already know. If not,
move onto something new, else you'll keep getting more frustrated because of
slow progress and lack of motivation.

------
dahart
I'm not sure whether the author wants to find the motivation to continue or
the will to stop.

This article is frustration embodied, and I _completely_ empathize, having
been in a very similar situation with a large and long running project that
had many (thousands of) users. Motivation and enjoyment comes and goes, but I
couldn't bring myself to stop doing it because of the effort it took to get
there, and because people were using it and counting on it's continued
development.

The author is sad and tired and can't see the big picture. It's extremely
unlikely he's getting worse at programming, unless he works really hard not to
learn from this -- but this article is evidence he's already learning what
happens to big projects. You have to acknowledge what's going on (done) and
then step back and think about how to improve the situation.

I'm not sure how to find the motivation to continue, if that's what he really
wants. But at least take a solid break and then spend some non-dev time re-
evaluating what's important and where you're headed. Consider whether
continuing solo is a goal, or whether recruiting real partners might be what
both you and the project really need. Ask what success looks like.

As for permission to quit, it's not true that giving up is a massive loss of
work. All the work done is already done. Lily runs, and lessons have been
learned. The code isn't going anywhere. You can walk away from this and you
get to keep everything you ever put in. What you lose by quitting is future
potential, not the sunk cost. So if you want to quit and the only thing
holding you back is fear or sunk cost -- go ahead and quit, sunk cost is
imaginary in this case.

~~~
FascinatedBox
> motivation to continue or the will to stop.

Either one. I keep imagining quitting, but then pulling myself back. That
thought of it'll get better in a month, or two months, etc. I'm hoping to
motivate myself to march through as I once did, or to drop it and not look
back. Not to be constantly conflicted.

~~~
dahart
That's interesting, I didn't quite expect that answer! Obviously I don't know
your exact situation, and I can't hope to offer actual advice, but I can still
empathize, and pretend to help, and suggest mental frames that have helped me.
Imagine that everything I say here is me talking to myself rather than telling
you what to do. :) Like a lot of people, I'm way better at seeing how to solve
other people's problems than taking action to solve my own.

There are a lot of lessons you can take from this project and leverage for
later, on this project or other projects or for your current or future day
job. If you leverage your work here for something else, and quit this project,
maybe knowing your experience helped you transition will ease your mind about
quitting. I'm serious about sunk cost being imaginary; you aren't losing
anything you have by stopping development. The outcome was always going to be
what you learned by doing it, and you have that.

Not sure, but it occurred to me that one thing you may be discovering is that
interpreters (like compilers & OSes) are a different beast than apps
programming. You can't necessarily use the same coding styles or keep the same
clean abstractions. You are bumping into project scaling problems. We all have
a point where we start producing spaghetti. Everyone. Some people have some
tricks for going further, but nobody can do it forever. Ever read this post?
[https://www.teamten.com/lawrence/writings/norris-
numbers.htm...](https://www.teamten.com/lawrence/writings/norris-numbers.html)

What you're learning about the discrepancy between what you expected to happen
6 years ago and what has actually happened since could be redirected towards a
management philosophy, or even a job doing that, if you were so inclined. You
mentioned you are antisocial (and we all are to varying degrees) but what's
happened to this project is what happens to most projects. Most software gets
ugly and less fun over time. In fact, it's probably all software.

I freaking love coding, it's addicting. But software as a whole has been
making me mildly unhappy in part because it's so difficult to feel like I ever
finish anything, whether I'm in a large team or a small one, or working solo.
Many days I feel like I could code every waking second I have and not end up
where I want to go. I have big plans and, more and more clearly every day, not
enough time.

BTW, I haven't gotten rid of my constant conflict. It might not go away unless
you decide to end the project. Mine is still there, and I'm still going. But I
have slowed my project down and I spend less time on it. It's helping relieve
some of the pressure, and helping me be more judicious about what I do. I'm
starting to spend more time doing side things that are fun & interesting to
me.

Maybe do a trial quit, and change your mind if you want. Walk away for three
weeks and don't think about it for one second. See if you're drawn back or
start to feel free.

------
jancsika
Is the author is suffering from depression?

Don't get me wrong-- most of his sections would sound familiar to any
maintainer having to deal with growing technical debt. But the section
headings "Communication" and "Resigned" are certainly red flags. And I've
furrowed by brow four times now trying to grasp the connection between the
author's astute observations about code maintenance and assertion, "I've
become worse, not better, at programming."

Anyone know the author? If so it's worth sending a message to check in.

~~~
FascinatedBox
Yeah, it's depression.

~~~
jancsika
There are people in the mental health profession who can help you with that.

I don't really want to pry any further than that, nor encourage others on this
list to attempt to problem-solve your situation.

I do want to say it's disappointing to see no other comments picking up on
this.

~~~
FascinatedBox
It's a mixture of problems, this just being one. That's as much as I'm
comfortable talking about here.

Your thoughts are much appreciated.

------
le-mark
If the point of personal projects is to push yourself and learn, you've done
that in spades, you should feel proud of your effort. I think it's normal for
a project like lily to wind down after a time. Particularly if there's little
or no uptake or contribution from others. I (and many others I wager) have a
much poorer language implementation in my archives, only difference is I never
made mine public, as you did on github. Kudos for that as well, putting it out
there for public scrutiny.

Re closure implementation, I suggest taking a look a how they're implemented
in the Lua source code. Also, the documentation for Guile has a lot of really
nice implementation detail. They're not trivial to implement, kudo's on doing
your own thing, but this is an instance where I think studying the work of
others can pay huge dividends.

------
mmjaa
In my 30+ years of experience with software development, computerisation, and
general technological prowess, applied, I have this to say: yes. But: no big
deal.

These things happen in cycles. Computers are nearly, entirely, a social
substance. There is nothing at all valuable about computers unless there is a
real social component.

Because of this significant aspect of its makeup, computing is necessarily
cyclic. The shadows of industry, as well as many many bright lights of
academia, shine directly through the world of computing, and specifically,
computerisation.

You see, computers are absolutely useless, _without the user_.

And users change. Societies change. Markets change, people change, attitudes
change, and so on. This is a natural state.

Users change.

Its the User who has become more demanding of the programmer, while individual
developers have the danger of staying, relatively, static and attached to the
things they know. The things they invest in.

Alas, its easier for a User to switch from one stack to another, than it is
for Developers. Usually.

So .. all I really want to point out is, this is normal. Embrace the change of
civilisation that is happening around you -all computer technologies,
productive+ or -productive, are a consequence of the progress of humanity, as
a whole.

------
erikb
"Fires everywhere" is an excuse that you can hear in 99% of offices around
this planet. And it's simply not true. 99% of people don't have "more fires
than most people" by definition. That's how it becomes 99 out of hundred.

The only thing one needs to change is this: Don't cover the fire, extinguish
it. That means the first fire you handle you stick to. Don't let a second fire
take away your attention from the first. Then find the source (e.g. by asking
yourself and colleagues "five times why"). Then find a reliable, resilient
solution for that cause. Then repeat until the fire is extinguished. Only then
take on a second fire.

If you start doing that, well, of course the first few fires will take you a
lot more time than any fire took before. But that's the way to reduce the
amount of fires.

And the great thing about it: If you work like that it doesn't matter if you
extinguish a fire in two hours or in eight hours. Since extinguishing a fire
has an iterative payout over the next few dozen years, a small delay of even a
few months doesn't harm you in the long run.

The only exception to this rule is paying your bills. If you really, really
need to fake a fireless environment in the next two hours to continue
surviving (e.g. as a company), then go ahead and cover all of them. But that
happens very rarely. Most fires only seem urgent because urgency lets us feel
important. And immediately after the urgency you can continue with the actual
process of extinguishing fires.

~~~
jononor
First time there is a fire, put it out. Second time put it out and do a
protective measure. Third time increase protective measures, and look at
addressing underlying issues (five why's or similar can be helpful). Do this
(and don't rewrite everything all the time), and fires will be rare.

~~~
cableshaft
Not if the source of the fires is ever-changing scope or features by clients
and/or BAs/Executives, especially with them trying to bypass the existing
process and get the changes out the door that day. When pretty much everything
is determined to be an escalation...

I've been in this situation many times.

------
j_s
Here's the reddit thread mentioned:

 _What makes someone a bad programmer?_

[https://www.reddit.com/r/cscareerquestions/comments/6crxwb/w...](https://www.reddit.com/r/cscareerquestions/comments/6crxwb/what_makes_someone_a_bad_programmer/)

~~~
daxorid
The top comment on that post is incredibly disappointing.

Unpopular though it may be, things like working memory, granular abstraction
comprehension, and logical reasoning capability are _highly_ correlated with
g. And g is largely immutable under "training".

Soft skills are, therefore, far more teachable than hard skills.

~~~
YCode
Maybe. I suppose it depends on the goal.

From my own experience, generally the barrier for being productive at a job
was soft skills, in that if a team member was suffering from an insufficient
hard skill but had good people skills/personality traits I could teach them
enough of the hard stuff they are missing so they can be productive, but the
inverse has rarely proved true.

Now, you can work around a team member's deficiencies in soft skills, but the
difference is they aren't likely to pick them up.

------
gwbas1c
"my mainstay project is Lily, a programming language, and I've been working on
it for about 6 years now"

First, 6 years shows great dedication. Kudos for that!

What kind of usage does Lily have? The biggest forcing function, IMO, is true
usage. Let your users tell you how good/bad of a coder you are.

Working on something for 6 years with no users is a problem. I spent about 18
months working on some web technology and never got any users. After 18
months, I realized the project was going nowhere and then I went and got a
job. (Plenty of users, plenty of collaborators, and a regular paycheck.)

So, IMO, don't ask yourself if you're a good coder. Ask yourself what kind of
niche Lily serves, and what you can do to grow Lily's usage base. Ask yourself
what is Lily's functionality.

I didn't see any examples of real-world programs written in Lily. The problem
with languages and frameworks is that the abstractions need to be tested in
real-world programs to verify the design assumptions.

~~~
fao_
> Working on something for 6 years with no users is a problem

You seem to think that the only purpose of writing programs is for people to
use them. Sometimes the act of constructing something is more interesting that
the result, and would only be interesting to one person.

~~~
MichaelBurge
> Sometimes the act of constructing something is more interesting that the
> result, and would only be interesting to one person.

It's not learning if it's 6 years. You can get a university degree in that
time, which is a far more efficient way to spend the time learning. It's not
research either, since research is directed.

~~~
hzhou321
A university degree is only one narrow aspect of learning.

------
hzhou321
What we need is to ask the questions again. E.g. why do I need work on a new
language? If the answer this time is different, even slightly different, that
is because after a certain amount of effort, we accumulated experience and
gained additional knowledge, and we have become better at what we do (relative
to the question, e.g. programming).

We are inherently very arrogant, often assume a God-like attitude, that once
we had an answer, that is the answer. That is a trap that we do not really
benefit from. What we needed is a scientific attitude, that we don't have the
ultimate answer (to anything), so we need investigate the same questions again
and again, while reminding ourselves, that every time we reach a slightly
different answer, we have become better selves.

------
josteink
> 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.

This is a critical factor. If you don't _care_ , your project will suffer no
matter what kind of project it is.

What is a good way to stay motivated? And at what point should you consider
calling it quits? (Since as he admits: persisting is now making him _worse_ at
what he's doing than he used to be).

I think these are some deep and fundamentally human questions way beyond just
programming.

------
egypturnash
Six years is a damn long time to work on a solo project. There comes a time
when you have to just put it down and move on to something else.

This applies to any discipline. I spent four and a half years working on a
solo graphic novel. Five and a half years if I count the time between
finishing all the art and running the Kickstarter to print the thing. I still
haven't gotten all the shipping done. I'm _done_ thinking about the book and I
want to move on to drawing the next project, and my enthusiasm for doing all
these other parts of the process is low.

Projects have ends and maybe this person's personal programming language has
come to one.

~~~
tonyedgecombe
I'm eighteen years into mine.

------
enugu
One possible step here is to step back from work, just look around at other
things going on(either software related or other topics in life) and start
learning some thing else.

For instance, one path look at courses/lecture-notes in pl
theory/implentation, or some other aspects of software.

Just learn out of curiosity. This might lead to solution of original obstacle,
or finding out that there are more interesting problems to work on. This
happens frequently, even on success, some other project becomes more important
than previous goal.

------
reacweb
You have succeeded in your creation and are suffering because maintaining a
product does not require the same set of skills. Maybe you should designate
another leader for that. IMHO, creative mindset is not good for maintenance
because you want to start too many changes at the same time. For maintenance,
you need a more accounting mindset. Write how you plan the evolution of your
product and gives this plan to someone else.

------
ensiferum
I think the ultimate problem here is lack of delivery. 6 years is a long time
to work on something and not to get something done, delivered, completed and
used. If the author wants to continue on the product id recommend going
backwards a bit and removing all the excessive features from the product.
Define the smallest set of features that makes sense and then complete those.
Get a release done and then take it from there in smaller increments. I have
worked on a personal small project (60-70kloc) for over 12 years and imho the
key is t o be able to.deliver something . I nearly killed my project when I
did the classic mistake of doing a complete rewrite which took me over 1.5
years. It was very slow labouros unthankful job with no positive feedback. In
retrospect I should have just carefully refactor my old code base to reach the
same end result but with smaller increments.

~~~
Etheryte
I don't think your point really applies here since as you can see on
Github[1], the project has numerous releases, averaging at a release about
every five months. Whether that's often or rarely is up for interpretation,
but I'd hardly say the project is standing still.

[1]
[https://github.com/FascinatedBox/lily/releases](https://github.com/FascinatedBox/lily/releases)

~~~
ensiferum
Oh, ok yeah. It just sounded like the had been grinding away for years without
getting anything "out there".

------
have_faith
You haven't provided anything that shows you've gotten any worse at
programming. Just looks like you're fatigued and have accepted some of your
own shortcomings that where always there but didn't have a stressful
environment to manifest themselves in.

------
beeforpork
I try to be deeply convinced that my projects are not about progress,
deadlines, or results. They are about working on them regardless of their
level of completeness. It is very easy to think that the result matters, so
I'm saying I try.

Ergo:

(1) If you care about the topic of your pet project, then rewrite it from
scratch, avoiding all you feel is technical debt. It will take way less than
six years to have the same features you have now (hopefully more maintainably
then).

(2) If you do not care about the topic anymore, abandon the project. For a
personal project, it is not lost work at all, because you've had your fun
hours with it.

------
ScottBurson
Tne author needs to read up on closure conversion [0]. What's described here
(a transformation on the generated opcodes) sounds like a real mess -- hard to
write, hard to maintain, and probably wrong in some cases. Time to be brutal,
rip it out, and start over the right way. Forcing oneself to do that when
necessary will definitely make one a better programmer.

[0] [http://matt.might.net/articles/closure-
conversion/](http://matt.might.net/articles/closure-conversion/)

------
Jach
Programming can be art if you let it. At some point, damn the bugs, and work
on what makes you happy. Start something new that excites you. Even if you
never finish anything (or at least finish to your satisfaction if nothing can
ever be truly finished), that's fine, artists that never go anywhere (and
those that do) have tons of sketchbooks of half-baked ideas. A 6-year effort
on a language is pretty impressive despite whatever monstrous bugs are inside.

But if you're not careful you'll end up gored by a bug and only be able to
drink herb tea for the rest of your days.
([http://www.workpump.com/bugcount/bugcount.html](http://www.workpump.com/bugcount/bugcount.html))

If you want to become better at programming, it's not fundamentally different
than becoming better at other things. Take the game of Go for example since
that's in my mind. Unless you're a natural genius, just playing a lot is no
guarantee of getting good. You need to study. You probably need mentors and
peers to play with and learn from. And of course you need to play for real.
But always shoot for higher challenges. If you just play beginners all the
time, you won't grow much, and may even regress by getting lazy.

------
jondubois
I can feel the author's anxiery. I've created and maintained an open source
project for almost 4 years and it's still not the most popular in its category
though it's doing well and growing slowly and steadily.

I have at times thought that I must have done something wrong but those people
who do use my project keep reminding me how useful it is for them.

I think it's easy as a project author to start blaming yourself for not making
your project more popular but you have to keep in mind that project quality
doesn't have that much to do with popularity. Some projects are just niche and
you have to focus on making a small number of users very happy instead of
making a large number of users a little bit happy.

Maybe your project could reach more people and the world would actually be a
better place because of it but to convince people at such scales, it really
takes a lot of marketing, connections and luck - This is beyond what you can
do as a single open source developer.

I think that open source projects these days cannot get past a certain
threshold of success until they raise funding and start seriously
commercializing.

------
jackyinger
For what it's worth, the majority of my personal projects don't get far beyond
concept.

Take a half full look: If you've created any software project on your own time
that really does something that's great!

If you feel like you've made mistakes, learn from them. You may be learning
more than if you hadn't made them.

------
quickben
Maybe redirect it? Let llvm / gcc handle the backend if you are sure the
syntax is where it should be?

It will give you closure. The project will live on. What you wanted to
accomplish, people writing in your own language, will live on?

It's all subjective. That you got bored out of it, is a sign of a healthy mind
when faced with a repetetive task.

Best of luck with the next cool thing, whenever you get enough rest from this
one ;)

------
arvinjoar
Sunk cost, just stop

------
andreasgonewild
Sounds more like you've become more experienced and critical, shit happens :)
Boring free-time projects will kill your soul; letting go takes practice, but
just giving something away for free is plenty good enough.

------
fniephaus
Reminds me of "Worse Is Better" by Richard P. Gabriel:
[https://www.dreamsongs.com/WorseIsBetter.html](https://www.dreamsongs.com/WorseIsBetter.html)

------
z3t4
giving up on something is very hard. what helps is to think in micro economic
conceps such as sunk cost and opportunity cost. if you could do anything more
fun with your time you have to weight that in.

------
sumanthvepa
I see the author recently (1-month ago) re-implemented the Lilly language in C
(It seems to have originally been written in Rust. In effect this is a
completely new project based on learning from an older very similar project.
Making a such a fundamental switch in the implementation technology is likely
to have a negative impact on on bug count and stability that the author refers
to. (Netscape went out business because they tried to re-write their browser
in Java.) The solution here is for the author to realize that this is a new
project and treat it as such and not worry about the state of bug
count/stability too much. He probably just needs to soldier on to complete the
project to their satisfaction.

~~~
kibwen
_> I see the author recently (1-month ago) re-implemented the Lilly language
in C (It seems to have originally been written in Rust_

That was an April Fools joke, Lily has always been written in C. :P

~~~
sumanthvepa
Ah. Thanks for the correction! This is the downside of a cursory examination.

------
rhapsodic
I seem to be in the minority here (perhaps I'm the only one) but this piece
struck me as a long humblebrag. "Golly gee, I'm developing this programming
language and ..."

------
inputcoffee
Also, new languages (kotlin, swift) and frameworks (vue, react) and practices
(containerization, CI) keep coming out so you might feel like you're getting
worse.

~~~
grovegames
Honestly, trying to stay current on all the new technologies is causing me
anxiety. After 20+ years at this, I always felt I was one step behind. But now
I feel I'm 3 steps behind. I can't imagine what it's like to be a developer
with a wife and kids. I just couldn't' stay on top of half what I'm able to do
now.

~~~
GoToRO
Relax. I've seen code written with/for the newest technologies and it's mostly
crap. Just like you don't have time to learn it, most people don't. But
everybody is happy, including the client, because they have this new tool
written in the newest technology so it must be good. People evaluate software
just like they evaluate cars: they take a good look at the paint job and
declare that this car is good, while in reality the seller only took care of
the paint job, the engine is dead.

~~~
Bahamut
People often think new tech is a cure for their woes, such as poor code
quality - often it is just papering over the real problems & barriers.

~~~
SomeStupidPoint
I've also seen tech switches used to mask rewrites, because they could sell
management on the idea that $NEW_THING would solve our woes when what we
really needed was just to spend half a year refactoring the legacy system
(regardless of language), but half a year to redo work didn't fly.

~~~
GoToRO
Now that you mentioned it, I think this is the most common case.

------
omgwtfbyobbq
Welcome to the bottom of the curve! On the plus side, this means you're doing
pretty well.

[https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect](https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect)

[https://www.psychologytoday.com/blog/head-in-the-
cloud/20170...](https://www.psychologytoday.com/blog/head-in-the-
cloud/201701/the-dunning-kruger-president)

------
staticelf
Sounds like that the author needs to switch jobs or something. Try something
out of your comfort zone. Maybe do something you feel is way harder but within
reach?

------
coldtea
> _Solo developer projects are supposed to be awesome and consistent, right?_

No. Where did the author get that idea?

------
optikals
I forgot my BASIC too.

------
haburka
The formatting of the text is awful on mobile. It looks like it's using
something like <pre> to render to because there are hard coded new lines at
the end of each line. Please don't do that, this isn't poetry! Just wrap your
lines normally!

