GENERAL TIPS (SOFTWARE ENGINEERS)

GENERAL TIPS (SOFTWARE ENGINEERS)

1. The engineer who wrote the code is responsible for QA for one time {Always do the QA on production/UAT environment after deployment}.
2. No code is finished until the unit testing is finished by you.
3. Good design results from getting something going quickly, followed by lots of quick iteration.
4. The best architectures evolve for a long time.
5. Code reviews are a regular part of development {do yourself first}.
6. Difficult parts of code are best done by a team of two people working closely together and discussing before writing the code.
7. If you see a new bug while doing something else, drop everything and jump on the chance to fix it. It just makes your life easier down the road.
8. It is possible to eliminate all bugs from many subsystems and you should use techniques that make it possible, exhaustive checking code whenever possible.
9. Complexity is your enemy – the sooner you learn the smell of too much complexity, the better and try to make it optimized and simpler.
10. Simplicity is your friend. Don’t fall for a really cool fancy algorithm unless you know you need it.
11. Never write a slow program it should be optimized.
12. Price is only one feature of software. It’s often not the most important. From the user’s perspective, simple things should be simple and complex things should be possible.
13. Automate releases.
14. Use source level debuggers.
15. Use IDEs
16. Don’t write; make files unless you already have.
17. Measures then optimize.
18. Always spend at least 10% of your time learning new things and try to implement them whenever required.
19. Use multiple languages, programming environments, operating systems and programming methodologies until you are comfortable with them and learn to appreciate the benefits of different approaches.
20. Optimize variable names for maximum clarity, not minimum typing.
21. It’s OK to make mistakes. The only thing that isn’t OK is to not learn from them.
22. Don’t leave code commented out unless it’s clearly explained.
23. Approach each piece of code you write like its final finished code. Don’t leave loose ends to clean up later because you’ll never have time to clean them up.{even you are creating the sample application}
24. Never code an algorithm that you know won’t work in the final product either because it won’t scale, run fast enough, or will have a rare failure case.
25. All successful products have a life longer than you can conceive. Files and processors will grow by factors of 10,000 – make sure your design can accommodate change {think for all possible areas before doing the code}.
26. Don’t code the first algorithm that comes to mind. Try to examine all possible approaches and choose the best. Best way to get someone to review your approach before coding {Always discuss your approach with in your team}.
27. Don’t put band aids on bad code, rewrite it. At first is seems hard, but after you’ve done it a while you’ll find successive rewrites go much faster than you thought.
28. When you work on someone else’s code, don’t leave it in worse shape than it came to you. Ask the original author to review your change.
29. No bug is impossible to fix.
30. Get to be good friends with a programmer, designer, or writer who’s better than you.
31. Get assumptions verified and do not be afraid to point out gaps in management or sponsor thinking. Do this tastefully, but do it before trying to implement a failed plan. We have the sole responsibility for solution quality or relevance. Realize what is needed is not always exactly what is asked for. Try to return people to pure business requirements if the document, email or post-it you have is too specific or generally too confusing to be understood. Be a bother in the short term to be an asset in the long term.