[Reading Notes Included] Second Meeting of Street Coder - Chapter 3

[Ozan Sazak]

Hi everyone,

We will have the next group meeting tomorrow (December 6, 2023). I will be the host of this session and we will cover Chapter 3 only, as it's already long enough to discuss about within the meeting duration :)

You can find my notes on Chapter 3 attached to this message, and I also wrote the discussion points below. If you also have different discussion points, please reply your ideas to this message with the related context (subheading, book quote, etc.).

Links for tomorrow's meeting:

Discord Server Link: https://discord.gg/kampus

Discord Voice Channel Link: https://discord.com/channels/839425986817818654/1163732320021397594

Meeting is at 20.15 Turkey time, and will take approximately 75 minutes. Meeting host: Ozan Sazak.

Discussion Points:

DP1 - “Every small bad decision will add seconds to your and your team’s performance. Your throughput will degrade cumulatively over time. You will get slower and slower, getting less satisfaction from your work and less positive feedback from management. By being the wrong kind of lazy, you are dooming yourself to failure. Be the right kind of lazy: serve your future laziness.” This is specifically important for projects on scale, but where should we draw the line of the need to abstraction? How granular should we apply abstraction?

DP2 - "My solution to this problem is to join the race toward the future. Keep the libraries up to date. Make it a regular habit to upgrade libraries. This will break your code occasionally, and thanks to that, you’ll find out which part of your code is more fragile, and you can add more test coverage." Monitoring the libraries constantly can easily be a burden on engineers after a certain time (think of your node_modules folder). Do you practice this idea in production? 

DP3 - Section "Don't write code comments" Code comments are pretty useful in documenting the reasoning of specific implementation choices. Where should we stop? How much verbosity we can introduce to make the code self-explanatory enough?

DP4 - Section "Use goto" Most of the goto code can be changed with linear non-goto code IMO. Do you have any case where you use goto in production systems where it is beneficial?

DP5 - "Certain changes can be performed on code that aren’t necessary but can help you in the long term. You can make it a regular habit to keep your dependencies up to date, keeping your app fluid, and identify the most rigid parts that are hard to change." From a pragmatic point of view, is regular dependency checking worth the effort? Is it a visible effort?