<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>DEV Community: Daria Gorchylina</title>
    <description>The latest articles on DEV Community by Daria Gorchylina (@madelgeek).</description>
    <link>https://dev.to/madelgeek</link>
    <image>
      <url>https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F693047%2Fd5612b18-1d07-4bc2-8a3f-e4c3c8c3d49f.png</url>
      <title>DEV Community: Daria Gorchylina</title>
      <link>https://dev.to/madelgeek</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://dev.to/feed/madelgeek"/>
    <language>en</language>
    <item>
      <title>12 Fun Idioms and Principles for Software Engineers</title>
      <dc:creator>Daria Gorchylina</dc:creator>
      <pubDate>Tue, 13 Aug 2024 06:35:23 +0000</pubDate>
      <link>https://dev.to/madelgeek/12-fun-idioms-and-principles-for-software-engineers-1lfj</link>
      <guid>https://dev.to/madelgeek/12-fun-idioms-and-principles-for-software-engineers-1lfj</guid>
      <description>&lt;p&gt;Software engineering is as much about creative problem-solving as it is about writing code. While technical skills are crucial, understanding and applying certain principles can transform your coding practices from good to exceptional🚀  &lt;/p&gt;

&lt;p&gt;Here are some idioms and principles every software engineer should know:&lt;/p&gt;

&lt;ol&gt;
&lt;li&gt;&lt;p&gt;&lt;strong&gt;DRY (Don’t Repeat Yourself)&lt;/strong&gt;: Avoid redundancy by ensuring every piece of knowledge has a single, unambiguous representation. It keeps your code clean and easy to maintain.&lt;/p&gt;&lt;/li&gt;
&lt;li&gt;&lt;p&gt;&lt;strong&gt;KISS (Keep It Simple, Stupid)&lt;/strong&gt;: Simplicity is key. Overcomplicating things not only confuses others but can also come back to bite you later. Remember, the simplest solution is often the best. If you find yourself with a convoluted design, step back and simplify.&lt;/p&gt;&lt;/li&gt;
&lt;li&gt;&lt;p&gt;&lt;strong&gt;YAGNI (You Aren’t Gonna Need It)&lt;/strong&gt;: Future-proofing can sometimes lead to bloated and unnecessary features. Focus on what you need now, and add functionality only when it’s necessary. It keeps your code lean and efficient.&lt;/p&gt;&lt;/li&gt;
&lt;li&gt;&lt;p&gt;&lt;strong&gt;SOC (Separation of Concerns)&lt;/strong&gt;: Think of your code as a pizza🍕 You wouldn’t mix all the ingredients together in a chaotic pile. Instead, you separate them into crust, sauce, cheese, and toppings. Similarly, divide your software system into distinct sections, each addressing a separate concern.&lt;/p&gt;&lt;/li&gt;
&lt;li&gt;&lt;p&gt;&lt;strong&gt;The Boy Scout Rule&lt;/strong&gt;: Just like the Boy Scouts aim to leave a campsite cleaner than they found it, leave the codebase better than it was before. Whether it’s fixing a bug, refactoring, or updating documentation, minor improvements add up over time.&lt;/p&gt;&lt;/li&gt;
&lt;li&gt;&lt;p&gt;&lt;strong&gt;The Broken Windows Theory&lt;/strong&gt;: Fix small issues immediately to prevent more significant problems. Ignoring minor bugs or bad practices can lead to a decline in code quality, much like a broken window invites more vandalism.&lt;/p&gt;&lt;/li&gt;
&lt;li&gt;&lt;p&gt;&lt;strong&gt;The Rule of Three&lt;/strong&gt;: When refactoring, wait until you’ve encountered something three times before optimising it. It helps to ensure that your optimisation is addressing a real problem and not just a premature concern.&lt;/p&gt;&lt;/li&gt;
&lt;li&gt;&lt;p&gt;&lt;strong&gt;The Beyoncé Rule&lt;/strong&gt;: If you liked it, you should have put a CI test on it. Continuous Integration (CI) tests ensure that your code remains functional and bug-free as you develop it. It’s like having a safety net that catches you when you fall.&lt;/p&gt;&lt;/li&gt;
&lt;li&gt;&lt;p&gt;&lt;strong&gt;Chesterton’s Fence&lt;/strong&gt;: Before removing or changing something, first understand why it’s there. This principle guards against making changes without appreciating the purpose behind the existing setup, preventing potential negative consequences.&lt;/p&gt;&lt;/li&gt;
&lt;li&gt;&lt;p&gt;&lt;strong&gt;Rubber Duck Debugging&lt;/strong&gt;: Sometimes, explaining your code or problem to a rubber duck (or any inanimate object) helps identify the issue. This quirky method forces you to articulate the problem clearly, often leading to a solution.&lt;/p&gt;&lt;/li&gt;
&lt;li&gt;&lt;p&gt;&lt;strong&gt;Cargo Cult Programming&lt;/strong&gt;: Avoid blindly copying code without understanding its purpose or function. It’s like building a plane out of bamboo and expecting it to fly because it looks like one. Understand the context and functionality of the code you incorporate.&lt;/p&gt;&lt;/li&gt;
&lt;li&gt;&lt;p&gt;&lt;strong&gt;Murphy’s Law&lt;/strong&gt;: Anything that can go wrong will go wrong, especially in complex systems. Prepare for the unexpected by writing robust, error-handling code and always have a backup plan.&lt;/p&gt;&lt;/li&gt;
&lt;/ol&gt;

&lt;p&gt;By embedding these principles into your workflow, you can enhance your coding practices and navigate software engineering challenges with greater ease and confidence. Happy coding!😎&lt;/p&gt;

</description>
    </item>
    <item>
      <title>What is ADR, and Why Do You Need It in Your Company?</title>
      <dc:creator>Daria Gorchylina</dc:creator>
      <pubDate>Tue, 06 Aug 2024 08:21:31 +0000</pubDate>
      <link>https://dev.to/madelgeek/what-is-adr-and-why-do-you-need-it-in-your-company-146o</link>
      <guid>https://dev.to/madelgeek/what-is-adr-and-why-do-you-need-it-in-your-company-146o</guid>
      <description>&lt;p&gt;ADR, or Architecture Decision Records, is a collection of documents where you capture the most important technical decisions of the company.&lt;/p&gt;

&lt;p&gt;Typical ADR Structure:&lt;/p&gt;

&lt;ol&gt;
&lt;li&gt;
&lt;strong&gt;Date:&lt;/strong&gt; Useful for visibility and tracking purposes.&lt;/li&gt;
&lt;li&gt;
&lt;strong&gt;Status:&lt;/strong&gt; Indicate whether the decision is proposed, accepted, rejected, deprecated, or superseded. If the decision is still under discussion, mark it accordingly so engineers do not pick it up for implementation until it is finalised.&lt;/li&gt;
&lt;li&gt;
&lt;strong&gt;Context:&lt;/strong&gt; Briefly describe why this architectural decision is needed. It could include historical information on how similar issues were solved previously and the pain points they brought to the product.&lt;/li&gt;
&lt;li&gt;
&lt;strong&gt;Decision:&lt;/strong&gt; Note what has been decided.&lt;/li&gt;
&lt;li&gt;
&lt;strong&gt;Consequences:&lt;/strong&gt; Detail any required actions from teams. Should they consider implementing refactoring, or does the ADR apply only to new code?&lt;/li&gt;
&lt;li&gt;
&lt;strong&gt;Optional:&lt;/strong&gt; Include examples of code if applicable.&lt;/li&gt;
&lt;/ol&gt;

&lt;p&gt;Discover more templates &lt;a href="https://github.com/joelparkerhenderson/architecture-decision-record?tab=readme-ov-file" rel="noopener noreferrer"&gt;here&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;ADRs should be created only for the most significant technical discussions, such as the selected development language, database, and architecture patterns that should be applied to all services. It’s important to keep the list of ADRs short and organised. An excessive number of architectural solutions can reduce the quality of their application.&lt;/p&gt;

&lt;p&gt;Learn more about &lt;a href="https://adr.github.io/" rel="noopener noreferrer"&gt;ADR&lt;/a&gt;&lt;/p&gt;

</description>
    </item>
    <item>
      <title>Mastering Focus in the Age of Information Overload: Key Insights from “Hyperfocus” by Chris Bailey</title>
      <dc:creator>Daria Gorchylina</dc:creator>
      <pubDate>Tue, 30 Jul 2024 08:23:20 +0000</pubDate>
      <link>https://dev.to/madelgeek/mastering-focus-in-the-age-of-information-overload-key-insights-from-hyperfocus-by-chris-bailey-b2b</link>
      <guid>https://dev.to/madelgeek/mastering-focus-in-the-age-of-information-overload-key-insights-from-hyperfocus-by-chris-bailey-b2b</guid>
      <description>&lt;p&gt;In our modern world, we are constantly bombarded with a flood of information. While this abundance of information can be beneficial, providing us the ability to learn new things quickly, it also presents significant challenges. The need to sift through and filter this continuous data stream can be overwhelming, often hindering our ability to focus and perform at our best. In Chris Bailey’s book, “Hyperfocus: How to Be More Productive in a World of Distraction,” he provides strategies to navigate this information overload and maximise productivity. Here are my top 8 takeaways from the book:&lt;/p&gt;

&lt;ol&gt;
&lt;li&gt;&lt;p&gt;&lt;strong&gt;Schedule Hyperfocus Sessions&lt;/strong&gt;: Block time in your calendar dedicated to hyperfocus. During this time, concentrate on one crucial and complex task. Managing your attentional space with the correct number of tasks is both an art and a productive investment. Remember, attention overload can be very costly.&lt;/p&gt;&lt;/li&gt;
&lt;li&gt;&lt;p&gt;&lt;strong&gt;Prioritize Focus&lt;/strong&gt;: Make time for hyperfocus no matter how busy you are. It’s crucial for accomplishing high-impact tasks efficiently, which usually generate more resistance&lt;/p&gt;&lt;/li&gt;
&lt;li&gt;&lt;p&gt;&lt;strong&gt;Reduce Task Switching&lt;/strong&gt;: If we constantly switch between tasks, the work lasts 50% longer than if we perform one task from start to finish. &lt;/p&gt;&lt;/li&gt;
&lt;li&gt;&lt;p&gt;&lt;strong&gt;Leverage Rich Environments&lt;/strong&gt;: Enrich your environment and experiences to gain deeper insights. Your “gut feeling” often reflects years of accumulated knowledge and observation. To capitalise on this, keep track of everything you consume and consciously seek out valuable information.&lt;/p&gt;&lt;/li&gt;
&lt;li&gt;&lt;p&gt;&lt;strong&gt;Intentional Attention&lt;/strong&gt;: Ensure your attention is always paired with intention. This alignment prevents energy waste.&lt;/p&gt;&lt;/li&gt;
&lt;li&gt;&lt;p&gt;&lt;strong&gt;Embrace Scatterfocus During Breaks&lt;/strong&gt;: Use breaks to enter scatterfocus mode, where your brain works on tasks in the background. Activities like short walks, quick workouts, or meditation are ideal. Fun fact: Social media disrupts scatterfocus, so steer clear during breaks.&lt;/p&gt;&lt;/li&gt;
&lt;li&gt;&lt;p&gt;&lt;strong&gt;Meta-Awareness&lt;/strong&gt;: Be aware of where your attention is at any moment to manage distractions effectively. Meditations and apps such as Headspace can help you learn this skill. &lt;/p&gt;&lt;/li&gt;
&lt;li&gt;&lt;p&gt;&lt;strong&gt;Mindfulness and Focus&lt;/strong&gt;: Mindfulness helps reduce stress and improves your ability to refocus after distractions.&lt;/p&gt;&lt;/li&gt;
&lt;/ol&gt;

&lt;p&gt;Integrating these practices can significantly boost your productivity, help manage distractions better, and enable you to accomplish more meaningful work🚀&lt;/p&gt;

</description>
    </item>
    <item>
      <title>Unlock System Stability with DORA metrics</title>
      <dc:creator>Daria Gorchylina</dc:creator>
      <pubDate>Tue, 23 Jul 2024 08:21:24 +0000</pubDate>
      <link>https://dev.to/madelgeek/unlock-system-stability-with-dora-metrics-3ab9</link>
      <guid>https://dev.to/madelgeek/unlock-system-stability-with-dora-metrics-3ab9</guid>
      <description>&lt;p&gt;Is your system stable enough? Are you ready for an increased number of users today?&lt;/p&gt;

&lt;p&gt;If these questions make you uneasy, this post is for you.&lt;/p&gt;

&lt;p&gt;To help you feel more confident in your answers, consider the DORA framework (The DevOps Research and Assessment). You can &lt;a href="https://dora.dev/quickcheck" rel="noopener noreferrer"&gt;run a quick test&lt;/a&gt; to understand your software delivery performance.&lt;/p&gt;

&lt;p&gt;DORA has identified four key metrics to indicate this:&lt;/p&gt;

&lt;ol&gt;
&lt;li&gt;&lt;p&gt;&lt;strong&gt;Deployment Frequency:&lt;/strong&gt; This measures how often code is deployed to production. If you are deploying to production once a month and each deployment is stressful, you might assume that more frequent deployments would increase stress. However, the opposite is true. Regularly deploying small chunks allows you to quickly debug and understand what exactly went wrong and where exactly in case of deployment issues.&lt;/p&gt;&lt;/li&gt;
&lt;li&gt;&lt;p&gt;&lt;strong&gt;Lead Time for Changes:&lt;/strong&gt; The time it takes for a commit to reach production. This metric shows how efficient your delivery pipeline is, precisely the testing step. If you rely mainly on manual testing, this process could take days. But if automated testing is integrated into your development flow, lead time could be reduced from days to minutes.&lt;/p&gt;&lt;/li&gt;
&lt;li&gt;&lt;p&gt;&lt;strong&gt;Change Failure Rate:&lt;/strong&gt; The percentage of deployments causing production failures. To emphasize the importance of this metric, all team members should know how to monitor production logs. It would be even better if each team member could prepare a production deployment pull request. As a bonus, this approach fosters a greater sense of ownership of the product among team members.&lt;/p&gt;&lt;/li&gt;
&lt;li&gt;&lt;p&gt;&lt;strong&gt;Time to Restore Service:&lt;/strong&gt; How quickly failures in production are resolved. A small hint here: sometimes you don’t need to touch code to revert changes. You can achieve this by adding each new feature with a feature flag. In this case, disabling the feature flag can happen in seconds. Of course, in other cases, reverting a pull request might be the best option.&lt;/p&gt;&lt;/li&gt;
&lt;/ol&gt;

&lt;p&gt;By embracing DORA, teams can achieve greater efficiency and reliability in their DevOps practices.&lt;/p&gt;

</description>
    </item>
    <item>
      <title>I used to hate my mornings until I discovered this transformative morning routine!</title>
      <dc:creator>Daria Gorchylina</dc:creator>
      <pubDate>Tue, 16 Jul 2024 10:43:25 +0000</pubDate>
      <link>https://dev.to/madelgeek/i-used-to-hate-my-mornings-until-i-discovered-this-transformative-morning-routine-54bb</link>
      <guid>https://dev.to/madelgeek/i-used-to-hate-my-mornings-until-i-discovered-this-transformative-morning-routine-54bb</guid>
      <description>&lt;p&gt;Background: I moved to Lisbon, Portugal, six months ago. Suddenly, my perfect work schedule was disrupted. My active workday, with meetings starting at 9:30, began two hours earlier than my usual 11:30 start. This change was challenging, and I needed to adapt to this new reality.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;The solution was establishing a productive morning routine, allowing me to ease into the day instead of diving straight into work after waking up.&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;Today, I want to share this life-changing routine with you:&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;7:00 AM - Wake Up&lt;/strong&gt;&lt;br&gt;
Most importantly, avoid opening news or social media! &lt;/p&gt;

&lt;p&gt;&lt;strong&gt;7:00-7:10 AM - Journaling&lt;/strong&gt;&lt;br&gt;
I use the Stoic. app for this, but you can use phone notes or even a paper notepad. Write down your thoughts, even if they are just how much you dislike mornings 😄 &lt;/p&gt;

&lt;p&gt;&lt;strong&gt;7:10-7:25 AM - Bathroom Time&lt;/strong&gt;&lt;br&gt;
Don’t forget to apply your SPF!&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;7:25-7:50 AM - Dress Up and Go for a Walk&lt;/strong&gt;&lt;br&gt;
It’s crucial not to listen to music or podcasts. As a reminder, avoid social media during this time. Leaving your phone at home can help avoid temptation.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;7:50-8:00 AM - Quick Workout&lt;/strong&gt;&lt;br&gt;
Nothing fancy. Just do a warm-up and one circuit of push-ups, squats, and tricep exercises.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;8:00-8:10 AM - Return Home and Take an Ice Shower&lt;/strong&gt;&lt;br&gt;
It’s a pure dopamine boost.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;8:10-8:30 AM - Quick Breakfast&lt;/strong&gt;&lt;br&gt;
I usually have Greek yoghurt with blueberries and coffee. Remember to take any prescribed supplements. And only now can you quickly check your phone for important messages.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;8:30-9:00 AM - Time for Learning, Reading, Writing&lt;/strong&gt;&lt;br&gt;
For example, I’m writing this post during this slot. I’ve also completed two online courses in a month, thanks to this dedicated time.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;9:00 AM - Start the Workday&lt;/strong&gt;&lt;br&gt;
I prefer checking emails and Slack messages and conducting pull request reviews.&lt;/p&gt;

&lt;p&gt;I encourage you to create your perfect morning routine. Give it a try and see how it transforms your day!&lt;/p&gt;

</description>
    </item>
    <item>
      <title>How do we measure team performance</title>
      <dc:creator>Daria Gorchylina</dc:creator>
      <pubDate>Mon, 08 Jul 2024 07:58:35 +0000</pubDate>
      <link>https://dev.to/madelgeek/how-do-we-measure-team-performance-mne</link>
      <guid>https://dev.to/madelgeek/how-do-we-measure-team-performance-mne</guid>
      <description>&lt;p&gt;The ancient question of all managers: how to measure team performance?&lt;/p&gt;

&lt;p&gt;What if today, we’ll take a look from a different perspective? Let’s assume that you are working with talented people who are oriented toward delivering products of higher quality. What can become an ancestral stone in this case? &lt;/p&gt;

&lt;p&gt;&lt;a href="https://sedano.org/software-development-wastes/" rel="noopener noreferrer"&gt;Software Development Wastes&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;Pay attention at:&lt;br&gt;
⚡️ Are we building a feature that brings maximum value to our customers?&lt;br&gt;
⚡️ Is our backlog well-maintained and prioritised? Are all stories/bugs/tasks well-defined?&lt;br&gt;
⚡️ Should we sacrifice code quality in this particular case and produce tech debt, or should we spend slightly more time and effort on a solution that will not require rework? &lt;br&gt;
⚡️ A project at work is not a programming Olympiad. The code should be readable in the first place. Always remember: We write code once and read it many times.&lt;br&gt;
⚡️ Think twice before pushing the team too hard to eliminate psychological distress. The happiest teams work with higher performance&lt;br&gt;
⚡️Benefit future you - write a documentation! And inspire the team to do the same &lt;br&gt;
⚡️ Check where you have slow processes. How quick is the code review? How fast are automated tests? Where does your team have the most extended wait times? Try to detect and fight with bottlenecks &lt;br&gt;
⚡️ Improve communication. It’s never enough to stop working on team interactions. Try asynchronous communication, and AI features as meeting transcripts for the regular meeting&lt;/p&gt;

&lt;p&gt;&lt;a href="https://media.dev.to/cdn-cgi/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fem6yq9eithsd1z3uqd7v.png" class="article-body-image-wrapper"&gt;&lt;img src="https://media.dev.to/cdn-cgi/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fem6yq9eithsd1z3uqd7v.png" alt="Image description" width="800" height="562"&gt;&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;Share in the comments your examples to wipe out software development wastes🤓&lt;/p&gt;

</description>
    </item>
    <item>
      <title>Essential Non-Trivial Skills for Frontend Developers</title>
      <dc:creator>Daria Gorchylina</dc:creator>
      <pubDate>Sun, 11 Jun 2023 18:33:39 +0000</pubDate>
      <link>https://dev.to/madelgeek/essential-non-trivial-skills-for-frontend-developers-590a</link>
      <guid>https://dev.to/madelgeek/essential-non-trivial-skills-for-frontend-developers-590a</guid>
      <description>&lt;p&gt;I know that there are quite a lot of developers who have just started their journey. I am aware of how challenging it can be to find valuable information that helps you grow as a professional.&lt;/p&gt;

&lt;p&gt;Today, I would like to share my top 5 recommendations:&lt;/p&gt;

&lt;p&gt;🔹 &lt;a href="https://www.patterns.dev/" rel="noopener noreferrer"&gt;Learn patterns&lt;/a&gt;. A concise explanation of almost every pattern that you may encounter while working. If you break out in a cold sweat after a question about factory and singleton patterns - highly recommended💡&lt;/p&gt;

&lt;p&gt;🔹 &lt;a href="https://egghead.io/courses/advanced-static-types-in-typescript" rel="noopener noreferrer"&gt;Advanced Static Types in TypeScript&lt;/a&gt;. Best practical course related to TypeScript. Saved a lot of time and nerves. Function assertNever is my must-have for switch statements.&lt;/p&gt;

&lt;p&gt;🔹 &lt;a href="https://www.amazon.com/Grokking-Algorithms-illustrated-programmers-curious/dp/1617292230" rel="noopener noreferrer"&gt;Grokking Algorithms: An Illustrated Guide for Programmers and Other Curious People&lt;/a&gt;. You can not use algorithms directly in your work, but it’s extremely important to understand basic structures. This book is a good entry point. Besides, it’s easy and simple to read🤓&lt;/p&gt;

&lt;p&gt;🔹 &lt;a href="https://www.packtpub.com/product/design-patterns-in-typescript-video/9781789347951" rel="noopener noreferrer"&gt;Design Patterns in TypeScript By Dimitris Loukas&lt;/a&gt;. A broader and more voluminous explanation of patterns. And as for me one of the most understandable.&lt;/p&gt;

&lt;p&gt;🔹 &lt;a href="https://overreacted.io" rel="noopener noreferrer"&gt;Personal blog by Dan Abramov&lt;/a&gt;. Here you can find great articles about React And some other not less interesting information. One of my &lt;a href="https://overreacted.io/making-setinterval-declarative-with-react-hooks/" rel="noopener noreferrer"&gt;favorites&lt;/a&gt;. But please, try to solve this task on your own before reading the article😉&lt;/p&gt;

</description>
    </item>
  </channel>
</rss>
