It is challenging to write code from scratch. Coming back after a few weeks or months to make changes is even more difficult. As a junior software engineer, I've realized that software engineering (SWE) entails more than coding. There are numerous factors to consider when developing software.

My time as an SWE student at ALX has been both challenging and rewarding. I've learned a great deal about clean code, code structure, and modularization.

These lessons came from my own experience as an SWE student working on projects. Tasks are assigned to projects. Each task has a clear set of requirements, rules, and interfaces(s). When you begin a project, you begin with the easiest task and gradually increase in difficulty as you proceed from one task to the next. During my onboarding days, I would jump in right away to solve problems I did not have a thorough understanding of or a reasonable thought process for. Despite the fact that I accomplished the task, the consequence is code that is very tough to modify. As I advance to the following tasks, I begin to question my own thought process, wondering if I actually wrote the code myself. This is due to the fact that implementing this new task and/or making changes to previous work would necessitate redoing the project from scratch, which would be extremely time-consuming, especially given the efforts I've put into writing the initial implementation. This continued to be my everyday nightmare until I learned to "think before I start". When I worked hard to write good, clean code, not only did I complete projects on time, but my life became much easier. But how did I accomplish this?

I used to think that coding just involved creating spaghetti (poorly organized) code or swiftly typing as depicted in science-fiction movies. There is more. As an illustration, consider a person who constructs buildings. This person would first create a plan and gather the necessary materials and tools before beginning to lay the foundations. A professional would consider potential failures and exceptional instances while carrying out his task. This could include asking the following questions: If the house's maximum load is 500 kg, what happens when it is more? Would the house be able to endure a flood or large wind wave? as well as others? This is the stage of preparation. When the builder begins constructing the foundations or the house is completed, the criteria may change based on the client's demands. This is where the designer's flexibility is put to the test. If reducing the number of doors necessitates creating a new foundation, then this is a terrible design

This is no different from creating software. A developer uses the "building" analogy described above to create excellent, maintainable code. First, you analyze the problem, choose appropriate tools and resources for the task, and develop a feasible solution. At this point, you considered edge situations that, if not addressed, might represent a hazard or failure. Likewise, plan ahead. What happens when your program has to be changed? if altering the implementation of a single function will render the entire program unusable, then this is not a good design. An excellent design must be flexible/orthogonal (components should be self-contained: independent, and have a single, well-defined purpose). When orthogonality is used in your system, you may make changes to a component without worrying about the other parts

You'd agree that around 60% of the time spent producing software or anything valuable ends up in the preparation stage. If this stage is followed by a sensible thought process, it will save time and minimize future difficulties associated with software development. this comes to mind the well-known adage "Solve the problem, then write the code"

While it's true that practice makes perfect, you can also use a variety of resources to improve your ability to write good, maintainable code. The book, The Pragmatic Programmer: Your Journey to Mastery by David Thomas and Andrew, taught me a lot. This book teaches a variety of ideas, including the one discussed, in great depth. It's something I advise junior software developers to read if they want to get better at developing well-maintained code