Development as a Team
Stages of Acceptance:
- It's impossible.
- Maybe it's possible, but it's uninteresting.
- It's true and I supported the idea all along.
- I thought of it first.
- How could it be otherwise?
Developers must work together as a team. If you find yourself dealing with difficult people frequently, you probably are the difficult person. Deal with your personality before it destroys your career. The most difficult people also are usually the ones that protest passively by doing no work, they are hard to notice.
Avoid aggressive competition with your team members. Never harm other programmer's performance. Productivity is the sum of the team's productivity.
Try to minimize your ego while working in a team. It tends to start disputes and prevents yourself from learning from others. Every programmer has techniques and ideas that you do not know. If somebody has a seemingly applicable idea, support the idea and learn from it.
Your team is your support. If you are having problems, do not hide or lie about it. Someone will help you out if you just ask for help.
Don't pretend to know things that you don't. If someone is talking to you about a technical detail or term that you do not know, immediately ask what it means. You learn a new thing and the other person feels more respected, win-win.
Making mistakes is tolerable.
Honesty about making a mistake is required.
Knowingly hiding mistakes is a grave fault.
Learn when to take and deny responsibility. Be honest and direct when you make a mistake or an error in judgement. Be brave and vigorous if someone else is trying to take your glory. But never be a dick about it.
Ask for forgiveness, not for permission. It is easier to beg for forgiveness than to ask permission. Other peoples' code is not sacred, fix and simplify it if you can.
- When you come up with a better way of implementing a feature, do it.
- When you encounter poorly documented code, document it better.
- When you encounter poorly written code, try to encapsulate it away from the public interface. Avoid temptation to rewrite it if it works.
Mutual respect is better than having fun. Corny jokes and parties are great but not as great as genuine respect. If everyone respects everyone else, nobody will want to let anybody down.
Understand that great developers more often disagree than agree with each other. This is just how people are, sometimes you just have to bite the bullet and do it the way other developer wants it. To show respect if nothing else.
Ask others about their job and role. It take 30 minutes to learn the basics of web administrator's job. It improves social bonding and shows respect.
Talking with all the members is important. Try to divide your time to as many people as possible. Spending too much time with the same people is less beneficial for you and for them.
Teams are more productive if they work the same hours. People are more productive in morning and operating on the normal business hours has multiple benefits.
A project shouldn't have shared ownership across timezones. As cost of communication increases, developers will either find ways to reduce coordination or avoid making changes. Either way, this will stagnate development.
Never badmouth your team to outsiders. It will not end well.
Developers And Management
Developers should focus on the greater good of the company that employs them. But insist doing things the right way if something feels wrong. Don't distract management with unnecessary implementation details. Listen what they want, understand the problem domain, ignore anything unnecessary, plan on implementing what they need, give your estimate and overdeliver.
You are meant to provide solutions, not excuses. Nothing is "impossible" when management asks for a feature. Ask for clarifications to provide options and alternatives. Explain if you feel that something is plainly stupid but avoid being a dick about it.
Don't create an inferior product for a single-party gain. You may refuse any work unless it's of existential importance to the company.
Websites that trick the users into ordering more.
Bad implementation that will slow down the program.
Back doors in the software.