Describes the four stages of habit formation: cue, craving, response, reward.
Outlines four rules for building good habits, corresponding to each stage.
Uses the example of checking phone notifications as a habit to explain the rules.
Implementation of Habits:
Shares personal habits focused on becoming a better developer.
Emphasizes setting specific implementation intentions, stacking habits, and bundling new habits with desired activities.
Highlights the importance of reducing friction, making actions easy, and connecting actions immediately after completion.
Advocates for habit tracking as a gamification technique for maintaining streaks.
Two minute rule – always stay below the point where it feels like a work. Do at least one #coursera
Reduce friction – minimize actions you need to take ( have a bookmarked page, setted up enviroment)
Breaking Bad Habits:
Discusses strategies for making bad habits unattractive, difficult, and unsatisfying.
Stresses the value of an accountability partner and even publishing a habit contract to the world.
A commitment device A choice you make in the present tht controls your actions in the future
Results and Impact:
Reports personal success using these habits, including a job promotion and improved focus.
Encourages the audience to start working on tiny habits for personal development.
Q&A:
Addresses questions about the duration of using these techniques, adapting habits to circumstances, and the applicability of habits to developers at different career stages.
Key Takeaways:
Small, consistent changes lead to significant results.
Lifelong learning is crucial for personal and professional development.
Personal examples demonstrate the effectiveness of atomic habits.
Cyclomatic complexity – a measurement developed by Thomas McCabe to determine the stability and level of confidence in a program. The complexity of the branches and deep code logic is going.
Does react.memo() component will be rerendered if parent does renders? ( same value, different pointer to object).
What is typescript tuple – array with fixed size and known datatypes. F.E.: useState
How in TS define a JSON.parse returned object? unknow or
CSS optimize animation which changes position of the element – use transform.
Encapsulation. The implementation and state of each object are privately held inside a defined boundary, or class. Other objects do not have access to this class or the authority to make changes but are only able to call a list of public functions, or methods. This characteristic of data hiding provides greater program security and avoids unintended data corruption.
Abstraction.
Objects only reveal internal mechanisms that are relevant for the use of other objects, hiding any unnecessary implementation code. This concept helps developers more easily make changes and additions over time.
Inheritance.
Relationships and subclasses between objects can be assigned, allowing developers to reuse a common logic while still maintaining a unique hierarchy. This property of OOP forces a more thorough data analysis, reduces development time and ensures a higher level of accuracy.
Polymorphism.
Objects can take on more than one form depending on the context. The program will determine which meaning or usage is necessary for each execution of that object, cutting down the need to duplicate code.
What are TypeScript Getters and Setters
A getter method returns the value of the property’s value. A getter is also called an accessor.
A setter method updates the property’s value. A setter is also known as a mutator.
As you can see from the code, the setters are useful when you want to validate the data before assigning it to the properties. In addition, you can perform complex logic.
The following shows how to create the fullname getter and setter.
class Person {
// ... other code
public get fullName() {
return `${this.firstName} ${this.lastName}`;
}
public set fullName(name: string) {
let parts = name.split(' ');
if (parts.length != 2) {
throw new Error('Invalid name format: first last');
}
this.firstName = parts[0];
this.lastName = parts[1];
}
}
Principles of Functional Programming
1. Pure functions:
– Given the same inputs, always returns the same output – Has no side-effects
2. Immutability 3. Referential transparency
– Referential transparency is a fancy way of saying that if you were to replace a function call with its return value, the behaviour of the programme would be as predictable as before. 4. Functions as first-class entities
– This just means that functions are able to be passed as arguments to other functions, returned as values from other functions, stored in data structures and assigned to variables. 5.Higher order functions – Takes one or more functions as arguments – Returns a function as its result
Paterns:
Factory patter – deal with the problem of creating objects without having to specify the exact class of the object that will be created
// Empty vocabulary of actual object
public interface IPerson
{
string GetName();
}
public class Villager : IPerson
{
public string GetName()
{
return "Village Person";
}
}
public class CityPerson : IPerson
{
public string GetName()
{
return "City Person";
}
}
public enum PersonType
{
Rural,
Urban
}
///
/// Implementation of Factory - Used to create objects.
///
public class Factory
{
public IPerson GetPerson(PersonType type)
{
switch (type)
{
case PersonType.Rural:
return new Villager();
case PersonType.Urban:
return new CityPerson();
default:
throw new NotSupportedException();
}
}
}
Software Engineering at Google: Lessons Learned from Programming Over Time
“This book would not have been possible without the massive collaborative effort of our curators, authors, and editors. Although the authors and editors are specifically acknowledged in each chapter or callout, we’d like to take time to recognize those who contributed to each chapter by providing thoughtful input, discussion, and review.
So maybe you want to take a look at those books
What Is Software Engineering?: Sanjay Ghemawat, Andrew Hyatt
Working Well on Teams: Sibley Bacon, Joshua Morton
Knowledge Sharing: Dimitri Glazkov, Kyle Lemons, John Reese, David Symonds, Andrew Trenk, James Tucker, David Kohlbrenner, Rodrigo Damazio Bovendorp Engineering for Equity: Kamau Bobb, Bruce Lee
How to Lead a Team: Jon Wiley, Laurent Le Brun Leading at Scale: Bryan O’Sullivan, Bharat Mediratta, Daniel Jasper, Shaindel Schwartz Measuring Engineering Productivity: Andrea Knight, Collin Green, Caitlin Sadowski, Max-Kanat Alexander, Yilei Yang Style Guides and Rules: Max Kanat-Alexander, Titus Winters, Matt Austern, James Dennett Code Review: Max Kanat-Alexander, Brian Ledger, Mark Barolak Documentation: Jonas Wagner, Smit Hinsu, Geoffrey Romer Testing Overview: Erik Kufler, Andrew Trenk, Dillon Bly, Joseph Graves, Neal Norwitz, Jay Corbett, Mark Striebeck, Brad Green, Miško Hevery, Antoine Picard, Sarah Storck
Unit Testing: Andrew Trenk, Adam Bender, Dillon Bly, Joseph Graves, Titus Winters, Hyrum Wright, Augie Fackler Testing Doubles, Brad Green, Miško Hevery, Antoine Picard, Sarah Storck Unit Testing: Andrew Trenk, Adam Bender, Dillon Bly, Joseph Graves, Titus Winters, Hyrum Wright, Augie Fackler
Testing Doubles: Joseph Graves, Gennadiy Civil Larger Testing: Adam Bender, Andrew Trenk, Erik Kuefler, Matthew Beaumont-Gay Deprecation: Greg Miller, Andy Shulman Version Control and Branch Management: Rachel Potvin, Victoria Clarke
Code Search: Jenny Wang
Build Systems and Build Philosophy: Hyrum Wright, Titus Winters, Adam Bender, Jeff Cox, Jacques Pienaar
Critique: Google’s Code Review Tool: Mikołaj Dądela, Hermann Loose, Eva May, Alice Kober-Sotzek, Edwin Kempin, Patrick Hiesel Static Analysis: Jeffrey van Gogh, Ciera Jaspan, Emma Söderberg, Edward Aftandilian, Collin Winter, Eric Haugh
Dependency Management: Russ Cox, Nicholas Dunn
Large-Scale Changes: Matthew Fowles Kulukundis, Adam Zarek Continuous Integration: Jeff Listfield, John Penix, Kaushik Sridharan, Sanjeev Dhanda
Continuous Delivery: Dave Owens, Sheri Shipe, Bobbi Jones, Matt Duftler, Brian Szuter
Compute Services: Tim Hockin, Collin Winter, Jarek Kuśmierek
Titus Winters. “Software Engineering at Google”.
