Screen of Codes

Lessons from the Keyboard Ballet of Pair Programming Adventures

Screen of Codes

Introduction

My first team project at ALX was a pair programming assignment that required each team to write a custom version of the versatile printf function. This post recounts my experience and a few lessons I learned from working on the project.

Background Experience

After almost two months of intensive studies and solving challenging coding tasks, the time came for us to work in teams of two. Resources were shared in advance to give us foreknowledge about the underlying concepts of the printf function.

Soon, the day to commence the project drew close and the various social media platforms on which I was a member were flooded with messages like, "I want a partner". I replied to one of these requests; we quickly introduced ourselves and waited for the day to come. During the wait period, we failed to assess each other for how prepared we were to stick through with the project. I had high hopes that my partner and I would maintain a high enthusiasm throughout the project’s timeline.

A day after commencing the project, I discovered that I only knew just enough of what we had learned so far to tackle the project. I saw this as an opportunity to advance my knowledge; to research and to seek assistance.

However, I had to resign from reaching out to others for assistance after the first attempt as the lure of self-discovery urged me.

This decision turned out to be beneficial. As of drafting this post, we have not yet completed the printf project, but the knowledge we have gained while demystifying the underlying concepts of the function is worth the effort.

Lessons Learned

The underlying concepts of the function

The printf function is a standard library function of the C Programming Language. It takes a format string as input among a variable-length list of other values. It produces a string output that corresponds to the format specifiers and the input values. The format specifiers begin with the percentage (%) character. The next character indicates the data type the function should use to translate the corresponding values to characters.

On the surface, it is as simple as typing something as the following:

#include <stdio.h>

int main(void)
{
    float score = 95.65;
    int cohort = 20;
    char *name = "Emmanuel Enchill";

    printf("Trainee name: %s\nCohort: %d\nScore: %.2f\n", name, cohort, score);

    return (0);
}
/**
 * This will print:
 * Trainee name: Emmanuel Enchill
 * Cohort: 20
 * Score: 95.65
 */

But beneath this simplicity is an underlying complexity that very few are aware of. For curious minds, visit printf and vprintf for a closer look. Despite these complexities, the underlying functions execute seamlessly. Proper code organization, proper naming of functions and proper handling of the algorithms and return values of the various sub-functions are some of the contributing factors to printf’s versatility.

Proper code organization involves grouping functions that perform closely related tasks and calling them in the right order at runtime. Properly naming functions and files also play a huge role in executing a project as bad namings can be a source of frustrations and untold challenges. These factors highlight discipline and consistency, planning for how to handle the project’s bits, critical thinking in addressing every bit of a problem, and cognizance of the concepts underlying the problem.

A function’s name should reflect exactly what it does. Similarly, a file’s name should be the collective activity name of all the functions contained in it. For example, a function’s name such as computeCircleArea() is self-explanatory and output_data.c as a file’s name denotes that, all functions in this file send their results to the standard output.

Again, the algorithms of functions, their return values and types contribute immensely to the simplicity of the printf function. These factors determine how the function will be invoked and processed at runtime.

As we worked through the project, we discovered adhering to these principles influenced our coding style and greatly reduced impending challenges.

Assess partners before commencing a team project

In pair programming, the members need to be honest with themselves, know each other’s level of understanding of the programming language of choice, the project being worked on, their preparedness to own their learning, the tools and resources, their availability and any other factors that might impact the execution of the project.

Failure to conduct this assessment might result in several challenges, among them may include the situation whereby the resourceful partner might end up teaching the other almost throughout the project timeline, the burden of the load of work the resourceful partner has to bear to get the project progressing, delay in the execution of the project and worse, the project stalling.

Team members must therefore endeavour to understand who they are and where they stand individually in terms of the project. They have to be aware of their knowledge and experiences of the tools and resources at their disposal, the project being worked on, and their determination to learn and stick through to the end and prepare accordingly.

Looking back, I have realized my partner and I would have done far better if we had assessed ourselves before commencing the project.

Own your learning

We have been told time and again to own our learning; to understand the tasks we are given, to grasp the underlying concepts of each programming lesson, to analyze every line of code we write to understand the whys and the hows and be able to explain our code to others without or with little help.

This approach to learning proves to be difficult and daunting but the benefits far outweigh the sacrifices. Not only are we able to internalize what we learn, but we are also able to think critically and apply the acquired knowledge to solve real-world problems. On the opposing side, preferring to take shortcuts by copying and pasting the codes from elsewhere does not amount to any serious learning.

We were fortunate to gain genuine insights into the printf function and the C language in general when we dedicated much time to grasp and internalize the lesson concepts.

Opportunities for growth are for grasps

Presently, software engineering is one of the most lucrative professions in the world. Many training institutions and boot camps have taken advantage of this and are charging high prices for their services. This makes it difficult for most people to afford. Even the majority of those courses offered online for free lack the industry-standard materials, and therefore fail to make the course-takers ready for the job market.

Moreover, while most universities offer similar courses for four years, ALX, in collaboration with Holberton is doing the same in a matter of 365¼ days. This is a genuine opportunity for career growth and development one can hardly kick away.

Growth opportunities are for grasps. We are to take advantage of them to prosper ourselves. Fortunately, I observed how I am changing in terms of improving my style of learning, thinking process, approaching problems, recognizing opportunities, and other positive traits by sacrificing the comfort of copying/pasting for the frustrations of grasping every concept I come across.

Conclusion

The printf function by itself is not an important factor in anyone’s life. However, following the ALX Learning Framework to demystify its underlying simplicity and versatility uncovered gems: an appreciation of how the C programming language works under the hood, a better understanding of what it takes to work in a team project, revolutionizing my learning style for continuous growth and seizing rare but life-transforming opportunities.

Thank you for your time. Have any questions or suggestions, let me know your thoughts in the comments.