One thing I’ve noticed since I started putting more of my software out into the world is how strange the phrase “independent developer” can be.
Technically, yes.
I’m the guy sitting at the computer writing the code.
I’m deciding what gets added.
I’m fixing the bugs.
I’m making the icons, working on the store listings, testing things, breaking things, fixing the things I broke…
And drinking entirely too much coffee while doing it.
So, sure.
I’m an independent developer.
But I’m starting to realize that doesn’t mean I’m building these things alone.
The Moment Someone Else Uses It, Everything Changes
When you’re building software for yourself, you know how everything works.
Of course you do.
You built it.
That button in the corner makes perfect sense because you remember putting it there.
That weird setting buried three menus deep?
You know exactly where it is.
Then someone else installs the app.
And they can’t find it.
Your first thought might be:
“It’s right there!”
Except…
Apparently it isn’t.
At least not to them.
That’s when you learn one of the most useful lessons in software development:
The person using the software is usually better at finding its problems than the person who built it.
Not necessarily programming problems.
Human problems.
Things that aren’t obvious.
Things that take too many taps.
Words that make sense to me but apparently don’t make sense to anybody else.
That’s incredibly useful information.
Sometimes the Best Feedback Is Really Simple
Feedback doesn’t need to be a five-page bug report.
Sometimes it’s:
“Could this button be over here?”
Or:
“I thought this did something different.”
Or my personal favorite:
“Why does it do that?”
That’s a dangerous question to ask a developer.
Because sometimes I have a perfectly good technical explanation.
And halfway through explaining it, I realize…
They’re right.
It shouldn’t do that.
So I change it.
Not Every Suggestion Becomes a Feature
This connects directly to something I wrote about in Journal #3.
Just because someone asks for a feature doesn’t automatically mean I’m going to add it.
That’s not because I don’t value the suggestion.
Quite the opposite.
I keep ideas.
I think about them.
I look for patterns.
If one person asks for something, that’s interesting.
If ten people independently run into the same problem, now I’m paying very close attention.
But I still have to ask:
Does it make the app better?
Does it solve a real problem?
Can I add it without making everything else harder to use?
Does it belong in this particular app?
Sometimes the answer is yes.
Sometimes it’s no.
And sometimes an idea sits in the back of my head for six months before I finally understand how it should work.
That’s okay.
I’d rather do that than bolt every suggestion onto the side of the application.
Eventually we’d need a bigger spaceship control panel.
Bug Reports Are Different
Now, if something is actually broken…
Please tell me.
Seriously.
There’s a special kind of confidence you get after testing something fifty times and watching it work perfectly.
Then somebody installs it on a phone you’ve never seen, running a version of Android you didn’t test, connected to an email server configured in some way you didn’t know was possible…
And it explodes.
Welcome to software development.
There are simply too many combinations for one person to test everything.
Different computers.
Different phones.
Different screen sizes.
Different servers.
Different configurations.
Different ways people use things.
That’s where having real people using the software becomes invaluable.
Every bug somebody reports makes the application a little better for the next person.
And Sometimes People Have Better Ideas Than I Do
This may be difficult for a developer to admit.
So don’t tell anybody I said it.
Some of you have really good ideas.
I’ve had people suggest things where my immediate reaction was:
“Why didn’t I think of that?”
Those are fun.
Because suddenly something I built takes a tiny step in a direction I hadn’t considered.
That’s one of the things I’ve started enjoying most about releasing software.
I build the first version.
Then people start using it.
And the application begins teaching me what it should become.
That’s Why I Want to Keep the Conversation Open
I don’t want HackitZ to become one of those places where feedback disappears into a corporate support system.
There’s no giant customer-service department here.
There’s no committee deciding whether your suggestion aligns with our third-quarter engagement strategy.
It’s mostly just me.
Which actually has an advantage.
When somebody sends me an idea…
The person building the software can actually read it.
I think that’s pretty cool.
I can’t promise I’ll implement everything.
I definitely can’t promise I’ll agree with everything.
And sometimes I’ll probably say:
“That’s a great idea, but it doesn’t fit what I’m trying to build.”
But I’ll listen.
Because once somebody chooses to install something I’ve made, they’ve given me something valuable.
Their time.
If they take even more time to tell me how I could make it better, the least I can do is pay attention.
So Maybe “Independent” Isn’t Quite the Right Word
I write the code.
But every person who reports a bug helps improve it.
Every person who suggests something makes me think.
Every person who tells me something is confusing helps simplify it.
And every person who simply uses the software shows me whether the ideas I’ve been writing about in these journals actually work in the real world.
That’s a lot of people influencing something supposedly built by one guy.
So yes…
HackitZ is independent.
But I don’t think it has to be built alone.
I can build the software.
You can help me build it better.
I think that’s a pretty good arrangement.
Until next week,
Kev