How to write better code than ChatGPT? Part1
If you ask the same question to ChatGPT, it will give you the answer below:
ChatGPT’s answer:
“Writing better code than an AI like ChatGPT involves a combination of understanding programming principles, best practices, and creative problem-solving. Here are some tips to help you improve your coding skills:
- Understand the Problem,
- Plan Your Approach
- Write Clean and Readable Code
- Use Appropriate Data Structures and Algorithms
- Handle Edge Cases
- Refactor and Optimize
- Test Thoroughly
- Seek Feedback
- Keep Learning
- Practice, Practice, Practice
Remember, writing better code is a journey, not a destination. Keep striving for improvement, and don’t be discouraged by setbacks. With dedication and practice, you’ll continue to enhance your coding skills over time.
Great advice from ChatGPT!! AI is telling us how to write better code than itself
In this blog, we will discuss various aspects of writing better code that is scalable, maintainable, and readable and best practices and processes the developer community has gained over years of experience that ChatGPT will never be able to do.
Commandments of Good Code
What is a good code?
“good code” is code that is easily and readily maintainable by an organization (not just by its author!) and will live for longer than just the sprint it was written in.
Never settle for code that just “works.” Write superior code.
Commandment: #1 : Treat Your Code the Way You Want Others’ Code to Treat You
What distinguishes a superb engineer is that they can write maintainable code efficiently that supports a business long term and have the skill to solve problems simply and in a clear and maintainable way.
In any programming language, it is possible to write good code or bad code. Assuming we judge a programming language by how well it facilitates writing good code (it should at least be one of the top criteria, anyway), any programming language can be “good” or “bad” depending on how it is used (or abused)
Commandment #2: Good Code Is Easily Read and Understood, in Part and in Whole
Good code is easily read and understood, in part and in whole, by others (as well as by the author in the future, trying to avoid the “Did I really write that?” syndrome).
By “in part” I mean that, if I open up some module or function in the code, I should be able to understand what it does without having to also read the entire rest of the codebase. It should be as intuitive and self-documenting as possible.
- Well-encapsulated code tends to be more readable, separating concerns at every level.
Naming Variables:
A well-named variable can make the code much more intuitive, whereas a poorly-named variable can lead to headaches and confusion.
Cleverness is the enemy
- When using fancy techniques, paradigms, or operations (Ternary, Arrow functions) be careful to use them in a way that makes your code more readable, not just shorter
- Consistency in style, both in terms of how you place braces but also in terms of operations, improves readability greatly
Commandment #3: Good Code Has a Well Thought-out Layout and Architecture
The software architecture of a system represents the design decisions related to overall system structure and behavior.
- Implementation details (that is, the folder structure of your repo)
- Implementation design decisions (Do you use server side or client side rendering? Relational or non-relational databases?)
- The technologies you choose (Do you use REST or GraphQl for your API? Python with Django or Node with Express for your back end?)
- System design decisions (like is your system a monolith or is it divided into microservices?)
- Infrastructure decisions (Do you host your software on premise or on a cloud provider?) more..
Commandment #4: Good Code Doesn’t Reinvent the Wheel, It Stands on the Shoulders of Giants
Before potentially reinventing a wheel, think about how common the problem is you’re trying to solve or the function is you’re trying to perform. Somebody may have already implemented a solution you can leverage.
- Dependencies don’t come for “free” without any downside
- By using a 3rd party or open-source library that adds some interesting functionality, you are making the commitment to, and becoming dependent upon, that library
- You only need a small bit of functionality do you really want the burden of updating the whole library if you upgrade
- Do your research and analyze the tradeoff which you are ready to live with and take a call in adding any new library into the code base
- Use the libraries which are used by most of the developers which will be stable
Commandment #5: Ask Questions
Before developing software, a software engineer should ask a comprehensive set of questions to ensure they understand the project requirements, constraints, and goals.
Here are some key questions to consider:
Understanding the Problem
What problem is the software intended to solve?
Clarify the core issue that the software aims to address.
- Who are the end-users?
- What are the main objectives of the software?
Requirements Gathering
What are the functional requirements?
- Detail the features and functionalities the software must include.
What are the non-functional requirements?
- Consider performance, scalability, security, usability, and other quality attributes.
Are there any existing systems or processes that the software needs to integrate with?
- Determine interoperability requirements.
Constraints and Resources
What are the time constraints and deadlines?
- Understand the project timeline and critical milestones.
What is the budget for the project?
- Clarify financial constraints.
What technologies and tools are to be used or avoided?
- Identify technology preferences or restrictions.
Project Management
What is the project management methodology?
- Decide whether to use Agile, Scrum, Waterfall, or another approach.
What are the deliverables and milestones?
- Define what needs to be delivered and when.
What is the process for handling changes in requirements?
- Establish a change management process.
Risk Management
What are the potential risks and how can they be mitigated?
- Identify and plan for potential risks and challenges.
Design and Architecture
What will the software architecture look like?
- Outline the high-level design and architectural choices.
How will data be managed and stored?
- Consider database design, data integrity, and data security.
What are the interface requirements (UI/UX)?
- Determine user interface and experience needs.
Testing and Quality Assurance
What is the testing strategy?
- Plan for unit testing, integration testing, system testing, and user acceptance testing.
How will bugs and issues be tracked?
- Decide on a bug tracking and resolution process.
Deployment and Maintenance
What is the deployment strategy?
- Plan for deployment, including environment setup and release management.
What is the maintenance plan post-deployment?
- Establish a plan for ongoing support and maintenance.
How will user training and support be handled?
- Plan for user onboarding, documentation, and support channels.
By addressing these questions thoroughly, a software engineer can lay a solid foundation for a successful software development project, ensuring that all key aspects are considered and planned for effectively.
After the project is completed
Other questions the software developers should ask after the project is completed
“How could I have done this better and/or faster?” Post Mortem analysis of your work is one of the best ways to improve.
Did I actually follow my plan, or did I take shortcuts and make concessions?
If I started over, would I take the same approach?
Do I know that there are weak areas in the implementation? We’re these due to time constraints or did I allow myself to focus on less important areas?
Did I use the lessons learned from my last project?
Did I solve the specific problems needed, or are there areas that are over-engineered?
Did I let any aspect of my training slide? DRY, SOLID, SOA, etc.
Be honest with yourself and ask others for feedback.
Here is the part2 of this article
