Gabriel Changamire
Before the Meta x MLH Fellowship, I understood software mainly through the act of building it. I thought about requirements, code, testing, and whether an application produced the expected result. The fellowship expanded that picture. It taught me that writing code is only the beginning of a system’s life. Once software is deployed, people depend on it, machines fail, dependencies slow down, and small problems can spread across several layers. By the end of the fellowship, I no longer looked at an application as an isolated program. I saw a living system made up of processes, networks, databases, containers, monitoring, security, and the people responsible for operating it. That deeper way of thinking is the most important thing I gained from the experience.
One of the greatest strengths of the fellowship was the conceptual foundation it gave me. We studied Linux, processes, memory, CPU behavior, disk input and output, networking, services, containers, databases, observability, and troubleshooting. At first, this amount of information could feel overwhelming because every topic connected to several others. However, those connections eventually became the point. If an application is slow, the code may not be the only cause. The machine may be under memory pressure, the CPU may be saturated, the disk may be slow, DNS may be failing, or a database query may be expensive. Production engineering required me to stop jumping to conclusions and build a structured understanding of the system.
The fellowship changed how I troubleshoot. I learned to begin with the symptoms, determine the scope of the problem, and move through the layers while gathering evidence. Is the problem affecting one user, one host, one service, or the entire system? Did it begin after a deployment or configuration change? Is the process running? Is the correct port listening? Can the service be reached locally and across the network? What do the logs and metrics show? Strong troubleshooting is not random guessing. It is a disciplined method of forming hypotheses, testing them, and narrowing the search area. Tools became more meaningful because I understood the questions they answered. Together, they allowed me to move from a vague complaint to a defensible explanation.
I also developed a clearer understanding of what happens between a user making a request and receiving a response. A request may depend on DNS, network routing, TCP, TLS, a reverse proxy, an application server, and a database before the result returns. Each layer has a purpose, but each can also fail. Learning this lifecycle showed me why production engineers need both breadth and depth. They must follow a problem across boundaries while knowing when to investigate one layer more deeply. In large systems, reliability is not created by one powerful machine. It comes from thoughtful architecture, redundancy, automation, monitoring, and engineers who can reason clearly when the system behaves unexpectedly.
The practical work made these concepts real. Building and operating software with Python, Flask, MySQL, Nginx, containers, CI/CD, Prometheus, and Grafana showed me how individual components become a realistic production service. Deployment is not simply moving code onto a server. The application must be configured correctly, dependencies must be available, ports must be understood, secrets must be handled carefully, logs must be accessible, and the service must be monitored. The fellowship pushed me to think about repeatability and automation so that a system does not depend on someone remembering fragile manual steps.
Observability was another major part of my growth. A service can appear to be running while still delivering a poor user experience, so it is not enough to ask whether a process is alive. We must also ask whether requests are succeeding, latency is acceptable, resources are healthy, and error rates are rising. Metrics, logs, dashboards, and alerts give engineers different views of the system. Prometheus and Grafana showed me how to make invisible behavior visible and create alerts that lead to action instead of noise.
Reliability and scale also became more concrete. Scaling is not only about serving more users; it means identifying bottlenecks, protecting shared resources, and keeping systems manageable as demand grows. Databases need efficient access patterns, while services need health checks and sensible limits. Queues and automation can help, but they introduce new failure conditions. I learned to consider tradeoffs instead of treating every technology as an automatic solution.
Security was part of this responsibility as well. Exposed ports, weak access controls, unsafe configurations, and mishandled credentials can all become production failures. I learned to reduce the attack surface, use secure connections, control access, and understand what should be reachable. Production engineers may not specialize in every area of security, but security awareness must be part of their everyday decisions.
The technical curriculum was only one part of the experience. The community made the fellowship feel active, supportive, and accountable. Our team meetings every Monday, Wednesday, and Friday gave the week a dependable rhythm. They encouraged me to reflect on what I had completed, explain what I had learned, identify blockers, and set priorities. Regularly communicating progress made me more intentional about my work and taught me to describe technical ideas clearly. Hearing the progress and challenges of other fellows also reminded me that growth does not happen in isolation. We were learning alongside one another and building confidence together.
The broader MLH events strengthened that sense of community. The weekly Cracking the Coding sessions gave me a consistent opportunity to practice solving problems and improve how I approached technical interviews. Mock interviews helped me work on more than finding the correct answer. They taught me to clarify the problem, communicate my reasoning, test assumptions, and respond constructively when I became stuck. Those are interview skills, but they are also engineering skills. In production environments, engineers need to explain what they observe, what they plan to test, and what risks are involved. Practicing this made me more confident and prepared.
My understanding of data structures and algorithms also became deeper. I did not want to memorize a pattern, pass a test, and stop there. I began asking what an algorithm was making the computer do. An array meant contiguous memory and indexed access. A linked structure meant references, separate allocations, and pointer traversal. Stacks, queues, hash maps, and heaps had different costs not only in Big O notation, but also in memory use and the way data moved through the machine. Even an algorithm such as Kadane’s algorithm became more meaningful when I traced the changing values, assignments, comparisons, and memory accesses behind each loop. Studying DSA at this lower hardware level connected coding practice to systems performance and made the subject feel practical rather than abstract.
Meeting senior Meta engineers was another valuable part of the fellowship. Those conversations gave me access to people who had operated systems at a scale that is difficult to reproduce in a classroom. Their experiences connected our curriculum to real production environments and showed me how technical judgment develops. I could ask about incident response, career growth, collaboration, and the habits that distinguish dependable engineers. These opportunities expanded my network and changed my sense of what was possible. I left with more people to learn from, more confidence in reaching out, and a clearer picture of the communities I hope to join.
Mentally, the fellowship challenged me in an important way. There was a great deal to absorb, and I had to remain patient while separate concepts slowly came together. I needed a growth mindset to approach difficult assignments without treating difficulty as failure. When I did not understand something immediately, I learned to break it into smaller questions, review the fundamentals, experiment, and return with a stronger model. I maintained perfect attendance, completed every assignment, earned a high overall grade, and made a serious effort to use each opportunity well. I am proud of that consistency because it reflects discipline, curiosity, and respect for the opportunity.
At the same time, I do not view the experience or my performance as flawless. There were moments when I could have moved faster, asked a question earlier, or managed the volume of information better. Recognizing that does not take away from my effort. It is part of the maturity I developed. Growth requires an honest assessment of both strengths and gaps. The fellowship taught me not to hide uncertainty, but to reduce it methodically. I am now more comfortable saying that I do not yet know something while trusting that I can investigate it, ask useful questions, and learn what is necessary.
By the end of the fellowship, I had gained more than technical skills; I had developed a systems mindset. I learned to see the path from code to deployment, from deployment to observation, and from observation to improvement. Maintaining software requires reliability, performance, scalability, security, automation, and communication. Production engineering is also deeply human. Reliable systems are built by people who share information, review decisions, respond to incidents, and help one another grow. The regular meetings, events, coding sessions, projects, mock interviews, and conversations with Meta engineers all contributed to that lesson.
Most importantly, the fellowship changed the kind of engineer I am becoming. I am more curious about what happens below the surface, more careful about evidence, and more aware of the responsibility involved when people depend on software. I now ask: How will this behave under load? How will I know when it fails? How will it recover, and can another engineer maintain it? I entered the program wanting to understand production engineering, but I finished it genuinely loving the field and seeing it as a future career. It brings together the parts of computing I enjoy most: software, Linux, infrastructure, solving problems, reliability, and continuous learning. I leave with a deeper foundation, a stronger network, greater confidence, and a mindset prepared for difficult problems. I am proud of how consistently I showed up, proud of the work I completed, and grateful for the community that helped me grow.