In the initial years of their career, Developers often struggle with questions like where to start and what to do first to gain some grip on coding. Here are some generic and technical advice bits for professionals who are just getting started with coding.
Don’t Just Code for the Sake of It / Writing Code is Not the Only Focus
When you are a coding geek, you only want to solve some exciting puzzle with your favorite music and a good cup of hot beverage. But the scenario changes if you are taking it up as a profession. Then,it would be beneficial if you put those efforts into solving the problems that matter.
Put reasonable effort into making sure that you are solving issues that are faced by users of certain tools.
You might be surprised to know, but software development of real-world projects focuses majorly and typically on maintenance. And, when you connect this fact with the goal of user- or business-oriented outcomes, no code is often the best! and the best part is, with no code or low code tools becoming prevalent, you may not even have to write code from scratch. However, if you do, always be open to frequent feedback in the early stages instead of waiting after releasing a whole new module.
Designing Software Will Help You in the Long Run
Generally, developers think software design is only for software architects or people with similar roles and see designing and practices like tests as a distraction. You are focused on making the code work and getting things done.
However, remember that going well is the only way to go fast. That means if you make a mess, it will slow you down. Good work takes time, so focus on getting things’ right’ rather than just ‘done.’ That means you ought to learn how to write well-designed, clean code no matter the time and effort it takes.
When you start, you will be slower and tend to make mistakes, but later on, you’ll get the hang of it. Remember, making things simple and suitable is not easy!
Using Best Practices is the Key
Writing automated tests comes under best practices and is essential in most cases, even if you don’t think so right now.
If you are new to writing tests, do it for everything as in the initial phases; blindly following the best practices will prove to be a better idea than trusting your as-yet immature judgment. Once you get the grip, writing tests will become easier as you’ll be able to identify issues and understand the value they bring on an intuitive level as you see the reductions in debugging sessions. These tests will help to form the proper judgment and level up your game, not just in the test but in any area of your life.
Technical Advice for New Coders
Write Automated Tests
Yes, we covered this in generic advice, but it is also essential on a tech level. Most of the time, writing tests before the code makes it easy to verify it in a repeatable manner, which saves you from long debugging hours and manual re-testing. More importantly, tests give you the cover to re-factor your code, which is needed to keep your code clean else; the code is more likely to become useless.
Writing tests can be complex only if your code design is poor, like using inheritance for static functions or code reuse. But, with SOLID classes and no global dependencies, writing tests is easy. Avoid binding the tests to your code’s implementation details or the system structure. It’s better not to overuse mocks and focus on test doubles.
Focus on Object-Oriented Code
Write SOLID code instead of STUPID code. Understanding these principles and anti-patterns is crucial to develop the right mindset. Creating objects is the key. Don’t just create classes with only static methods; this is not called being object-oriented. It will be better to avoid static code altogether.
Be Functional
Don’t confuse functional programming with imperative structural programming, but this doesn’t mean switching entirely to the functional language. Using a functional style in your object-oriented language will prove beneficial. Prioritize not getting into a mutable state and do only one thing in your function.
Take References, Not The Whole Code
Copying the seemingly same code piece from your favorite sites is only partially helpful. Every developer learns to DRY (Don’t Repeat Yourself) sooner or later, but sadly sometimes this notion leads to casual complexity and over-engineering. This is where the opposite of DRY, WET (Write Everything Twice), comes in. The idea behind it is to de-duplicate only when there is a third occurrence of duplication.
Focus on Writing Self-Documenting Code and Avoid Comments
Comments can be deceptive because the code often changes without updating statements. New regulations are added under the comments, which might have been inaccurate in the first place. So, the comments not only become useless, they become misleading.
The types, names, and variables you write in the code must be self-explanatory of what you are doing as it becomes easy to remember, call, and use a well-defined code ahead. Even if somebody else works on your code, they know what is happening. Clean and self-explanatory code wins in the long run!
