[HN Gopher] Ask HN: Indie devs, what is your development process?
___________________________________________________________________
Ask HN: Indie devs, what is your development process?
I'm curious how you go about developing a new feature. This is
specifically for solo devs. As for me, sometimes I write down a
brief overview, add some tasks to my todo list, and start coding
right way. Please share yours.
Author : jmconfuzeus
Score : 16 points
Date : 2022-07-23 17:15 UTC (5 hours ago)
| philmcc wrote:
| Not sure if you care about validation. If not skip to 2.
|
| 1. Anybody want it?
|
| First I pitch the rough idea to a few paying customers. If they
| are lukewarm on it I set it aside.
|
| If they are warm on it I set it aside.
|
| If they say they want it I set it aside.
|
| When some time goes by and they check in and say "whatever
| happened with (feature) I consider it validated."
|
| 2. Be bad at it
|
| Give myself permission to make the absolute worst version of it.
|
| That frequently involves writing a one page max description of
| it, and then asking myself "okay how much of this could I cut
| before it was literally doing nothing." But if I'm feeling bored
| I just start coding.
|
| This version has no error checking. No tests. No capacity for
| large requests. No logging. Nothing. It just prays beyond all
| reason that the user doesn't do anything silly that breaks it.
|
| 3.beta test the MEV
|
| I just made it up. It's not a real acronym. most execrable
| version. It fits because it does feel like something I excreted.
| I hate it. I'm embarrassed. My impostor syndrome is no longer a
| syndrome it is just accurate identification and classification.
|
| I give it to those users who were interested.
|
| I watch them on hot jar.
|
| 4. Tea leaves
|
| This is the hard part. If they are enthused great. But if not You
| kinda have to sense whether or not their dissatisfaction is
| because it's an MEP.
|
| If you've done it right, however, and found something they super
| want they will actually struggle through it to get that thing
| done. Sometimes the MEP isn't far off from an MVP. Sometimes
| their satisfaction is enough to convince you not to do the rest
| of the stuff you thought was necessary in your on paper Valhalla
| take.
|
| 5. Users of Software
|
| I often forget that your average software user does not have our
| relationship with software. They don't see the amazing version in
| your head so the crap version feels like magic.
|
| You'd be surprised how hard people will work with a subpar system
| with the hope that it'll work out for them, both from optimism
| but also from a lack of viable alternatives.
|
| Or maybe you're not that surprised because you've voted in
| America zing I went political at the end.
| lapcat wrote:
| Process?
|
| Seriously, one of the great things about being a solo dev is
| _not_ having a process.
| philmcc wrote:
| Oh. One other thing. I tend to go backwards. UX first. Then API.
| Then whatever fuels it.
|
| If I go the other way around I -inevitably- forget some stuff
| that is crucial for the front end implementation, whereas it's
| hard to forget how it supposed to work for the user.
| retrocryptid wrote:
| I too favor a "code early" strategy. Though I always write down
| sample data inputs and outputs on paper or in a text file.
| Sometimes I realize I misunderstood some aspect of an API I'm
| using. It's good to learn that early on.
|
| I'm a test-first fan, so I start coding by doing a small test of
| a small bit of functionality. I'm not doctrinaire, so sometimes
| I'll write functionality before tests, but usually not. And I
| write tests pretty soon after if I don't write them first.
|
| I use GIT, even on personal projects and have moved away from
| Gitflow to a CI/CD branching strategy.
|
| I'm a bit of a weirdo and write basic usage docs pretty early in
| the process. I average a couple paragraphs per file, just an
| overview of what the functions in the file are supposed to do.
| That way I can get away with shorter per-function comments.
|
| Most importantly my comments document my intention, not what I'm
| doing. I can tell I'm incrementing a variable by looking at the
| code, but if it's non-obvious why I'm incrementing it, I'll writa
| a comment about that.
|
| Test first and documenting intent help me regain context if I
| have to put the project down and pick it back up later.
|
| I sometimes use code coverage tools, but I've gotten pretty meh
| about it lately.
|
| I'm learning TLA+, but already use KAMI on hardware projects. I
| think there's a lot of potential upside w/ verification tools,
| but dang if it's not a little brain-bending sometimes.
|
| I've also rediscovered my love of Lisp in the last 5 years, so am
| using Janet or Scheme a lot for personal projects. Not sure why I
| don't use Clojure more, it's a perfectly fine language.
| twolettername wrote:
| > I too favor a "code early" strategy. Though I always write
| down sample data inputs and outputs on paper or in a text file.
| Sometimes I realize I misunderstood some aspect of an API I'm
| using. It's good to learn that early on.
|
| > I'm a test-first fan, so I start coding by doing a small test
| of a small bit of functionality. I'm not doctrinaire, so
| sometimes I'll write functionality before tests, but usually
| not. And I write tests pretty soon after if I don't write them
| first.
|
| I also do this and find it very helpful in breaking down
| assumptions. I will add that it has been, in my experience,
| best to do _everything_ to break down assumptions of any kind
| first - you don't want to find out far later in the process
| that some technical solution you had isn't viable for your
| needs, or even that some business-oriented solution doesn't pan
| out.
| retrocryptid wrote:
| That got me thinking. The reason I moved to test-first (or
| test-early) is I've coded myself into a corner with respect
| to tests, that is, I wrote code that was super-hard to test.
| I think that falls under "breaking down assumptions" -- I
| _assumed_ I would be able to easily test code I was writing.
| I 'm going to start using "BDA" as an acronym at work (and
| see if anyone thinks I mean "Battle Damage Assessment.")
___________________________________________________________________
(page generated 2022-07-23 23:02 UTC)