My Coding Process

        This is the process I use to write my code. It's likely that you have a somewhat different process, but I often find it helpful to learn from others when it comes to their coding process and to take inspiration from it. So I'm presenting mine here. Here are the categories of code that I write most often and how I approach them:

Code to Execute Commands or Supply Data

  1. Look for code that serves a similar or identical purpose. It's very likely that someone has done what you are doing in the past. This person has already struggled with trial and error and will save you an enormous amount of time getting exactly the right calls to make. It's even possible they copied their code from yet another source -- in which case, they have iterated and improved upon it.
  2. When looking to use someone else's code, it's important to spend time breaking it down and understanding exactly what it does. The better you understand it, the more capable you will be when modifying it to fit your own needs. It's very likely that you will need to make modifications to its intent, as well as to its code style and how it fits into the rest of your program.

Connecting Code Within Your Own Program

        While the individual components of code are rarely unique, it becomes exponentially less likely that you will be able to find code that connects two unrelated components. I suggest taking inspiration from adjacent code in your program instead of searching in this case. Look at how other components are wired together and make something similar.

Unique Business Logic

  1. This is the code you need to spend the most time on. You are the person doing the trial and error for the first time in this case. Thus, it's very likely that you will make mistakes when working on this code. That's perfectly normal. There are ways of making this trial and error process safer. I suggest an outside-going-in approach: Write your externally facing components first. If it's possible, treat your code changes like a subsystem within the code with its own entry points and classes.
  2. Avoid piling code onto large existing classes when possible. You may need to modify existing code architecture in order to do this. This is the better outcome as it avoids mixing multiple use cases in the same classes and methods.
  3. Make sure that your data suppliers and connecting code are separate from your business logic to a reasonable extent. The more isolated your business logic, the easier it will be to read and modify.
  4. Call your API using example data with the blank methods and classes and see that all of your wrappers and entry points work before writing your core business logic. This will help isolate your code so that you can work on the core business logic and just the core business logic.
  5. Similarly, you can use test driven development in order to validate your code. When doing this, it's often good to have a very stable entry point or you will need to re-write the test every time you change that entry point.
  6. Finally, write your core business logic. This will likely be written and re-written several times before you find an ideal architecture. Try to fit within the code style that others have set before you, along with giving good documentation and method/variable names in order to make the code as readable as possible. When people are reading this code, it's likely they will have quite a bit more difficulty with it than other components because it is unique. Readability is the path to maintainability.

Comments

Post a Comment

Popular posts from this blog

Using Kanban Boards to Stay Organized and to Stay Motivated

I often work with Trello or Notion as Kanban boards. I maintain tasks for everything that I do. This helps me keep organized when I'm working on a large number of tasks, or especially if I have ideas for tasks that I am not actively working on. It creates a clear, constant document of the state of the tasks I'm working on. And more than anything, it shows to me what I've accomplished and lives on as a constant motivator for me. Why Kanban Boards Matter for You and Your Team One best practice that anyone working on a large project should adopt is to have at least one Kanban board task they're working on at any given time. Kanban boards are a visual way to track progress on tasks, enabling you to see the status of each task and its associated details. By consistently updating your tasks on a Kanban board, you'll reap several benefits: Greater personal efficiency : As you wrap up your day or put a project on hold, having detailed information on your Kanban board task h
Read more

Low Level Design Part 1: Reading and Gathering Information

Start out your document writing day 1 with a long list of open questions. As you read documents, you should slowly grow a longer and longer list of open questions. Maintain this list and keep adding to it while you write the doc. Questions are often more important than answers as they represent unknowns you need to disambiguate. You will need to ask people for most of your open questions. This is okay and most engineers are very happy to answer such questions. In general, people will feel more complimented rather than inconvenienced when their expertise is requested. If you can't find an answer to something and don't know who to ask, ask your manager or a senior engineer on your team. What if no one knows in your team? Formulate your question into something brief and meaningful and post it in your org or company-wide chat. If your question is technical, ask it as a stack overflow question and link it in the chat along with your question. Link to everything as hyperlinks in the
Read more

Low Level Design Part 3: Estimates

You should include your task breakdown and estimates in the low level design in the appendix if it's available. Design your project with the idea of disambiguating hard questions in mind. Frontload as much ambiguity in the project as possible. Changes in estimates months in advance are preferable to ones right before the deadline universally. Usually, the best way to do this is to write a thin vertical of your project first and then start fleshing out the functionality after that. If you haven't worked with a library, platform, language, etc. your estimates on that topic will have low accuracy due to unknowns. You can reduce this effect with additional reading, especially of code, or by writing code using that library yourself. Call out everything that you don't know.  Low accuracy estimates almost always take more time to complete rather than less . If you estimate a task as a week, the shortest it can be is an hour. The longest it can be is infinity. This asymmetry means
Read more