This document provides 31 tips for software engineers. Some key tips include: thoroughly testing code on production/UAT environments after deployment; doing code reviews regularly as part of development; dropping other work to immediately fix new bugs; optimizing code for simplicity, efficiency and to avoid complexity; automating releases; and getting assumptions verified before implementing plans. The tips emphasize best practices like thorough testing, code optimization, automation, learning new skills, and collaboration within teams.

1. 1
Created by Prashant Kumar
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.

2. 2
Created by Prashant Kumar
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.