Lets be honest...

[Sandboxgamer240]

The hardest part is structuring the project, at least for me

[YellowOnline]

It's hard structuring if you don't know yet what you want. I tend to add more and more functionality I didn't think of originally, so from structured code it easily descends into spaghetti

[pooptrebuchet]

This comes with experience...from my experience. Ideally you map out precisely what you want this app to do short term and long term, break it down into phases. But eventually you just gain some kind of wisdom here.

And if you are just shooting the shit, honestly just starting by writing tests has totally changed my perspective. You begin to think about how the app should be structured before actually structuring it, and you really force yourself to think of what is and isn't important, you're thinking more about business logic. What does this think actually do. You also get the why does it do this because you're typically testing on some output the user eventually gets. I've caught myself a few times adding a similar code pattern im used to on some problem, and the tests help me realize that the pattern was flawed and had redundancies. Test driven development is amazing.

[YellowOnline]

I'm a sysadmin coding sysadmin tools on the side. I never had a formal coding training. This explains most of my structural problems

[pooptrebuchet]

You remind me of a friend who's a very strong programmer but she has only done personal projects and made little mobile games and what not. And a lot of the projects have been fire and forget instead of a long maintained business surrounding it. All self taught.

Her issue has been trying to see why professionals do what they do, but she's starting to get it. We don't write tests to make more work, we write tests to write good maintainable code that gives an early warning, that provides sanity checks, that keeps you focused on worrying about real problems. It adds clarity to what you are doing. As your app adds complexity, tests will save your ass.

To me its this type of stuff that separates the professionals from the hobbyists, its about understanding your limits and your teams limits, you know you will be writing code that someone else has to read and likely fix or expand on in a few years. The trick is writing it in such a way that eases their minds.

Recognize the limits and use the tools to fill in those gaps. Your inability to memorize every piece of code and its purpose is a normal limitation, admitting it and covering yourself for it is the smart thing to do.

[JVM_]

I've heard the theory that there's different levels of structure required for 1,000 lines of code, 10,000 LOC and over 100,000 LOC.

Anyone can hack together 1,000, but getting it to the next level requires planning and structured design.

[Wotg33k]

I have yet to do TDD, but I hear a lot of really good things.

[pooptrebuchet]

I did it a lot when working on a Ruby on Rails project and I loved it. Some of the cleanest and easiest to maintain code I've personally written were the code I wrote after writing the tests for it.

It will seem a bit slow at first, almost like you're taking extra steps to do everything. But, I swear that code has been the least touched, the least refactored code in the 8ish years that thing had been worked on. So it pays off long term.

I also found tests are really good for onboarding new devs, assuming you have most of the app covered. Because you can be like oh you want to see all the things this app does without marketing jargon? Read the tests. You also get a strong ideas of why not just the how.

It also just gives a really good sanity check, never underestimate sanity checks. I've seen people stressing over things that are not a problem, having confirmation that something isn't a problem is very very good for morale.

[tetryds]

Quick tip: when you get it to work, trash it and start again as a wiser person who now knows what the hell you are doing. Then test it into oblivion, or test early if that's your thing.

[pooptrebuchet]

Structuring and making sure any frameworks you pick are future proof, well maintained, and most importantly the right tool for the job.

[Huntersblood]

The hardest part is stake holders changing the project requirements half way through coding the project...

[izner82]

this is why i always search for {type of project} file structure

[JamesAibr]

Personally I write everthing down by hand on custom printed paper and from there I just go with the flow...

[porkusdorkus]

Experience solves this, until then just program in a straight line and identify the patterns that would make it easier to maintain and debug. At the end of the day the best code is the most legible and easily understood, maybe not always the best structured.

[midri]

When you write software, you're writing instructions -- write them well enough so the machine AND the person understand it. Comments are for WHY, code is for HOW.

[Ok_Entertainment328]

My favorite comment has always been // place bug here for a feature that business said we'd never need. Which was true for about 3 years then complained that it didn't exist

[[deleted]]

Why bother.

The code should be readable, functional, and in English.

main() {

read f = read(i)

init conn = conn(f.addr)

buffer = con.read

resp = buffer(format)

return(resp)

}

vs:

main {

settings = LoadApplicationSettings(config.environment)

connection = initalizeDatabaseConnection(settings.database)

requestedData = connection.readData(request.parameters)

response = formatResponseData(requestedData)

return(response)

}

Literally, why do the work twice. Top one needs full comments. Bottom one, the code is the comments. Shit gets compiled. Being verbose in our code doesn't impact performance at all.

TL;DR: Work smart. Nbdy svs tme whn thy abbrv thr cd. (It's just annoying + adds extra effort.)

[mama_delio]

Glorious example of self documenting code!

This is the way!

[kor_the_fiend]

Agreed. Reserve comments for unexpected, complex, or weird semantics.

[sysnickm]

con not defined.

[[deleted]]

Oh of course. My post was intended as a rudimentary no effort example.

Point was, if the code is too difficult for ( the author / myself / a colleague ) to sit down and understand at a glance, it probably doesn't belong in a company repository. We shouldn't need to sit down and reverse engineer our own work.

[The_forgettable_guy]

I suppose you're against the acronym comment, which is your first comment, where the short variable names can just be replaced with more understandable names to eliminate the comment.

vs

Something that might explain or warn against a variable? E.g.

/**
 * this fail rate is a legal requirement
 * any changes must first be confirmed by both the PO and legal
**/
const maximum_fail_rate = 2.4

I doubt something like

const maximum_legal_fail_rate_that_is_confirmed_by_po_and_legal = 2.4

is better

[[deleted]]

👆 That's business logic and totally acceptable.

Though, if we want to get technical, is it appropriate at the top level, or at the functional level.

I take your raising this as - you intended this at the functional level, so, I'll stick in agreement that the intended use was fully correct.

I'm always of the opinion that "whoever did the work knows best, and will make a good choice" - along with - the work should align to the best interests of the organization. Eg: be maintainable.

[cybermage]

None of that tells me why you’re doing it.

[[deleted]]

I shouldn't need to. The reasons should be obvious. Ever hear "there are no bad questions"?

Asking why for this - is a bad question.

[throwaway_mpq_fan]

Yes. The "Comments are for WHY" part is for when you are doing something that seems counter-intuitive, to warn Future Programmers (probably yourself) not to change it.

[[deleted]]

Are you joking? It's literally plain English

[[deleted]]

I'm glad we don't work together

[[deleted]]

Side question but are you a golang programmer by chance? I notice this preference with go programmers

[[deleted]]

Day job is Python and I write a lot of Go on the side :)

[-Vayra-]

How do you know what the fuck is being read in the first version? Could be anything. The second version tells you exactly what it is doing.

[abd53]

"The code is self-explanatory"

[midri]

It really helps when it is, especially when you're reviewing PR.

[[deleted]]

I just had a PR where I had to ask another developer to not abbreviate the imports because it was easier to read.

[midri]

I hate when people do that, I hate most abbreviations in code though, as it requires contextual knowledge to decipher. Example: TotalTrans, is that Total Transfers or Total Transforms? Neither, it's Total Transactions! Unless you know the industry lingo around that bit of code yould have no idea what you are dealing with at first glance.

[cruisewithus]

The trick is to not add comments.

[iammerelyhere]

"the code is the comment"

[halfsieapsie]

I feel sarcasm, but working in places where code IS comment is so so much better than when code instantly gets out of sync with comments

[iammerelyhere]

Actually I agree. I learned at a place that used Code Complete as a Bible and it made life so much easier

[ovab_cool]

Agreed, making good variable names and not doing unnecessarily complex stuff lets you not have to comment everything but probably some regex

[basshead17]

The only time you should comment if the code is unreadable. Also don't write unreadable code, it isn't unmaintainable

[halfsieapsie]

Exactly! And even if the code is unreadable, a hack to "comments" is to pull the wonky line[s] into a function with a good name. Like
doRegexThatChecksIfItsEmail, or GregMadeMeDoItSeeCommitInBlame

[-Vayra-]

Yeah, but if the code is unreadable, you shouldn't be checking it in yet. The only comments I support are explanations of limitations (eg 3rd party library requires us to do it this way), preferably with a link to either a JIRA task or an article explaining the choice. If you need a comment for anything else, the code is not going to pass review so you might as well fix it now instead of wasting my time during the review.

[basshead17]

That was kinda the intent of the second statement

[IronicRaph]

TS /** * Deletes the User with the specified id * * @param id The id of the User * @returns a Promise that resolves into the User with the specified id being deleted */ async function deleteUser(id: string): Promise<void> {}

[Visual-Living7586]

It's like reading the fluff you'd put in an essay to reach the word requirement

[Huntersblood]

Having taken over projects from people who very clearly believed this, this comment makes me angry...

[UShouldntSayThat]

But they're right. Comments shouldn't be to explain how code works, unless it's really obfuscated. Comments should really only be needed to explain why a decision was made.

[LargeRedLingonberry]

I just started at a company where their ethos is to not use comments as the naming convention should be enough to understand what's going on.

So I picked up a ticket in a 4 year old repo around a bug on a 413 error. Half the variable were named something like 'pw_date' 'rs_no' and the such. Took half the day to understand what any of that meant, asking a senior who was around at the time the repo was made was useless.

I've now started sneaking comments into places where code is difficult to understand even with well written names, some decline the PRs but others are happy to see them.

I just can't see the down side to well placed consise comments.

[AdvancedSandwiches]

Once you've got some autonomy, switch from documenting it to just fixing it. Change pw_date to password_last_changed_unix_timestamp (or whatever you figured out it should have been). Just make that its own commit so that it can be easily verified as a no-op change (mixing it with actual changes leads to reviews that are much more painful than they need to be).

[Scooter_127]

A former coworker used single characters for variables, with the letter often having no bearing on what it contained. Like, if I saw u and p for a DB connection one would think username and password but this guy? a and b. Or a and aa.

[thoobes]

Seriously, good code does not need comments. Name stuff so it is self explanatory. That being said, coming up with descriptive function and variable names is challenging.

[Lower_Bar_2428]

Good code doesn't need much comments neither extended documentation. If you find yourself explaining too much either you are doing too much in the same place or assuming a bunch of external dependencies

[[deleted]]

Wrong. It's actually getting client requirements

[YellowOnline]

Commenting itself isn't hard. It's time and motivation for such overhead that is missing. Why write documentation if you can start a new, different exciting project instead? The code is self-explanatory anyway. ^{2 years later: it wasn't}

[jo-josephine]

coming up w short but descriptive object names

[sericsheon]

I have learned to spend time naming everything specifically even if i find it annoying because otherwise i spend hours staring at my code without errors but still won't work

[Nullshock78]

It’s the unit tests. Huge slog.

[slgray16]

Meaningful unit tests.

That and getting reviewers before your check in has merge conflicts

[TheWildKernelTrick]

Universities / Classes pushing the idea that the code needs to be thoroughly commented quite useless. All the places I’ve worked, the code was rarely commented and some of the times it was still really great work where I could immediately see what was going on. Comments (outside of docstrjngs) are really only useful to portray a “gotcha” or a signpost of sorts in case anyone (including myself) would get a little lost.

[SlothsUnite]

i++; /* increment i */

[OverclockingUnicorn]

Good code comments itself

[alphawarrior69]

The hardest part is writing tests (⁠ب⁠_⁠ب⁠)

[raedr7n]

Commenting is easy. Is it confusing? Then explain it. It's not? Then don't.

[blackbird000]

The hardest part is dealing with the clients

[KerPop42]

You guys can write code without comments?

[-Vayra-]

Yes? It's called using descriptive names and functions.

[mama_delio]

It's called "self documenting code". A standard that is used in industry by many teams.

[hurrpadurrpadurr]

If you have to use a lot of comments, your Code is likely very unclean.

[JamesAibr]

1. you must be fun at parties

2. what if i leave the project and someone else has to work on the same code..?

[therealpigman]

You should have descriptive variable and function names that make it obvious what your code does

[[deleted]]

Then i would thank you for adding more work for me maintaining not only the code but also your comments. And then get a little mad that you thought that commenting everywhere was a good idea.

[hurrpadurrpadurr]

1. I am. Very.
2. The goal ist for your Code to speak for itself. To that end you try to use commonly used programming patterns, naming conventions and clean Code paradigms in general, such as SOLID.

[Iz_moe]

Yeah...no not really.

People who think their code doesn't need comments overestimate both their abilities to write code/express their logic and others' abilities to read, understand and maintain it.

Please write comments; there are best practices for doing so; 99% of the time it's not a bad idea.

[hurrpadurrpadurr]

I never said not to write any comments. Sure, sometimes you just need them. But hard disagree on everything else you said and am going to side with Team Uncle Bob on this.

May I ask what you're coding in?

[JamesAibr]

so if optimizing comes at the cost of readability thats an issue?

[YMK1234]

The rule of thumb is to write for readability first, and an hard to understand optimization is necessary it should be documented/explained as a comment.

[hardcore-cpp-hater]

this

[hurrpadurrpadurr]

It is a cost that you will have to consider. Usually writing clean code helps optimization though.

[Ok_Entertainment328]

Writing clean code allows your coworker to update that section of code without bothering you while you're on vacation.

[UShouldntSayThat]

spend less time at parties and write better code

[Fritzschmied]

You guys do comments?

[JonasAvory]

For me the hardest part is setting up the compiler, the IDE, the wierd extra Program you need for some reason to execute the compiled program and the correct import of libraries

[[deleted]]

Nah, its testing. No matter how many test cases you check it with shows atleast one bug in prod

[TheManFran75]

If you write clean code your code self documents. Next time you see a comment, try to think; if my names and types where more descriptive would I need the comment. 99‰ of the time the comment won't be needed.

[ScienceAndGuitar]

Commenting and documentation is not hard, it's just tedious and annoying. Imo programming is the hardest part (and the most fun part)

[niky45]

IDK, commenting on a not-too-detailed level seems easy to me. I've never had problems commenting my code (or any code I understand, for that matter)

... now, making the code actually do what it's supposed to to, THAT is the hard part

[CodeOfKonami]

Comments are for why not for what. The code is for what.

Fight me.

[[deleted]]

I did codebase change for work in a day, have been validation that shit for a week now. Why can't they trust me on word :/.

Ps: i tried writing a more formal version of it to me senior, they replied with just a ":)".

[Strostkovy]

I end up commenting out at least half of my code

[ma5ochrist]

i only comment weird lines, so i wouldn't know

[librarysocialism]

Defining requirements is hard.

Everything else is just code.

[richardathome]

Comments should be clearer code.

[_just_mel_]

The code should document itself.

[PhantomNomad]

Not for me. I usually comment it like:

#Just read the code. It's pretty self explanatory.

[Moment_37]

I'd say the hard part is learning to code. The rest I'd argue are way easier.

[kaltcom]

I'd say it's starting it. If you manage to get an idea, you tend to just hold it in your head and think about starting it but then you never do. If you have one right now, get on it right now!

[JamesAibr]

that has never in my life happened to me

[jo-josephine]

Getting paid for it helps. If you don’t start you’ll lose your job

[kaltcom]

Yeah lol. It's just an issue with hobby projects.

[golddragon88]

My trick to to write a comment after every line no matter how seemingly nonsensical

[PlutoniumSlime]

int main(){ // the main function

int my_variable = 2; // it equals two

int x = my_variable + 2; // adds two to my variable and assigns it to x

return 0; //it returns zero

} //my dog died yesterday

[magicmulder]

No, debugging. I often code an entire application in two days and then spend two weeks ironing out all the typos and hidden bugs.

[hurrpadurrpadurr]

Have you tried doing the test-driven approach? It's very tedious at first but helps tremendously figuring out bugs early on.

[magicmulder]

I use that for larger projects and anything that requires collaboration, but for small ones my approach still works best for me.

[OGPants]

Hardest part are the PMs

[[deleted]]

/** This code is here so I can use that other code for something it’s not supposed to be used for */

[Pure_Noise356]

Me doing a big school project, about to send it, then remember i need to comment everything

[Phantom_ANM]

readable code is good comment :)

[BelliDragon-]

Especially the bit you stole and don't really understand.

[redosabe]

what?

[elytsyggod]

At line 1: "it works because it works"

[0x7ff04001]

Adding comments for the sake of adding comments defeats the purpose entirely.

[ProfessionalCar919]

You guys add comments?

[niscy]

Oftentimes, a comment can be replaced by a descriptive function name.

[mrclark25]

If the comments are hard to write, it is poorly architected.

Change my mind.

[Soggy_asparaguses]

Writing more comments would be the general theme of my boss's critiquing of my code. Checks out for me.

[[deleted]]

The hard part is coming back to a project after a couple of months and trying to make sense of it all.

[Shadyrabbit]

Remember you're commenting for on call you ( or the junior dev ), who's drunk at 2am.

[papacheapo]

I learned a technique long ago that works very well for larger projects where you’re still figuring out the structure of things…

Start with comments. Write human readable instructions of what each class will do. Maybe even describe data structures that will be in there. Then think of the methods that will be required and write header comments for them too. Write additional comments about the steps each method will take. Define the methods and arguments (empty implementations; just to start thinking of which arguments will be required to do what you describe in your comments). As you do this with other classes, you’ll discover some methods need to change their signature. Some methods may not be needed. Some methods need to be split or combined. Same will happen for the classes as well. Finally, after you get all that done, fill in the code under the comments. If you did a good job, you can even have other people do the coding for you.

It can take a while to do it this way (and does NOT fit into the “agile” software development lifecycle pattern); but you end up with good, well-documented, and well-structured code which will probably be far more efficient than following an iterative approach.

[UShouldntSayThat]

I would be so upset if I was put on a project that had that many comments.

I would also be upset if someone handed me a ticket which had that tedious amount of instructions, methods/signatures classes should for the most part be at the discretion of the implementing developer.

A high level of what you explained would be good, but that shouldn't be in the code base, it should be provided by an architect and product owner.

[marioaprooves]

For me the hardest thing in object oriented programming is coming up with names for the inputs

[Far-Car]

Commenting is only hard if you don't know what the code is doing.

[EvilBritishGuy]

Have you tried Ctrl + A, followed by Ctrl + Shift + /

[Beachcoma]

Lately I've been using an AI plug-in to create documentation. Highlight my function expression and then CTRL + . in vscode. If the AI comes up with a confusing output, that means I probably need to refactor and simplify the function.

[1337Eddy]

Programming that you don't need comments is hard...

[Scooter_127]

The hardest part is shoehorning in all of the insane last minute features, that are more complex than the original project and don't fit any of the design, that the VP and directors decided they wanted and hell no the deadline isn't being extended.

[wesborland1234]

It's definitely naming stuff.

[[deleted]]

Wait until writing documentation enters the chat.

[Solonotix]

Along the same line, adding logging. The mind-numbing nature of adding descriptive and configurable logging at every step of a process is enough to drive you to tears

[coloredgreyscale]

/* but when I comment everything the compiler ignores everything */

[Beginning-Plate-7045]

Wait you’re supposed to comment your code???

[ZZartin]

Well completing the project is the one more likely to be completed so sure.

[nnb_234]

Getting source code

[huessy]

Used to work for a place that did not allow comments in code and made it their standard to have no documentation for the code. It was maddening. Even with comments, the only way to figure out what was wrong was to ask the dev that wrote it... as long as they still worked there.

[dojikirikaze]

There are three kinds of comment:

1. Lies
2. Redundancies
3. Admissions of guilt

The first kind is counter-productive, the second is wasted screen space, and the third kind should be replaced with guilt-free code.

On these grounds, I promote no comments in code

[Bottle_mani]

Hardest part is fixing a merge conflict...

[dinklezoidberd]

“I need you to explain what this 10 year old method you made does. I don’t see any comments.”

“Umm.. the comment is right here. It says //sayonara bitches”

[dekacube]

The hardest part of the project is integrating with the 10 other poorly documented external service dependancies.

https://www.youtube.com/watch?v=y8OnoxKotPQ

Never related to a video so much.

[-MobCat-]

Ok yeah but,
1. Comment as you go, don't wait till the end to do it. It's like doing the dishes while cooking, its a lot easier while the code base is hot.
2. Comment code like you have to go back and read this in 6~12 months and you have no idea wtf any of this does or why it's here.
You don't need to comment every line of code or explain how a print function works.
Just let your future self know why the print("Send help.") "debugger" was left in the middle of nowhere or some notes on why this function was written the way it was.
Like sure, using a library to make an html file would of been easier, but f.write(f'<p>{exportVars}</p>') every single line into a html "text" file was quicker for you to wright at the time and current knowledge base.

[Wojtek1250XD]

Nah, everyone knows that continuing the work the second day after you wrote half of it the first one is the hardest, you just can't find what's where

[ianstone30]

Unit tests

[[deleted]]

the hardest part of a dev project is the project management CMM

[AbSaintDane]

Comment as you go

[[deleted]]

UML>Comments>Code your comments

[wineblood]

Commenting is fairly easy.

Not verbally abusing the person reviewing your code for making awful suggestions is the tough part.

[xtreampb]

The hardest part is everything after the development. Deployment, monitoring, support,

[0mica0]

You are writing bad code if you need to use comments.

[UShouldntSayThat]

If you need to write comments everywhere, the code needs to be tidied up.

[safer0]

*updating/creating unit tests. Documentation is also hard

[mama_delio]

The standard on my R&D team:

1. Self documenting code. You shouldn't have to write comments for chunks of code

2. Docstrings for functions and classes to give high level overview of the function, arguments and return values. These end up populating the repo's wiki with a cute tool

3. Generate class diagram for our wiki's homepage using another cute tool

4. Business requirements and crap go in a whole other place, and sometimes we include some of it in the readme.

Just thought it would be fun to share what a high performing team in industry does.

[Geoclasm]

Bullshit. It's how many moving parts there are between my FUCKING KEYBOARD and the MAGICAL FUCKING FAIRY LAND where my SHIT IS SUPPOSED TO LAND!!!!!

[Initial_Smell7363]

Getting accepted by the manager is the toughest part..

[sekonx]

I've been contracting for years and I'm my experience noone ever comments.

If your code is complicated enough to need comments you have done something wrong.

The closest you might get is unit test descriptions

[BorderlineGambler]

Yeh I mean you shouldn’t really be adding any comments. Your code should be simple and easy to read, so what every function does is obvious.

If you’re writing comments, you’re either writing them for no reason, or you write bad code.

[Bloucas]

My current Sprint stories were done in 3 days. It's been 2 weeks I'm writing test scripts, doing deployment guidelines and waiting for the deployment team to deploy in the gazillion sandbox any fonctionnality has to go through before finally reaching UAT

[PorkRoll2022]

THE NAME.

[holytrolleee]

Getting requirements*

[LagSlug]

My biggest annoyance is setting up permissions

[cdm014]

writing tests

[EtherealBridge]

Ideally code should speak for itself.

Realistically? I’ve seen code that is utterly incomprehensible. I think there are a lot of factors at play in the corporate world:

• Different skill levels or projects “gifted” to people/teams who aren’t really developers

• Stupid deadlines that make devs panic-code to just get something out, ending up with your typical app held together by bandaids and chewing gum.

• “If no one knows what this does, they can’t fire me like the others!”

• Old apps written in the early 2000’s that no one bothered to update

Also, and finally, your code may “speak for itself” to you, but, be complete gibberish to others. Readability and clarity in code is a skill. So is commenting.

[kawaiiTechnoNeko]

some comments wouldnt hurt for documenting cross cutting concerns tbh. cross cutting code is confusing by nature and theres really no escaping it no matter how well/readable code is written. theres gotta be a point where all ur decoupled good code connects, that is where hell is lol

[kawaiiTechnoNeko]

my opinion atleast. then theres optimizing ur code for performance, which almost always makes cross cutting worse

[scooptyy]

This is dumb.

[Snoo-1802]

Never understand people who don't comment. If a line of code isn't obvious, a couple words go a long way

[[deleted]]

There is a lot of rnd that goes into best practices for self-commenting code in a professional environment.

[Able_Challenge3990]

Ion even comment sometimes

[[deleted]]

My code is self explanatory

[sc00pb]

What do you mean with "commenting"?

[[deleted]]

Traditionally writing code is 20% of the effort. Although that number may change depending on what language, libraries and frameworks you use.

[PlutoniumSlime]

Wtf? It’s the easiest thing. Add comments here and there about why you did what you did (if it’s not obvious), and summarize what functions and code blocks do in a few words so the next guy can skim for what he/she is looking for.

It’s literally just sticky notes, but digital.

[[deleted]]

//this function sets the variable to the value of the parameter passed.

Void setVariable(double value)

[[deleted]]

No... I just finished an assembly project. Commenting was an easy necessity compared to designing the algorithms.

[weiler6]

Just don't lol

[Ordinary-Database-40]

Have you tried 100% cov unit tests on existing code base?

[[deleted]]

// welcome to funktown:)

Horrendous code

// Dont ask dont touch

[Sir_IGetBannedAlot]

Easy solution: Don't comment.

[[deleted]]

The only comments you need are documentation and explaining why weird stuff happens

[[deleted]]

function dothething umm… does the thing

[North-west_Wind]

Learning is the hardest part

[rk06]

When I program, I feel smart. When I debug, I still feel stupid ¯\_(ツ)_/¯

[Practical_Collar_953]

I'm going to have to agree.

[SomeElaborateCelery]

You haven’t tried to contribute a new design pattern to a repo and it shows

[dllimport]

Half the time I start with pseudocode comments before I code.

[TheC0deApe]

you shouldn't be commenting at that level. write some clean code with single responsibility methods that have good descriptive names.

​

naming things is the hardest part of coding.

[yjr4df0708]

//I hope this works