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.