You’re a S/W Developer. Maybe you’re fresh out of school…or maybe early in your career…or maybe you’ve been writing code for years and years and are a complete rock star. Now you find yourself having just been hired, or maybe having just been moved into a pre-existent S/W development team to work on a pre-existent project. Regardless, the point is that you are new to the team and project, and you have other developers with which you must work, and the goal is to produce the best product you can.
I have been that guy. I’ve been the guy who is already on the team. I’ve been the leader of that team. It can be a tough situation, but I have developed a few rules to live by in that environment that I have found to be effective in helping to produce team efficiency. These rules have been aggregated from a variety of sources, and just plain experience. It all starts with an attitude…a healthy attitude about one’s role as a developer on a team and that your focus is on the product being developed. The goal is a well-functioning team. The reality is that a team that functions well will generally produce the best product. That doesn’t mean everybody on the team is invited to each other’s birthday parties, but it does mean a certain amount of respect should be afforded to each member, and that each team member should be able to count on the others to act professionally.
Here are those rules, presented in no particular order.
- You will make dumb mistakes, forgive your team members for the same.
You’re going to shift the wrong number of bits, or the wrong direction. You will use a pointer to the wrong string. You will forget to update the comments or std out. You will link to the wrong version of the library. You will perform countless boneheaded maneuvers like these that you won’t catch with your exhaustive unit testing. It’s OK, it’s not a big deal. We’re glad you found the issue. Just remember to afford your colleagues the same generous attitude as they undoubtedly follow the same path.
- When taking over somebody else’s code, or coming into a project mid-stream, learn on your own, but start asking questions before you commit code.
Project leads and managers not only like, but require developers to be able to be responsible and work on their own. But, you have to know your limits, and before you start committing your changes to the repository, make sure you understand what you are doing. Always assume there were solid design principles and reasons for the current code to be the way it is. This is not always the case, but assume it is. Therefore, when you take it over, make sure you learn why it’s done the way it is, and do this autonomously as best you can. Prototype ideas, work through technical reasons for making changes. Ask questions of those who know. Hacking around is an awesome way to learn how it works, and try out new ideas, but don’t commit until you’re sure you are correct.
- Discuss design/implementation ideas and ask for code reviews.
Sometimes project team methodologies demand formal milestones like design reviews and code reviews…sometimes they don’t. In any case, always lean on other team members when you are thinking about the design and implementation and for reviewing code that you have implemented. This may be just informal, if the project methodology doesn’t call for it formally. Most, if not all, good team members, even if they are very busy, will be very willing to talk through things with you and review anything you ask. Learn from the criticism offered. In the end, you’ll be a better developer.
- Argue technically, not philosophically or personally.
Arguing, and sometimes heated arguing, can be a good thing for product development teams because it helps get to the end goal of a great design/vision. Passionate team members are the #1 reason a project will be successful. To be effective, and not destructive, the arguing must be kept to the technical realm of the product and its implementation. Come to design and development discussions armed with technical reasons to back up your opinions. Never, ever attack people personally, and never, ever argue purely from a philosophical point of view, unless the philosophy backs up the technical argument.
- Don’t be married to a development methodology, or…Fit the development methodology to the product, not the product to the development methodology.
Product development is about understanding the problem being solved by the product and its intended features. It’s not about your personal crusade to implement a particular methodology. There are many great academic methodologies that have been developed over the years, but sometimes no matter which methodology you personally like best, you may have to adapt or use a hybrid in order to make your project successful. For example, if you’re building a web app, a pure Agile approach may be perfect for your team. However, if your developing embedded firmware for an SoC that is still in the design stage, pure Agile is likely to not be a great fit. In this case you may want to use a hybrid that blends principles of waterfall, Agile, and test-driven development. The point is, not all projects are created equal, and therefore, not all methodologies are implicitly correct. An adjunct to this commandment is that you personally should be adaptable to various methodologies.
- Don’t be married to a particular language.
As with the rule above, the same principles can be applied to particular coding languages languages as with methodologies. Use what makes sense for the project, and be adaptable. Learning new languages should be a desire you have, and any project that provides that opportunity is a good one.
- Know and follow the project or team’s coding guidelines, development methodology, and configuration management methodology.
If you are on the team, you must conform to these. Teams work better if everybody is on the same page here. Knowing what to expect from your coworkers is a huge step towards better productivity. If you have a real problem with something in particular, discuss it with the team lead or the collective.
- When implementing new features, functionality, and API’s, or changing existing ones, think first about how changes you make will affect your users/customers, second about how they will affect the test team, and third about how much work it is for you.
You are changing or writing new code for a reason. The most important thing is to think about how your new code will be used, whether its interfacing directly with users, or with other developers on the team. Next in line is to think about how your changes or development may affect or be used by the test team. Don’t be insensitive or underestimate the work required on the verification side. Only then worry about how much effort it is for you. If you are proposing a solution because its “easiest for you”, but doesn’t address the other concerns adequately, then rethink it.
- Always think about readability and maintainability.
Assume you will be handing over your code to somebody else some day, and that they will have to maintain after you’ve moved on. Clever is NOT always better. Good, elegant code is readable and maintainable, not obtuse.
- Develop what the product needs, not what you want.
Unless of course the product is for you 🙂 Applying different technologies, design patterns, or novel ideas only makes sense if it helps the end product in some way. The project is about the product, not about your ability to shoehorn cool stuff in. I caveat this commandment with the following: Sometimes the product is all about new technologies or cool stuff. In that case, go ahead and get it in there.
- Always think about performance.
Cycles, memory, network traffic, latency, code size…Always have these in mind. Generally (but not always), the first goal is readability and maintainability, but you should also be working to making your code perform well.
- Test it, test it again, and then test it again.
An absolute for production code.
- If the test team indicates there is a problem, assume they are right, or…Never just hurl “Works for me” across the bow without backing it up.
Heated exchanges between the s/w development and test teams is an objective truth, and makes for a lively work environment. Much like fundamental disagreements between s/w and h/w teams about each other’s usefulness and personal hygiene. However, as the developer, always assume that the issue being indicated is an actual problem. If it’s not a real bug, do the work to explicitly show why the issue is not real. Provide information to back up your stance. Just stating, “That’s not a bug”, or “Works for Me” will rarely solve an issue.
- If its not right the first time, rewrite it.
Requirements change…you think of new ways to implement it better…it doesn’t meet the requirements. Whatever the reason, do not be put off or ashamed or annoyed. Just redo it until it’s right. Many very experienced developers assume that they will completely rewrite (or at least refactor) their code 3 times before it’s production worthy. That’s one of the great things about software…It’s just typing.
- Avoid changing interfaces to other groups or modules, unless necessary.
When working on well established API’s, or other interfaces, your first goal should be to minimize or eliminate changes to the interface itself. This minimizes the ripple effect into other code modules and test developments. However, many times the change will necessitate a modification to the interface. In this case, think about, discuss, and understand the impact of the change to other areas. You may change 1 argument in your API, and you just affected 150 system test scripts to the order of another week of work. Be aware of this.
- Design your code.
Code development is usually an iterative process. The first time you write a feature/function, it may be perfectly acceptable to write it stream of consciousness. But always go back and see if there is a better way. Everybody designs and implements in different ways. Sometimes you have to think for a while upfront, and…oh, no…maybe create some documentation to work through or share your ideas. Sometimes you just need to dive in and prototype to flesh out ideas. Whatever your method, make sure the end result is intentional.
- Expect little documentation, but produce much.
In short, act like a professional. Professionals produce documentation, no matter what the Agile manifesto says. Depending on the project this may mean different things. It might be something “in-line” like doxygen or good commenting practices, or it might be something more document-ish like wiki pages, but it may mean good old-fashioned specs or user guides in MS Word. The more useful documentation that is produced, the easier it is for teams to work together, and for long term maintainability of the product. There are smart ways to develop documentation that don’t make the project move slowly.