Recurring Engineering Thoughts I Have

I’ve been building solutions professionally for companies since 2019 and have had the fortune to be in a lot of different situations. Small teams, medium teams, big teams, internal tools, high volume e-commerce tools, SaaS tools, refactored old code, architected and built new tools, and saw the long-term outcomes. Here are recurring thoughts that I have, most garnered by doing these things the wrong way one time or another.

personal

• Write a list each day, prioritize it, break things down
• Take breaks
• For big problems, it’s usually worth it to go slow and think a lot first, I like planning on paper
• Good WLB produces better quality over the long term
• I usually build better stuff if I have a real-world hobby I am working on outside of work like guitar, woodworking, etc.
• Remove the possibility of distractions
• Control your controllables
• Dont sweat small stuff

development

• When a component reaches 400-500 lines, it’s worth considering breaking it down more
• Parent-child communication across more than 2-3 levels is usually bad, consider alternatives
• Long names that are descriptive are better than short names and worth the space
• Small commits, small functions, small AI outputs
• Consistent is better than sexy when it comes to tech stack, if the company has used a framework historically, either use that framework, or be prepared to give a good reason why you aren’t
• Wrap libraries with an interface, they change so often, some stop giving updates and become a security vulnerability. You want to change 1 place when this happens not 100
• Dont use a library unless you have to
• There is usually a good scrappy MVP solution that can iterate into whatever waterfall thing someone is requesting from above

ai code gen

• I like to use a planning mode, or develop a spec sheet in markdown to serve as context for the agent. Ill usually add ticket info, api documentation, relevant existing features in the app for reference, file names and locations, and a step-wise plan.
• Small code generation, don’t let the agent change more than you can thoughtfully review, commit when happy
• Give the agent access to code standards, but don’t generate those via AI, write them yourself
• Ask the agent for ADHD friendly responses, helps cut out the fluff
• Write code without AI sometimes

pr review

• If a comment is minor, prefix it with nit: or something similar. Let you team know they can skip those if they don’t agree. Helps the important stuff stand out.
• Refer to outside and generally accepted principles like SOLID whenever possible to justify a change request
• Develop code, make a draft PR, take a break or if end of day sign off, review with a fresh brain, then move to Ready for Review
• Write a PR description, if the feature is visible, do a couple screengrabs, share trade-offs and decisions
• Don’t mix tech debt into feature work, unless it stays within the bounds of that feature, otherwise, handle separately
• Use seperate PR’s into a parent branch for large features, github stacks are helpful.

collaboration

• Be willing to be outvoted, usually debates happen around a few good options
• Always consider that debates might be bikeshedding
• Share concerns openly
• Understand that each person you work with knows something you don’t and you can learn from them
• Maybe this is unprofessional, but I throw a good gif or meme into a document when I can
• Also, a silly short commit comment never hurt anyone, I’ve littered them across many codebases over the years, hopefully people enjoy them today when seeing the git blame
• It’s always hard, but try to pause and stop and think before responding
• If you have to write a thing and want AI proofing, paste it, then ask for spelling and clarity suggestions only, then make the changes manually so you learn something
• People usually only really read a few sentences at a time, don’t send a book, especially don’t send AI slop
• Don’t be the new person that has 100 ways to make a codebase better on day 1, unless it’s asked of you. Things are the way they are for a reason, learn those reasons, then suggest improvements later after actually getting exposure to the code.