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 challenging people frequently, you probably are the challenging person. Deal with your personality before it destroys you. The most challenging people also are usually the ones that protest passively by doing no work as they are harder 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 acceptable.
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 ask 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.
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 another developer wants it. To show respect if nothing else.
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. Most people are more productive in morning, and operating on the normal business hours has multiple benefits outside work.
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 never ends well.
Developers And Management
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.
Some developer generate negative value.
A bad developer spends 5 hours writing convoluted code. Other 4 developers on the team spend 3 hours each trying to figure out how it works while working on related tickets over the upcoming weeks, months and years.
Net loss: (4 * 3) + 5 = 18 hours spent
A good developer spends 10 hours writing easier to understand code. Other 4 developers on the team spend 1 hour each trying to figure out how it works.
Net loss: (4 * 1) + 10 = 4 + 10 = 14 hours spent
Difference: 18 - 14 = 4 hours saved
# and __these numbers rise exponentially__ as time goes by and the team grows
# ... and here the good developer took twice as long,
# usually good developers are also faster, so it's not
# about the speed but _the quality_, which is harder to qualify
Stagnant influencers are the worst.
Programmers that refuse to learn new technologies and have influence in the company are even worse than bad programmers. They abuse their power to keep processes from evolving.
2023: there are still companies who don't believe in version control
Alarming behavior to look out for:
- Appear to do a great job rather than doing a great job.
- Trying to do as little as possible without getting fired.
- Focusing only on their work without looking at the big picture.
- Valuing their own time more rather than thinking about the team.