Junior developer (for purposes of this post) is a developer with < 2 years experience programming in industry who have an interest in sharpening their technical skills.
1. Read other people’s code
Perhaps the best way to enhance your technical ability is to directly read other people’s code. Github is a fantastic resource; and it’s even better if you have an all star developer already within your work environment that you can bounce questions off of. Here are two things I think are particularly valuable:
Focus on naming conventions; good programmers define variables with names that enhance the readability of the code and also provide intent, but also don’t couple the variable name to a certain data structure type.
Try to load the whole system into your head and understand it. Notice how the various components are decoupled, design patterns, and also how they have spelled out their unit tests. Holding well designed systems in your head is very much like visualization within athletics. Visualizing yourself in a certain athletic situation or doing a specific technique correctly has been linked to improved performance. Do it for coding too.
2. Plan things out
Before you ever start coding you should sit down with a whiteboard or pen and paper. These drawings don’t have to be complex, but should provide you with a holistic view to how all of the components you are about to code or touch should interact. In addition you should be exploring different design choices at this stage, it’s much easier to erase a whiteboard and start from scratch then be a week into your coding and realize what a mess things have become due to lack of planning.
3. Have an opinion
As a junior developer you should have opinions and you should have reasons as to why you have that opinion. Even asking yourself the question of “why did you make choice X?” as a thought experiment is a nice way to have a robust answer and solution to your problem. The reason you need to have opinions instead of simply following along is because you are literally learning into understanding. Ask yourself the tough questions so that when a senior developer reviews your code you have a legitimately robust solution.
4. Ask questions
Ask questions about peculiar things, there is often wisdom and learning to be had.
5. Explore new technologies
When confronted with a situation they aren’t good at they often freeze up for fear of failure. As a junior developer it is in your best interest to fight those instincts and cast your net far and wide. Every piece of technology you touch influences you in some way, and having used various technologies exposes you to new paradigms and ways of doing things. Touching a new technology / programming language is expanding your ‘world view’ of programming.
6. Embrace unit testing
As a junior developer you really do need to embrace unit tests. I will advocate for Test Driven Development (TDD) not only because it improves my confidence that my code is functioning properly but has also really improved my function prototypes as I generally ‘call’ the function before its even built. I’m not particularly fond of BDD; however any form of testing you can do is better than nothing (trust me when it comes for v 1.1 of your app you’ll want those regression tests too).
7. Refactor
One of the problems of being a junior developer is that you haven’t been in industry long enough to be bitten by poorly written code that becomes impossible to maintain. Being a developer isn’t about writing code, it’s about producing working software while simultaneously hitting business goals and maintaining expectations. When you start with a blank slate everything is golden: you get to build from the ground up, features get spun out faster because they don’t interact with other parts of the system as much and the sky is the limit. If you are simply slinging code without any regard to maintainability, after about 6 months you will have accumulated a huge pile of technical debt. New features can’t get put out as fast, it takes longer to know what a certain function does and changing one thing wreaks havoc on another component of the system. Unfortunately the demand for new features from your users doesn’t simply decline with your technical debt; in fact it is likely increasing. This puts developers in a bad spot because they have a tangled pile of code and non technical folks requesting new features at rapid fire pace who have no idea what it means when you say ‘spaghetti code’.
So what happens next? The developers say the old system is slow and everything would magically be better if only we could rewrite the thing from scratch. So new developers are brought on to maintain the old stack and your ‘best’ developers begin creating the system from scratch. Bottom line… this is a huge waste of resources and doesn’t work anyways (it always takes longer to rewrite than you think, the new stack is always trying to catch up with the old stack, lots of QA time, etc).
But here’s the kicker, who wrote the initial version in the first place? Developers.
The solution to this is preventative medicine. As a developer you should be constantly rewriting and refactoring your code. Don’t ever check in code that isn’t a little better off than before you started. Maintainable code is code that is easily readable, extendable, and testable by outside developers.
Unless you have a very very good reason to put in that ‘quick fix’ don’t ever sacrifice a local maxima of productivity for the long term health of your codebase.
Nguồn: On being a Junior Developer