booknotes: Skills of a Successful Software Engineer

Notes that's relevant to me while I was reading Skills of a Successful Software Engineer, by Fernando Doglio.

Overengineering is the art of creating complex solutions for simple problems. YAGNI.

There are no random bugs, every problem has RCA

Performing a root cause analysis (RCA)

Always focus on 3 questions

Why is it happening?

How can you solve it?

How can you keep it from happening again?

5 Whys approach.

Think like a 5 years old and keep asking why. Why did this happen, why is slow, why didn't we do better, etc

Remember that technology that you're using is nothing but a tool. Don't get attached to language, tools, etc.

You can jump from language to language

You can translates concepts from one language to another

GET OUF THE BOX!

Always be on the lookout for the best practices specific to the tech you're using (KISS, DRY, SOLID). You don't need to memorize, just keep it in the back of mind to ensure quality code.

Good code beats perfect code every time. Optimizing code is only required once your code works.

Bad code can be a great starting point

Documenting your code is a must. Self documenting code is a lie.

Testing

Each test should test one thing only.

Make sure you test a unit of code. Atomic piece of logic that's complex enough to be tested

Only test your own code. Don't waste any time writing tests for third party library or frameworks

Don't test external calls (DB query, HTTP request, etc). It's meant to be run in isolation.

Only tests what's on the rug. What we can see. In this case public interfaces & properties

use dependency injection to manage external dependencies

master the 4 concepts - mocks, stubs, spies and dummies

Refactoring

How do you make sure your changes doesn't break existing behavior? TESTS!

Have a plan for your refactoring.

Make sure you understand exactly why you're doing it & focus on that. A clear goal is key to successful refactoring.

It will never be perfect, so don't aim for perfection. DON"T OVERDO IT!

Think about these 3 things to decide whether the refactoring is worth it or not

How much valude is your change adding?

What's the impact of your change?

Do you have enough time to refactor the code without affecting your team's timeline?

Learn to communicate with others. Having a great communication skills makes for a great developers.

2 ways of communications

Direct -> being in front of the audience, talking directly

Indirect -> write articles, create videos, build online courses

Find ways of getting feedback

Interview process is not only meant for the company to know you. It's a great opportunity for you to know theme. Ask questions.

Don't lie during interview or in resume. Stay away from absolute statements.

Overtime is not mandatory nor should it be expected of you

Working in a team

Task tracking is not eveil. Make sure it's always updated. Put yourself in the shoes of your manager.

On meetings

Be there on time & avoid chit chat.

Prepare for the meeting, don't just "wing it"

Make sure there are actionable items at the end of the meeting

Align with everyone in the meeting by sending the meeting's minutes afterwards

Don't reinvent the wheel

Make peace with your testers

Leave your ego at the door

Socializing with your team is just as important as doing good work

Make sure you keep learning new things and compare your progress with yourself.

Key traits of a good leader

They like to challenge the status quo

They set clear expectations for everything

They create a clear plan for success

They prioritize the team over themselves

They constantly look for sustainable results

They constantly try to improve themselves

They build networks and always looking for external collaborations

90-10 rule

First 90% of the project is finished within 10% of the time while the last 10% of the project require 90% of the time

Scope creep -> if you see this happening, raise it up and talk about the effect it'll have on the delivery date

Leave unknown for the last -> if you notice you're working on a feature based on assumptions, raise it up. Cause there's a huge risk of rework if it's not addressed.

Feedback should be mandatory. Both for leader and team members.