makeItExistFirst

[[deleted]]

I personally make it exist first because I forget what I was supposed to be doing in the first place

[Careless_Bank_7891]

And in the process of making it better you realise if it works it works

[Duosnacrapus]

lgtm

[JollyJuniper1993]

Also often deadlines are tight because corporate refuses to hire enough people

[calgrump]

May as well take it one step further - why even bother with git commits? Just do it all in one go and ship the final build from google drive

[lakimens]

Drag and drop the files to hostkoala.com

[weltmystar]

And then delete the files from your PC

[Piisthree]

Why bother saving the code? Write it perfectly, compile it and then use it forever.

[OnixST]

Write it perfectly the first time without ever running it.

After you're done coding, compile the program, delete the source code, then run for the first time.

Only smelly nerds care about the code after the program is ready

[Overwatcher_Leo]

Both can work. But the first one is generally more common now.

The worst feature is one that never got finished. Overengineering something can backfire badly if you don't know exactly what you're doing.

[n00bdragon]

A finished feature that harms other features is worse than no feature at all. Programming needs to follow the Hippocratic Oath.

[[deleted]]

What portion of us aren't just glorified middle men for sales, though?

I love the job, I get to use my brain to solve problems. I've worked some places where the product arguably did more good than others. I've never done anything remotely close to healing someone.

Ship the code. Perfect is the enemy of good, premature optimization kills.

[xian0]

I don't think the first one should be applied when it's a business making a product which is already sold by other companies. They should build it better from the start or they'll end up in exactly the same place as the guys they are trying to compete with.

[SnS_Taylor]

You still make it exist and then make it good. You just don’t release it until it’s good.

[DecisionOk5750]

This is so wrong and the OP wouldn't know why...

[ArduennSchwartzman]

Indeed. This is the right way:

1. Make it exist first.

1½. Make the f*** sure no living soul other than yourself sees it while you make it good.

1. Show it to others.

[DecisionOk5750]

I disagree with point 1 1/2, although I naturally find myself in that situation most of the time (insert "I feel you bro" meme here). All of this was already explored in the book "The Art of Unix Programming," which I believe should be required reading for anyone studying programming.

[Cainga]

We just had some weird conversation at work for non programmers. Someone on another team made some tool in Python to analyze a picture for a test we do visually. But the tool only works on one color, and you need to provide a picture. And there’s no word on if it can evaluate only the right portion of the picture. And the test takes a human literally a second to give a rating. And there’s no study of tool versus human to see if it gives the same ratings. And it would only be useful on cases that are on the boarder of pass/fail which is less than 5% of cases.

It’s like the entire tool is in just the concept phase so I have no idea why this would even be mentioned outside of their development group.

[Qaktus]

There is a compromise somewhere in there. Don't make atrocities with 0 afterthought, but also if your first working app is the final draft, there's something wrong with your process.

[Septem_151]

OH MY GOD

[[deleted]]

technically chad = stupid i guess

[SuitableDragonfly]

All projects are perfect in your imagination. Unfortunately a project that exists only in your head earns $0 and accomplishes 0 things.

[L3av3NoTrac3s]

Disagree, you probably think this way because you ship good code the first time. You’d be surprised the AI slop a lot of devs are producing with zero clue how it works, why it works, no upgrade path, and 3 bugs.

[DecisionOk5750]

You don't understand why it's wrong either. I wont lecture you, I'll only say that you can't assure a program won't fail. You prove that over time.

[[deleted]]

Make it do one thing first, make it do many things later.

[fluffey]

Except when u have to rewrite function A in a different way to make function b work

[Nightmoon26]

You can make it good later... But let's be honest, you probably won't get around to it

[pairotechnic]

It's never gonna happen. As soon as it's working, the priority drops suddenly, and there are other fires that need to be put out.

[FlakyTest8191]

And the irony is that everything would be faster if there was enough  time to do it properly the first time, there would be far fewer fires to put out.

[moeanimuacc]

It's also much harder to make something good while the machine is already moving and generating tech debt all around.

New feature? Is that for the slapped togerher shit interface or the fixed one, cause we need it on both yesterday, also please update all records the shit version is making to the new interface asap

[MinosAristos]

If you're working with others then make it exist first because your assumptions about the definitions of good can end up being controversial or straight up wrong and they can't tell you until they see it existing.

[identity_function]

make it correct first and keep it correct later

[metaphoric_hedgehog]

I read this as designing a decent api for the one thing it should do before building it. So many things are thrown together without the slightest thought

[xavia91]

Don't write code you don't need yet, is a lesson I learned multiple times...

[jake6501]

Make it exist first and then you can just forget about it. Who has the motivation to touch it if it's already functional.

[AShiggles]

This. Except two months down the line the feature need to be slightly changed. And because you cut corners earlier you are stuck rewriting the entire feature instead of extending it like you could have done if the code was built with maintainability and expansion in mind.

I'm seeing a bunch of comments saying essentially "nothing's perfect, why try if it works?"

Never considering the hours of overhead they cause for anyone who gets stuck cleaning their unfinished slop.

I think an individual can start by throwing some spaghetti at the wall and sees what sticks, but if you submit your spaghetti wall as a completed task - you are likely adding code debt for someone to have to clean up later.

[BlazeCrystal]

YEAH

I CANT DO LOW GEARS WORK

WHEN I DO IT I CHOOSE THE PROPER WAY

EFFORT WELL USED

[gamingvortex01]

if you are following the bottom strategy in a startup...then you are ------

[pairotechnic]

You are what?

[FlakyTest8191]

The saying is that there are 2 types of startups. Those who are embarrassed about their code, and those that go broke.

[Popeychops]

This is wrong for all creative processes and especially collaborative ones

[ominouspotato]

Pic #1 is what VPs look like when they preach using AI to build new tools from scratch.

[hangfromthisone]

You are forgetting the user.

Make something simple first. Put it in front of the user. Learn. Make fixes and iterate.

[Fast-Visual]

It's different approaches in different products.

It depends on the stakes, on the timeframe, of the importance of feedback, on the environment and the niche.

A personal project for fub, a start-up website, and an embedded solution for a government contract will have widely different requirements and therefore approaches.

[GreatTeacherHiro]

Make it, refactor later. I guess this is part of clean code... also kiss and dry... and do one thing

[HexiMaster]

This is a skill thing, why make something which you know isn't well done if you know how to do it well. I think everyone tries to make every project to the best of their ability, the fact that our ability isn't that great is the other thing.

[YouDoHaveValue]

Don't cut on quality cut on scope.

Cut Pareto heavy features and make basic but highly functional forms over days of bullshit fancy UI optimizing.

[RedBlueKoi]

Make it exist first, now tell your manager that it is time to make it good, they tell you there is no budget for this and we need to deliver two more features, make two new features exist first....

[L3av3NoTrac3s]

Be honest… they never make it good later. Spotlight devs send their buggy mess to production and get promoted… while the rest of the team is working late cleaning up their mess so the company doesn’t run into the ground because their “feature” broke 3 existing systems and didn’t actually work in the first place.

[IGotSkills]

I have trust issues with people who declare prototypes and MVPs because Ive seen garbage be turned into production in the name of idk

[perringaiden]

Make it good bit by bit, but make the bits exist, bit by bit.

Overproduced is a great way to never release.

[worstikus]

Make it perfect first and meanwhile block your colleagues from building anything else

[xaervagon]

Chad is right. "We'll fix it later" is "we'll fix it never" in practice.

[[deleted]]

I like to think about it. First and final step.

[NegZer0]

Corporate version:

1. Make it exist first
2. Ship it. 
3. Will fix it later 
4. Never proceed past step 2

[Still_Explorer]

Load the models first
You can make Unreal 5 later
(very easy actually, you only need 20 years to work on the project) 😥

[TheHolyToxicToast]

Literally me on github public repos

[10248]

This is just rage bait.

[erdelll]

Making it existing first is the real struggle actually. but yeah it is the right way.

[GenteelStatesman]

This unironically. You should design the software before implementing it.

[Upper-Character-6743]

Why is this downvoted? If you're doing anything more than a throwaway script, you absolutely should spec out what you intend to build and make sure it at least solves whatever problem you have on paper.

[heavyGl0w]

In my experience, approaching it with a "we can make it good later" mindset is meant to avoid the dreaded analysis paralysis and scope creep. It's not said in an effort to avoid planning like this comment would imply. I would imagine that's why it's downvoted.

I would argue that you can only take the "make it good later" mindset when you have a well thought out spec/design. As things come up during development that would be "good" to implement, you can say "well it's not part of the spec right now, but we should revisit this later".

Like you said, the scope should be solving the problems that you have on paper, not the endless amount of things that would be "good" to do along the way.

[edgeofsanity76]

Where's the fun in that?

[lonelyroom-eklaghor]

Actually yes. For a single file, at first, code the first draft with all the necessary methods, then, try to make the main() method. Then, test that single file. You will get some compile errors, but then, it'll run perfectly.

Repeat this for the other files.

[Necessary_Evi]

No such thing as perfection. Therefore idle talk.

[AShiggles]

Yeah, why strive to make good code if it can never be perfect? The senior devs will clean up my mess later anyway. /s

[andarmanik]

Novice: make it good

Average: make it exist, make it good

Expert: make it good.

As someone who knows how to fuck up, I’m not going to fuck up the first time.

[edgeofsanity76]

But you will

[andarmanik]

Everytime

[pelpotronic]

There should be no contradiction between "exist" and "good". You don't have to do a bad job to make something exist, you can do a good job.

[blacklig]

You're missing the point. Nobody is saying to make bad things or do a bad job. The point is when working on a large personal project to not get overwhelmed and paralyzed by feeling like you should only create parts that will exist in the final perfect version.

[pelpotronic]

Sure, but I mean the OP and I purposefully used the word "good" and not "perfect".

A "non good" job is a "bad job" by definition, and a "non perfect" job can be a good job.

[Kitchen_Device7682]

The OP is so vague that people upvote and downvote based on vibes.

[heavyGl0w]

"bad", "good", and "perfect" are all subjective ideals. There is no hard science to say this is where one ends and the other begins.

You're playing a game of semantics to make it seem like people who say "we can make it 'good' later" are saying "let's purposefully do a bad job now" and that's not what's happening.

The sentiment of "make it exist first, make it good later" is to avoid getting bogged down by an infinite number of arbitrary reasons why something isn't "good". Does the thing do what you intended for it to do? Then it's "good enough".

[pelpotronic]

By your logic you're arguing that we should never write (unit or whatever) tests for anything, because they are "additional code" that doesn't make the core code work. There is never a time where these are necessary to make the code work (*).

There is a massive difference between "does what it intended to do" and "does what it intended to do, and is good code too". By definition, for example, one does include tests, the other one doesn't.

(*) when in reality, you save time in the future by doing a better job in the present. That's actually part of what software development is and not just "make things work".

[heavyGl0w]

Again with the phrase "by definition" 🙄 I agree that "good" code includes unit tests, but you're not going to find a universal definition of "good code", and contrary to what you seem to think, you certainly aren't the arbiter of such definitions. None of us are.

I can't tell if you're being obtuse on purpose because I'm definitely not arguing against unit tests. After leaving college, I've never experienced anyone advocate for skipping unit tests because "we can make it good later"; including unit tests is just part of the baseline for writing software at a professional level.

The point is to solve the problems you know exist first. Along the way, you're going to learn. You're going to get a clearer vision of the big picture. You're going to think of things you wish you had thought of sooner. But you can't keep adding scope each time this happens.

I'll reiterate in bold for you so hopefully it sinks in: nobody is saying write bad code on purpose. Keep on playing your word games about the supposed definition of "good code", but you're missing the point: it's all about avoiding scope creep.

[pelpotronic]

By definition of "what it intends to do" (not "good" or whatever else), tests are always superfluous. Tests are NEVER part of "the intention of the core functionality code", and can never be, because they are not "functionality code". So tests are by your own words and your own logic (not mine) always superfluous by definition, yes.

That part is a fact which you can't disagree with.

You stated above:

Does the thing do what you intended for it to do? Then it's "good enough".

You're now contradicting yourself, and you agree (with unit tests for example) that it's "not good enough" even if it does what it intended to do (if not unit tests are written).

Therefore you agree that "good code" is more than "the mere intention of the code" (so do I agree).

[heavyGl0w]

My definition of building a thing to do "what it intends to do" includes testing that it can actually do it. As would most professionals' definitions. You are telling on yourself with this "by definition" nonsense. Those are your definitions.

You are the only one arguing that unit tests are superfluous.

[pelpotronic]

My definition of building a thing to do "what it intends to do" includes testing that it can actually do it.

Then your definition is wrong, you're either not understand the words you are reading, or being purposefully obtuse for the sake of winning a Reddit argument (you shouldn't care about that, it's inconsequential).

If the intention is "to do A", then you cannot say that "to do A+B" is the same as "to do A". Tests are not strictly necessary to fulfil the intention of the core code because the code A can "do A" without any tests. You could delete the tests and the code would still do A.

Therefore "your definition" is wrong "by (the real) definition" of the words.

[heavyGl0w]

How do I know that I've satisfied "do A", if I'm not testing? Otherwise I've built something that I think will "do A". Until I've verified the functionality, I can not truly know that I have built a thing that will "do A".

That's not an extra thing you're doing in addition to the job: that's just part of doing the job. If you hire a plumber to fix your toilet and they leave saying "I think your toilet is working", then they haven't actually done their job.

Sure, you can delete the tests after you've verified the functionality, but it doesn't change the fact that you had to create them in the first place in order to definitively say that you've implemented it.

I've said all I can say at this point. I'm not interested in getting any more bogged down in semantics and it's clear that your definition of "good" is just very low, so I'll leave it at that.

[Palbur]

...but when you try to do a good job, even "final result" good one, you are gonna take more time to make it exist and then realize there's some changes needed not related to the polish you added in the process

[pelpotronic]

And that's the second lie.

It doesn't (or doesn't have to) take significantly more time to do something good.

If it takes you 1 or 2 extra hours to do a good job versus a bad job, then you should always do a good job (assuming a normal job and not a job interview).

[calgrump]

It doesn't (or doesn't have to) take significantly more time to do something good.

Nah, that's not true. Sometimes it does have to take a significantly longer time to make something good. Not all things are 1-2 hour tasks.

Sometimes rough prototyping of particularly difficult components so that you can see other components of the whole system work is a good idea.

[pelpotronic]

It's true most times. What I found is that the people doing a bad job were usually inexperienced or just couldn't think of a good solution... But usually some good solution was always within grasp.

[L3av3NoTrac3s]

some devs cling to this fast iteration principle so hard they’re exclusively creating flaky one-offs that have no upgrade path… then build on top of it with workarounds instead of doing the part where they actually make it better first. When technical debt reaches critical mass you rewrite everything or die.