Graduated ALX Software Engineering!

This article wraps up a documentation series on my ALX SE journey. If you haven’t read it yet, check it out here, especially the first article which talked on why I registered for the ALX SE Program.

Wanting to try something new in the documentations I write, I decided to switch the structure of this article. Instead of a straightforward recap on things, I will be going for a Question and Answer format (with questions provided by our friendly neighbourhood LLM, ChatGPT).

Q: What inspired you to enrol in the ALX Software Engineering program, and how did your expectations evolve over time?

I think my major inspiration to enrol for the ALX SE program was its curriculum. I had been looking for a way to learn some software engineering concepts (which I talked about here), and all of these concepts were outlined in the ALX curriculum.

To be fair, I had a pretty clear outline of what I wanted from the program, and I’m not sure much changed as I went through it. ALX did prove something to me though; “Do not mistake a clear vision for a short distance.” Yes the vision was there, but the work I had to put in towards achieving it? A crazy amount of work (to be fair on ALX, they did specify that the program needed ~70 hours a week.)

Q: What were some of the most complex technical challenges you faced, and how did you approach solving them?

A technical challenge worth mentioning was having to use the Command Line for almost everything! Now this might sound so mundane, but damn. In our ALX assessments, the platform we were allowed (or preferred) to use in writing code was an Ubuntu Linux CLI Operating System. The implications of this meant there no VS Code or fancy syntax highlighting, I had to grind Vim and Emacs—both are text editors on the terminal—like a kid blindfolded in a circus (Team Vi btw🔥.) It was a crazy experience.

There was no straightforward way of solving this problem though, I just had to keep using Linux and getting more adapted to working on it. I even had to get an O'Reilly book on Emacs😅. After a while, it became less weird working on the terminal, and I began to appreciate the larger set of tooling available to me on Linux. But before it became natural, it was war.

Q: Can you walk us through one of your favourite projects? What technologies did you use, and what did you learn from it?

One of my most favourite project built during the course of ALX would be SuperClap. SuperClap is a browser extension (now available on the Chrome Web Store) that allows Medium readers to engage and appreciate articles more by enabling them to give multiple claps for an article in one click. A friend and I were discussing how annoying it was having to repeatedly click on Medium’s clap button when I realized that I could do something to solve that problem, I am after all, a Software Engineer (😗😗).

This project was the first time I was building a browser extension and I had to use a JavaScript framework called Plasmo, which allowed me to create a browser extension from React code. It was a rollercoaster of experiences. With a timeline of a week and some days, I had to; talk with an interface designer on my idea of the extension—creating a base design that felt similar to Medium, get myself acquainted with using Plasmo to build a publishable extension, actually build out the extension while playing around with Medium to find a feasible way in manipulating the clap counts. And there was still the drama that came with publishing the extension and making sure that it worked well on multiple devices (and browser versions.) Again, it was a rollercoaster.

A major thing I internalized while building it, was the “power” I had in my hands (lol). Being able to think of a solution to a problem, then going ahead to build said solution. Then having people use your solution! Wild experience I tell you.

Q: How did working on infrastructure and overcoming resource constraints shape your development experience?

Okay, resource constraints. I think an instance I can think of where I had a major infrastructure/resource constraint was during my final project at the program. I planned to build a web application that was going to be taking data from a public API, using that data to generate images that could be shared among the application users. Halfway through development, I hit some errors with the API due to rate limits. I was mostly shocked than annoyed. This wasn’t even live yet, if I was hitting this error now, what would happen when the application was out in the open. I needed a better alternative fast, and the timeline for the project was closing quickly (as usual with all ALX projects🙄).

In the end, I had to build my own API setup. Sourced for a valid dataset through Kaggle, cleaned and preprocessed the dataset using Python (pandas), then hosted the processed data on a Google Sheet, converting the spreadsheet into a no-cost database and backend system (used Google’s Apps Script to make that happen.)

I literally built the API I was rate-limited out of, in a day! While I’m all for not reinventing the wheel, this taught me that sometimes one just need to have in-house solutions (and that I was capable of building a rival to a popular public API🤭.)

Q: What non-technical lessons did you learn, particularly when it came to teamwork and collaboration?

A major value that the program tried to incorporate into us, right from the start, was collaboration. I remember my first team project where I had to build a smaller version of the UNIX Bash Shell using C. And then I found out that I had to build it alongside a fellow student. It was scary. That project still remains one of the most impactful on me; not just because of the complexity, but also due to the fact that I had to constantly communicate with my project partner on our present tasks, and my attempts on them, and her attempts on them, then having to do that over and over again till we built a workable version of Bash.

Building software can be difficult naturally, and having to always tell someone what you’re trying to do can easily get annoying. Learned (the hard way) not to ever assume that the people I work with will know what I’m doing on the codebase, or that my partner will understand a particular change without adequate documentation (either through comments or commit messages.)

A quote I can remember writing while building that project was something like this; “If you think a piece of code you wrote might be complex, the task is on you to write comments/documentations that helps your teammate understand your work better.” A valid point that was important in my other team projects.

Q: How do you stay up-to-date with new technologies, and how has this mindset helped during your time in the program?

You probably would not find me checking the docs of every new JavaScript framework that gets announced, but a skill I have had to get used to, involves learning technologies when I need them.

I prefer to spend my time getting better at the tools I often use, rather than spreading myself thin on every new technology that is released. During ALX, a common site I spent time on was the DigitalOcean blogs, particularly on articles that delved into sysadmin and server management tools. This was because of the amount of system administration tasks that I was struggling with in my assessments, and learning through those articles really helped.

Now, I’m finding myself learning more about frontend technologies due to the current projects I’m working on. If I have to work on extended reality next, focusing on learning useful XR technologies would be a default.

Q: What value can you bring to a development team now that you've completed the program?

Hmm. Recently, a friend was discussing an issue he had with Kubernetes and Docker. He’s a backend engineer with a fair understanding of DevOps, and was sound boarding off me (using the innocent frontend developer—me—as a rubber duck, tch.)

Then I realized that I had an idea of the issue he was talking about. Not like I could solve the problem oo, but I understood what he meant and things that could have caused the issue. And this was because we had a topic on Docker and containerization during my specialization months at ALX.

This is something I often underestimate, the range I have in different fields of software engineering due to the ALX curriculum. Yes, my skillset (and current knowledge base) is mostly on frontend and building interfaces, but I have an understanding and have worked on tasks across multiple fields involved in building software products.

From managing a server group alongside a load balancer in distributing web traffic (Sysadmin), to using Puppet to manage configuration of these servers and creating Docker containers for scalability (DevOps), writing technical and non-technical articles (Technical Writing), to building backend applications in Flask. These experiences have made me into a “T-Shaped” Developer, and I believe that would make it easier for me to contribute (and learn) in any development team I join.

Q: What’s next for you? What are your career goals after completing the program?

Uhmm, I’m now a certified software engineer (yada yada yada) from ALX Africa with a specialization on backend engineering; but the path I have been gravitating to recently has been Interfaces, a.k.a. Frontend Engineering (across web, mobile, and virtual realities.)

My present career goals are to upskill in my knowledge of frontend technologies, while building applications I find interesting. I also hope to intern at a company that builds amazing products, and would love to learn while contributing to their growth.

Above all things, I look forward to always attempting to #dohardthings. As a developer, as a person, as a software engineer.

Wheew, that marks the end of that Q&A session, and my documentation series on ALX Software Engineering. Thank you so much for going through it; do leave any thoughts or questions you might have in the comment section. I hope (and am working) towards getting better at my writing; feedback through the comments always help with knowing what to refine on.

So yea; sayōnara, ciao, [insert goodbye in your native language here], byee🫶🏾.