WAYS TO BECOME BETTER DEVELOPER
1. Enjoy in Pair Programming
Pair programming is an agile software development technique in which two programmers work together at one workstation. One, the driver, writes code while the other, the observer or navigator, reviews each line of code as it is typed in. The two programmers switch roles frequently.
Pair programming is the best way to improve yourself. You get chance to read code from another developer and see their thought process in real time. Same vice versa. You can both challenge your point of views and both grow as developers.
2. Read other’s code and Get someone to read your code
In Greek mythology, Narcissus fell in love with his own reflection in the water. He couldn’t resist looking at it. As developers, we are prone to the same syndrome that has now been named after him, Narcissism.
When you code, it is easy to fall in love with your “artwork”. But a piece is of code is only close to perfection when someone else can read it and understand what you are on about.
Get others to read your code by doing code reviews often. You will learn a thing or two every time. Especially when you discover that method name doesn’t mean so much sense after all.
How to read other’s code:
- Try to build and run it.
- Don't focus on the details just yet.
- Make sure you understand all the constructs.
- Now that you've got a good idea about most of the constructs, it is time to do a couple of random deep-dives.
- There were undoubtedly things in the previous step you were confused about, so this is the perfect time to go and read some tests.
- No tests you say, sounds like the perfect time to write some.
- Extract curious bits of code into standalone programs.
- The code is dirty and smelly? Why not refactor it.
- Get yourself a code reading buddy.
3. Fix bugs before writing new code
I’m sure you have been there. You discover a bug and you say, “I’ll fix it later, let me just get these features out of the way”. Or you see a failing unit test but you cannot be bothered to go find out why it is failing, so you either comment out the test or hack it. You can do “The Joel Test” like below
- Do you use source control?
- Can you make a build in one step?
- Do you make daily builds?
- Do you have a bug database?
- Do you fix bugs before writing new code?
- Do you have an up-to-date schedule?
- Do you have a spec?
- Do programmers have quiet working conditions?
- Do you use the best tools money can buy?
- Do you have testers?
- Do new candidates write code during their interview?
- Do you do hallway usability testing?
4. Learn a new technology
The following list is some things which are helping to learn new technology.
- Find/Rediscover Your Passion
- Remove Distractions.
- Listen to Podcasts & Read Blogs
- Learn a New Technology Each Month
5. Keep it simple
You can always find more elaborate ways to implement a task in programming. Some people get off of looking at how amazing their code is, and that’s okay but keep it simple, will you? This ties into the earlier point made about getting someone else to read your code.
If they can’t understand it within a few minutes then you are doing yourself (and frankly anyone that has to maintain that piece of code) a disservice.
6. Writing a blog post about your code
If you are able to make someone else understand a concept, that means you have been able to grasp it and not just hacking or blagging away.
Write a blog post explaining how you went about the process of solving the problem at hand.
This is also a good resume BTW, if you are ever looking for contracts and you can point your potential recruiter at a series of blog posts, you have an advantage.
Thought leaders always the advantage.
7. Contribute to open source code for googlers
This means to either start an open source implementation of your own or contribute to an existing one. This helps you understand how to collaborate with a bunch of developers. This is especially helpful if you do a lot of lone projects.
Learning from other like-minded developers is a plus and, come on, isn’t it cool to give back to the community?
8. Deal it, not delay it.
when you facing any issue or error in code, try to solve it same time, if even that is not stop working your current feature.
As developers, we encounter the same thing often. The “one-liner” bug that kills the whole show. It is tempting to put in a hack without really researching why your code isn’t doing what is should.
9. Give comments on each thought of code
There is a chance to your code will run by other, use by other, execute by other and edit by many. your comment in common language will help to other read your code.
Another way to train up junior developers. We used to have peer code review, which is basically what this is, which it was taken in two ways 1) aggression (coders are biased) 2) heated verbal aggression. The only way this is functional is a senior developer on a junior developer because there is a clear definition of status
Very nice article 8th point is "the best"
Awesome!!
Article like "Keep it Simple" :)
Clean,Clear,Simple, To the Point , Great Palak ! 😀