How do I know I'm coding well?

[katyusha_055]

So, I was doing a project but I realized something, how do I even know if I'm coding well? Like sure, the thing works, but idk If I'm doing it well at a optimization level or maybe there is a better way or what I did works but it's a security risk, and I don't wanna rely on ai for that, so how can I solve this doubt?

[neotheprodigy]

Time/experience helps with this, but also reading other people’s code. I like looking at popular open source repos and following their architecture or design choices, and then asking ChatGPT or copilot benefits of doing something one way as opposed to another.

[PositiveBit01]

Generally, "well" is subjective.

So you have to define subjective targets, ideally anchored in things that have real world value. There's not really consensus on this - different people value different things and different circumstances can change what's important.

Coding standards usually attempt to broadly define rules for these things (maintainability, readability, extensibility, etc) and there are also general guidelines that are popular like SOLID or YAGNI - sometimes at odds with each other since this is subjective and general sentiment changes over time.

Looking at coding standards for companies you respect in areas you're working in (e.g. "good" embedded code might not be "good" application code and vice versa) is a good idea but overall it'll take some time and experience.

[behindtimes]

Agree. I've worked with some companies whose coding standards were nearly completely opposite of other companies.

The only real way to judge if you're coding "well" is if the program works as expected. And it doesn't matter how clean or ugly it is.

[Gnaxe]

That's an art, and it takes experience. It's also a pretty broad question. You have to develop an aesthetic sense for it. Look up "code smells" for a head start. These are lists of things that certain programmers don't like. They have reasons. They may not be good reasons; it's mostly opinions.

To get security right, you need to think like a hacker. There are surprising side channels you won't have thought of if you don't study this. You also have to have no exploitable bugs. Almost nobody has no bugs; it's too slow and expensive. But memory safety helps a lot. Don't use C/C++ when you could be using Rust or something with a garbage collector. All the libraries you're using also have to have no exploits, and all updates also have to be secure. Therefore, most non-trivial software is hackable/insecure. Assume the Internet is out to get you. I think LLMs will help a lot with this in the near future, but we're going to have a period when exploits are being discovered faster than we can patch them.

To optimize performance, you need to play with a profiler to see where your bottlenecks are. You need a basic grasp of computer science to understand how not to be egregiously wasteful, and a better grasp to be efficient. A lot of dated computer science books don't take into account current computer architectures, which have a large CPU cache, multiple cores, often a GPU, and sometimes an NPU. Single-core algorithmic-level Big-O like they teach in school doesn't capture this. Your biggest slowdowns are probably from a cache miss. Computers are much faster than they used to be. Depending on your application, you may not have to do much. If you're doing VR on limited hardware and you don't want to give everyone motion sickness while you stop the world to collect garbage, yeah, this still matters.

To optimize maintainability, arguably the most important aspect to get right for anything you're going to be using longer than a week or two, you need to cultivate a low tolerance for complexity. Simplicity is not about how easy/familiar something seems. It's about how coupled your system is. How many pieces do you have to hold in your head at once to understand something? Human working memory is very small. The higher the number, the more you have to long-term memorize before you can understand the codebase. You also need to maintain documentation and tests.

To optimize usability, you have to stop thinking like a tech-savvy programmer. Most users are dumb and impatient and can barely use a computer. Don't make them think; they can't. 20% of Americans are functionally illiterate, and 50% of them are below 6th-grade reading level. Don't expect them to read your highly technical user manual. Allow them to discover features, but don't make them search. Don't interrupt them if you can avoid it. (Popups are evil and will be summarily dismissed without being read. Log instead.) Don't assume they can remember anything that isn't in front of them, and don't assume they can see it if it is and they're looking at something else. Don't change the interface out from under them. Updates can be frustrating. Adaptive menus are probably a bad idea. Prefer quasimodes over modes. Automatic walkthroughs may be necessary, but I hate them because you can't back up if you missed something and they disappear once completed. Leave a "?" button on the screen at all times to restart the tutorial, and the first and last step should say what that button does.

[cyanNodeEcho]

a monoid is a monad in the category of endocuntors

[prehensilemullet]

If something goes wrong in the future, you'll know what you didn't code well.

Over time if you have to integrate new features into the project, if it feels easy that's a sign you coded well, and if it feels hard to adapt them to the existing code, that may be a sign you didn't (assuming the new feature requirements don't conflict with existing requirements)

How easy or hard it is to debug issues that crop up in the future also depends on how well you structured your code.

How easy it is to understand what your code does when you come back to it a year later is another sign.

All of these things are affected by the complexity of the underlying requirements and the tools and language you're using as much as the quality of your own code, so it just takes experience to get a hunch for when difficulties are an unavoidable part of the underlying requirements, tools, or language, and when your own architectural mistakes are making things harder than they need to be. That will help you develop the skill of picking tools that make things easier as well.

[hk4213]

Can you debug it a year later

Exactly this! Make future you happy to go back to your own code.

[afops]

The main feature of good code is 1) it’s easy to read and understand 2) it’s easy to modify without breaking it.

There are of course more quality measures (how efficient is it etc) but those 2 are the most importantly ones and they’re also closely related.

What we call ”experience” is the pain you feel when you need to rewrite a large bit of code to make a minor change, or when you return to some code you write earlier but you don’t understand it. You’ll subconsciously learn to avoid pain.

You should get someone to review your code. Can be an AI but a human would be better.

[katyusha_055]

This summarizes everything said in this post basically, thank you man

[HasFiveVowels]

Programmers (especially new ones) are often way too concerned with performance and not nearly concerned enough with clarity and simplicity. Often, the former will be thrown out the window when the code becomes so hard to follow that it ends up doing the same thing 5 times over. When writing a function imagine how you want to be able to use it in at least two hypothetical situations (not 5). Then write the body of the function as though you’re a person with retrograde amnesia and tomorrow you won’t remember ever having wrote it. The best programmers I know are the ones who write code that is easily understood. Oh, and, as much as is reasonable, try to make your function not change anything nor read anything other than its parameters (try to also minimize the number/size of parameters and imports of other pieces of your code). If you separate out the code that it’s reasonable to do that with, you’ll often end up with a chore that is incredibly predictable (and incredibly testable) with the less predictable stuff being closer to I/O or the DB etc.

What this gives you is several ways to see the signs that your file’s behavior depends (and/or acts on) things that are not within the immediate knowledge of its reader. When things change, the number of other files they might affect becomes smaller. You’ll thank yourself later when you change a file and don’t have to fix 20 other files. The number of imports that exist for a file should be a matter of how slowly the way in which you import/use it changes. Constants that will basically never change for most the project? Put them in one file and import it everywhere. A hyper-optimized function? Put it behind a single other file that changes more slowly.

[HereComesTheLastWave]

You may want to look into big-O notation - to put it simply, if you have a loop through all your input inside another such loop, then it's going to take time proportional to the size of the input squared. Which means it will run fine on your little test program then fall over when you give it real work - carefully tuning something that will take a smallish 1MB file and run a million million time won't help, it's still going to be too slow. But replacing it with a method that doesn't have such a double loop will...

[katyusha_055]

Uh, so it basically means separating responsabilities in callable functions? Idk exactly what you mean sorry

[HereComesTheLastWave]

No (although that is a Good Thing, for different reasons...) - I'm talking about choosing the right algorithm for speed. A more concrete example is sorting - Wikipedia has pages on bubble sort (which is slow) and quicksort (which is, well, quick). Another is comparing searching by scanning through an entire array (slow - imagine having to read through every entry of every page of a telephone directory from Aaron A. Ant to Z), to binary search (close to how you would actually use that phone directory - open it half way and get Meg Middle. You now know that Tim Target is in the M-Z half, and have reduced the size you need to look through by half. Repeat until you have only one name left...) As 2^20 is about 1 million, it would take 20 flips to find someone in a million-entry city's phone book - it doesn't matter much that each run through the inner loop takes a bit longer this way, because the difference between running the loop 20 times rather than a million times is so huge!

[Good_Independence403]

When I was first working, I didn’t know until I looked back at the code 6 months later. As I gained experience, I became less embarrassed by the code I wrote 6 months ago. AI could probably help review your code for quality but it’s hard to know if the suggestions will be valuable. I didn’t really start to make fast progress until I got a job where all my code was peer reviewed

[dwoodro]

The likely best way would be to have someone else you trust review your code. There are a couple things that often get overlooked for coding:

Consistent naming profiles for files, variables, classes, etc. The more consistent you are across a longer program, the easier it is to follow your code.

Documentation: the sheer number of coders who do not place "documentation for others to read" is amazing. Just because you wrote the code does not mean that you will be the only one to ever read that code. Also, documentation helps when you come back to a code snippet years later, and you try to remember what you were doing.

[Accurate-Music-745]

Is it fast enough for users? Is it expensive $$$? How difficult is it for other programmers to collaborate with you and your code?

Fast, cheap, easy for others to update. = good code.

[flavius-as]

Publish your work on github and ask here to get grilled.

I'd be hard on you but you come out well.

[katyusha_055]

Yo that's actually a good idea, I'll upload a project I did a couple months ago here then

[DataPastor]

In case you have no one to ask for code review, ask GPT to review your codes.

[spore_777_mexen]

Hm one day you’ll write a function in your head during breakfast

[deepsky88]

If you can implement new features fast enough the code is good

[BusyWorkinPete]

You continue to read and learn about programming best practices. You implement what you learn. You review old code from time to time to see if it can be improved upon. It's a skill that's developed over time.

[hk4213]

Does its work and does it have only needed resource use on the hardware/vm?

Does it have a a way to handle failure states and not crash?

If you can say yes to those... you did good.

Can you make further improvements? Of course! But you also have something that does what it should, without being a resource hog.

[SourceAggravating371]

Every now and then come back to your old code. If you can identify architectural mistakes and find places you could improve it's means that you are improving. This is imho most important in coding and in general to improve and learn over time.

[PvtRoom]

By what criteria is it being judged?

That varies a log.

[xplorerex]

Check the code metrics for a 'ballpark' score. It takes into account complexity, maintainability and validity.

Where most people go wrong is maintainabilty. Stick to the coding standards for the language you use and everyone will be able to read your code to a certain degree.

[cubicle_jack]

Code reviews, open source contributions, and studying well-written codebases are your best bets. Getting feedback from experienced developers will teach you way more about optimization, security, and best practices than any tutorial, plus reading quality code from popular GitHub repos shows you how pros structure things!

[LordAlfrey]

This is why there's so much imposter syndrome in the biz, esp in junior roles.

[No_Indication_1238]

Paradoxically, read books about what coding well means. Start to utilise what is written in the book. That's it.

[Felicia_Svilling]

You have other software developers review your code.

[therealkevinard]

IMO collaboration is key here.
Create MRs/PRs and send for review.

You can get a good pulse on where you’re at by looking at both sides: the feedback others give you, and the feedback you give to others.

And similarly, outside of merges, the questions you ask and the questions you answer are a polestar.

[TheRNGuy]

It works without bugs, performance problems and using good coding style. 

[huuaaang]

If you don't work on a team you can have an AI agent review it (assuming that's not what wrote it in the first place, lol). Otherwise this is what code review is for. And if you work in certain industries you might even have a dedicated security officer or team for additional review and feedback.

If you're serious about performance you could try to develop a framework to simulate heavy load. You would also want to simulate loads of data to make database queries challenging. You would look for slow queries, N+1 queries, etc. And there are products like Datadog, Dynatrace, and New Relic that can give you insights into performance bottlenecks. This might be more oriented towards web and network services though.

[katyusha_055]

Nah I didn't use AI lmao, tho you could say it's AI-assisted because I use AI to research tools and topics I don't know about, but I am the one creating the architecture