Soft Skills and Leadership
"Heart of a Junior, knowledge of a Senior"
This chapter isn't about code. It's about what really makes the difference between a good developer and a great developer: soft skills. Because you can be the best at writing code, but if you don't know how to communicate, lead, or work in a team, you're going to hit a wall in your career.
Heart of a Junior, Knowledge of a Senior
"I'd rather deal with a Junior than with a Senior"
I say this phrase often, and it always generates controversy. But it has a deep explanation: what we want is to combine the best of both worlds.
The problem isn't being Junior or Senior. The problem is when you get trapped in the worst aspects of each stage.
The Senior Mindset
Seniors have experience, and that's valuable. But that experience sometimes comes with baggage:
Problematic aspects:
- Rigidity: They already have their established ways of working and struggle to change
- Inflexibility: "I already know what works, why try something new?"
- Resistance to learning: By going with the familiar, they don't enjoy learning something new
- Closed vision: If it's not what they already know, they don't consider it valid
- AI resistance: They refuse to use new tools because "we've always done it differently"
- Lack of adaptability: They refuse to change, even when the context requires it
I'm not saying all seniors are like this. But it's a pattern I've seen many times, especially in developers who've been doing the same thing for a long time.
The Junior Mindset
Juniors come with a hunger to learn, and that's refreshing:
Positive aspects:
- Curiosity: Eager to try new things
- Humility: Accept criticism, asking for the fundamentals of why something is right or wrong
- Adaptability: Quickly adjust to new technologies and methodologies
- No bad habits: No preconceptions of "how things are done"
Areas to improve:
- Lack of experience to evaluate risks
- Sometimes don't know when something is a bad idea (even if it's new and shiny)
- Can be impulsive in technical decisions
The Best of Both Worlds
What we're looking for is a developer who combines:
From the Junior:
- Curiosity for the new but with caution: Eager to try new things, but evaluating risks
- Acceptance of criticism with criteria: Accepts feedback but keeps what actually serves
- Selective adaptability: ALWAYS selects what best solves the problem ACCORDING to the current context
From the Senior:
- Applied experience with openness: Has a way of seeing things BUT wants to know how others see things
- Controlled courage: Not afraid to dig into the unknown, BUT in a controlled and respectful way
- Shared knowledge: ALWAYS makes a problem known → knowledge is power
Fundamental principles:
- ALWAYS want to help, when possible
- EVERYONE must try to understand others
- Your job is NOT just your job, it's everyone's
Types of Leadership
Leader Type 1: The Mentor
"I'll send you this documentation, let me know if you have any questions in a bit, I'll be working on this in the meantime"
Characteristics:
- There's trust: Delegates but stays available
- Guides others: Gives tools, not direct solutions
- Generates trust: Trusts the other person and that generates reciprocal trust
Result: The team grows, learns, and gains autonomy.
Leader Type 2: The Task Completer
"Let me do it"
Problems:
- Not a leader, just a task completer: Focuses on doing, not on training
- Doesn't train others: The team doesn't grow
- Damages confidence: Makes the other person feel bad, makes them feel useless
- Affects self-esteem: Makes them lose confidence not only in him but also in themselves
- Fosters lack of communication: Nobody asks because "he's going to do it anyway"
Result: The team stagnates, people get frustrated, and eventually leave.
How to Become a Senior or Leader
The short answer: by being a Senior and being a Leader.
There's no title that makes you a Senior. There's no promotion that makes you a Leader. It's something you demonstrate with actions.
Step 1: Demonstrate that you're capable
Don't talk about what you can do. Do it. Results speak louder than words.
Step 2: Act accordingly
The concrete process:
- Detect where there's a problem: Don't wait to be told
- Look for a solution: Research, propose alternatives
- Involve the rest: It's not just your solution, it's the team's solution
- Experiment transparently: Make it known that it's an experiment and that EVERYTHING can change
Practical example:
❌ Bad approach:
- See a problem
- Solve it alone
- Say nothing
- If it goes wrong, hide it
✅ Good approach:
- See a problem
- Research possible solutions
- Present it to the team: "I found this, I think we could do X or Y, what do you think?"
- Experiment together
- If it goes wrong, learn together
Effective Communication
Communication is 80% of the job. You can write the best code in the world, but if you don't know how to communicate:
- Why you made a decision
- What the status of your work is
- What problems you found
- What you need to move forward
You're going to be a bottleneck.
Communication principles:
1. Overcommunicate rather than undercommunicate
It's better for them to know too much than too little. Especially in remote work.
2. Assume good intentions
Before reacting badly to a message, ask. Text has no tone.
3. Be direct but respectful
"This code has problems" is better than "Everything is wrong" but also better than "Maybe, if you want, you could consider reviewing some minor little things that perhaps..."
4. Document decisions
Conversations get lost. Documents remain.
Conflict Management
Conflicts are inevitable. How you handle them defines your professionalism.
Principles:
1. Attack the problem, not the person
❌ "You always do this wrong" ✅ "This approach has these problems, how can we improve it?"
2. Seek to understand before being understood
Before defending your position, make sure you understand the other. Maybe you're missing something.
3. Focus on solutions, not blame
The code is already broken. Looking for who to blame doesn't fix it.
4. Escalate when appropriate
Not every conflict is resolved between two people. Sometimes you need a third party, and that's okay.
Mentoring and Growth
If you're being mentored:
- Ask: There are no stupid questions, just questions not asked
- Take notes: Don't make them explain the same thing twice
- Do your homework: Before asking, try. "I tried X and Y but it didn't work because Z"
- Be grateful: Your mentor's time is valuable
If you're a mentor:
- Don't give the solution, give the path: "Check the X documentation" instead of "Do this"
- Let them make mistakes: Mistakes teach more than successes
- Celebrate achievements: A "well done" makes a difference
- Be patient: You were a junior too
Conclusion
Soft skills are not "nice to have". They're "must have". You can be the best programmer technically, but without these skills you're going to hit a glass ceiling.
Remember: Heart of a Junior, knowledge of a Senior.
- The junior's curiosity to keep learning
- The junior's humility to accept you don't know everything
- The senior's experience to make informed decisions
- The senior's responsibility to guide others
That combination is unstoppable.
Let's go. 🚀
- Gentleman Programming