Every dev picks up a pile of rules early on. Write tests first. Never commit to main. Keep functions under 20 lines. DRY everything. Comment your c...
For further actions, you may consider blocking this person and/or reporting abuse
Coding by hand which is seems long long time to a best practice to make a program, right now I can vibe code near anything.
The next best practice is the UI and mouse intensive application. I moved to the terminal handler direction, so my frequently used IDE is pure VIM. I can work in my MacBookPro terminal or my 6 years old company windows11 laptop,
wsl install ubuntu|> ubuntu console ( technically windows CMD program )React |> no framework |> do not care of which programming langague are using - even I completly not familiar of them like a Go or Rust
OOP |> functional programming |> minimal functional programming
The problem with OOP is to tigh linked the data and the code. Functional programming can be unreadable very sortly like using of ramda. The big question is who would like to code by hand, I am very advice to do that at least hobby level. On your work you can use as many AI as would like to help your project.
Care about money |> My advice is: don't need to care too much, the life is important!
Mine's "make it reusable from the start."
I build the specific thing first and let it be a little messy. With Mochi, my Linux desktop pet, I got one actual pet working (its animations, moods, and little behaviors) before thinking about reuse at all.
Once it worked, I pulled the systems that had proven themselves out into their own runtime, Deskling: animation, the state machine, the event bus, movement and boundaries, dragging, scheduling. I didn't rewrite any of it from scratch. I extracted code that already worked, and by then I knew which parts deserved to be reusable because Mochi was already using them.
Where I do design for reuse now is Deskling itself, since the whole point is letting other people make pets. Community pets ship as data-only
.desklingpackages with no arbitrary code, so "reusable" there means "safe for strangers to share." That's a much more specific problem than "maybe I'll need this someday."Curious if anyone went the other way and got burned by NOT abstracting early.
Never commit to main. Working solo, a branch per change was a review step with nobody on the other side, so small changes go straight to main now, one commit each.
I still branch for anything that stays half-built for days. A paywall experiment and guest accounts both lived on their own branch until they were ready, so main stayed shippable the whole time.
100% aligned with this
I was looking at some parsing logic in a codebase for a simple custom format. I wanted to understand how it worked, so I decided to implement it myself.
I wrote my own version, found a few bugs, fixed them, and eventually got it working. It behaved exactly like the original, and I even tested it against the real code.
The original implementation used some efficient looping techniques. Mine was simpler, and it was actually the first time I had written something like that. Even though it worked, I kept doubting myself: Is my approach really as efficient as the original?
So I gave both versions to AI. It brutally told me that mine wasn't good practice.
I spent an entire day trying to prove that my version worked the same way. Finally, I asked the AI to compare both implementations line by line and loop by loop, with actual data.
In the end, they were doing the same thing.
That whole experience taught me something: sometimes, just because code looks different from an experienced developer's code doesn't mean it's less efficient.
Great Article!
I’m new to Dev.to and have recently started writing about data pipelines and AI. I’ve published a few blogs so far. If you have a moment, please take a look I’d really appreciate your feedback! 😊
Abstracting everything just because it makes the code look “cleaner,” even when the abstraction adds nothing to functionality or improves the overall developer experience.
I stopped following even 2 in fact:
Two small ground rules so this stays useful.
1) I am as general as possible.
2) I disagree with everything in your post.
-2147483648) Less talking, more raiding
One I quietly stopped following is “abstract it early so it can be reused later.”
I used to see two similar pieces of code and immediately think they should become a shared service or utility. The problem is that similar code doesn’t always mean the same concept. I’ve had cases where two API flows looked almost identical at first, then their validation and error handling started evolving differently. The shared abstraction ended up needing flags and special cases just to keep both behaviors alive.
Now I’m fine with a little duplication until I see the same rule changing for the same reason. For example, if two endpoints both calculate pricing but one is for checkout and the other is for internal reporting, I’d rather keep them separate until the domain relationship is actually proven.
For me, DRY became less about removing repeated code and more about avoiding duplicated knowledge. The abstraction should earn its place in the architecture, not get promoted because two functions happen to look alike.
"Ship it raw and grow from feedback"
"Reproduce it Locally First" A crash minidump from the customer's machine, loaded with matching symbols, usually tells me more in ten minutes than days of trying to reproduce it.
Hopefully not too much people listen best practices for AI ENGINEER with 2 months experience in this field
? I’m not an AI engineer, nor have I claimed to be one. This post is just a discussion about engineering practices people have reconsidered
Commenting what the code does. I used to put comments on nearly every block, and later found comments describing code that no longer existed. These days I mostly comment on the why, especially when there’s a workaround, a business rule, or something that looks wrong but is actually intentional. If I feel the urge to explain a line, I’d rather rename the variable.
I still add a short what-comment when the code is genuinely hard to read at a glance, though.
I ignore some parts of PEP 8. Tabs over spaces 4lyfe!
Forcing password changes every 90 days. For years, I set it up by default on every Microsoft 365 tenant I looked after, and all it really did was teach people to add a number to the end of the same password. These days I would rather enforce MFA everywhere, block known weak passwords, and only force a reset when there is a sign the account is compromised. Fewer helpdesk calls and genuinely better security.
"never use a global state object."
every tutorial screamed to use redux, zustand, or react context to avoid global mutable state.
but i code on a $150 android phone with 4gb of ram. loading those state libraries + a UI framework bloats the bundle and literally crashes my mobile browser.
so i quietly dropped the rule. my entire ai web app runs on a single global
const state = {...}object, and i just call explicitrenderMessages()functions when things change.people call it an anti-pattern. but it keeps my app at 92kb with zero npm dependencies, and it loads in 400ms on a 3g network.
sometimes the "worst" practice is the only way to survive your hardware constraints. would love to hear if anyone else broke this rule for performance reasons. 🐯
I stopped chasing 100% test coverage everywhere, now I focus tests on critical logic and edge cases where they provide the most value. Mobile home parks across the city rely on our junk removal Hemet service for sheds, carports, and worn furniture. Compact haul trucks let us fit tight lots and narrow lanes.