tl;dr:Vadim shares: (1) his personal struggle with anxiety and burnout in 2017 after becoming Head of IT at his startup. (2) He realized that not all deadlines are critical, and sometimes pushing back releases for the sake of the team's well-being is the best decision. (3) What worked for him - recognizing symptoms, setting boundaries, replacing coffee with decaf, walking, gaining perspective, turning off notifications, and educating himself on mental health.
tl;dr:(1) You go to an event. (2) Approach person, say Hi, and introduce yourself. (3) Ask questions. (4) Listen carefully and share your experiences. Keep a look out for common ground. (5) Go to 3 if the conversation feels fresh; otherwise, continue. (6) End Gracefully. Go to 2 if you’re not tired; otherwise, continue. (7) Eat some food. Leave the event. (8) Follow up with everyone you liked via email. Vadim also shares his core principles: (a) Make others feel accepted. (b) Give first, then give some more i.e. don’t make networking transactional. (c) Don’t overthink it.
tl;dr:Vadim differentiates between technical questions that address code and processes, with project management questions that deal with team dynamics. Key advice includes: (1) Conducting thorough research before posing a question to ensure you're not asking something readily available. (2) Ensuring clarity and precision in question formulation to get meaningful answers. (3) Avoiding the XY problem, where a perceived solution might overshadow the actual issue at hand. (4) Utilizing the "rubber duck method" as a tool for clarity, where explaining a problem aloud to an inanimate object can help in understanding and structuring thoughts. (5) Recognizing the importance of the medium and tone when asking questions, choosing the right platform and approach based on the nature of the query. And more.
tl;dr:“Start small, but start today. Don't wait for a grand strategy or a perfect tool. Start by documenting your code, your decisions, and your learnings. Make it a part of your daily workflow, not an end-of-the-day chore. And as you move forward, imbibe this culture of documentation into your teams, your projects, and your organization. Create systems and processes that encourage and facilitate documentation.”
tl;dr:“Who am I to tell you how to estimate projects? I can only give you some pointers and describe some things that worked well for me over the years. So that’s exactly what I will do — give you some rules of thumb to make your life easier.”
tl;dr:These include: (1) Any form of a non-compete clause in employee contracts. (2) Confidentiality agreements. (3) Exclusive distribution agreements. (4) A project-based agreement without a clear definition of scope and definition of done. Vadim also discusses clauses to avoid.
tl;dr:(1) You rarely write something from scratch. (2) Domain knowledge is more important than your coding skills. (3) Writing documentation is not emphasized hard enough. (4) Code is secondary. Business value is first. (5) You’ll need to work around incompetence. (6) You work with uncertainty most of the time. (7) Assume everything has bugs. And more.
tl;dr:Vadim shares things that would have made life easier to know when becoming CTO of a small company, including: (1) If you’re moving from the same team to become their manager, you need to make sure they respect you as a developer first. (2) Your friendship with your teammates will suffer once you’re their boss. (3) Stop wanting to do everything yourself. And more.
tl;dr:Vadim splits the topics into four categories: (1) Onboarding. (2) Day-to-day business, discussing methods that make life easier when you don’t see your employees every day. "Small things that may seem unimportant but have a huge impact." (3) Culture, people feel happy and engaged. (4) Results, making sure the team delivers and pushes the company forward.