DEV Community: Sagrario Meneses

Finding Strength in Code, Part 2: Lessons from Loss and the Power of Reflection

Sagrario Meneses — Fri, 28 Nov 2025 22:50:51 +0000

It’s been more than a year since I published the post — Finding Strength in Code: Navigating Emotional Overwhelm as a Software Engineer — and yeah, the trip from there to here was worth it. At some point, I realised I had built a whole personality just to fit in a place that wasn’t mine. Fixing that mess turned out to be one of the most significant projects of my life, and strangely enough, my job was one of the main tools that helped me do it. Years of tackling complex codebases and deadlines didn't just sharpen my technical skills; they equipped me to address my personal struggles and sustain a more profound sense of purpose amid life's chaos.

My inspiration for this follow-up struck at the crossroads of my daily grind and more profound reflections. Recently, my dog passed away, and once again, I found myself staring down grief. In that raw space, I revisited my original post, and it hit me: this is the natural sequel. Life keeps throwing profits and losses at you; how we process those entries—turning debits into data points for growth—shapes our capacity for joy.

A quick nod to where we left off: In the first article, I shared a toolkit for wrangling emotional overwhelm, framed through an engineer's lens. Before diving deeper, a gentle reminder: I'm not a mental health professional. These insights stem from my vantage as a software engineer who's leaned on code-like logic to stay afloat. Over the past year, those strategies have been my anchor, and one recurring mantra has fueled my resilience: "I've debugged intricate systems for over a decade, surely I can apply that to my own life." It might sound self-centred, but it's not about ego; it's about trusting the problem-solving muscle I've built through countless pull requests and late-night fixes. I'm no genius, but I believe in my capacity to iterate.

In this part, I'll unpack what I've learned from personal losses, not just surviving them, but weaving their lessons into my engineering practice to handle future ones better. We'll explore how engineering principles like multiple solutions, divide-and-conquer, and postmortems aren't just for production outages; they're blueprints for emotional recovery.

So here’s what I figured out after a few personal losses, especially this last one, and how I’m now using those lessons both in life and at work.

Every problem usually has more than one solution. The engineers who grow the fastest are the ones who can look at their own mistakes without ego, list what they’re good at and what they're not, and then actually see multiple ways forward. Same with life. A loss (a pet, a breakup, whatever) is a bug that breaks your personal system.

Recommended steps to start solving a problem:

Name and Assess: Articulate the issue plainly. What happened? What's the blast radius—does it affect sleep, relationships, or deadlines? Quantify the impact if you can (e.g., "This grief is costing me 2 hours of deep work daily"). Naming it demystifies it, turning vague fog into a ticket you can triage.
Divide and Conquer: Big losses feel monolithic, but they're not. Break them into subtasks. After my dog's passing, I couldn't "fix" the emptiness overnight, so I chunked it: Day 1: journal the memories; Day 2: walk the routes we shared; Week 1: research and expand the family to honour his legacy. In engineering, this is how we tackle monoliths—slice into services, assign owners, and parallelise. Life's no different: Enlist a "co-pilot" (therapist, friend, or accountability buddy) for the heavy lifts. I've found that splitting emotional work prevents burnout, just as modular code eases maintenance.
Collaborate When Scale Demands It: Solo debugging has limits. On sprawling systems, we rally the squad—frontend, backend, QA—to converge faster. Similarly, grief isn't meant for isolation. I've leaned on my network: a quick Slack thread with empathetic colleagues or a vulnerability share in my dev community. It distributes the load and uncovers blind spots you might miss on your own.

You're probably nodding—I'm not telling you something new. In my opinion, the real learning came after the problem was solved, such as life itself.

Once a problem is solved, it is essential to communicate the solution. The list of lessons from that solution: some companies solve problems, but never put the effort into documenting the process in a way that prevents them from happening again. I know it is impossible to avoid problems, as it is impossible not to make mistakes in our lives. The true inefficiency? Skipping the "why" and "how next time." Here are some questions to ritualise:

What triggered this, and why did it escalate?
What one tweak (process, tool, boundary) could mitigate it?
How might I respond differently (faster rollback or deeper self-compassion)?

The Postmortem: Turning "What Broke" into "What Builds"

My go-to ritual for extracting signal from noise. Borrowed from incident response, it's a structured debrief that prevents recurrence without finger-pointing. In engineering, it ensures resilience; in life, it builds emotional antifragility.
There are endless flavours of postmortems—simple Markdown outlines to full-blown docs—but the gold standard is "blameless," focusing on systems over scapegoats. Big tech pioneered accessible templates:

Google's SRE Postmortem (from their Site Reliability Engineering book): Emphasises a timeline of events, root cause via "Five Whys," impact assessment, and action items. It's shared widely to foster org-wide learning, treating incidents as resilience investments rather than failures.
Amazon's Incident Postmortem Template: A concise framework covering summary, timeline, root cause, contributing factors, and prevention plan. It's designed for cross-team input, with a nod to unplanned work in backlogs that could have averted the issue.
Netflix's Chaos Engineering-Inspired Approach: Less template-heavy, more experimental—they simulate failures (like their Chaos Monkey tool) and debrief with metrics on detection speed and recovery. Post-incident, they prioritise visibility gaps, echoing how I now track "grief metrics" like mood logs to spot patterns early.

One of my favourite habits now is running a quick, blameless postmortem, not just for production incidents, but for personal ones too. I ask myself five simple things:

What actually happened, and why did it hit so hard?
How bad was the real impact (on me, on work, on people around me)?
What triggered or worsened it?
What’s one small thing I can change so it hurts less (or less long) next time?
What did I learn that actually made me stronger?

That’s it: ten or fifteen minutes, a page in Notion, a text file or a physical notebook. Doing personal postmortems made me better at work postmortems, and doing work postmortems made me kinder to myself when life breaks. Funny how that works.

Code as Compass for the Soul

Applying these practices has transformed how I face "future losses"—not eliminating them (impossible), but shrinking their shadow. In my engineering workflow, postmortems now include a personal pulse-check: After a bug bash, I ask, "How's this echoing my off-hours state?" It keeps empathy in the loop, reminding me that resilient code starts with a resilient self.

From the first post's overwhelm hacks to this reflection ritual, the thread is clear: We're all debugging humans in a beta world. Treat your inner system with the same curiosity you'd give a legacy repo—refactor ruthlessly, test often, and version-control your growth. What's one "postmortem" you'll run this week? I'd love to hear in the comments.

Thanks for joining the journey. If this resonates, share it with a fellow dev navigating their own compile errors. Until next time—keep shipping, and keep healing.

(A note: If you're in crisis, reach out to a pro.)

New Year's Resolutions for Software Engineers

Sagrario Meneses — Sun, 29 Dec 2024 00:32:51 +0000

Oh no! Here is another post about New Year's resolutions! I know this season is already overflowing with this kind of content, and sometimes, it can feel overwhelming to use the start of a new year to set goals. However, we can’t deny that it can also serve as a powerful boost to embrace a fresh start. So, keep reading if you’re looking for inspiration to craft your resolutions. Here are some ideas and suggestions that could be valuable for any software engineer.

1. Learn a New Programming Language
Before jumping into this resolution, take a moment to reflect:

How many programming languages do I already know?
How many of them do I feel confident using?
Is there one that has recently caught my attention?

Got your answers? If you’re still unsure about what to learn or improve, I recommend checking out the book "Seven Languages in Seven Weeks" by Bruce A. Tate. Published in 2010, this book remains relevant today because of its diverse language selection. It offers a well-rounded introduction to different programming paradigms. My suggestion? Pick at least one language from the book, dive in, and conquer this resolution as soon as possible!

2. Take an Online Course or Earn a Certification
"What a time to be alive!" These days, countless resources are available online, and with the boom of AI, learning new skills has never been more accessible. Consider this:

Do you already have a cloud certification?
Would you like to build on Resolution 1 by learning a framework related to the programming language you just explored?

The opportunities are endless, so take advantage of them! Some platforms I highly recommend for this resolution include Pluralsight, Udemy, and the official documentation for any tools or technologies you’re interested in. Choose a course, commit to it, and level up your skills!

3. Share Your Knowledge Through a Post or Talk
One of the best ways to solidify your understanding of a topic is by sharing it. Even if you’ve never done it before, consider exploring options like writing a post just like this one! Pick a topic, unleash your creativity, and let your ideas flow.

Would you prefer to give a talk? Many communities on platforms like Meetup or local tech groups always seek someone brave enough to share their expertise.
Speaking from experience, I can tell you it’s a fantastic opportunity. I was incredibly nervous before my first talk, but I did it, and now it feels so much easier!

Taking this step is a valuable learning experience and a great way to expand your network and grow as a professional. So go ahead, take the leap, and share your knowledge with the world!

4. Propose or Implement an Improvement at Work
Time for some self-reflection:

Are you typically the proactive member of your team?
How many improvements or implementations did you propose this past year?
How many of those did you lead or implement?

Of course, this resolution depends on your team dynamics and how open your client or employer is to change. You know your situation better. However, there’s almost always room for optimizations, automation, or other improvements in the software engineering industry.

We’re often caught up in the rush of following instructions and meeting deadlines, but their proactivity sets professionals apart. This skill becomes more prominent at senior levels and accelerates your growth and experience.

So, give it a shot! Even if your proposal isn’t accepted, don’t be discouraged by a "no." Searching for improvement opportunities will sharpen your analytical skills and help you develop a problem-solving mindset. Who knows? Your idea might be the one to make a difference!

5. Build Habits Outside of Software Engineering
Last but (in my opinion) the most important resolution.
In our career, it’s essential to free our minds from the world of 0s and 1s once in a while. Don’t get me wrong, I love being a software engineer! However, I’ve noticed that my creativity, energy, and productivity in work and personal projects improve significantly when I make time for other activities, like exercising, drawing, reading, writing, cooking, meditating, or spending quality time with loved ones.
Before we’re professionals, we’re human beings. Finding balance in our lives sets us apart from machines. Life isn’t just about work; it’s about living fully.

We risk spending long hours sitting and staring at screens in our field. By making small changes to our daily habits—organizing our time, prioritizing self-care, and enjoying life, we can create a healthier, more fulfilling balance.

Trust me, the difference is worth it.

Conclusion

If you’ve read this far, thank you! I hope it inspires you to start the new year positively.

Bonus suggestion! Use the "SMART Goals" framework to define your New Year’s resolutions:

Specific: Clearly define what you want to achieve.
Measurable: Set metrics to track your progress.
Achievable: Ensure your goal is realistic and within reach.
Relevant: Align it with your personal or professional priorities.
Time-Bound: Set a deadline to keep yourself accountable.

Example: Instead of saying,
"I want to learn a new programming language," try...

"I will learn Python by completing a 5-week online course and building a small project by the end of March 2025."

Happy Holidays! Here’s to a successful and fulfilling 2025! 🎉

Finding Strength in Code: Navigating Emotional Overwhelm as a Software Engineer

Sagrario Meneses — Thu, 08 Aug 2024 20:11:28 +0000

Hey, it has been a while since my last post on this platform. With the recent "boom!" of AI, I started to feel like writing blog posts is no longer unique; however, recently, a personal situation broke my entire world, and I would like to do something with this energy in the middle of the disaster.

I have been working in the Tech industry since 2011, and I have had many adventures, challenges, and different situations, you know, standard stuff; we are humans.

In 2016, my father died, and it was the first time my world broke into a thousand pieces. As an engineer, I always look for a logical explanation for everything. My dad's death was sudden, without much time to get used to the idea. But in the end, there was logic: he was an older man who suffered heart failure. You don't know how much I still miss him.

More recently, I found myself facing the fact that I have been diagnosed with an autoimmune disease. It is nothing too severe and controllable with medication. I have managed to accept that situation, too.

I am now going through a separation from someone significant to me. Life sometimes puts us on different paths from the people we love. Sometimes, it makes you evaluate the things that put you on the same path in the first place and reflect on whether that feature is still in use or should be updated.

"Shit happens!"

The important thing is always to give the best of ourselves. We should always learn from every situation that happens to us. As a failed deployment, I must know where to set up the configurations next time.

The problem I've faced recently is that a failed deployment doesn't hurt as much as a personal loss unless you get fired for it, right? But assuming you don't get fired, trust me, it hurts more. A personal loss significantly impacts our concentration, our daily activities, and the quality of our work. Even if you are an expert in managing emotions (I am not), the feelings knock you out during a meeting or a problem debugging. God knows it is challenging.

Luckily, I work for a company that allows me to be human. However, to maintain trust with an employer, we must first show results and communicate clearly.

During this stage of my life, I might not share details about my situation with my team, but I raise my hand and mention that something important is happening to me, and I could need moments of support. If you work in the correct place, they will say, "You can count on us" (spoiler: I'm in the correct place, I'm very fortunate).

I will share the current list of agreements with myself with you.

Accept reality, don't force it, and stop overthinking. I know we are engineers, but please stop.
Seek professional help. A mental health specialist is your ally.
Let all your feelings flow.
This is the perfect time to gain new skills.
Write down your hateful thoughts and burn them or let them go.
Express only positive emotions and spend time with the people you love.
Exercise, eat, and sleep as much as you can.
Take hold of the strong hand of your spiritual source.
Listen to music that cheers you up.

About my tasks as a software engineer:

Split objectives and conquer. Focus on small results, and recognize you are giving your best.
Save your concentration time (check some apps to help with time organization and follow the rules).
Doing pair programming helps a lot so as not to lose concentration.
Remember the commitments you made at work and store the fulfilled register.
Remember that taking care of your work is taking care of yourself.
Post notes in your workspace that motivate you.
Ask for feedback to your coworkers.

Last but most importantly, remember that everything happens and ends. We can't control our lives like we control the logs of an application, but we can control how we feel about it. Let go; it's the best thing we can do.
If you got this far, thank you for reading this reflective post.

Today I am closer to the person I will become and I hope you are too. See you on GitHub!

The Hidden Cost of Social Media for Developers Community

Sagrario Meneses — Thu, 27 Apr 2023 23:29:45 +0000

I decided to write this opinion post because it is a topic we have always discussed. Our daily dose of "Tech Drama" gives us happiness and pleasure, but sometimes it also gives us bad feelings, such as sadness, madness and anger. What happens with the Developers in social media? (Maybe the question is "What happens with the people in social media?" and not only developers, but let me try to write this post in the context of my area.)

There is a daily competition to have the highest number of followers, be an "Influencer", and have a monetized life, which is fine, but remember,

"With Great Power Comes Great Responsibility" Uncle Ben - Spider-Man.

We have developed an addiction to creating, consuming, and sharing magical recipes. The tech community is full of headlines similar to "Learn to code in one day", "Make a lot of money programming", "Unlock your inner programmer", and "With my infallible programming course, you get a job in IT even if you have no experience", the most recent one "Become an AI expert" and don't get me wrong, it's not that these courses are rubbish or that it's impossible to reach what their titles promise, it's instead that in my opinion lately we only have that kind of posts and that forces us to do research for quality content and the decision of where we are going gets complicated.

What are some of these dangers?

For a person who is starting in the world of programming:

Information overload: Social networks have a lot of programming-related content, but not all may be relevant or accurate.
Misinformation: Social networks are also home to misinformation and fake news.
Distractions: Social networks can be very distracting and may make it difficult to focus on learning programming.

While social networks can be a valuable source of information and inspiration for beginners in programming, it's essential to approach them cautiously and be mindful of the potential dangers that that environment provides. Balancing social media consumption with practice and learning from reliable sources is necessary.

For a content creator:

Plagiarism: Social networks make it easy for content to be shared and circulated without proper attribution or permission (in this point, please consider the legal clauses of plagiarism in your country).
Trolling and harassment: Social networks can be a breeding ground for trolls and cyberbullying.
Misrepresentation of content: Social networks can distort the context or meaning of your content.
Content saturation: The vast amount of content on social networks can lead to saturation, where your content may get buried or lost in the sea of information, making it challenging to gain visibility and build an audience.
Reputation management: Social networks can play a significant role in shaping your online reputation. Harmful or misleading content about you or your work may spread quickly, and managing your reputation may become challenging, potentially affecting your credibility as a content creator.

Well, okay... every environment and everything we try has its dangers. This post does not intend to discourage or ask you to delete your social networks. It is simply a door to analysis. How much of this environment does it contribute to me as a professional?

Damages I can tell you about

I have been a technology community member for about seven years, with 12 years of experience working in IT.

Disclaimer: I enjoy drama, and I enjoy being a troll a lot of times. I have been part of this more than I would like to admit.

But, hey, there are moments that I have witnessed that have not been pleasant. Although it is fun to participate in the conversation, blocking and being blocked from somebody else's circle sometimes makes me value personal relationships over virtual ones.

Many creators seek to have followers by generating low-quality content. Why? Because it is faster to create low-quality content than high-quality content why? Because there are many topics that you can spend talking about it over and over again. Also, some throw out a "spicy" question to stir up the hornet's nest and get more visibility.

People who try to make a continuous performance around "This programming language - insert any name - is the best! And everyone who doesn't use it is a fool."

Also, people start pitching fights with others because they have opposite ideas and bring all their followers to the battle.

"Don't take it personally", it's something that is repeated a lot by conflict experts, "they're talking about a language, not about you", "it's about content that is not related to you", and the typical excuse "It's the Internet". Indeed, I agree we cannot control the external environment. We can only control our reactions and behaviours in that environment. And that's why I'm writing this, for me, to remember that and give my time there a better use, for example:

Networking: Social media platforms can be a great way to connect and stay in touch with friends, family, and colleagues, especially those far away. Social media can also provide opportunities to meet new people and form connections.
Crowdsourcing and collaboration: Social media platforms can provide opportunities for crowdsourcing and collaboration, allowing people to work together on projects, gather information, and solve problems.
Career development: Social media can be valuable for your career development, allowing people to connect with potential employers, industry experts, and mentors. It can also provide opportunities for job seekers to find job postings and learn about new opportunities.

You can think of more uses with a good impact. Good luck browsing there.

Before finishing this post, I want to give you some advice. Keep in mind the number of people on social media vs the real people;

This planet has an approximate population of 8000 million.
Around 5160 of those millions have an Internet connection.
Around 300 millions of those use Twitter(as example).
And more than once the content creators who feel powerful do not even reach 1 million.

Stay aware of your reach and the impact you can make; that means remembering these numbers the next time you participate in a "Tech Drama". And also, as part of this point, consider the differences in a person's behaviour on the Internet and face-to-face. There are many. Let's think more about our actions in the virtual world, not for others, nor to maintain followers, but for our good and growth.

Thanks for getting here, happy Social Media interaction! if you read me, say hi!

An ancient practice that we keep doing wrong: Code Review.

Sagrario Meneses — Thu, 23 Feb 2023 17:42:26 +0000

Spanish Version

What is "Code Review"?

It is the practice that software engineering teams perform to verify code changes before applying them into the principal source code.

Where to apply it

Everywhere, as a team member, as an individual contributor, and as a student. You have the opportunity to get involved, contribute and give your opinion. Some examples:

During a pair programming session:

"Two heads are better than one."

Looking into a piece of code with a coworker, developers can make recommendations, improvements and additions to the system in real-time.

In version control features, such as:

Pull Request (PR) on GitHub.
Merge Request (MR) on GitLab.

This feature allows developers to propose changes to a codebase owned by someone else. It is a way to review and discuss the proposed changes before merging them, allowing other developers to leave comments, request, or approve them asynchronously.

In any proposed piece of code:

There are other channels or ways to share code with teams. Sometimes, developers do it through Slack (or other message services), and sometimes by sharing links.
If a developer notices something to improve or add up, a tech team should be a place that allows those interactions and feedback to happen organically.

Benefits of code review

This practice significantly increases teamwork. Getting involved with the others' code and involving others in your contributions increases the success of building products. Some of the benefits are:

Fix bugs early

Let anyone among you who did not crash production be the first to throw a stone.

As humans, software engineers are not exempt from making mistakes, and it is a great advantage to have a team that supports, reviews and releases tasks together. During a code review, these mistakes can be detected and fixed.

Improve quality

It's cheaper to do things right the first time.

Establishing style rules that increase the code's readability, maintainability, and scalability helps to write quality software.

Exchange knowledge

It is an excellent tool for receiving and giving feedback, learning best practices from developers with more experience, and exchanging solutions.

Synchronization

With this practice, the team can know what everyone is working on, avoid duplicating efforts and stay up-to-date with business logic.

Basic guidelines

A good idea to apply this practice correctly in teams is to set some rules before starting.

Establish a description template with the minimum points the team will need to understand the context and purpose of a code change request and apply that template consistently in all the requests.
The minimum number of reviewers to approve a piece of code; this will depend on the size of team.
Channels or tools that will communicate to the team that a code is ready to be reviewed.
A time between the reviews means if a developer marks a piece of code ready to review and the team makes suggestions or asks for changes, and the developer update applies those changes, the amount of time that should pass in order to ask for a new review. This rule can be helpful in big teams which are involved in different systems, which need to split time between develop and review. In small teams, a rule of this kind is optional.

Effective review

A good review needs experience and professionalism rather than seniority level.

Only some developers can do a good code review, which is the main reason to write this post. This practice is not new at all. On the contrary, it has existed for decades since people have written codes. One of the earliest references to this practice as a formal process is in the book "The Mythical Man-Month" by Fred Brooks, published in 1975.

So, why is it still a popular topic? I have been working with software engineering teams for around 12 years, and I keep reading comments that are vague or aggressive in tone or lack explanation and context, which makes it challenging to produce effective code changes.

Code review IS NOT a practice for:

Demonstrating superiority.
Making colleagues feel insecure.
Imposing coding styles.
In short, being a jerk.

Here are some examples.

func search(array []int, target int) int {
    for i, val := range array {
        if val == target {
            return i
        }
    }
    return -1
}

Bad review:
"This code is bad. Why are you doing a linear search?"

Good review:
"This code block could be optimized by using a binary search instead of a linear one. Applied this would improve performance when searching large data sets."

In the bad review, there is criticism without proposing alternatives or why the code needs to be improved. On the other hand, the good one offers an optimization, explaining why that different approach can improve the function.

More bad ones:

"This code sucks." - This is unhelpful and does not provide feedback or suggestions for improvement.

"I don't understand what you're trying to do here." - This is dismissive and does not provide constructive feedback.

"I wouldn't have done it this way." - This comment is not helpful, and feedback or suggestions for improvement are missing.

Code review comments should be specific, constructive, and actionable, avoiding personal aggressions, dismissive language, and generalizations.

Altogether avoid the use of exclamation marks and icons to emphasize feedback. Finally, remember that misinterpretations in written communication are common that could occur even if the intention is good.

Code review IS a practice for:

Increasing teamwork.
Recognizing good work.
Being flexible with code styles and learn from them.
In short, being a team player.

Here is a potent suggestion, not only comment on what you consider can be changed or improved, but also comment on what you liked about an implementation, for example:

Great work! This code is very well organized and easy to follow. I particularly appreciate how you used the built-in functions in the Go standard library to simplify the code. Keep it up with the excellent work!

Also, remember to take the time. Work is demanding, and sometimes we don't take enough time for reviews, and we comment "LGTM!"(Looks good to me) to move forward, but remember, the other developer spent time working on those changes, so it's worth checking carefully.

Another suggestion is to establish conventional comments like the "NIT" (nitpicker) prefix, which means you are suggesting a change, but it does not block or prevent that request from being accepted/merged; it is simply a "perfection" that you offer but that can be ignored. You can learn more about conventional comments here.

Code review receptor

Lastly, being the person who receives reviews also needs practice.

Do not take it personal.
Even if you receive a bad comment, remember that the team's objective will always be to deliver quality. A piece of your work is in review, not your person or your work itself.
Being a team player.
Other people will use the piece of code that you wrote today. Therefore, being open to modifying your work for the good of the team and the product is essential.
Responds positively to feedback.
There will be cases in which, as the developer who wrote the piece of code, you will have reasons to believe that it is the solution that should remain, however, if someone asks for changes or suggests something else you should communicate your reasons clearly and justify them.
Participate in the review exchange.
Don't be just a spectator who only generates code to review. Also, regardless of your level, the experience obtained by analyzing code as much as possible is not surpassed by anything.

Conclusion

It is the year 2023, and AI technology accompanies us daily in our activities, some practices will disappear but the differentiators will remain. A machine can tell us what is wrong or where a piece of code can be improved, however, the warmth, empathy, and support that another human being can provide to teams can't be replaced(yet), let's continue practicing it and look forward to giving our best in all the processes where we participate.

My Experience as a Mentor

Sagrario Meneses — Wed, 07 Sep 2022 19:04:34 +0000

Spanish Version

"The circle is now complete. When I left you, I was but the learner. Now, I am the master." - Darth Vader.

Avoid being a master of evil; in the last months, I had the opportunity of being the mentor of two incredible women.

The trip started with my participation in a training program in the company I work for; the company invited people with seniority experience to be mentors of junior and mid-levels. I created my profile following the recommendations of the program team. In the beginning, the truth is I was putting some limitations on myself, such as:

"I don't know what to share"
"I'm not sure if my experience is useful for anybody."
"Maybe, I don't have a mentor profile."
"What can I teach them that they don't already know?"

Luckily, I got my match with an excellent QA Engineer. She helped me break those limits because we created a solid mentee-mentor bond from the beginning. Sharing with her mentoring sessions, listening to her situations, trying to share recommendations, or sharing my experience was an excellent opportunity for me.

Almost at the same time, a member from a women's tech community where I have participated contacted me and asked me to be a mentor of another woman with a different profile, this time most similar to mine (backend engineer), and again, I was like

"Oh... I don't know if I can do it."

But thank God I accepted, and luckily one more time, we also built a robust mentee-mentor bond, and it was a pretty cool feeling.

I was supporting and sharing stuff with two fantastic engineers. Today I do not regret anything; on the contrary, my two new friends gave me very positive feedback about my performance as a mentor. Also, another great win, during this time, one of them decided to take a new job offer, and I could enjoy the process with her.

(Images source: Hercules 1997 Disney film)

My first mentees are women, and I'm proud because I'm still working on engineering teams where there is a 10% of female presence. However, I do not limit mentoring by gender; I constantly try to share my knowledge by giving talks, writing articles or offering my help. I think the first step to collaborating with the community is definitely "start" do not let yourself stop you from sharing your knowledge. Trust me; you have something to share.

Here are some things that I learned and I can list from this experience:

We all have insecurities; help mentees to identify and manage theirs.
When our mentee shares something, we must be active listeners and ask for details. That means building a safe environment.
Help our mentees to be conscious of their capabilities; they must be able to recognize and compare how far they have come.
Usually, people do not need knowledge; they already have it or know where to obtain it. What they need is inspiration.
Being open and sharing vulnerable moments in life can help others to identify and pass their difficult moments faster.
Helping them to be visible in what they do on their team or job. Visibility can boost a career very quickly.
An informal talk can be more valuable than a formal one. However, do not lose the fact that in professional mentoring careers, the relationship, as the name says, is professional, and engineers are not psychologists. If you consider it proper, you can redirect to a specialist.
Share experience related to interview processes with your mentee; what you have already thought can speed up the mentee process.
Do not forget to provide and ask for feedback constantly. Everyone is continually growing as professionals, do not be blocked from that, and listen/share the areas of opportunity.
Share sources, books, posts, podcasts, etc., that can be helpful for your mentee, but remember it is not homework; if they have the chance, they can use those resources.

There might be other things that I could list here. But, I preferred to limit it to these ten because, in the end, we are different people, and there is no zero to a hero for being a good mentor. I can only tell you that if you want to try, take the risk and be open to constantly improving as a professional.

What was my professional growth during this experience?

I identify the following.

Confidence increased
Had the chance to go over the knowledge
Practiced the interview process
Improvements in communication
Learned from other areas
Increased networking
Experienced good feelings (fun, happiness, I felt proud)
Increased discipline

Last but not least. I want to thank my mentees for everything you taught me during this time; today, thanks to you, I am a better Senior Engineer than yesterday.

Are you Jumping into a New Job?

Sagrario Meneses — Thu, 28 Jul 2022 17:18:00 +0000

Spanish version

It was November 2020, yeah 2020, the first year without interactions in offices... Wait, I will give you more context: I had been working for 7 years for e-commerce, I was well appreciated in that job, and I liked it. We were one of the coolest e-commerce companies in LATAM. I started working there when it was a startup and I enjoyed participating in its growth. During my last year there, a big multinational corporation from LATAM acquired the company and with that acquisition, new challenges arrived.

What was I doing back then?

I was working on something important, the first API that I proposed on my own and would have an impact on the business processes. After developing the MVP more developers joined to work with me on that project, and we built the first version (that as far as I know is still in use). During that time the team was awesome, my position was good, and my opinions were respected but then, suddenly, I got a message from a friend:

"Hey! I'm working in [...] and I would like to refer you to a Senior Software Engineer position, would you be interested?"

It took me by surprise. I used to be a person who enjoys stability over money and challenges (haha) but we were full into the pandemic, and I started wondering:

"I already have 7 years of experience with this product, what would happen to me if I switch jobs?"
"Is it a good time to make this change?"

At that moment I realized I was in a kind of comfort zone! Don't misunderstand me, it is not bad to enjoy being comfortable. I did it, and it was a wonderful stage. But back then, I was thinking about new challenges...

The decision

My friend talked to me about all the good stuff the new position would bring. I decided to start the process and guess what? I got the offer! I took a deep breath and made a "leap of faith". It was not easy, you know? There are amazing engineers out there that often switch jobs and I admire them because of their strength and experience doing that. But on the other hand, there was me, specializing in a product company, being good at my job, and not looking for any changes.

What happened with my previous job?

Well, considering I was not the only one working in the API anymore, I wrote the documentation, with some proposals I imagined as the next steps for the API, talked with my coworkers giving them two weeks' notice and I left the company, a company that remains in my heart as the one that helped me become the engineer that I am today.

The beginning of a new stage!

I had no idea what would be next, but the difficult part was done. The company I work at is a global technology services provider, which means I am not necessarily working on a specific product. For a person like me, who spent 7 years in the same place, this was a very good opportunity. To start the process, once again, of being interviewed, getting new certifications, and, most importantly, switching to a new programming language. Without a doubt, this last point is something that many can do without changing jobs. However, IMO, doing your side project in different technologies is not the same as getting professional experience in those technologies in your full-time job. I enjoy my current position.

This is how my home office setup evolved during this time:

Why am I writing this post?

With the current changes in the industry and the difficult situation in the global economy, there are a lot of people switching jobs. If you are one of the lucky ones like me, and you decided to switch to a new job because it is a better opportunity for you, I want to congratulate you. Embrace the learning curve and do not look back. It's not easy, but every new achievement is a milestone in your career development. On the other hand, if you had to change jobs not because you want to, but because something happened, let me tell you changes are good. Even if we suffer them without planning it, will definitely be difficult, but what in life isn't? I just hope you can find a good place for your next challenges and that your situation is good enough to endure the change.

Conclusion

Last but not least, to everyone, as software engineers, consider updating your professional profile(LinkedIn, GitHub, etc.), being open to job offers, and networking as much as you can. Also, don't be selfish with your knowledge and skills, we are in the same guild and it's important we support each other to build the technology we deserve.

Thank you for reading this little piece of my life. I wish, with all my heart, that you achieve your goals.

Importance of code standards

Sagrario Meneses — Mon, 03 Jan 2022 17:02:14 +0000

Standards are ever present in our lives, are the building blocks of order in an otherwise chaotic world. Software Engineering is not an exception to the rule, as a consequence, code standards are a basic requirement for quality systems.

For companies, the quality of their digital applications represents growth. If you are part of a team that do not pay attention regarding following standards, please keep reading to know the advantages of this practice.

What are code standards?

Code standards are a series of rules defined for a programming language or a specific programming style. The style ensures that all engineers who contribute to a project have a single way to style their code, resulting in a consistent code base, making certain the product is easy to read and maintain.

The use of standards is very important in the quality of software, however, keeping all projects in perfect compliance with established standards is not an easy task. It requires great effort and consistency on the part of the engineering team. While more and more companies have adopted standards, there are still those that begin the development of new projects without them.

Working without code standards

When you are part of a team that does not work with rules, it is very common to see different styles of coding in the same project, which can turn into a repository that is difficult to read and maintain. If poor organization increases, this can make us spend hours trying to fix a problem.

Not establishing rules can also lead to a hostile work environment, in which some engineers write code in their own style and others write differently. At the time of unifying the work, there are discussions to choose the best option, and by not having established rules or not having them officially validated by the entire team, the discussion can be longer than normal, causing delays in the delivery of new features.

Usually, when we create a new project we focus on getting the application to work as the first goal, this is not bad, most of the software applications have a commercial or economic purpose that must be resolved in principle, but once certain stability is reached it is important to go back to review the initial product and consider refactoring, this is in order to make the future maintenance easier.

How to introduce code standards to existing projects

"Rome was not built in a day." the adaptation must be progressive. Considering that those kinds of practices are not something a team can adopt immediately, start by trying to implement standards in new projects and then gradually establish an appropriate level of standards in existing ones.

Initially, it may be difficult for the engineering team to adapt, the contrast between not having official rules established in the code review process vs. starting to have them may be a change that not everyone accepts naturally, some will take longer than others. To reduce the adaptation time, it is important to let the whole team know the main advantages of this practice.

Not all companies use the same tools in their development and it can be complicated to find the best standards that fit with your team and codebase. But a good start to achieving quality can be documenting the standards agreed upon, the team can create a standards repository that everybody can continuously reference, review, and update.

Also, you can start by adopting official standards from the tools/languages you use. Automating certain code validation processes can be of great help for continuous integration.

Considerations

Use the official standards of the tools used in each project as the base.
To improve code readability, pay attention to code styles like code segments, indentation, length of lines, and line spacing.
Naming variables, functions etc.
Establish limits in complexity or length of functions.

And most importantly, do not stop at the implementation of these rules, do not increase the technical debt in projects. Maybe today you have a very large project in which standards have never been implemented and it seems a waste to start doing it, but it is a worthwhile investment to build a quality product and also an engineering team with quality. If the implementation of these standards starts to be a real headache, it is necessary to consider a complete refactoring of your system. "Divide and conquer", it is recommended to start module by module.

Advantages of having code standards from my experience

Early error detection:
When trying to comply with the standards we established, it has been easier to detect possible errors in code reviews, preventing these problems from reaching production.
Reduction of complexity:
Complying with the rules about code style helps build cleaner code, allowing us to easily detect opportunities to simplify our functions.
Easy to read code:
Respecting the standards in our projects has allowed new team members to easily adapt to the way of work and better understanding of the code in the repositories.
Reusable code:
Thanks to the use of good practices, we have code segments that can be consumed by more than one service, reducing duplicate code.

Recommended clean code principles

It is a good strategy to familiarize the team with some principles of clean code. Below are some of the principles that can inspire an engineering team to create standards and to seek quality in the development process.

DRY - Don't Repeat Yourself.
YAGNI - You Aren't Gonna Need It.
KISS - Keep It Simple, Stupid.
SOLID
- S - Single-Responsibility Principle.
- O - Open-Closed Principle.
- L - Liskov Substitution Principle.
- I - Interface Segregation Principle.
- D - Dependency Inversion Principle.

Conclusion

Keep in mind that there will always be processes to improve but it is a continuous effort and you will be able to continue working on it.

In my experience working with different engineering teams, I have seen very good results using this practice, for example:

A reduction between 60 and 80% of incidents.
Decrease in the number of hotfix deployments.
A significant improvement in the quality of the development team.

As we can see, the definition and use of standards provide many benefits, personally, I enjoy the work more when there is an approach towards quality code than when there are no established rules. However that cannot be achieved without the work of all engineers in a team, it is about pursuing the same goal together.

PHP 8: How to Get Started

Sagrario Meneses — Mon, 27 Dec 2021 17:27:43 +0000

PHP 8 is a major update to the PHP programming language, released on November 26, 2020. Most recently PHP 8.1 was released on November 25, 2021. And still more recently on December 17, PHP 8.1.1.

According to the official page, this most recent version contains several new features and optimizations. In this post, I will tell you about some of the most interesting new features and detail how to get started. But before that, let’s talk a little about why PHP is a very special language.

What Makes the PHP Coding Language Fantastic?

PHP developers are used to dealing with jokes about being bad developers, but thankfully, this has changed recently. The truth is that being a good developer does not depend on the technologies, tools, or languages we use. Instead, being a good developer results from the qualities, skills, and experience acquired from doing our work properly.

From a business perspective, PHP has evolved significantly. Many companies are using the PHP language to create different applications. Since these companies are constantly upgrading their PHP versions, they can build new features and reach their business goals faster.

A good example of this is serverless PHP applications. I like to think that one of the significant advantages of using serverless is that we, as developers, can release code without thinking about servers. The cloud-based execution model is revolutionizing the industry, even though it’s not a new concept. Many companies are just starting to utilize serverless advantages like modularizing applications, scalability, reduced server costs, improved deployment process, etc. This paragraph alone can provide material for another blog post highlighting that PHP is not dead, contrary to what some people believe.

Nowadays, as PHP developers, we have the opportunity to work with cool stuff. Frameworks like Laravel and Symfony changed the way we set up new projects. CMSes like Drupal gave us the power to control our customization of content pages, and other contributions made by the PHP community have opened a world of opportunities.

And that is not all; today, we are enjoying the latest version of the language.

From my experience working with PHP for years, if I had to name an essential feature of the language, I would say it is the community. The PHP community is one of the warmest and most active communities nowadays, from the creator Rasmus Lerdorf to those who maintain the core of the language, people involved in creating and improving frameworks, the documentation, and the companies that use it and share their knowledge. It’s an amazing community, and I love being a part of it.

Now, let’s get into PHP 8.

Getting Started With PHP 8

If this is your first time working with PHP, lucky you! PHP 8 is an excellent version to start with. Some groundbreaking changes were introduced in this update, and I will describe some of them. Keep reading if you’re interested in joining the PHP world.

If you have experience with another PHP version, you will need to make some changes in your code to get it running. You will have it easier if you’re updating from version 7 because most of the changes were deprecated before that version.

Recommendations for the Transition to PHP8

Try to get familiar with the documentation.
Do not resist the changes: as time passes, it gets more difficult.
Consider the effort: This will depend on:
- Your current version. (as mentioned earlier)
- The size of your application.
- The priorities of your business.
Be aware of the advantages.
If you are working on a big project:
- Divide and conquer.
- Take baby steps.
Make sure to finish what you start.

The Most Interesting New Features

Constructor Property Promotion

Who does not like to see fewer lines of code? Well, with this RFC, a shorthand syntax was added. We can now combine the specification of the class properties at the constructor.

Before, your code looked like this:

Now it can look like this:

There are some constraints and specifications that you can review on the official documentation.

New in Initializers

We can now initialize the value directly in the function declaration:

Check more about this improvement on the official documentation.

Union Types

There have been times as a PHP developer where I wanted to use a more “flexible” variable. Considering the dynamic nature of the language, it can be useful. A “union type” is a collection of multiple types that indicates one of those types can be used.

PHP 8 already supports:

Type or null, using the special ?Type syntax
Array or Traversable, using the special iterable type

In the above example, the input argument can be of type Foo or Bar, and the function returns either an int or a float.

There are some exclusions, especially with the void type. Please review the official documentation for more information.

Named Arguments

This RFC allows passing arguments to a function based on the parameter name instead of the parameter position. A benefit of this new feature is that you can now skip optional parameters, which allows you to keep clean and understandable code.

You can read about the benefits, attributes, and more on the official documentation.

Enumerations

Enums for short, this RFC allows us to define a new structure much like a class that can set a group of allowed values, if you have time using PHP probably you use public constants to handle this logic. This new option avoids errors during the management of these values.

A variable may be assigned to one of those legal values, like this:

You can check the official documentation for more examples and details.

JIT Compiler

The JIT acronym means “just in time.” JIT is a compiler that promises significant performance improvements. On the web, you can find some documented posts with tests made by PHP developers comparing processes with and without JIT, and in some cases, they got a ten times performance increase using JIT.

With this compiler, there are some new opportunities for PHP developers that didn’t exist before, for example, machine learning, AI, etc. For me, this sounds promising. On the other hand, when thinking about web applications, you should know that there is no significant impact for you in using JIT right now.

Fibers

"For most of PHP’s history, people have written PHP code only as synchronous code. Execution of functions stops until a result is available to return from the function, including for I/O operations, which can be quite slow."

That is the initial paragraph in the official documentation about this RFC that seeks to eliminate the distinction between synchronous and asynchronous functions by allowing functions to be interruptible. Allows the creation of full-stack, interruptible functions that can be used to implement cooperative multitasking in PHP, also known as coroutines or green-threads.

This RFC can give us material for a new post, I will only get into a general description in order to get us familiar with it.

Methods that use:

start() pass the arguments to the callable and will return whatever the suspend() method receives.
suspend() returns whatever value the resume() method received.
resume() or throw() returns whatever the next call to suspend() received.

Fibers functions are asynchronous until the brakes are hit, calling suspend(). This passes the control to the "outside", but keep in mind this function is still alive waiting to be resumed.

Basic init example:

Check the official documentation for more details and examples.

Other Improvements That Caught My Attention

PHP 8 has added a few more warnings and changed others to exceptions, for example:

Warning to dereference null objects and arrays

When I try to access a key inside a null array, PHP 8 shows “Warning: Trying to access array offset on value of type null.”

In object references, it shows Attempt to read property {foo} on null the same warning that appears if we try to access a property on a null object.

New Errors

In PHP8, TypeError and ValueError were introduced. With these exceptions, types and value validations were enforced. The significant advantage of this enforcement is that we can now discover bugs early.

Further Thoughts

If you are thinking about upgrading your PHP version, do it securely; do not forget to visit the list of breaking changes in the upgrading document.

Remember that the level of complexity will vary depending on which version of PHP you’re upgrading. If you’re upgrading from a version greater than version 7, it might be more straightforward.

Conclusion

Here, I only mentioned a few of the many features of the latest PHP update. If this post caught your attention and you want to choose your favorite features, visit the official documentation to get familiar with all of them.

I also want to include a book recommendation, “RECTOR – The Power of Automated Refactoring”, written by two great members of the PHP community, Matthias Noback and Tomas Votruba. This book is helpful in the journey of refactoring a PHP codebase.

Keep in mind that the tech industry is constantly improving. As software engineers, we must be aware of the things that can make our work easier. Updates are usually one of them. I hope this post will be helpful for those who are interested in starting to use PHP or who already have a special affection for it.