The truth is giving feedback can be awkward. It’s hard to be direct and constructive without veering into harshness. And sometimes, it’s tough to come up with anything meaningful to say at all.

Here’s what I’ve learned about giving impactful feedback while avoiding the common pitfalls.

Interrupt Your Biases

We’re all human, and humans are naturally biased. Pretending you’re immune to biases isn’t just unrealistic; it’s dangerous. The first step to giving fair feedback is acknowledging unconscious biases, recognizing where they might creep in, and actively interrupting them.

Common Biases to Watch For:

• Recency Bias: Overemphasizing recent events while ignoring a broader timeline of performance.

• Halo Effect: Letting one positive attribute overshadow everything else.

• Confirmation Bias: Looking for evidence that supports your preconceived notions about someone.

• Affinity Bias: Favoring those who are more like you in personality, interests, or background.

Take a moment before giving feedback to reflect on whether any of these biases might be coloring your perspective. By consciously interrupting them, you’ll provide feedback that’s more balanced and useful.

Giving Positive Feedback

Let’s start with the good stuff. Just because someone isn’t struggling doesn’t mean they don’t need feedback. In fact, positive feedback can be just as transformative as constructive criticism. Sometimes, people don’t even realize they’re excelling.

As a leader, it’s essential to highlight the efforts and successes of your team—not only to motivate them but also to reinforce the behaviors and practices you want to see more of.

Things to Keep in Mind:

• Be Specific: General praise like “Great job” feels nice but doesn’t inform the person what they did well.

• Be Timely: Don’t wait until feedback season to share positive observations.

• Be Genuine: Empty flattery is easy to spot and does more harm than good.

Good Example:

“Your thorough code reviews last sprint caught several issues that would have been costly to fix later. Your attention to detail saved us a lot of time and effort.”

Bad Example:

“You’ve been doing a great job overall.” (This is too vague to be meaningful.)

Giving Negative Feedback

Here’s where it gets tricky. Negative feedback can be uncomfortable, but avoiding it does a disservice to your colleague and the team. Everyone has areas to grow—and addressing them early prevents bigger problems down the road.

When delivering constructive criticism, it’s even more critical to interrupt your biases and frame the feedback in a way that’s actionable and forward-looking.

Keep in Mind:

• Be Direct but Empathetic: Sugarcoating doesn’t help, but harshness isn’t effective either.

• Focus on Behavior, Not the Person: Address what happened, not who they are.

• Be Solution-Oriented: Pair your feedback with suggestions for improvement.

Bad Example:

“You’re not pulling your weight on the team.” (This is accusatory and unhelpful.)

Good Example:

“During the last project, some of your tasks missed deadlines, which impacted the team’s delivery. Let’s talk about how we can manage your workload better or if there’s anything you’re struggling with.”

How to Receive Feedback

Feedback is a two-way street. No matter how much experience you have, there’s always room to learn and grow. Receiving feedback with an open mind is hugely important to your development.

Tips for Receiving Feedback:

• Listen First: Resist the urge to defend yourself or explain right away.

• Clarify If Needed: Ask follow-up questions to fully understand the feedback.

• Reflect and Take Action: Even if you don’t agree entirely, look for kernels of truth and ways to improve.

• Thank the Giver: Feedback takes effort to deliver; showing appreciation encourages more of it.

Conclusion

Feedback season doesn’t have to be awkward or stressful. With the right approach, it can be an opportunity for growth, both for the giver and the receiver. By interrupting your biases, delivering positive feedback thoughtfully, and approaching negative feedback with empathy, you can transform these conversations into something truly impactful.

And don’t forget, receiving feedback is just as important. Embrace it with curiosity and gratitude.

There’s a romantic notion in tech about perseverance, that grit will eventually lead to success. We glorify stories of relentless engineers who, against all odds, built something world-changing. But for every one of those stories, there are dozens of projects quietly abandoned or pivoted to something else entirely. And that’s okay. In fact, knowing when to pivot or quit is a skill worth mastering.

🎢 The Sunk Cost Trap

There’s a trap we fall into when we’ve put time into a project, the sunk cost fallacy. You’ve poured hours, days, maybe even years into your code. You’ve envisioned the perfect launch and imagined users loving what you’ve built. Walking away feels like throwing all that time into the trash. But here’s the truth: the project doesn’t owe you success just because you’ve worked hard on it.

Think about it like this: you’re digging a well, and after hours of shoveling, you realize there’s no water here. Do you keep digging, just because you’ve already put in the effort? Or do you move to a new spot? For a long time, I kept digging on projects because I didn’t want to waste the time I’d already invested. But the reality is, the sooner you recognize the dead end, the sooner you can move on to something more rewarding.

Share

🔄 The Pivot

Pivoting gets a bad rap sometimes, as if changing direction means you’ve failed. But a pivot is simply a shift in strategy based on new information. It’s what separates good ideas from great ones.

Early in my career, I worked on a travel planning tool, hopeful that it would be a game-changer. I spent months developing a detailed itinerary feature, convinced it would be the app’s standout. But after getting feedback from colleagues, I had a crucial realization: there just wasn’t enough demand for the tool. Coding it wasn’t fulfilling, and I found myself frustrated with how much I was relying on existing libraries, rather than building something truly innovative.

Rather than doubling down on the itinerary feature, I pivoted and focused on refining the chat experience. The app didn’t become the next big thing, but the process taught me a lot about system design, user experience, and consistency in databases—lessons I still apply to this day. While the project didn’t turn out as expected, the knowledge I gained from it has shaped how I approach development, making me a more thoughtful and adaptable engineer.

🚪 Letting Go

Here’s the part no one wants to admit: sometimes the best decision is to walk away entirely. Us software engineers pride ourselves on persistence and late nights. But there’s a difference between persistence and stubbornness. Knowing when to abandon a project can be the most strategic decision you make.

I remember working on a machine learning model a few years ago, trying to build an algorithm that could predict stock prices (because who doesn’t want to be a millionaire?). I put in endless hours, tweaking the model and feeding it new data. But the more I worked on it, the clearer it became that I was trying to solve an impossible problem, at least with the resources I had. I wasn’t building a solution—I was chasing a mirage.

Letting go of that project wasn’t easy. It felt like admitting defeat. But looking back, it freed me up to start a new venture that became far more successful. I’ve been rereading On Writing Well by William Zinsser as of late to keep my writing skills intact. Funnily enough he talks about the power of cutting out what doesn’t serve the piece. The same applies to software: sometimes you need to cut the dead weight to move forward.

💡 Trust Your Gut and Your Data

If you’re staring at a project right now, unsure whether to pivot, persevere, or abandon ship, here’s my advice: trust your gut, but also look at the data. Are users engaging with it? Are you excited to work on it? If the answer is "no" to both, it might be time to say goodbye.

We often think of letting go as a failure, but in reality, it’s a step forward. It’s making room for the next great idea, the one that will make you glad you had the courage to move on.

Because sometimes the hardest part of being a software engineer isn’t building, it’s knowing when to stop building.

💡 Posts I Enjoyed This Week

Engineering Leadership

Discipline over Motivation in the engineering industry

Read more

2 years ago · 64 likes · 8 comments · Gregor Ojstersek

The Pragmatic Engineer

How to become a more effective engineer

Hi – this is Gergely with the monthly, free issue of the Pragmatic Engineer. In every issue, I cover challenges at Big Tech and startups through the lens of engineering managers and senior engineers. To get weekly emails like this in your inbox, subscribe here…

Read more

2 years ago · 212 likes · Gergely Orosz and Cindy Sridharan

Product for Engineers

Why you're bad at giving feedback

“Feedback is a gift…” or so they say…

Read more

2 years ago · 42 likes · 1 comment · Lior Neu-ner

The Fallacy of Perfection

Early on in my career, I was obsessed with doing everything perfectly. I was that engineer who double-checked code for hours, avoiding any risk that might lead to a bug or error or even a code review with too many comments. But the truth is, playing it safe often meant missing out on opportunities to explore something new or even better. I learned the hard way that perfectionism and innovation don’t always go hand in hand. In fact, they can clash.

Innovation thrives on experimentation, and experiments come with a risk of failure. But those failures aren’t roadblocks; they’re guideposts. Every failed deployment, botched integration, or misunderstood requirement is a lesson that gets you closer to a breakthrough. The reality is that a bug that makes it to production is usually an indicator of a larger issue in the team’s processes/mechanisms and less about an engineer causing it.

Learning the Hard Lessons

I remember a time when I tried to over-engineer a solution to a relatively simple problem. I thought I was being clever—layering abstractions upon abstractions, thinking that would make the system more flexible. But what I created was a nightmare for my teammates. It became impossible to debug and even harder to scale. I failed, no question about it.

But that failure was invaluable. It forced me to rethink what “good engineering” meant. Simplicity, I realized, often beats complexity. And while that lesson cost us some sleepless nights, it taught me to focus on what’s essential and trim the fat in my designs.

A Culture of Experimentation

Now, when I lead projects or mentor moew junior engineers, I emphasize the importance of experimenting without fear. In any field, especially tech, creating a culture where failure isn’t stigmatized but instead used as a stepping stone to success is critical. This is where the true magic of innovation happens.

Teams that are afraid to make mistakes become stagnant. They stick to the tried-and-true, avoiding new ideas that might push the boundaries. But fostering a culture where it’s okay to fail—and more importantly, learn from it—leads to some of the most groundbreaking innovations. And COEs (Correction Of Error Documents which other companies call post-mortems) at Amazon play a crucial role in that. We may break things, but we must learn from those events through COEs to continually improve. You probably heard about the huge Cloudstrike event a month or so back that delayed flights all over the world. Well their team diligently wrote up a post mortem that included a lot of helpful information on what they’re doing to rectify the problem and how it will be avoided in the future.

Learning from Mistakes at Amazon

Whenever a large customer impacting event or failure happens, we tend to write a COE. It’s not about pointing fingers or shifting blame. That’s the key. The entire purpose of the COE is to draw out lessons learned and figure out actionable steps to prevent the same mistake from happening again.

I’ve had my share of writing and reviewing these COEs, and the process is a valuable learning experience. A failure that causes downtime or impacts customers can be nerve-wracking, but the COE turns it into an opportunity for growth. Instead of looking at what went wrong, we focus on why it went wrong and how we can fix it moving forward.

In a future issue I’ll talk more about the specific details of a post mortem, how it should be written, and what to and not to include in one.

Move Fast and Break Things—But Not So Much Anymore

Remember Meta’s famous motto, "Move fast and break things"? It was a rallying cry for innovation at speed, encouraging engineers to take risks, break systems, and learn from the wreckage. And it worked, for a while. But the company eventually realized that too much breaking can lead to instability and long-term damage. As they scaled, the focus shifted toward building stable, reliable products. They still emphasize innovation, but now it’s more about “Move fast with stable infrastructure.” It’s a reminder that while failure is essential for growth, the stakes get higher as you scale.

Embrace Failure, Innovate Freely

So, here’s my advice: stop trying to avoid mistakes at all costs. They’re inevitable, and they’re necessary. If you’re not making them, you’re probably not pushing yourself hard enough. Failure is part of the process, but it’s also part of the fun. Each misstep opens a door to something new.

The next time you hit a snag, don’t get discouraged. Instead, ask yourself: what is this mistake teaching me? How can I use this to fuel my next innovation?

That’s where the real magic happens. Failure is just the first step on the path to improving yourself.

In the silence that followed, I waited for the backlash, but instead, something amazing happened. The lead engineer offered to help me break down the problem, and other teammates began sharing their thoughts and experiences. What could have been a solo failure turned into a group effort to find a way forward. That moment taught me a valuable lesson: admitting what you don’t know isn’t just liberating—it’s transformative. It takes a certain quiet strength to let go of your ego and embrace humility.

Humility as a Superpower in Engineering

In engineering, there’s a constant pressure to have answers. After all, we’re paid to solve problems, right? But here's the thing: technology moves so fast that it’s impossible for one person to know everything. Admitting this reality is where real strength lies. The ability to deliberately not care about appearing smart is a rare form of strength. The truth is, the best engineers aren’t the ones who know everything; they’re the ones who admit when they don’t and are willing to learn.

There’s a specific kind of freedom that comes with acknowledging your gaps in knowledge. It’s the opposite of impostor syndrome, where you’re constantly afraid of being exposed as inadequate. Humility allows you to shift the focus away from proving yourself and instead toward improving yourself. When you admit what you don’t know, you’re giving yourself permission to grow.

The Growth Mindset in Action

A fixed mindset tells you that your abilities are set in stone—you either know something, or you don’t. On the other hand, a growth mindset views knowledge as fluid and ever-evolving. People with a growth mindset embrace challenges because they see them as opportunities to improve. In engineering, this mindset is critical because no one knows everything, and the field is constantly changing.

I remember working with a principal engineer who always seemed to be one step ahead of everyone else. He wasn’t afraid to admit when he was stuck or didn’t understand something. In fact, he often encouraged engineers to ask the questions we were too afraid to voice. That kind of humility didn’t make him less respected; it made him more approachable, more trustworthy. It was a perfect example of how humility fosters collaboration and team growth.

Humility Fosters Stronger Teams

Admitting your gaps isn’t just about personal growth—it’s also essential for building effective teams. When you’re upfront about what you don’t know, you create a space where others feel safe doing the same. I’ve seen teams struggle with solving problems simply because no one wanted to admit they didn’t fully understand the issue. Weeks were wasted chasing incomplete ideas, only for the truth to finally come out: the original assumptions were flawed.

It’s like that classic story in "The Emperor’s New Clothes". Everyone saw the emperor had no clothes, but no one dared to speak up. Humility in engineering teams acts like the honest child in the story—it cuts through the façade and opens up a real conversation. By creating an environment where it’s okay to not know, you save time, and the team can focus on finding real solutions rather than spinning wheels.

Humility and Long-Term Success

There’s also a strategic advantage to admitting what you don’t know. It’s not just about collaboration or even personal growth—it’s about staying adaptable in the long term. In "Antifragile", Nassim Taleb talks about the concept of antifragility: things that get stronger through stress and uncertainty. Engineers who embrace humility become antifragile—they don’t break when confronted with gaps in their knowledge. Instead, they use those moments to become stronger and more resilient.

The best part is, when you admit you don’t know something, you invite others into the problem-solving process. You gain new perspectives, learn from those around you, and ultimately become a more well-rounded engineer. Humility, in this sense, is not about thinking less of yourself—it’s about recognizing that you don’t have all the answers and being okay with that.

So, the next time you find yourself in a situation where you don’t know the answer, try admitting it. Let go of the fear of judgment. Ask the question. Seek the advice. It might feel vulnerable at first, but in that vulnerability lies the strength to grow, both as an engineer and as a person.

In the end, it’s not about having all the answers—it’s about being willing to find them.

Way back when I was a biology student, I thought my future was set. The plan was clear: study hard, go to med school, and become a doctor. But as the semesters rolled on, I found myself frustrated, unfulfilled, and, frankly, miserable. The excitement I once imagined at the prospect of helping others through medicine had faded, replaced by a dull dread each time I opened my textbooks. The unspoken pressure from family and friends also did not help. I realized that this path wasn’t for me, but the idea of switching careers felt daunting, almost impossible. After all, I’d invested so much time and effort already.

But that feeling—that nagging thought that I could be doing something else, something that truly ignited my passion—never left me. It took courage, but I eventually made the decision to switch paths. While I completely understand that switching majors as a student is nowhere near as serious or challenging as a parent making a life-altering decision with kids and responsibilities, I believe the same lessons can be applied. I fully acknowledge that my experience doesn’t come close to the complexities faced by those with greater responsibilities, but the underlying principles of flexibility and courage in the face of uncertainty still hold true. When I finally decided to step away from biology, I didn’t jump straight into another field. Instead, I gave myself the freedom to explore. I enrolled in a plethora of different courses in a single semester, spanning fields from psychology to computer science, from literature to economics. I was searching for that spark, that thing that would make me excited to get up in the morning.

The transition wasn’t easy. There were moments of doubt, where the fear of the unknown crept in. Had I made a mistake? Was I ever going to pass this Calculus course? Was I simply avoiding the hard work needed to succeed? While I was seeking advice from my advisor, they recommended a book called Thinking, Fast and Slow by Daniel Kahneman. In it, I came across the concept of the sunk cost fallacy. The book explained, the commitment heuristic as the tendency to continue an endeavor despite the current costs outweighing the benefits. This insight resonated deeply with me. Clinging to a career or major simply because of past efforts can be a trap, preventing you from pursuing something that might be a much better fit.

Understanding this principle helped me move forward without guilt. I realized that it was okay to let go of what wasn’t working, to cut my losses and focus on finding something that truly resonated with me. Eventually, my curiosity and love for problem-solving led me to software engineering. The combination of creativity and logic in coding was something I hadn’t experienced in biology, and it felt like I had finally found my niche.

But even now, I continue to question where I am and what I want to do. A few years ago, I was convinced to try a six-month stint as a manager, thinking it might be the next step in my career. But I quickly realized it wasn’t the right fit for me. The managerial role lacked the hands-on problem-solving that I loved about coding, and I found myself longing to return to the trenches of software development.

This experience taught me something crucial: it’s okay to keep questioning your path. Flexibility in your mindset is key to finding what you want to do in life. It’s about being like water, flowing and adapting to new circumstances rather than rigidly sticking to a predetermined plan. Even though I’ve settled into software engineering, I know that my journey isn’t necessarily over. I might switch paths again someday—and that’s perfectly fine.

When deciding what to do next, there are a few principles that can help guide you:

1. Listen to Your Gut: Your instincts often know when something isn’t right. If you’re feeling consistently unhappy or unfulfilled, it might be time to consider a change.

2. Gather Data: Just like in software development, where data drives decisions, collect information about what excites you. Take different courses, try new hobbies, or talk to people in various fields to see what sparks your interest.

3. Steer Clear of the Sunk Cost Trap: Don’t let past investments of time, money, or effort dictate your future. If something isn’t working, it’s okay to let go and move on to something better.

4. Embrace Flexibility: Life is not a straight path. It’s okay to pivot, to explore new directions, and to change your mind. What matters is finding what makes you happy and fulfilled.

5. Be Patient: Finding your true passion or the right career isn’t always immediate. It can take time, and that’s perfectly normal. Trust the process and allow yourself the grace to experiment and explore.

What matters is the willingness to listen to that inner voice, the one that nudges you to explore, to grow, and to change. In a world that often celebrates early success, it’s easy to feel like you’ve missed your chance if you haven’t figured it all out by 30, 40, or even 50. But that’s not true. It’s never too late to shift your career, to explore new interests, or to follow a passion that you didn’t even know you had.

So if you’re feeling stuck, unfulfilled, or simply curious about what else is out there, give yourself the permission to explore. Life isn’t about sticking to one path; it’s about finding the one that’s right for you, even if it takes a few tries to get there. And remember, every experience, whether it feels like a success or a failure, is a step toward discovering where you truly belong.

Designing Data-Intensive Applications by Martin Kleppmann

Let’s kick things off with a book that’s become almost like a bible in the world of software engineering: Designing Data-Intensive Applications. I've been a big fan of this book, returning to it time and again for inspiration. I've even held book clubs within a few teams, going through it chapter by chapter to fully absorb its lessons. If you’ve spent any time in the tech industry, you know that data is the lifeblood of modern applications. But understanding how to manage, process, and scale that data effectively? That’s where this book comes in.

Before I dove into this book, my approach was, admittedly, a bit scattered. I understood the basics—databases, transactions, etc.—but I lacked a cohesive strategy for designing systems that could handle the vast amounts of data we deal with today. This book was a game-changer. It didn’t just teach me about building systems at scale; it taught me how to think about data as a first-class citizen in the systems I was building.

What I love about Designing Data-Intensive Applications is that it’s not just a technical manual. It’s a guide to thinking holistically about the trade-offs in system design. It covers everything from the basics of database internals to the complexities of distributed systems and consistency models. The insights from this book helped me lead my team through the design and implementation of several data-heavy projects, and it’s a resource I return to again and again.

The way Kleppmann breaks down complex topics into digestible chunks is nothing short of brilliant. Whether you’re dealing with batch processing, stream processing, or designing for scalability, this book provides the foundational knowledge and the practical guidance you need to make informed decisions. It’s a book that has undoubtedly shaped my thinking and has become an indispensable part of my technical library.

The Pragmatic Programmer by Andrew Hunt and David Thomas

The next book on my list is one that I’d call a rite of passage for any software engineer: The Pragmatic Programmer. This book has been around for a while, but its lessons are timeless. When I first picked it up, I was still early in my career, wrestling with the day-to-day challenges of writing clean, maintainable code. This book helped me refine my approach to problem-solving and gave me the tools to become not just a better coder, but a better engineer.

One of the key takeaways is the importance of continuous learning and adaptability. The authors stress that software development is as much about craftsmanship as it is about engineering. This perspective was pivotal for me as I transitioned into leadership roles. It taught me to value simplicity, to embrace automation (as I’ve mentioned before, automating mundane tasks is a lifesaver), and to always be on the lookout for ways to improve both my own skills and those of my team.

Another lesson from this book that stuck with me is the idea of “tracer bullets.” This concept of building just enough to test your ideas and validate your assumptions before diving into full-scale development has saved me and my team countless hours. It’s a principle that I’ve carried with me throughout my career, and it’s one I encourage every engineer to adopt.

This book is also filled with practical advice on everything from debugging to refactoring, to managing dependencies. It’s the kind of book that you can pick up at any point in your career and find something new to learn. I’ve found that its principles have helped me become more efficient in my work and more strategic in how I approach problems. It’s a book that has truly stood the test of time.

The Phoenix Project by Gene Kim, Kevin Behr, and George Spafford

Rounding out my top three is The Phoenix Project, a book that’s a bit different from the others but just as impactful. While the previous books focus on technical skills and principles, The Phoenix Project dives into the world of IT operations, DevOps, and how organizations can be transformed by embracing a culture of collaboration and efficiency.

This book is written as a novel, which makes it an engaging read. It follows the story of Bill, an IT manager who’s tasked with rescuing a floundering project and, in the process, saving his company from disaster. Through Bill’s journey, the book illustrates key concepts in DevOps, lean manufacturing, and the Theory of Constraints—concepts that are crucial for anyone looking to lead technical teams effectively.

What struck me most about the book was how relatable the scenarios were. I’ve been in situations where it felt like everything was on fire, and this book offered not just solutions, but a new ways of thinking about solving problems. It highlights the importance of breaking down silos, improving communication between development and operations, and focusing on delivering value to the customer. These lessons have been invaluable as I’ve taken on more responsibilities, and they’ve helped me guide my teams through some pretty challenging projects.

Another key takeaway from The Phoenix Project is the emphasis on the human element in software engineering. It’s not just about tools and processes; it’s about how people work together, how they communicate, and how they overcome obstacles. This book has been a cornerstone in my understanding of how to lead teams effectively and how to drive change within an organization. It’s a must-read for anyone who wants to understand the bigger picture of how IT can drive business success.

Final Thoughts

These three books—Designing Data-Intensive Applications, The Pragmatic Programmer, and The Phoenix Project—have been instrumental in shaping my career as a software engineer and a leader. They’ve taught me how to think critically about the systems I build, how to continuously improve my craft, and how to lead teams through complex, high-stakes projects.

If you’re looking to grow in your career, whether you’re just starting out or aiming to take on more technical leadership responsibilities, I can’t recommend these books enough. They’re not just about learning new concepts—they’re about transforming how you think about your work.

Thanks for taking the time to read through this post! I hope you found it valuable, and maybe even discovered a new book to add to your reading list. As always, I’m here to connect, share ideas, and learn from each other, so don’t hesitate to reach out on LinkedIn or drop a comment below. Let’s keep the conversation going and continue growing together.

Until next time, happy reading!

There’s never enough time to get everything done in a single day. So why not automate as many things as possible? A typical day in the life of a software engineer can be littered with meetings, operational tasks, and planning. The only way to get around this and actually get something done is to automate anything you can.

Automation is powerful, especially for engineers. If you can transform the most mundane repetitive tasks into automted processes you’ll end up freeing up time for more important work. Here are the first things I would prioritize automating in an engineering organization to to enhance the team’s efficiency and productivity.

Email

I’ll start with the most obvious one. Automating your email management can greatly enhance productivity. By setting up rules to automatically delete useless emails, such as automated ticket management emails, spam, promotions, you keep your inbox uncluttered. This prevents these emails from taking up space and ensures you only see what's important. Additionally, use filters to automatically sort emails into relevant folders. This way, important messages are organized and easy to find. Whatever your email tool is there’s a way to do this. This way you reduce the time spent manually sorting through emails, making your workflow more efficient.

Build Processes

Jenkins, Travis CI, or GitHub Actions can build your code automatically whenever changes are made. I’ve had to work on complex projects where every build was a manual process. It was a real bottleneck and even more of a pain. Introducing Jenkins automated our builds, saving hours of manual work and catching issues early.

Continuous Integration and Continuous Deployment (CI/CD) pipelines automate the process of testing and deploying your applications after each commit. At a previous job, we spent countless hours manually deploying updates. CI/CD reduces errors and deployment times significantly. Nowadays there are many tools out there that make CI/CD pipelines easier to build than ever before!

Testing

Unit Tests: Automating unit tests ensures new code doesn’t break existing functionality. Tools like JUnit for Java or pytest for Python run your tests automatically. We’ve all been in that situation where a last-minute change breaks some critical feature right before a big release. Automated unit tests give thatpeace of mind, catching bugs early and preventing late-night firefighting.

Integration Tests: Automate integration tests with tools like Postman or SoapUI to ensure that different parts of your application work together correctly. During a crucial project, our integration points kept failing without notice. Automating these tests helped us identify and fix issues before they became major problems, ensuring smoother project milestones.

End-to-End Tests: Tools like Selenium or Cypress can automate end-to-end tests, simulating real user interactions with your application. Manually testing user experiences for regression is a tedious and error-prone job and regardless of how much documentation is provided can be hit or miss. Implementing automated end-to-end tests with tools like Selenium can save hours of manual testing and significantly improved release quality.

Security Testing: Automating security tests ensures your application is protected against vulnerabilities. Tools like OWASP ZAP, Snyk, and Burp Suite can automatically scan your codebase and applications for security issues. Early in my career, I encountered a security breach that could have been prevented with regular automated security testing. These tools continuously monitor for vulnerabilities, providing reports and suggesting fixes, thereby ensuring that security remains a priority throughout the development lifecycle. Integrating these tools into your CI/CD pipeline ensures that security checks are performed with every code change, reducing the risk of deploying vulnerable code.

Automated Load Testing: Automating load tests helps you understand how your application performs under stress. Tools like Apache JMeter and Locust simulate high traffic loads, identifying performance bottlenecks before they impact users. During a major release, automated load testing with JMeter revealed several performance issues that we were able to address before going live, ensuring a smooth user experience. By automating load tests, you can regularly test the scalability of your application, making sure it can handle increased traffic and usage without degrading performance.

Chaos Testing: Chaos testing, or chaos engineering, involves deliberately injecting failures into your system to test its resilience. Tools like Chaos Monkey and Gremlin automate these tests, helping you identify weaknesses in your infrastructure. In one instance, automating chaos tests allowed us to uncover critical vulnerabilities in our failover processes, which we then fixed to ensure better system reliability. By regularly running chaos tests, you can ensure that your system can withstand unexpected disruptions and continue to operate smoothly.

Code Quality and Style

Linters and code formatting tools like ESLint for JavaScript or Prettier automatically check your code for style issues and potential errors. Early in my career, code reviews were filled with nitpicking over style. Comments complaining about spacing or empty lines were all over our pull requests. This saves time and ensures your code looks clean and professional. In a previous role, implementing Prettier eliminated endless debates over formatting, allowing the team to focus on functionality and performance improvements.

Documentation

Keeping API documentation up-to-date can be challenging. Tools like Swagger or Javadoc can automatically generate documentation from your code comments, ensuring it's always current and accurate. I recall joining a project with outdated API docs—it was a nightmare. Automating documentation with Swagger made our APIs easier to understand and use, both for new team members and external partners. Tools like Doxygen can turn code comments into comprehensive documentation, making it easier to maintain and share your knowledge.

AI tools like ChatGPT or CodePilot can enhance your code documentation. You can help generate good code comments and documentation, saving time and improving clarity. However, always ensure that using such tools does not violate your organization’s guidelines on feeding code into large language models or similar systems.

Infrastructure as Code (IaC)

Tools like Terraform and AWS Cloud Development Kit (CDK) allow you to define your infrastructure in code, making it reproducible and version-controlled. During a major migration project, CDK ensured our environments were consistent and easy to set up, reducing setup time from days to hours and minimizing configuration errors. With IaC, you can automate the deployment and management of your infrastructure, ensuring that all environments (development, staging, production) are identical. This approach not only saves time but also reduces human errors, making your infrastructure more robust and reliable.

Using IaC tools, you can version control your infrastructure just like application code. This means you can track changes, review them, and roll back if necessary. During another project, we faced a critical issue where manual configurations caused inconsistencies between environments. By switching from manually configured infra to a mix of Cloudformation and CDK in different services, we eliminated this problem. CDK defined our infrastructure, allowing automated provisioning and setup. We could deploy the same configurations across multiple regions and accounts with confidence, knowing that everything would work as expected. Additionally, integrating with CI/CD pipelines ensured that any infrastructure changes were tested and reviewed before deployment, further increasing reliability and reducing downtime.

Consistent Development Environments

Docker creates consistent development environments, eliminating “works on my machine” problems. Early in my career, I spent countless hours debugging environment-specific issues. Docker containers made these problems a thing of the past, ensuring consistent behavior across all environments. By containerizing applications, Docker encapsulates all the dependencies and configurations needed to run the software, making it easier to develop, test, and deploy applications across different environments without discrepancies.

With Docker, you can create an isolated environment that mirrors your production setup, allowing developers to run applications in the same way across different machines. For example, during a critical project deadline, we encountered an issue where the development environment was not replicating the production environment correctly. This led to bugs that only appeared after deployment, causing significant delays. Implementing Docker solved this problem. Each team member could spin up a containerized version of the application that included all necessary dependencies. This approach not only sped up development but also reduced the risk of environment-related bugs making it to production. Docker Compose further simplified the process by allowing us to define multi-container applications, managing dependencies and service interactions effortlessly.

Monitoring and Alerts

I’m a big fan of CloudWatch (Go Figure!). Through it you can automate the monitoring of your application’s performance and resource usage, providing real-time insights into your system’s health. I’ve been in a situation or two before where automated monitoring with CloudWatch alerted us to a critical memory leak before it caused any downtime, allowing us to fix it proactively and before it had any customer impact. CloudWatch Alarms can be configured to send automated alerts via email, SMS, or other methods, notifying you of critical issues as soon as they occur. While you can take the manual route and setup these metrics and alarms via the AWS console, I much prefer doing so in an automated fashion via CDK. This especially helps when deploying your infrastructure across multiple regions or even accounts.

These alarms will likely end up in operational tickets. To take your automation one step further, you can automate the sourcing of graphs relevant to the alarm and links to SOPs or runbooks on operational tickets. This helps the engineer on call to solve the problem quicker and guides them on how to investigate. By including these automated links and graphs, you provide all the necessary information to increase the speed of root cause identification and mitigation. This approach ensures that whoever is on call has immediate access to the tools and knowledge needed to address issues effectively, reducing downtime and improving system reliability.

Notifications

Integrate your workflows with tools like Slack or Microsoft Teams using ChatOps tools like Hubot or Mattermost. This automates notifications about build statuses, deployments, and other important events directly in your chat channels.

Code Reviews

Standardizing pull request descriptions with templates ensures that you include all necessary information for reviewers, making the review process more efficient and thorough. This approach reduced misunderstandings and streamlined our code review process, leading to quicker approvals and fewer iterations.

Tools like SonarQube automatically review your code for potential issues, such as security vulnerabilities or code smells, providing an additional layer of quality control. During a security audit, automated reviews helped us identify and fix vulnerabilities quickly, improving our code's security and robustness.

Setting Up Command Line Aliases

Setting up command line aliases for commonly run commands is a simple yet powerful way to enhance your productivity. By reducing the need to type out long, repetitive commands, aliases save time and minimize the risk of typos and errors. This allows you to execute tasks more quickly and consistently, streamlining your workflow. Additionally, aliases can be customized to fit your specific needs, creating a more efficient and personalized command line experience. This small optimization can significantly improve your day-to-day operations, allowing you to focus on more complex and valuable tasks.

That’s all folks!!!

By automating these tasks, you can reclaim your time and reduce errors. It’s about working smarter, not harder. Set up your automation today and let the machines handle the mundane tasks while you focus on the fun and challenging parts of engineering. Automation not only improves your productivity but also enhances the quality and reliability of your work.

No matter your level of experience, there's always room to optimize and improve your workflow. Ask for feedback, reflect on what works and what doesn't, and don't be afraid to try new tools and approaches.

Thank you for reading! Your insights and interactions mean a lot to me, so please, don’t be a stranger. Feel free to reach out and connect on LinkedIn. Drop me a message, share your thoughts, or just say hello. Don’t forget to like the post and share if you’ve found this valuable!

Neglecting Code Readability

Imagine picking up a book with no punctuation, random capitalization, and an unpredictable plot. Frustrating, right? That's what poorly written code feels like. Your code is not just for machines; it's for people too. Future you, your colleagues, and maybe even open-source contributors will thank you for writing clean, readable code. Use meaningful variable names, write comments, and keep your functions focused and straightforward.

Over-Engineering

Sometimes, simpler is better. You wouldn’t use a sledgehammer to crack a nut, would you? It wastes time and resources. Stick to solving the problem at hand without adding unnecessary complexity. Over-Engineering can lead to overthinking and result in a lack of overall action and progress otherwise known as analysis paralysis. Remember, a good solution is often the simplest one that works.

Analysis Paralysis

Analysis paralysis strikes when the abundance of choices leads to a complete halt in decision-making. Barry Schwartz, in his work "The Paradox of Choice," delves into how having too many options can overwhelm us, leading to decision fatigue and dissatisfaction. He notes, "The fact that some choice is good doesn't necessarily mean more choice is better." This principle applies across all creative fields. Whether selecting the right brush for a painting, the perfect word in a novel, or the ideal strategy for a startup, the key is to simplify choices.

You can combat this paralysis by setting clear objectives and limitations for your project. Limiting options can paradoxically free you, channeling your focus on innovation rather than choice. Moreover, adopting an iterative approach, where you refine your work over time, can prevent the stagnation that comes from seeking perfection in the first draft.

From “Battling the Mind’s Barriers to Innovation” - Chemil M

Ignoring Testing

Skipping tests might save you time today but will cost you dearly tomorrow. The best software is built on a solid foundation of disciplined testing practices. Unit tests, integration tests, and end-to-end tests ensure your code works as expected and helps catch bugs early. Invest in testing to save time and frustration later. You might as well take it one step further and put in place checks and balances to make sure test coverage does not dip. This is one of the many ways of holding that high bar for testing and avoiding bugs and regression from seeping out into production and impacting customers.

“Not Invented Here” Syndrome

Reinventing the wheel isn’t just unnecessary; it’s counterproductive. Plenty of robust, well-maintained libraries and frameworks can help you. Don’t shy away from using them. Open-source contributions often come with extensive documentation and community support, making your job easier and your projects more reliable.

Skipping Documentation

I know, we all hate doing it. But the truth is that good documentation is like a roadmap for your code. It helps others (and your future self) understand your thought process and how to use or extend your software. Skipping documentation is a disservice to everyone who will interact with your code. Write clear, concise documentation and keep it up-to-date.

Writing Documentation Musn’t be delayed

Delegating work to others can only be as efficient as the material they’re given to ramp up. Sadly, Software engineers (Myself Included), love to delay writing docs. It’s just not fun.

In 2023 I faced the harsh reality that delaying writing documentation only slows the team down in the long run. Onboarding engineers took longer, I had too many repeated conversations about common issues and technical vision, and sometimes it even impacted pull requests. I wouldn’t say documentation was absent, but it was definitely inadequate. Early March, I was fed up with the number of meetings I had on my schedule to get engineers and managers up to speed with things. My outlook calendar looked like an absolute mess. From that day forward “I’m writing a doc for that” became a term I used more than I’d like but getting them done freed up my time to work on truly impactful initiatives instead of spending time on the same rinse and repeat conversations.

From “Reflecting On 2023” - Chemil M

Poor Communication

Coding is just one part of being a software engineer. Effective communication with your team, stakeholders, and users is crucial. Don’t hide behind your computer screen. Share your progress, ask for feedback, and discuss ideas openly. Good communication fosters collaboration and leads to better software.

Being Disruptive or Uncooperative

Being a software engineer isn't just about having the technical chops; it's also about playing well with others. Remember, you're part of a team, and your actions can ripple through the entire group. Avoiding disruptive or uncooperative behavior is crucial if you want to stay employed.

Think about it: arguing with teammates, refusing to follow instructions, or deliberately sabotaging projects not only kills morale and productivity but also makes you look bad as a professional. So, if you want to keep your job and maintain a good reputation, steer clear of any behavior that disrupts the team's harmony.

Ignoring User Feedback

Your users are your best critics and your best source of improvement. Ignoring their feedback is like steering a ship without a compass. Listen to them, understand their needs, and iterate on your product based on their input. It helps you build software that truly serves its purpose.

Overworking yourself (Burnout)

Now this one is easier said than done, but pushing yourself to the limit might seem heroic when in reality it’s unsustainable. Burnout leads to mistakes, reduced productivity, and even health issues. Balance is key. Take breaks, set boundaries, and make time for activities outside of coding. A well-rested mind is more creative and efficient.

Resisting Change

Technology evolves rapidly, and so should you. Clinging to outdated practices or resisting new tools and methodologies will hold you back. Back when I was an Android engineer, I was stubbornly sticking to my guns, crafting designs in XML code. I refused to switch to the new tools in Android Studio, convinced my way was best. But after hitting a roadblock with a specific feature and finally giving the new tools a try, I realized how much time I could have saved by taking a leap of faith earlier. Embrace change, stay curious, and continuously learn. It keeps you relevant and opens up new possibilities in your career.

Avoiding these pitfalls doesn’t just make you a better software engineer; it makes your work more enjoyable and sustainable. By focusing on readability, simplicity, testing, collaboration, and continuous learning, you’ll navigate the vast ocean of software engineering more effectively. Remember, knowing what not to do is just as important as knowing what to do.

Thanks for reading and keep an eye out for my next post!

Email: chemil.makhlouta@gmail.com

Picture this: you're leading a technical meeting, the kind that can stretch on for hours, filled with complex discussions. It's a scenario many of us in software engineering face as we climb the career ladder. Now, imagine that meeting spiraling out of control – a common nightmare where valuable time evaporates into thin air, leaving everyone frustrated. I've been there, in the trenches of corporate meeting rooms, for over a decade. In my journey across quite a few companies, I've gathered some techniques to help steer these meetings away from chaos and towards productivity. Whether you’re a seasoned veteran in leading technical meetings or just starting out, I hope these insights offer something valuable to add to your toolkit. Sharing this knowledge is all about helping each other grow, no matter where we are in our professional journey.

The Calm Before the Storm

Really? A meeting…… for that?

For starters, be completely sure that the meeting is actually necessary. So many meetings could just be an email or a quick slack group thread. To answer that ask yourself these questions.

1. Can this issue be resolved asynchronously? Consider if the matter needs real-time discussion or if it can be handled through non-immediate communication channels.

2. Who needs to be involved in this discussion? If only a few people are needed, it might be more efficient to have a direct conversation with them instead of a larger meeting.

3. Is there a need for collaborative decision-making? If the situation requires brainstorming or group consensus, a meeting may be justified.

4. How urgent is this matter? If it's not time-sensitive, it might be better to handle it through a less disruptive communication method.

5. What would be the outcome of this meeting? Ensure that there will be actionable results or decisions made during the meeting.

6. Have I prepared enough to make this meeting productive? If you're not ready to provide necessary information or direction, postpone the meeting until you are.

Send that invite!

After asking yourself those questions, if you’re sure you still need a meeting, you’ll need to send out the invite. Your invite is going to include a few things:

• Meeting Date/Time

• Meeting Length

• Attendees

• Agenda

• Location

• Virtual online bridge link

I’ll talk mostly about the first four since the last 2 are just blatantly obvious requirements to accommodate in person and virtual attendees.

Ah yes, nothing like spending lunch on another call!

Make sure you pick a reasonable time in the day, nobody likes 8AM meetings and only choose lunch time if you really have no other choice and it’s an urgent meeting. To get the best potential time slots it goes without saying that you’ll have the best bet by scheduling as ahead of time as possible. Not only that, make sure you aren’t setting a meeting on a public holiday or a day/time when a key stakeholder you need in that meeting is on vacation.

You set it for how long?

The length of your meeting is a lot more important than you think. You make it too short and you’ll have to reschedule a follow up. Too long and you open up much more topics in the meeting and the value of it goes down the drain. You need to find the sweet spot. Not only to avoid wasting people’s time but to also make sure you’re optimizing their attention span. Here’s a little graph that shows the obvious relationship between attention spans over time spent in a meeting.

• Start: Completely absorbed in the meeting, catching every detail.

• 10 Mins: Actively engaged, contributing and catching the nuances.

• 20 Mins: Mostly focused, occasionally jotting down notes.

• 30 Mins: Listening, but also replying to an “urgent” email.

• 40 Mins: Tuning in for key points, but also doodling on your notepad.

• 1 hr: Considering faking a family emergency to leave

• 1 hr 30 Min: Afraid you’ll get asked a question since you stopped listening 10 mins ago

• 2 hr: Struggling to keep your eyes open, on the verge of falling asleep.

Keeping meetings as short as possible is key to optimizing the attention span of your attendees. Human attention is a fickle beast, especially when the alternative is daydreaming about the weekend or that hidden stash of snacks in the office. The longer the meeting drags on, the more likely your team is mentally checking out or planning their snack heist. Short meetings keep everyone on-point and engaged, ensuring that the focus remains on the agenda and not on whether the chocolate biscuits are up for grabs in the break room. Remember, a concise meeting is a productive meeting – and one less likely to be upstaged by thoughts of munchies lurking in the office.

Who’s coming?

You need to keep your attendees to a minimum. Now, this doesn’t mean you have to always have a small group for your meeting, it’s just better to include those that are completely necessary. Now if you have some attendees that you’re unsure of then indicate their presence as optional and not required. That way they’ll only join if they have time. Outlook and other mailing apps have a feature for this when selecting attendees.

So… what’s it about?

In my journey as a Lead Engineer @ Amazon, I can recall a very specific moment that reshaped my approach to leading meetings. It was during a critical project review on my previous team. For the sake of simplicity let’s call the project “Eclipse”. We had a complex agenda, and the meeting was teetering on the edge of chaos much like the state of “Eclipse” at the time. After I held the meeting, I decided some change was needed. I had a talk with a mentor at the time and the first thing he asked me was “What was the meeting agenda?”. I had an answer, but it was just such a long winded and wordy one that I noticed it was too broad. That's when I decided to put together well-prepared agenda for the next “Eclipse” project review. I quickly drafted a clear, concise agenda, outlining our objectives and expected outcomes. To everyone's surprise, the meeting transformed. We went from a disorganized group to a focused team, efficiently tackling each point. It was a game-changer, proving that preparation isn't just a step but the keystone of successful meetings. Ever since that day, I've ensured every meeting I lead has a straight forward agenda, turning potential chaos into productive clarity. This has been the cornerstone of my approach, and it's something I encourage every professional to adopt. Trust me, it's a revelation when you see the difference it makes!

I’ve personally taken the stance of declining meetings that don’t have written agendas in their invite. Now to be clear, I don’t condone a straight up decline and ghosting the organizer. I respond with a decline/tentative and add a note asking what the agenda and expected outcomes will be. This way, I can focus on more pressing work instead of spending time catching up and potentially delaying everyone else in the meeting. The agenda doesn’t have to go into specifying the expected time allocated for every topic, although I would expect the meeting leader to track that on the side. Every good meeting Agenda contains the following:

• Topics to be discussed

• Previous context

• Linked Relevant documents

• Expected outcomes

If your meeting is going to entail reviewing a document together then provide that document to the key stakeholders and most vocal team members a few days before the meeting to give them time to review it offline. This will mean you’ll have them on the same page with you ahead of time and will produce less revisions/iterations of the document.

BONUS: MAKE SURE EVERYONE HAS ACCESS TO THE DOC!!!

I’d love to come… but I have a thing…

This is one I always miss. Check that your most important attendees have confirmed their attendance to the meeting beforehand. If not, get in touch with them and ask if a reschedule is needed. The last thing you want is to join a meeting where the key stakeholders aren’t there and you’ve just wasted 10 minutes waiting and talking about “That totally rad hike” your coworker ventured on over the weekend, the football game, or even worse …. the weather.

Heading into Battle

Why are we here again?

When I first joined Amazon, there were a few jarring changes to what I’m usually used to in meetings. For starters powerpoint presentations aren’t really a thing, instead doc reviews are preferred, this is to make sure everyone is on the same page and has consumed the same information before discussions begin. Unlike a presentation where people’s attention drifts in and out from time to time. I also noticed that the most successful and impactful meetings were the ones which started by reminding all attendees why we are gathered and what the purpose of the meeting is. This helps to contextualize the discussion but also to set clear goals for what is and is not expected to be discussed in the meeting. That usually sounds a little something like this.

“Good morning everyone, thank you for joining. The purpose of this meeting is to discuss the pipeline issues we are having that are blocking the release of project Z. The topics we will cover are 1. Infrastructural blockers, 2. Integration test failures, and 3. Beta deployment failure. By the end of this meeting we expect to have assigned action items to solve all these issues. Attendees of this meeting have context on the root cause of these issues so at this point we should only discuss mitigations.”

An opener like that clarifies the reason why we are meeting but also limits the discussion to mitigations of the issues and not for long historical tales of where the issues originated from or what their complex technical root causes are.

A long time ago in a galaxy far far away….

Make sure you keep control of your meeting! The last thing you want is someone having a good ol’ bout of ADHD storytelling and waste everyone’s time.

Avoid never-ending tangents when possible. It’s okay for a small relevant tangent topic to be mentioned here or there. But as the meeting leader it’s your job to steer the discussion in the right direction. Make sure that overly complex topics or ones that are not directly related to the purpose of the meeting are timeboxed. At times you may need to cut people off and ask them to take the topic offline or follow up later on in a separate discussion. (A good opportunity for an assigned action item).

Certain voices tend to be heard more than others. And while this is to be expected you need to avoid the meeting from getting hijacked by one specific individual rambling or telling tales of their previous battles. A good reminder of the purpose of the meeting tends to help stop this from happening.

You’ve been here the whole time!?!?!

As a meeting goes on, you may notice some attendees are less collaborative than others. Either they are not providing feedback to the doc in real time or are just not speaking up at all. This often indicates a much deeper issue, either about the team’s chemistry or about team members that are lacking confidence so it’s unlikely that you’re going to solve it all within the meeting. However it is more than okay to give them a little nudge. Something along the lines of “I feel we should hear more people’s opinions on this, especially since it’s such a crucial issue and many people have worked on pipeline X in the past. I’d love to hear more team-members’ take on this.”

Note down those notes!

As the meeting ebbs and flows important nuggets of wisdom will be dropped from time to time. Not only that but sometimes in the middle of a meeting some potential action items will pop out and quite easily be forgotten. To avoid this, you’ll either need to take notes or assign someone to do so. Preferably decide on that beforehand to avoid the awkward silence after asking for a volunteer notetaker in the middle of the meeting. Even if you do have a notetaker it’s always best to take some of your own light notes on the side as well. Keep note of significant decisions or questions that need to be followed up on.

If your meeting has a demo, or the discussion is of critical importance consider recording the meeting if possible. When you hit the record button be sure to inform all meeting attendees that you’re doing so.

It’s not you… it’s me

Be okay with the fact that some people may leave as they may feel they are not participating or don’t add a lot of value to the meeting.

The Final Countdown!!!

As the meeting comes to its final minutes make sure that the most important topics are getting wrapped up. You want to be respectful of people’s time while getting the expected outcomes from the meeting complete. Make sure you have now written up a well thought out list of action items and they’re assigned with reasonable estimations or date for dates if needed.

The Aftermath

What was that meeting about again?

Collate your notes and those from the notetaker into an update email. Provide as much context as possible including what was discussed in the meeting, what the crucial decisions made in the meeting were, and what the next steps are. This will provide ample context not only for revisiting the notes in the future but also for those that were unable to attend the meeting.

From here on in you should be able to use the team’s mechanisms that are already in place, such as daily stand ups or scrum meetings to follow up on the action items from the meeting. If you’re dealing with multiple teams, it’s best to get these updates from the respective team’s engineering manager instead of having to collate multiple updates from every single stakeholder.

Help me to help you!

No matter how senior or junior you may be it’s never a bad idea to ask for feedback. Choose one or two attendees whose opinion you hold in high regard and ask them what they think you can improve on and what they think went well in the meeting. It’s not enough to ask others, you’ll also need to do some review and reflection on your own.

That’s All Folks!

And with that, we've reached the end of today's post! I genuinely appreciate you reading through this. Your insights and interactions mean a lot to me, so please, don't be a stranger. Feel free to reach out and connect on LinkedIn. Drop me a message, share your thoughts, or just say hello. Don’t forget to like the post and re-stack if you’ve found this valuable!

This jarring experience got me thinking about habits – how deeply they're ingrained and how challenging they can be to break, especially the bad ones. As a software engineer, one such pervasive habit stands out: procrastination. It's like driving on the wrong side of the road in your professional life, leading to a journey filled with unnecessary detours and delays. Just as I had to consciously remind myself to stay on the left side of the road, shake off the instinct to turn on the wipers when I meant to signal, and remember to approach the car from the left side, software engineers too must tackle the habit of procrastination head-on. It takes a conscious effort, a deliberate reprogramming of our habits, to steer our productivity back on track.

Procrastination

Procrastination has a direct relation to stress. You don’t really stress about something you’re actively doing, especially when you’re able to get into that flow state. But delaying inevitable work ends up lingering on the back of your mind taking up important real estate in your head when it could be used for something else far more valuable. I’ve been a victim of this time and time again. Not only putting off my highest priority work but even finding other work to fill my time and distract me from the lingering stress of the important tasks I’m delaying. The reality is this only ever ended up putting me in a much worse situation later on that required me to work late nights to meet deadlines.

To overcome procrastination, you need to start by recognizing when you're avoiding a task and understand whether there's a legitimate reason for the delay. If the postponement becomes indefinite or if you're switching focus to avoid something, it's likely procrastination. You might find a task unpleasant or fear failure, but these issues need to be addressed directly. Poor organization and decision-making largely contributes to this as well, so having a well defined to-do list and prioritizing it accordingly is extremely important. The question that then comes to mind is “How do I prioritize tasks when everything seems so pressing”. Well you’ve got to start with listing your tasks and breaking down the large ones into smaller chunks. Once you have them in place, only then can you prioritize them. Finally comes the fun part, execution!

Listing your tasks and breaking down the large ones

Jumping into an ambiguous project with an inconsistent approach often times leaves you feeling lost and unaware of what you’ve truly accomplished. This is why keeping an up-to-date to-do list or task list is crucial for maintaining clarity and focus. It acts as a visual representation of your workload, helping you to understand and manage your responsibilities effectively. As tasks are completed, ticking them off will give you a sense of accomplishment and momentum. An organized list is your anchor, ensuring that nothing slips through the cracks. Tools like Notion are excellent for this. You can not only list your tasks but also categorize them, set deadlines, and even collaborate with others.

The challenge often lies in tackling larger, more complex tasks that can seem daunting at first. This is where you must break down these larger tasks into smaller, more manageable chunks. By dissecting a big task into smaller sub-tasks, you transform what appeared to be an insurmountable challenge into a series of achievable steps. Each step completed brings you closer to your final goal, making the process less overwhelming and more structured. It's not just about making the task seem more manageable; it's also about creating a clear roadmap and building a sense of progress and achievement as you tick off each sub-task.

There's still a charm and effectiveness to the old-fashioned way of using a physical journal or even sticky notes. They provide a tangible sense of control and satisfaction that digital apps sometimes lack. Personally, I use combination of Notion and a physical notepad. I find the notepad helps me keep track of more immediate/pressing thoughts especially in during long form meetings. The act of physically writing down a task can reinforce its importance, making you more committed to completing it. There's just something uniquely satisfying about the physical act of crossing off a completed task. In the end, the key is to find a system that resonates with your workflow and stick to it consistently for the best results in managing and accomplishing your tasks.

Prioritizing tasks

Eisenhower's Urgent/Important Principle is a practical tool for managing time and prioritizing tasks effectively. Through it you can categorize tasks into four quadrants based on urgency and importance. By focusing on tasks that are both urgent and important, you can identify what needs your immediate attention. Simultaneously, planning for activities that are important but not urgent helps in proactive and strategic thinking, fostering long-term success. This principle encourages a balanced approach to time management, preventing you from solely reacting to urgent matters while neglecting important but less pressing tasks.

Here's a straightforward explanation of each quadrant:

1. Urgent and Important: These are tasks you need to do right away. They're crucial for your immediate well-being or for meeting your goals. Examples might include deadlines for work or responding to a family emergency. Handle these tasks immediately to avoid crises or missed opportunities.

2. Important, Not Urgent: These tasks are important for your long-term success and satisfaction but don't need to be done right this moment. They include activities like exercise, planning for your future, or spending time with family. You should schedule time for these tasks to ensure they get done and don't slip through the cracks.

3. Urgent, Not Important: These are the things that demand your attention now but don't contribute to your long-term goals or fulfillment. They often involve helping others with their urgent issues. While these tasks might be urgent, you should minimize or delegate them as they can distract you from your important goals.

4. Not Urgent, Not Important: These are the activities that don't help you achieve your goals or fulfill your responsibilities. They can be leisure or time-wasting activities like mindlessly scrolling through social media or watching TV shows you're not really interested in. It's best to limit these activities as much as possible.

By categorizing tasks into these quadrants, you can focus on what truly matters and manage your time more effectively.

Executing your tasks

Awesome, now that you’ve got your tasks prioritized with Eisenhower's wisdom in your back pocket, it’s time to pick the most urgent and most important one and roll up your sleeves. But wait, how do you tackle this beast of a task without getting overwhelmed or, let’s be real, sidetracked by tiktok and instagram? Enter the Pomodoro Technique, your new productivity sidekick.

Imagine slicing your workday like a pizza. Each slice is a focused work session, portioned to keep you engaged and not exhausted. Set your timer for 25 minutes—yes, just like cooking a mini pizza—and dive into your task. This is your “Pomodoro,” a sacred time where it’s just you and your task, no distractions allowed.

You're in the zone, crushing it, one Pomodoro at a time. When the timer dings, congrats! You've earned yourself a guilt-free break. Take five to stretch, hydrate, or do your best victory dance. After four Pomodoros, it's time for a longer break—your brain's equivalent of a halftime show.

This technique turns monstrous tasks into a series of short sprints. Before you know it, what seemed appalling becomes applause-worthy progress. You’re not just getting things done; you’re giving a standing ovation to your productivity!

The Pomodoro Technique encourages people to work with the time they have—rather than against it. Here's how it works:

1. Choose a Task: You pick a task that you want to work on or need to get done.

2. Set a Timer: You set a timer for 25 minutes—this is one "Pomodoro."

3. Work on the Task: You work on the task until the timer rings. If a distraction pops up, write it down and get back to the task at hand.

4. Take a Short Break: Once the timer rings, put a checkmark on a piece of paper and take a short break (about 5 minutes). This helps your brain relax and refresh, making it ready for the next round of focused work.

5. Every Four Pomodoros, Take a Longer Break: After completing four Pomodoros, take a longer break (15–30 minutes). This helps prevent burnout and keeps your mind sharp for the next sessions.

The idea is that the timer creates a sense of urgency. Instead of feeling like you have endless time in the workday to get things done and then ultimately getting distracted and not making much progress, you know you only have 25 minutes to make as much progress on a task as possible. Also, the regular breaks keep your mind fresh and focused.

The Pomodoro Technique is effective for several reasons, particularly in how it aligns with human psychology and work habits:

1. Enhances Focus and Concentration: Setting a timer for a short interval minimizes distractions and fosters a sense of urgency. Knowing that the clock is ticking, you're less likely to give in to the temptation of checking your phone or browsing social media. This focused time encourages deeper concentration on the task at hand.

2. Combats Overwhelm: Breaking down work into smaller, manageable intervals makes daunting tasks seem more approachable. It's easier to motivate yourself to work on a big project when you view it in terms of several 25-minute efforts rather than a monolithic block of time.

3. Encourages Regular Breaks: Regular breaks are crucial for maintaining a high level of mental performance. The short breaks prescribed by the Pomodoro Technique (5 minutes after every 25-minute work session) allow your brain to rest and reset, reducing mental fatigue. The longer breaks after every four 'Pomodoros' give you more time to relax and recharge, preventing burnout.

4. Maintains High Productivity Through the Day: By preventing prolonged work sessions without breaks, the Pomodoro Technique helps maintain a consistent level of productivity throughout the day. This can lead to more work being done with less mental strain compared to longer, uninterrupted work sessions.

5. Provides Structure to Work: For people who struggle with time management or procrastination, the Pomodoro Technique offers a clear, simple structure. It turns the abstract concept of time into something tangible and manageable, making it easier to plan your day and track your progress.

In essence, the Pomodoro Technique taps into the natural rhythm of work and rest that suits human cognitive patterns, making it a powerful tool for enhancing productivity and managing time efficiently.

Breaking the deeply ingrained habit of procrastination requires a commitment to change. You need to start by forgiving yourself for past procrastination, committing to tasks with specified timeframes, and coming up with your own rewards for completing difficult tasks. Sometimes some form of external accountability helps where you could have someone check up on your progress from time to time. If a task seems unpleasant, focus on the long-term benefits and acknowledge the potential conquences of avoiding it. Embrace and celebrate thesmall wins and you’ll eventually have a more positive mindset overall.

That’s all for today!

And with that, we've reached the end of today's post! I genuinely appreciate you reading through this. Your insights and interactions mean a lot to me, so please, don't be a stranger. Feel free to reach out and connect on LinkedIn. Drop me a message, share your thoughts, or just say hello. Don’t forget to like the post and re-stack if you’ve found this valuable!

Delegate and Trust Others

I’ve spent the vast majority of my career in one of two mindsets. Either I get it done on my own, or I take on the most ambiguous and complex tasks in a project and hand over the simpler ones to others. Both of these stem from not trusting anybody more than myself. I wasn’t always like this, heck in uni there were a few projects where I was nothing more than a bystander hitching a free pass through a course alongside my peers. Something about a professional work environment always made me want to deliver on my word and exceed expectations. For that reason I’d always taken it upon myself to assure the timeliness of deliverables, regardless of how many people were working on a project with me and regardless of how much overtime it took. This might stem from a hunger to always do better, maybe fear of losing my job, but mostly a lack of trust with others. Whatever it was it worked until the past few years that is. As of late, obsessing over all the minute details has started to hinder my career growth. I’ve spent too much time making sure everything is done the right way instead of looking forward into the future and defining strategies that will multiply my team’s productivity and direction moving forward. Over the past year I’ve dabbled in letting go of the steering wheel and putting others in the driver’s seat and it’s paid dividends. Not only has it allowed me the time to work on more impactful things, but it’s also provided others with newly found experience and confidence in their work.

Writing Documentation Mustn’t be delayed

Delegating work to others can only be as efficient as the material they’re given to ramp up. Sadly, Software engineers (Myself Included), love to delay writing docs. It’s just not fun.

In 2023 I faced the harsh reality that delaying writing documentation only slows the team down in the long run. Onboarding engineers took longer, I had too many repeated conversations about common issues and technical vision, and sometimes it even impacted pull requests. I wouldn’t say documentation was absent, but it was definitely inadequate. Early March, I was fed up with the number of meetings I had on my schedule to get engineers and managers up to speed with things. My outlook calendar looked like an absolute mess. From that day forward “I’m writing a doc for that” became a term I used more than I’d like but getting them done freed up my time to work on truly impactful initiatives instead of spending time on the same rinse and repeat conversations.

Not all docs are good docs

It took me time, but after a few doc reviews early in the year I realized my writing needed work. I had an issue with wordiness, repetition, and context switching. This was something I always knew I needed to work on in the back of my mind, but the technical nature of my work always took priority over it. The more strategic, cross organizational documents I wrote the more I realized getting better was something I could no longer delay. So, what did I do to get better? I read some books, most notably “On Writing Well” by William Zinsser. I re-took a few technical writing courses and did a lot more reviewing of my own docs. I’d also noticed that my doc writing got worse, the more I coded. I guess this was mostly because the more I coded, the less documents I wrote and also the less books I had time to read. The more I code the more my english erodes, or maybe it’s just the brain fog from the lack of sleep, who knows. The same could be said about the late nights I spend on RTS games, but that’s a story for another time.

Focus Over Diversification

Sports, miniature painting, Real Estate, woodworking, video games, coding, board games, guitar, gym. I’m not the only one with a ridiculous list of diverse interests. The past year I’ve definitely tried to dabble in a few of these. Heck I’ll even shamelessly show you the coffee table I built from scratch and a miniature I painted this year.

Instead of becoming skilled at either one of these, I’ve managed to accomplish a few measly projects that kept me busy for a weekend or two. Maybe that’s okay for hobbies, but for side hustles and projects it’s certainly left me almost exactly where I was a year ago today.

It’s okay to fall out of love with your job from time to time

Social media is riddled with stories of unbridled passion for your work, painting a picture where every day is a dream come true. The reality is that this is not the whole truth. It's normal to sometimes feel out of sync with your work. Recognizing this as a natural part of a career can be enlightening. These periods aren’t failures; instead, they offer valuable chances for self-reflection and growth. They prompt us to ask important questions: Are we on the path we want? What new skills or challenges might reignite our passion?

Reevaluating our goals during these times can lead to rediscovering what we loved about our job in the first place or to finding new aspects that excite us. This process, rather than a sign of weakness, is a step towards a more fulfilling and sustainable career. Embracing these fluctuations helps us build resilience and maintain long-term job satisfaction.

I’ve certainly had my ups and downs over the past year with work. Continously re-assessing where I was in my career and acknowledging how I felt saved the day at times. But at times it got a lot harder. Tight deadlines and mundane tasks can do that to you and it had me down and out around the midpoint of this year. In the end I accepted that a job is a job and it’s not always going to be sunshine and rainbows. Sometimes you need to put your head down and get the things you hate doing done. Luckily enough that slump passed and the exciting tasks ended up coming my way, but only after toughing it out.

Bonus Lesson! Burnout is harder to avoid than I thought

In late 2022, I wrote “Safeguarding Your Mental Health As a Career Driven Individual” where I talked about the importance of taking breaks. The first part, “Take breaks. You need it and it’s good for you!”, was something I should have paid more attention to in my own life. I’ve come to realize that not every break is the same. Some are just a pause, a brief moment to catch your breath, while others are truly refreshing, giving you new energy and perspective. For example, Playing 20 minutes of rocket league as a break only leaves me even more fatigued.

I've learned that it’s not enough to just stop working for a while. What you do in that downtime matters a lot. It’s about finding activities that recharge your batteries, not just things that pass the time. For some, it might be a walk in the park, for others, reading a book or spending time with family. This understanding has changed how I view work and leisure. I now see that effective breaks are those that help you return to work with a clearer mind and a lighter heart. It’s about quality, not just stepping away from your desk. This new approach has made my work more enjoyable and my off-time more fulfilling. In 2024 I hope to combine the 4 previous lessons to live an burnout free life. I’m sure I’ll have a grand time re-reading that next year.

Instagram: @chemil.m

Email me @chemil.makhlouta@gmail.com

Analysis Paralysis

Analysis paralysis strikes when the abundance of choices leads to a complete halt in decision-making. Barry Schwartz, in his work "The Paradox of Choice," delves into how having too many options can overwhelm us, leading to decision fatigue and dissatisfaction. He notes, "The fact that some choice is good doesn't necessarily mean more choice is better." This principle applies across all creative fields. Whether selecting the right brush for a painting, the perfect word in a novel, or the ideal strategy for a startup, the key is to simplify choices.

You can combat this paralysis by setting clear objectives and limitations for your project. Limiting options can paradoxically free you, channeling your focus on innovation rather than choice. Moreover, adopting an iterative approach, where you refine your work over time, can prevent the stagnation that comes from seeking perfection in the first draft.

The Dunning-Kruger Effect

The Dunning-Kruger effect highlights a cognitive bias where people with limited knowledge overestimate their abilities. In their study, Dunning and Kruger explain, "The miscalibration of the incompetent stems from an error about the self, whereas the miscalibration of the highly competent stems from an error about others." This phenomenon can be particularly deceptive in creative endeavors where subjective judgment plays a significant role, like in writing, music, or design.

The key to overcoming this is continuous learning and seeking feedback. Embrace a beginner's mindset, no matter how advanced you are in your field. This approach not only keeps you grounded but also open to new ideas and perspectives, essential in any creative field.

The Four Stages of Competence

The Four Stages of Competence model provides a framework for understanding the journey from ignorance to expertise. The stages are:

1. Unconscious Incompetence: You don't know what you don't know.

2. Conscious Incompetence: You are aware of what you don't know.

3. Conscious Competence: You know how to do something but with effort.

4. Unconscious Competence: The skill becomes second nature.

This model, first described by psychologists Martin M. Broadwell and later developed by Noel Burch, illustrates the path to true mastery in any field. The journey involves recognizing gaps in knowledge, dedicating effort to learn, and eventually integrating these skills into effortless proficiency. In creative work, this path underscores the importance of self-reflection, persistent learning, and practice.

Overcoming Impostor Syndrome

I’ve experienced my fair share of imposter syndrome. Almost every time I started a new job or picked up a significant project the first thought wasn’t excitement but self-doubt instead. "Do I really belong here? What if I'm not cut out for this?" It's like an annoying voice, popping up at these critical junctures.

But here’s what I’ve learned from these bouts with Impostor Syndrome: first, it's way more common than you'd think. It's not just me; it’s a lot of us, even the most outwardly confident people. Knowing this has been a game-changer. It's not about actual incompetence; it's more about how we perceive ourselves.

The way around this is to accept that you’re where you are for a reason, embrace positive feedback when you receive it and understanding that challenges are opportunities for growth, not indicators of inadequacy.

Embracing the Uncertainty of the Creative Process

The creative process is filled with unknowns and challenges. Creative individuals often find joy in navigating the uncertainties in challenges. To get through those challenges a growth mindset can be incredibly empowering, turning potential obstacles into opportunities for growth and innovation.

Adopting a growth mindset, is crucial to get through your career’s toughest obstacles. Viewing skills and talents as developable through effort and perseverance shifts the focus from inherent talent to continuous improvement. This perspective fosters resilience and adaptability, key traits for successful work.

Thanks for reading and keep an eye out for my next post!

Email: chemil.makhlouta@gmail.com

Twitter: @ChemilM

Insta: @chemil.m

AI's Increasing Presence in Our World

Firstly, AI's integration into our daily lives is no longer a subplot in a sci-fi novel; it's our new reality. As we approach 2024, AI will further entrench itself in various facets of our lives.

Picture AI-driven personal assistants that not only manage our schedules but also predict potential conflicts and offer solutions. This isn't far-fetched; companies like Timeful and X.ai have been doing this for years and are also making strides with AI that can not only schedule meetings but also anticipate and resolve scheduling clashes.

In healthcare, we can expect AI systems to continue to move beyond disease prediction to crafting personalized healthcare plans. Firms like Tempus and Flatiron Health are already leading the charge, using AI to analyze vast datasets and provide tailored treatment recommendations. Let's also consider the burgeoning field of AI in finance. Many Banks and Companies like Kabbage are using AI to transform loan processing and risk assessment, making lending more efficient and accessible. In the realm of education, AI is set to revolutionize the way we learn. Startups like Century Tech are employing AI to provide personalized learning experiences, adapting to each student's pace and style of learning. Transportation is another area ripe for AI innovation. With companies like Tesla at the forefront, we're not just talking about autonomous vehicles, but also AI-driven traffic management systems that could reduce congestion and improve safety.

Large Language Models (LLMs) are expected to play an increasingly significant role in our daily lives, with advancements that extend far beyond current applications. One of the key areas of growth for LLMs will be in their integration into various industries and tasks, making them more accessible and useful for a wider range of people.

British multinational oil and gas giant BP, for example, is already integrating generative and classic AI technology into its culture. Their approach aims for every employee, regardless of technical experience, to build their own AI tools and share them, significantly democratizing AI use within the organization. This concept of "AI for everyone" reflects a broader trend where LLMs and generative AI become more accessible and user-friendly, allowing even non-technical users to engage with and benefit from AI technology​​.

Looking forward to 2024, we will see more enterprises and organizations investing in AI governance, as the proliferation of generative AI technology internally raises concerns about its safe and responsible use. Governance will involve controlling how employees use the technology, ensuring compliance with existing and upcoming government regulations, and staying ahead of potential legal and ethical issues​​.

Additionally, the advancement of LLMs is expected to bring about more autonomous agents. While current systems like ChatGPT require significant prompting and user intervention, future iterations will aim at requiring less prompting, understanding higher-level actions and intents from users. This will enable users to accomplish more with less intervention, making these systems more intuitive and efficient​​.

In 2023, platforms like MidJourney have already made significant strides in the realm of AI-generated imagery, showcasing the evolving capabilities of AI in creating visually stunning and complex art pieces. As we look towards 2024, these technologies are expected to advance further, potentially revolutionizing the fields of art and entertainment.

In the context of art and entertainment, the implications of the advancements in AI and LLM for 2024 are profound. Looking ahead, the industry is anticipating a shift towards more sophisticated multimodal models, akin to Google's Gemini. These models represent a significant leap in AI capabilities, moving beyond single-dimensional outputs to a more holistic, multimedia creation process. This means not just text-to-image translations but a fusion of text, image, audio, and video outputs, all seamlessly integrated by AI.

For artists and entertainers, this heralds a new era of creativity. Imagine AI tools that don't just assist in visual art creation but also contribute to filmmaking, music production, and even interactive media like video games and virtual reality. The possibilities are as endless as they are exciting.

This technological renaissance, however, isn't without its challenges. As AI becomes more integrated into creative processes, it raises questions about the essence of art and the role of the artist. The key here is balance – leveraging AI to enhance creativity without overshadowing the irreplaceable human touch that lies at the heart of art.

In 2024, we're not just looking at AI as a tool for creation but as a collaborator that brings a new dimension to the artistic process. While this raises ethical and intellectual property considerations, it also opens the door to uncharted territories of creative expression.

As we move into 2024, the landscape of AI and LLMs is set for a transformative phase, with more personalized, efficient, and multifaceted applications that could significantly impact how we interact with technology in our daily lives.

Thanks for reading and Keep an eye out for my next post where I’ll delve further into AI and LLMs, uncovering more on their evolving impact to our daily lives.

Email: chemil.makhlouta@gmail.com

Twitter: @ChemilM

Insta: @chemil.m

Here are a few pointers to consider that I’ve learnt the hard way throughout my career working at both startups and big tech.

Take breaks. You need it and it’s good for you!

I’ve been through it. 1 AM. Just 1 more bug to fix. Just let me make sure that function is not breaking my unit tests. Odds are I broke much more than that and my code would have been way better had I written it at a more reasonable hour.

“Breakfast”, “lunch”, “a midday stroll in the park” believe it or not these are more than just words to use when you don’t want to be bothered during your focus time. I can confidently say I’ve solved some of the most complex problems in my career after taking a well needed hour break and attacking the problem with a fresh mind, good cup of coffee and new perspective. Sometimes it can be hard to let go of a task or bug, especially when it is leading you down a breadcrumb trail of clues, but that extra 2-3 hours in the afternoon would likely just be a 30 minute investigation the next morning with a revitalized mind.

Taking breaks is more than just giving yourself time to breathe in any given day. You have PTO and vacation days, they are meant to be used, so use them! If you have a half decent manager, they’ll remind you to do so, but if you don’t, you’ll have to prioritize this yourself. Blasting out one more project in the financial year likely won’t make that much of a difference in the grand scheme of your career, but what will is taking well deserved time off to avoid burnout. Odds are pushing yourself to the point of burnout will only make you hate your career more and shorten its lifespan, so go on that Euro trip, sleep on the beach, or just sit at home and play Warzone.

When you need help, ask for it!

Back in the day when I got my first job in Beirut I was hellbent on restructuring the company’s android application while writing up a script to analyze customer behavior on the side. Both of which I had no experience at all in doing. After a few weeks of learning things online and reading documentation, I quickly noticed I’d gotten almost nothing done. As a junior engineer, this was really unsettling and at times made me question my whole career. Once I finally put down my walls and learnt to ask for help things started to kick off in all the right ways.

The thing is, team members will have context on certain things that may take weeks to learn. So sometimes asking questions is the right thing to do, and if they’ve documented their work properly then that’ll make the process even easier. I’ve learnt to have a good balance between RTFM and asking team members questions regardless of my position within a team and it has made my life so much easier.

Likelihood is that being a lone wolf, going off and doing things your own way, will inconvenience your coworkers on the long run much more than having a quick chat with them, so speak up!

You WILL make mistakes so don’t beat yourself up for it

My favorite introduction, came from a very senior coworker @ AWS, let’s call him Jack. “Hi my name is Jack and I break things”.

As a software engineer you never want to be that guy who pushed that one commit that shut down your system for customers. But often a production failure is a reflection of the missing checks and balances within a pipeline or release process and not the bad performance of a single person.

The reality of it all will be that one of these days you will be that person, and that’s okay, heck it comes with the territory of being a career driven individual. Don’t beat yourself up for it. With every failure comes a lesson to be learned.

If the issue caused quite a large failure consider writing a post mortem, documenting your learnings and sharing them with your coworkers so that others don’t run into the same problems in the future. (More on post mortems and how to write them in a future post)

Remember, nobody expects you to be perfect.

Celebrate your wins and don’t shy away from taking credit

Now with a few bumps on the road, eventually you’ll come to the point of delivering a fantastic project that’ll truly add value to your team and achieve high level goals. Performance reviews are something we all go through so it is important to take ownership of your great wins. Be specific and detailed when reporting the work you’ve done. Have a data driven mindset and clearly explain how your delivery has impacted customers or added value. It’s easy to belittle the hard work you’ve done and pass it onto someone else but if you review your work sometimes, you’ll surprise yourself with all the things you accomplished along the way.

So enjoy it. Throw a release party. Order some pizza, eat the cake, you deserve it.

Instagram: chem_misc

Email me @ chemil.makhlouta@gmail.com

Likelihood is that this will add very little value to what’s already out there on the internet, but if this can function as something as little as a reference to helpful documentation/tools online written by people way more qualified than I am then I’m happy to help.

Programming has a notoriety for being this voodoo language that us computer nerds use to make magic happen on computers in a “Matrix” fashion.

(The image above is not an accurate representation of what we do although it might be an accurate representation of what I see when I close my eyes at this point)

To be honest this is probably a more accurate representation.

(PSA: The individual in the above GIF is not me)

Truth is that a lot of a Software Engineer’s job has to do with planning the overall outlook of a project, coding structure and design patterns of a system, which in a way or another is similar to writing a blog (More on that in a future post).

A lot of the information and blogs you’ll find here might be catered to the software engineering industry but I’ll do my best to keep some blogs a little more generalistic.

For now all I can say is welcome to the newsletter and thank you for subscribing! If there are specific topics you’d like me to discuss in this blog I’m open for suggestions so feel free to DM/email me and I’ll do my best to get back to you!

Cheers!

Instagram: @chem_misc

chemil.makhlouta@gmail.com