Code Planning Tips for Entry-Level Developers

I'm a Software Engineer working at AWS, with over 7 years experience. The last few years of my life has taught me a lot. If I could talk to my younger self or any other junior engineer for that matter, here's what I would tell them:  [1] Learn fundamentals, not frameworks. Frameworks change quickly, but core concepts stay with you your whole career. Strong fundamentals make you adaptable, confident, and effective anywhere. [2] Design before coding. If you can’t explain your solution clearly, then the implementation will be unclear too. Draw it. Write it. Challenge it. Then build it. Good design reduces rework and gives you a direction worth building. [3] Read code, not just write it. Study the systems you work in and understand why things were built the way they are. Reading code builds real context — and context makes you faster, wiser, and more effective. [4] Write for humans first, computers second. Choose clear names, small functions, and simple logic, and follow the practices set by your team and engineers before you. Maintainable code makes everyone’s job easier. [5] Know when not to build. Not everything needs more code, sometimes the best solution is removing or reusing what already exists. Favour simplicity, avoid premature abstractions, and keep your systems lean. Code is a liability. [6] Write things down. Design docs, architecture notes, and thoughtful PR descriptions show your thinking. Writing brings clarity, and clarity helps the entire team move faster. [7] Don’t shy away from operations / devops. Many engineers avoid this work, but understanding how your code runs in production is one of the most important parts of the job — build it, own it, run it. It leads to safer judgement. [8] Become great at debugging. Most engineers can build features, but not many fewer can fix issues under pressure. Learn how to troubleshoot calmly using logs, tracing and systematic problem solving. [9] Own your career path. If you’re in a job that doesn’t help you grow, work with your manager to change that. If things still don’t improve, find a place that supports your goals. Your career is yours to steer. [10] Communicate clearly and earn trust. Be honest about what you know and what you don’t. Listen carefully, share progress early, and follow through on what you promise. [11] Keep pushing yourself and don’t give up too quickly. There will be tough days and difficult problems. Stay patient, and keep pushing through. Growth often happens right after things start feeling uncomfortable. Resources to level up as software engineer: → The Pragmatic Engineer with Gergely Orosz for industry insights. → System Design One by Neo Kim for system design fundamentals. → Coding Challenges with John Crickett for real world project ideas. → Connect with engineers like Anton Martyniuk, saed, Alexandre Zajac, Demitri Swan, Sanchit Narula, Daniel and Mohamed A. for daily engineering wisdom. #softwareengineering

If you're a junior engineer, here's advice that took me 6+ years to learn the hard way. These lessons won’t just make you better at coding — they'll make you someone every team wants to work with. 1 Code is a liability, not an asset. Every line you write is something the team has to understand, test, and maintain. Writing less—but clearer—code is the true superpower. 2 Start by solving problems, not by choosing tools. Frameworks come and go. What doesn’t change is understanding the actual problem, user pain, and business need. Let that guide your stack, not trends. 3 The easiest way to gain trust on a team is to be reliable. Not the smartest, not the fastest—just the person who consistently delivers what they commit to, communicates well, and makes others’ work easier. 4 Logs are your second monitor. Well-structured, searchable logs will save you in ways you can't imagine—especially at 2AM when a random service breaks and no one knows why. 5 Comments are like tattoos—don’t write them unless you’ll be proud of them a year from now. Write self-explanatory code instead. When you must comment, make it count: why, not what. 6 The cost of abstraction is paid in bugs. If you can't explain how the abstraction works under the hood, it will bite you when things break. Always understand the layer beneath you. 7 Testing isn't optional once real users depend on your system. Even a flaky test today is better than realizing next week that your feature silently broke production. 8 Learn to read code like a detective, not just write it like an author. Most of your career will be spent reading code you didn’t write. Practice understanding systems fast—it’s a superpower few prioritize. 9 Production is where the real learning begins. You’ll never know how good your code really is until it faces real traffic, edge cases, and failures. Treat production like a mentor, not just an environment. 10 Be curious about the “boring” stuff. Things like DNS, HTTP headers, caching layers, file descriptors—they seem dull until they cause real-world fires. Then they’re everything. 11 The best engineers aren’t heroes. They’re builders of systems, habits, and tools that prevent the need for heroics in the first place. Good engineers write code that works. Great engineers build systems that keep working—even when they’re not watching. Let me know which of these hits hardest for you. 👇

Imagine you’ve just been hired as an SWE and deployed to one of the core teams in the company. You access the codebase and find millions of lines of code & your manager assigns you a task to make changes. Now, as a new hire, you’re scared…..(I would be too) Here’s what I’ve learned from my experience when dealing with a new codebase: 1/ Connect with Tenured Engineers   Leverage 1:1s with experienced engineers to clarify broader or specific questions about the codebase and services. 2/ Add Simple Telemetry   Implement basic telemetry to gain insights into the service's performance and behavior. 3/ Start with Bug Fixes   Engage in small bug fixes to familiarize yourself with different parts of the codebase and improve problem-solving skills. 4/ Understand the Workflow   Gain a high-level understanding of what the service does and its interactions within the system. 5/ Identify Dependencies   Know what the service depends on and how these dependencies affect its functionality. 6/ Review Service KPIs   Examine the service dashboard to understand its key performance indicators and how they measure success. 7/ Explore Architecture Documents   Go through architecture and design documents to understand the service's structure and design decisions. 8/ Watch Past Sessions   Review previous sessions on the codebase to get a sense of historical decisions and common issues. 9/ Debug with Integration Tests   Use integration tests to debug the codebase, helping you see how components work together. 10/ Review Code Reviews   Study code reviews from other engineers to learn best practices and common pitfalls in the codebase. 11/ Embrace Ambiguity   Accept that you won't know everything in a large codebase and focus on the most crucial parts first. 12/ Navigate Regularly   Dive into new parts of the codebase regularly to build familiarity and confidence over time. 13/ Use Bug Fixing as Learning   View bug fixing as an opportunity to explore different codebase interactions and expand your understanding. 14/ Trust the Code   Rely on the actual code over documentation, as it provides the most accurate and up-to-date information. 15/ Check Git History   If you are confused about a component, review its git history to understand its recent changes and interactions with other parts. There is no specific way of dealing with a new codebase; it’s challenging, but these tips can help refine your approach. What would you add from your experience?

I am an Engineering Manager working at Google with almost 20 years of experience. If I could sit down with a Jr. Software Engineer, here are 11 good pieces of advice I would tell them that I learned through my experiences… 1// If your app only serves around 10 users, a single server and a basic REST API will do the job. But if you’re handling 10 million requests a day, you need to start thinking about load balancers, autoscaling, and rate limiting. 2// If only one developer is building features, you can skip the ceremonies and just ship and test manually. But if you have 10 developers pushing code daily, it’s time to invest in CI/CD pipelines, multiple testing layers, and feature flags. 3// If a bit of downtime just breaks a single page, adding a banner and moving on is usually enough. But if downtime kills a key business flow, redundancy, health checks, and graceful fallbacks are absolutely necessary. 4// If you’re just consuming APIs, make sure you know how to handle errors like 400s and 500s. If you’re building APIs for others, you need to version them, document everything, test thoroughly, and set up proper monitoring. 5// If your product can tolerate a few seconds of lag, always pick code clarity over squeezing out a little more performance. But if users are waiting on every click, profiling, caching, and edge delivery need to become a part of your daily work. 6// If your data easily fits in RAM, keep things simple and store it in memory using maps. But if your data spans terabytes, you have to start thinking about indexing, partitioning, and optimizing for disk access patterns. 7// If you’re coding alone, poor naming might just annoy you. But in a growing team, bad names become a ticking time bomb for everyone. 8// If you’re only fixing bugs once a week, basic logs and console prints are probably enough. But when you’re running production systems, you need structured logs, tracing, real-time alerts, and dashboards. 9// If you’re up against tight deadlines, write the simplest code that gets things working. But if the code is meant to last, focus on readability, thorough testing, and making it easy to change in the future. 10// If you’re working alone, “it works on my machine” might be good enough. But in a real team, reproducible builds and shared development setups are the bare minimum. 11// If your app is new, move fast and don’t worry too much about cleaning up right away. But once your app is stuck in maintenance hell, you’ll pay the price for every rushed decision you made in the past. People think software engineering is just about building things. It’s really about: – Knowing when not to build – Being okay with deleting good code – Balancing tradeoffs without always having all the data The best engineers don’t just ship fast. They build systems that are safe to move fast on top of.

The best advice I got as a junior engineer: 1. Make it work: In the initial stages, focus on creating a functional solution. Prioritise getting the core functionality up and running to establish a baseline. 2. Then make it right: Once the basic functionality is achieved, shift your focus to refining the code. Clean up your implementation, improve code structure, and adhere to best practices for better maintainability. 3. Then make it fast & pretty: After achieving functionality and code cleanliness, work on optimizing performance and enhancing the user interface. Ensure that the software runs efficiently and has a polished, user-friendly design. 4. Embrace Continuous Learning: Stay curious and committed to ongoing learning. Keep abreast of new technologies, tools, and methodologies to stay relevant and enhance your skills throughout your career. 5. Seek Feedback and Collaboration: Actively seek feedback from peers and experienced colleagues to improve your skills. Foster a collaborative environment that encourages open communication, leading to innovative solutions and a stronger team dynamic. 6. Prioritize Documentation: Document your code, processes, and decisions clearly. This not only aids in understanding your work later on but also helps team members comprehend and maintain the code, contributing to an efficient workflow. 7. Understand the Business Context: Go beyond technical skills and strive to understand the broader business context. Align your technical efforts with organizational goals to make your contributions more impactful and meaningful. 8. Practice Problem-Solving: Develop a problem-solving mindset by breaking down complex issues into manageable components. This approach not only makes problem-solving feasible but also helps in identifying root causes and fosters resilience in the face of technical challenges. 9. Prioritize Security and Reliability: Emphasize security and reliability in your work. Write secure code, ensure robustness in solutions, and prioritize testing to create software that not only functions well but is also resilient to potential vulnerabilities and failures. Remember, a well-rounded set of skills and attitudes will not only make you a proficient engineer but also contribute to a positive and productive work environment.

I once looked at my early startup’s codebase and realised something uncomfortable… It wasn’t code. It was panic-driven typing disguised as progress. If you’ve ever hacked your way through a product deadline, you know this feeling. You move fast. You tape things together faster. And suddenly the whole system feels like a fragile Jenga tower held together by hope and coffee. The 6 rules I wish I had learned earlier, the ones that stop you from cleaning up your own chaos later. 1. Separation of Concerns When one function tries to do everything, it ends up doing nothing well. It’s like getting stock tips, relationship advice, and fitness routines from the same friend. Split responsibilities. Clean code starts with clean boundaries. 2. Document Your Code A comment today is a gift to your future self. Because your future self will have zero memory of the clever thing you wrote at 2am. Don’t make debugging a crime scene investigation. 3. Don’t Repeat Yourself (DRY) Copy-paste feels fast. It’s not. Every duplicate is a future bug waiting for its moment. Write once. Reuse everywhere. Let functions do the heavy lifting. 4. Keep It Simple Complex code looks impressive, until you’re the one maintaining it. The real flex is clarity. Readable > clever. Understandable > magical. 5. Test Driven Development (TDD) TDD is like writing the exam before studying. The test fails → you add logic → the test passes → you clean up. It forces discipline. It prevents surprises. It builds confidence you can’t get from vibes and manual testing alone. 6. YAGNI (You Ain’t Gonna Need It) Founders love planning for the future version of the product. Except most of those imagined features never ship. Focus on what users need now. Earn the right to build more later. So, treat your codebase like a campsite: Leave it cleaner than you found it. Your team and your roadmap will thank you. P.S. What’s the most chaotic codebase sin you’ve ever seen… that still haunts you to this day?

Best Practices for Writing Clean and Maintainable Code One of the worst headaches is trying to understand and work with poorly written code, especially when the logic isn’t clear. Writing clean, maintainable, and testable code—and adhering to design patterns and principles—is a must in today’s fast-paced development environment. Here are a few strategies to help you achieve this: 1. Choose Meaningful Names: Opt for descriptive names for your variables, functions, and classes to make your code more intuitive and accessible. 2. Maintain Consistent Naming Conventions: Stick to a uniform naming style (camelCase, snake_case, etc.) across your project for consistency and clarity. 3. Embrace Modularity: Break down complex tasks into smaller, reusable modules or functions. This makes both debugging and testing more manageable. 4. Comment and Document Wisely: Even if your code is clear, thoughtful comments and documentation can provide helpful context, especially for new team members. 5. Simplicity Over Complexity: Keep your code straightforward to enhance readability and reduce the likelihood of bugs. 6. Leverage Version Control: Utilize tools like Git to manage changes, collaborate seamlessly, and maintain a history of your code. 7. Refactor Regularly: Continuously review and refine your code to remove redundancies and improve structure without altering functionality. 8. Follow SOLID Principles & Design Patterns: Applying SOLID principles and well-established design patterns ensures your code is scalable, adaptable, and easy to extend over time. 9. Test Your Code: Write unit and integration tests to ensure reliability and make future maintenance easier. Incorporating these tips into your development routine will lead to code that’s easier to understand, collaborate on, and improve. #CleanCode #SoftwareEngineering #CodingBestPractices #CodeQuality #DevTips

Master these strategies to write clean, reusable code across all data roles. Here is how you keep your code clean, efficient, and adaptable:  1. 𝗠𝗼𝗱𝘂𝗹𝗮𝗿 𝗗𝗲𝘀𝗶𝗴𝗻: Break down your code into distinct functions that handle individual tasks. This modular approach allows you to reuse functions across different projects and makes debugging far easier.       2. 𝗗𝗼𝗰𝘂𝗺𝗲𝗻𝘁𝗮𝘁𝗶𝗼𝗻: Comment your code clearly and provide README files for larger projects. Explain what your functions do, the inputs they accept, and the expected outputs. This makes onboarding new team members smoother and helps your future self understand the logic quickly.       3. 𝗣𝗮𝗿𝗮𝗺𝗲𝘁𝗲𝗿𝗶𝘇𝗮𝘁𝗶𝗼𝗻: Use parameters for values that could change over time, such as file paths, column names, or thresholds. This flexibility ensures that your code is adaptable without requiring major rewrites.       4. 𝗜𝗻𝘁𝗲𝗻𝘁𝗶𝗼𝗻𝗮𝗹 𝗡𝗮𝗺𝗶𝗻𝗴: Variable, function, and class names are your first layer of documentation. Make them descriptive and consistent.       5. 𝗖𝗼𝗻𝘀𝗶𝘀𝘁𝗲𝗻𝘁 𝗦𝘁𝘆𝗹𝗲: Adopt a coding standard and stick to it. Whether it’s the way you format loops or how you organize modules, consistency makes your code predictable and easier to follow.       6. 𝗘𝗿𝗿𝗼𝗿 𝗛𝗮𝗻𝗱𝗹𝗶𝗻𝗴: Include error handling in your functions. Use try-except blocks to catch exceptions, and provide informative messages that indicate what went wrong and how to fix it.       7. 𝗧𝗲𝘀𝘁𝗶𝗻𝗴: Implement unit tests to verify that each function performs as expected. This proactive approach helps identify issues early and ensures that changes don’t introduce new bugs.       8. 𝗩𝗲𝗿𝘀𝗶𝗼𝗻 𝗖𝗼𝗻𝘁𝗿𝗼𝗹: Use Git or another version control system to manage changes to your code. It allows you to track progress, roll back mistakes, and collaborate seamlessly.       9. 𝗖𝗼𝗱𝗲 𝗥𝗲𝘃𝗶𝗲𝘄𝘀: Encourage peer reviews to catch potential issues, share best practices, and foster a culture of collaborative learning.      10. 𝗥𝗲𝘃𝗶𝗲𝘄 𝗮𝗻𝗱 𝗥𝗲𝗳𝗮𝗰𝘁𝗼𝗿: Review your code after a break, seeking opportunities to simplify and improve. Refactoring is your path to more robust and efficient code.   Whether writing small SQL queries or building large Python models, a clean coding style will make you a more efficient analyst. It’s an investment that will pay off in productivity and reliability. What’s your top tip for writing reusable code? ---------------- ♻️ Share if you find this post useful ➕ Follow for more daily insights on how to grow your career in the data field #dataanalytics #datascience #python #cleancode #productivity

Software Design Principles Great software isn't just about making things work, it's about creating systems that are maintainable, scalable, and resilient. These fundamental design principles guide developers toward writing better code. 1./ 𝐊𝐈𝐒𝐒 (𝐊𝐞𝐞𝐩 𝐈𝐭 𝐒𝐢𝐦𝐩𝐥𝐞, 𝐒𝐭𝐮𝐩𝐢𝐝) ➟ The most elegant solutions are often the simplest. ➟ Avoid unnecessary complexity, keep code clear and concise, and focus on essential features. Remember that code is read far more often than it's written. 2./ 𝐃𝐑𝐘 (𝐃𝐨𝐧'𝐭 𝐑𝐞𝐩𝐞𝐚𝐭 𝐘𝐨𝐮𝐫𝐬𝐞𝐥𝐟) ➟ Every piece of knowledge in a system should have a single, unambiguous representation. 3./ 𝐘𝐀𝐆𝐍𝐈 (𝐘𝐨𝐮 𝐀𝐢𝐧'𝐭 𝐆𝐨𝐧𝐧𝐚 𝐍𝐞𝐞𝐝 𝐈𝐭) ➟ Resist implementing features "just in case." ➟ Build what's needed today. 4./ 𝐒𝐎𝐋𝐈𝐃 𝐏𝐫𝐢𝐧𝐜𝐢𝐩𝐥𝐞𝐬 the backbone of object-oriented design: ➟ Single Responsibility - Classes should do one thing well ➟ Open/Closed - Open for extension, closed for modification ➟ Liskov Substitution - Subtypes must be substitutable for their base types ➟ Interface Segregation - Many specific interfaces beat one general interface ➟ Dependency Inversion - Depend on abstractions, not concrete implementations 5./ 𝐏𝐫𝐢𝐧𝐜𝐢𝐩𝐥𝐞 𝐨𝐟 𝐋𝐞𝐚𝐬𝐭 𝐀𝐬𝐭𝐨𝐧𝐢𝐬𝐡𝐦𝐞𝐧𝐭 ➟ Software should behave as users expect. ➟ Consistency in terminology, conventions, and error messages creates intuitive experiences. 6./ 𝐏𝐫𝐢𝐧𝐜𝐢𝐩𝐥𝐞 𝐨𝐟 𝐌𝐨𝐝𝐮𝐥𝐚𝐫𝐢𝐭𝐲 ➟ Well-defined, independent modules make systems easier to understand, maintain, and test. 7./ 𝐏𝐫𝐢𝐧𝐜𝐢𝐩𝐥𝐞 𝐨𝐟 𝐀𝐛𝐬𝐭𝐫𝐚𝐜𝐭𝐢𝐨𝐧 ➟ Hide implementation details to reduce cognitive load. ➟ Users of your code shouldn't need to know how it works internally, just how to use it. 8./ 𝐏𝐫𝐢𝐧𝐜𝐢𝐩𝐥𝐞 𝐨𝐟 𝐄𝐧𝐜𝐚𝐩𝐬𝐮𝐥𝐚𝐭𝐢𝐨𝐧 ➟ Protect the internal state of objects from external manipulation. ➟ This creates more robust systems by preventing unexpected side effects. 9./ 𝐏𝐫𝐢𝐧𝐜𝐢𝐩𝐥𝐞 𝐨𝐟 𝐋𝐞𝐚𝐬𝐭 𝐊𝐧𝐨𝐰𝐥𝐞𝐝𝐠𝐞 (𝐋𝐚𝐰 𝐨𝐟 𝐃𝐞𝐦𝐞𝐭𝐞𝐫) ➟ Components should have limited knowledge of other components. ➟ This "need-to-know basis" approach creates more modular, flexible systems. 10./ 𝐋𝐨𝐰 𝐂𝐨𝐮𝐩𝐥𝐢𝐧𝐠 & 𝐇𝐢𝐠𝐡 𝐂𝐨𝐡𝐞𝐬𝐢𝐨𝐧 ➟ Minimize dependencies between modules while ensuring each module has a clear, unified purpose. ➟ This balance makes systems more maintainable and adaptable. You’d probably agree, It's easy to nod along with design principles when reading them, but much harder to catch when drifting away from them in real code. That's where tools like CodeRabbit can be valuable. During pull requests, it identifies potential issues that developers might overlook, such as unnecessary complexity or signs of tight coupling, without being intrusive or slowing down the development process. Understand, these tools don't replace human judgment but provide an additional layer of verification that can help maintain code quality over time.👊 coderabbit.ai

𝗧𝗵𝗲 𝗛𝗶𝗱𝗱𝗲𝗻 𝗞𝗲𝘆 𝘁𝗼 𝗪𝗿𝗶𝘁𝗶𝗻𝗴 𝗖𝗼𝗱𝗲 𝗧𝗵𝗮𝘁 𝗟𝗮𝘀𝘁𝘀 - 𝗔𝗿𝗲 𝗬𝗼𝘂 𝗨𝘀𝗶𝗻𝗴 𝗦𝗢𝗟𝗜𝗗 𝗣𝗿𝗶𝗻𝗰𝗶𝗽𝗹𝗲𝘀? Picture this. Six months after you proudly ship your app, a single feature request lands on your desk. You make the change, and suddenly five unrelated parts of the code break. Deadlines slip. Frustration builds. Confidence drops. This is what technical debt feels like. Silent at first, painful later. The good news? Most of it can be prevented by mastering five timeless rules that the best developers swear by. 𝗧𝗵𝗲 𝟱 𝗦𝗢𝗟𝗜𝗗 𝗥𝘂𝗹𝗲𝘀 𝗳𝗼𝗿 𝗖𝗼𝗱𝗲 𝗧𝗵𝗮𝘁 𝗦𝗰𝗮𝗹𝗲𝘀 𝟭. 𝗦𝗶𝗻𝗴𝗹𝗲 𝗥𝗲𝘀𝗽𝗼𝗻𝘀𝗶𝗯𝗶𝗹𝗶𝘁𝘆 𝗣𝗿𝗶𝗻𝗰𝗶𝗽𝗹𝗲 (𝗦𝗥𝗣) A class should focus on one purpose and do it exceptionally well. Example: A UserManager manages users. It should not handle payment processing. Clean separation makes testing easier and debugging faster. 𝟮. 𝗢𝗽𝗲𝗻/𝗖𝗹𝗼𝘀𝗲𝗱 𝗣𝗿𝗶𝗻𝗰𝗶𝗽𝗹𝗲 (𝗢𝗖𝗣) Your code should be open for adding new features but closed for rewriting existing functionality. When you design for extension instead of modification, you build systems that grow without breaking what already works. 𝟯. 𝗟𝗶𝘀𝗸𝗼𝘃 𝗦𝘂𝗯𝘀𝘁𝗶𝘁𝘂𝘁𝗶𝗼𝗻 𝗣𝗿𝗶𝗻𝗰𝗶𝗽𝗹𝗲 (𝗟𝗦𝗣) Subclasses must work anywhere their parent classes are used. Example: A Square that inherits from Rectangle often fails because changing the width should also change the height, which breaks the expected behavior of a Rectangle. Getting this wrong leads to subtle and frustrating bugs. 𝟰. 𝗜𝗻𝘁𝗲𝗿𝗳𝗮𝗰𝗲 𝗦𝗲𝗴𝗿𝗲𝗴𝗮𝘁𝗶𝗼𝗻 𝗣𝗿𝗶𝗻𝗰𝗶𝗽𝗹𝗲 (𝗜𝗦𝗣) Clients should never be forced to implement methods they do not need. Think about utensils. If all you need is a spoon, a spork will only get in the way. Keep interfaces small, focused, and purpose-driven. 𝟱. 𝗗𝗲𝗽𝗲𝗻𝗱𝗲𝗻𝗰𝘆 𝗜𝗻𝘃𝗲𝗿𝘀𝗶𝗼𝗻 𝗣𝗿𝗶𝗻𝗰𝗶𝗽𝗹𝗲 (𝗗𝗜𝗣) Code should depend on abstractions, not on specific implementations. By programming to interfaces rather than concrete classes, you gain flexibility. Swapping a database, email provider, or third-party API becomes painless and predictable. 𝗙𝗶𝗻𝗮𝗹 𝗧𝗵𝗼𝘂𝗴𝗵𝘁: Bad code does not happen overnight. It happens by design, or rather, by the lack of it. SOLID principles are more than theory. They are your blueprint for software that is easier to maintain, extend, and scale. Do not just learn these principles. Internalize them. Live them. follow Umair Ahmad for more insights