CS student building a side project, when did you decide your project was "real" enough to show people?
Posted by leadvoy@reddit | learnprogramming | View on Reddit | 12 comments
Working on a small tool for a friend. The code works, but it's far from polished. Part of me wants to wait until it looks pro, the other part knows perfectionism is just procrastination.
For those who shipped side projects: when did you actually let people see it? Half broken but functional, or only after it felt presentable?
PM-ME_YOUR_WOOD@reddit
As soon as the main flow works end-to-end, show it. Call it v0.1 and tell them what’s broken so feedback stays about the idea, not the polish.
BrannyBee@reddit
When it does something, ideally something close enough to the client request to show progress. You should look up the term MVP, minimal viable product.
Its basically as barebones of a version of what the client wants, with absolutely nothing else, as you can get. If you're developing anything that doesnt get you closer to the MVP, you're wasting time. In fact you may be wasting more time than you realize, because an MVP can be shown, and the client can realize that they actually want something slightly different, then you work with them and pivot or add features. Then you show them the new MVP, and repeat, THEN you perfect. If you perfect things now, the chances of you throwing away hours and hours of work skyrocket, and so do the chances of you building out stuff that will never see the light of day.
If I was making a tool for a friend, lets say they wanted something simple that he could enter the amount of a meal and calculate the percentage he would tip, I would straight up shon him a CLI tool the second I got the logic working. Then when im showing the "client" the app, I would explain "im typing a number here in the terminal which looks scary and alien to non technical people, but obviously when this is finished the same logic will be applied to the numbers you submit on your phone"
Then if he says "thats great, the math checks out, but it would be cool if I could get 3 separate tip values for bad service, mid service, and good service"
Then id go back and make the shitty minimal app do some more business logic til it works and show him that. Then he can tell me its great or that he wants it to work with different currencies, and I go back and do more work.
If at anytime he says "I also want it to track how much I've spent at restaurants and show me a chart at the end of the month showing what restaurants I ate at the most, and another graph to show me which ones I tipped the highest to find out which are the best".... then Im ready to add features and make that work. That simple business logic can grow even in small little apps like this, and client requirements can increase in scope drastically.
Being a perfectionist isnt helping you or the client, its delaying you getting to the stage where the client says "this is cool, when can you finish it?" At THAT point, you go perfectionist mode. You arent squashing a million bugs or trying to make a feature work, you're polishing what works, and if its the kinda thing that you will want to sad features to, you are making sure the code is setup in a way that facilitates that.
leadvoy@reddit (OP)
Thank you and how do you handle small "nice to have" requests during MVP? Like if my friend says "can you add dark mode", write it down and ignore till later, or just knock it out if it's 10 min? Worried I'd say yes to everything and never actually ship.
BrannyBee@reddit
Good rule to follow for development, the client is an idiot.
Dark mode is great, maybe even necessary before shipping. But you know itll take 10 minutes, and you know that it has nothing to do with the actual core feature.
He's not wrong to make a request like that, it might even be the most inportant thing in the world after the actual "logic" your program is doing. The developers job is basically to work with the client to give things priorities. Some things are easy, and clients think theyre hard, other things are hard and clients think theyre easy. As a dev you communicate whats easy and whats not.
In a real world scenario, youd meet and discuss with the client and basically get a big list of todo items. Having a ton of little features like Dark Mode is actually great for that list, but youll also have other stuff that relates to the core functionality. Then you'd distribute the most important tasks across the team (the team being just you i suppose).
Some teams even give point values based on time needed for a task, theres no hard and fast rule for how to give value to a task so you gotta find what works for you. Percentages are great for this, especially as a solo dev, imo.
You have a full list of things to do, you've figured out whats necessary for the MVP, whats extra, and whats needed but not a priority. Combine the priorities with some kind of guess as to how much dev time each will take, and you've basically built an alarm carte menu you can use to take the app as far as you need, while adding more features whenever you want. There's a bunch of tools like Kanban boards that are used professionally and by solo devs (and non devs) for doing this kinda organization you can look into
Now you have some idea of everything you gotta do, a guess of how hard each thing will be (which is wrong, its never accurate lol), and lets say 2 weeks to work til you show your friend the app. You know whats important, because you've labelled the high priority stuff, so start there. If theres only 2 high priority tasks on your menu, and they both will take 50% of that 2 weeks, you know what you're doing, easy solution with no tough decisions. If you finish with a 10% of the two weeks left, grab a small 10% task, or maybe two 5% tasks even if theyre a lower priority.
Maybe you have a high priority task that will take 90% of the two weeks. Thats just the opposite of that last example, you work on the high priority 90% task, and when its done, if there's nothing more important than maybe dark mode is expected to take 10% of the time.
In the dev world this "menu" is called a backlog. The client can request a million things and you can put them on the backlog. Maybe they report a bug, they can go on the backlog too. Maybe refactoring can go on the backlog. If you take some time to set up some sort of system like this, you'll basically have a constant stream of stuff to do, and it should keep you from getting distracted and focusing on stuff thats not important, because you know whats important.
If you like visuals, theres a million Kanban boards apps for this kinda thing. Theres more professional software for teams ofc, but dont bother with something like Jira. Hell, post it notes on a whiteboard are a favorite of mine for some projects. At the end of the day a backlog is basically just a slightly more complicated ToDo list, but it exists to solve exactly the issue you're running in to.
leadvoy@reddit (OP)
Damn, didnt think anyone would write this much, really appreciate it. The backlog idea makes a lot of sense actually. So far I just had MVP stuff vs random ideas floating in my head, nothing in between. Think I'm gonna start with post its on my wall, sounds way less overwhelming than setting up Jira or whatever. Thanks again for the writeup, definitely shifted how I look at this.
nightonfir3@reddit
If you want one step up from post it notes you can use trello. Its basically a digital board with columns of sticky notes. You can drag between them and then share the board with others so they can see what your doing.
patternrelay@reddit
I treated it as "real" once it solved the core problem end to end, even if rough. Early feedback usually exposes gaps you won’t see alone. Waiting for polish just delays that learning loop. Functional and a bit messy is usually enough to show.
leadvoy@reddit (OP)
Yeah this hits. I keep telling myself "just one more thing" before showing it but thats just procrastination wearing a productive hat. Functional and messy is probably already further than I think.
PalpitationOk839@reddit
Show it once the core feature works. It doesn’t need to be perfect, just usable. Early feedback is way more valuable than polishing in isolation.
HashDefTrueFalse@reddit
To me "presentable" means bare minimum to present... so that. Perfect is usually some unachievable state I'll never reach, so I don't worry too much about it. But personally I care too much to release things that are not at least in a presentable state. What that means depends on the project. The state of the code might not even be a consideration.
FooWho@reddit
The code will probably never going to be "perfect". There will always be one more thing that needs cleaned up, or you thought of a better way to do a part of it, or whatever.
You can "show people" anytime you want. If functionality is what you want to show, show it as soon as it does something. If code is what you want to show, show it as soon as there is some code to show.
There is no magic moment where it will be done or good enough or whatever it is that you are looking for. If you keep building things, you are going to have projects that, five years later, you still look at once in a while and say to yourself, "I should clean up this section here."
Cold-Watercress-1943@reddit
Man you nailed this. I released my first project when it barely worked and was embarrassed about code quality but people actually liked it more than expected
My friend who works in software told me something similar - he said companies ship products with bugs all time and just fix them later. Made me realize I was overthinking it too much
Now I just show stuff once basic functionality works. Worst case people give feedback that makes it better anyway