Remix.run Logo
s_Hogg 3 days ago

You need to be twice as smart to debug code as you need to be to write it. So if you write the smartest code you can, then you by definition are too dumb to debug it

Just write simple code

tracker1 3 days ago | parent | next [-]

I hold KISS above most "Enterprise Patterns" with YAGNI as a close second. I think abstractions should be used to reduce complexity with code as opposed to making it harder to reason about. If a pattern increases complexity in understanding, then it should make sense in more cases than not.

I'm also a fan of feature-oriented project structures. I want the unit test file in or next to the code it's testing. For UI projects, similar with React it's about the component or feature not the type of thing. For APIs I will put request handlers with the feature along with models and other abstractions that go together based on what they fulfill, not the type of class they are.

I consider this practice more intuitively discoverable. You go into a directory for "Users" and you will see functionality related to users... this can be profile crud or the endpoint handlers. Security may or may not be a different feature depending on how you grow your app (Users, Roles, Permissions, etc). For that matter, I'd more often rather curate a single app that does what it needs vs. dozens of apps in a singular larger project. I've seen .Net web projects strewn across 60+ applications in two different solutions before. It took literally weeks to do what should take half a day at most.

All for one website/app to get published. WHY?!? I'm not opposed to smaller/micro services where they make sense either. But keep it all as simple as you possibly can. Try to make what you create/use/consume/produce as simple as you can too. Can you easily use/consume/interact with what you make from a system in $NewLanguage without too much headache? I don't like to have to rely on special libraries being available everywhere.

flykespice 3 days ago | parent | prev | next [-]

This resonates so much with my upbringing.

When I was a kid learning programming, I would skim through the whole book teaching Python and type the code using as much keywords as I learned each day, just to boast on my parents and my non-programmers peers about the obfuscated mess that came after.

As I grew I started to contribute to other open-source projects and I came across every kind of unmaitanable spaghetti code, so that I just gave up contribuiting on said project, that is when I gained the consciousness about being zealous on keeping the code as simple as possible so that the next person who comes after me to change the code don't have as much trouble understanding the code, even myself when I revisit the code later.

That altruistic mindset about caring how others read your code, you don't acquire easily unless you get experience how your previous peers did feel.

vjvjvjvjghv 3 days ago | parent | prev | next [-]

“Just” writing simple code is not well defined. Sometimes it’s about avoiding abstractions, sometimes it’s about creating the right abstractions.

I guess it’s best to take a look at the code once something works and then see if it can be simplified. A lot of people seem to skip that step.

thomasikzelf 3 days ago | parent | prev | next [-]

Writing simple code is also much harder then writing complicated code. If you write some complicated code at the limit of your mental capabilities you can not debug it, but you might also not be smart enough to write the simple code.

I guess this means that one should solve the appropriate problems for a given skill level

api 3 days ago | parent [-]

My #1 belief about engineering, and one I harp on constantly, is that simplicity is harder than complexity.

I use it as a heuristic. If my work is getting more complex, it's a warning sign that I might be doing something wrong or using the wrong approach. If it's getting simpler it means I might be headed in the right direction.

rottc0dd 2 days ago | parent | prev | next [-]

Good ol' Kernighan strikes again [0]

[0] - https://www.laws-of-software.com/laws/kernighan/

Ferret7446 3 days ago | parent | prev | next [-]

This is not just about writing code, but designing systems. If you design the smartest (most complex) system you can, you won't be able to debug/fix/extend/maintain it.

lukan 3 days ago | parent | prev | next [-]

Thank you, I will be using this.

Not sure if there is actually data for the assumption to be twice as smart to debug than to write code, but it sounds about right.

And also, if you write the smartest code you can, while you are at your peak, you also won't be able to read it, when you are just a bit tired.

So yes, yes, yes. Just write simple code.

(I also was also initially messed up a bit by teachers filling me up with the idea to aim for clever code)

EGreg 3 days ago | parent | prev | next [-]

what exactly is "the smartest code you can" :)

brudgers 3 days ago | parent | next [-]

Actual quote:

Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?

OnionBlender 3 days ago | parent [-]

Known as Kernighan's Law.

flykespice 3 days ago | parent | prev | next [-]

I guess this https://www.ioccc.org/

havefunbesafe 3 days ago | parent | prev [-]

In this case, it sounds like "The code that will most impress your parents"

draw_down 2 days ago | parent | prev [-]

[dead]