Skip to content

HadeelDaragmeh158/my-notes.

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

2 Commits
 
 

Repository files navigation

my-notes

Hello

my name is Hadeel, I am graduated from University of Jordan ! [my linkedin] (https://www.linkedin.com/in/hadeel-daragmeh-524727206)

I learned about somthings like :

  1. Unity
  2. Javafx
  3. Php And so on...

I love learning so much, i feel it's a good way to unload energies and gain skills in a perfect way And that it😉

study hard

" Learn the fundamentals of a good developer mindset "

these ore the steps mentioned in the article, and each one is explained in detail:

  1. Conceiving The Purpose of Software
  2. The Goals of Software Design
  3. (Mis)understanding
  4. Simplicity
  5. Complexity
  6. Maintenance
  7. Consistency
  8. Prioritizing
  9. Solving Problems
  10. Good enough is fine
  11. Predictions
  12. Assumptions
  13. Stop Reinventing
  14. Resistance
  15. Automation.
  16. Code measurement
  17. Productivity
  18. Testing
  19. (Under)Estimation
  20. Running Away From Rewriting
  21. Documentation and Commenting
  22. Picking Technologies (Tools, Libraries, etc.)
  23. Self-Development
  24. Don’t be a hero
  25. Don’t Ask Questions… Ask For Help.

Your design should be easy for you and helpful for others..

Bad developers don’t understand what they are doing, and good developers do. It really is that simple

A “good developer” is doing everything in their power to make the code as simple as possible for other programmers.

Controlling complexity

First,

you will exactly know your software purpose and its definition. Second, you will be as simple as possible in every piece of code you write. Third, when a new feature or change request comes to the discussion table, you will evaluate them based on your software purpose and question them.

Your main purpose is to control complexity, not to create it.

effort of maintenance than it is to reduce the effort of implementation.

The desirability of any change is directly proportional to the value of the change and inversely proportional to the effort involved in making the change.

Think before acting.

dividing. Don’t try to solve one big problem. When you look at the problem as a whole, it can scare you. Divide it into smaller tasks and solve each sub-problem one by one. Once you solve each sub-problem, you connect the dots.

Don’t predict to future. Be only as generic as you know you need to be right now.

Code should be designed based on what you know now, not on what you think will happen in the future. 

Don’t reinvent the wheel. Always resist adding more code, more features until you are convinced that they are required and there is a need to implement them. Because unnecessary changes will increase defects in your software. If you can automate it, automate it. The optimum code is a small bunch of code that is easy to understand, easy to read.

  • When you have a bug, first you should reproduce it. You shouldn’t guess the source of the bug and apply fixes based on your assumption. Most probably, you will be wrong. You should see it with your own eyes before applying the fix.

Break the big thing into smaller things. The smaller it is, the easier it is to estimate.

You’re probably still going to get it wrong, but you’ll be a lot less wrong than if you estimated a big project. *

  • When you can’t make the code simpler then you should add the comment to explain this complexity.

Keep learning

When you have tried everything, and preferably after you have a working solution, now is the best time to seek advice. Look to peers and senior developers to review your code.

you can read the article from this link
klick here

you are the best

About

No description, website, or topics provided.

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published