{"id":1124,"date":"2024-10-27T20:12:51","date_gmt":"2024-10-27T14:42:51","guid":{"rendered":"https:\/\/www.mrcoder701.com\/?p=1124"},"modified":"2024-10-27T20:12:53","modified_gmt":"2024-10-27T14:42:53","slug":"12-tips-from-a-mid-level-developer","status":"publish","type":"post","link":"https:\/\/www.mrcoder701.com\/2024\/10\/27\/12-tips-from-a-mid-level-developer\/","title":{"rendered":"12 Tips from a Mid-level Developer"},"content":{"rendered":"

Tips\u00a0and\u00a0advice\u00a0for\u00a0developers<\/p>

1. Level Doesn’t Matter, Results Do<\/h2>

If you are solving people’s problems, no one asks how long you have been developing. If a subject interests you, don’t let its name deter you from learning more about it. It might be useful sooner rather than later because you never know what you’ll be asked to build.<\/p>

\n <\/path>\n<\/svg><\/div><\/div>

2. Don’t Memorize<\/h2>
\"\"<\/figure>

<\/p>

Discover how to find the information you need. I’m not talking about Stack Overflow or GenAI. Know where the specifications or documentation for the tools and languages you’re using are stored. Discover who writes the best guides.<\/p>

When using a JavaScript conditional operator, it doesn’t matter if you can’t remember which comes first (? or:). It is critical that you understand when to use a conditional operator and where to find the exact syntax.<\/p>

Tools change all the time. Verify the document version you are reading at all times. Whether it’s a newsletter or that one friend who is really interested in CSS, find a way to stay current.<\/p>

\n <\/path>\n<\/svg><\/div><\/div>

3. Go Deep on the Basics<\/h2>

<\/p>

\"\"<\/figure>

<\/p>

As someone who has worked with three different JavaScript frameworks in three years, I can tell you that learning a new tool in the ecosystem is much simpler if you understand the fundamentals. You’ll most likely write software that is more reliable and easier to use. Because you were unaware that features already existed, you won’t attempt to write them. You’ll be able to predict mistakes before you make them and comprehend the mistakes you make better.<\/p>

\n <\/path>\n<\/svg><\/div><\/div>

<\/p>

<\/a>4. Systems Thinking Will Get You Far<\/h2>

<\/p>

\"\"<\/figure>

<\/p>

Any bug must be troubleshooted using systems thinking. In the event that the toaster fails to turn on, you won’t think to check the plug in the wall. It is simpler to anticipate edge cases and create new features when one can view the system as a whole. To learn more about developing mental models for your codebase, see How to Begin in a New Codebase<\/p>

\n <\/path>\n<\/svg><\/div><\/div>

<\/p>

<\/a>5. Trying Before Asking Ensures It’ll Never Be a Stupid Question<\/h2>

<\/p>

\"\"<\/figure>

<\/p>

Typically, developers are focused on solving problems. They’ll likely want to look into why the apparent fixes didn’t work if you can demonstrate that you tried a few different approaches and they didn’t work.<\/p>

\n <\/path>\n<\/svg><\/div><\/div>

<\/p>

<\/a>6. Every Line of Code is a Liability<\/h2>

<\/p>

\"A<\/a><\/figure>

<\/p>

Write code as though it needs to be fixed by someone else. (Even if, in six months, that someone is just you.) Install packages as though you will need to update them often. To avoid later breaking something by accident, note the reason. Before integrating an opinionated tool into your system, find out how its views conflict with the features you require.<\/p>

\n <\/path>\n<\/svg><\/div><\/div>

<\/p>

<\/a>7. Practice Reading Others’ Code<\/h2>

<\/p>

\"\"<\/figure>

<\/p>

You might think that you will frequently get to create brand-new apps because of the way software development is taught. Fixing and adding features to an existing codebase is far more likely to be your task. It’s possible that you read code more often than you write it. Develop your ability to read code and refactor it without adding new errors.<\/p>

<\/p>

<\/a>8. Test, Test, and Test Again<\/h2>

<\/p>

\"\"<\/figure>

<\/p>

According to Chocho’s remarks at DevNexus 2024, “Software is practice. Code is theory.” Always test and run your code before submitting it for review. Try to write as many tests as you can. You will become a better developer by foreseeing how a user might break your code and considering options beyond the happy path.<\/p>

\n <\/path>\n<\/svg><\/div><\/div>

<\/p>

<\/a>9. Practice Turning Requirements into Software<\/h2>

<\/p>

\"\"<\/figure>

<\/p>

Ticket #387<\/p>