If you grew up in Nigeria, there is one sentence that can stop your heart in the middle of cartoons:

“My pikin, come o.”

You know what’s coming. An errand. Go and buy bread. Go and buy salt. Go to Iya Toyin’s shop, and count your change o. And as you’re walking out of the gate, you hear the final warning:

“If I count this money and one naira is missing…”

So I did what any normal adult would do with that memory. I turned it into a 3D game. 😂

So what is Pikin Days?

Pikin Days is a free 3D browser game where you relive your Nigerian childhood, one memory at a time. Each episode is a different slice of growing up.

Episode 1 is “Hold Your Change”: run errands for the family and bring back the complete change. You pick your child, pick who is sending you (Mama, Papa, Grandma, Aunty, Uncle…), and off you go.

On the way you have to:

• find the right shop and buy the right item (salt and sugar are not the same o!)
• count your change, because sellers are not always honest
• dodge okadas, kekes and buses that are not slowing down for anybody
• run from Bingo, the neighbour’s dog who has never liked you
• decide if you’ll stop and play football with your friends… while Mama’s patience is running out
• get home before she sends someone to come and look for you

At the end, Mama gives you a trust rating. I got a C on my own game. Mama said, “Was it for tomorrow I sent you?” I felt that. 😭

Why I built it

Honestly? Nostalgia, and curiosity.

The memories in this game are ones many Nigerians share, especially those of us who grew up in the 90s and early 2000s: the kerosene lantern when NEPA took light, everybody shouting “Up NEPA!” when it came back, the secret spoonful of powdered milk and the white lips that gave you away. I kept thinking: what if you could walk inside those memories?

The other half was curiosity. I write about developer tools for a living. I explain how things work. But I had never built something like this end to end, a real 3D world in the browser that real people play, and I wanted to know what that actually feels like from the inside.

Spoiler: it feels like joy, panic, and a lot of testing on your phone at 6am.

How I built it (without being a game developer)

Here’s the stack:

• Three.js to build a living 3D Nigerian street (the stalls, the people, the okadas, the goats) that runs right in your phone’s browser, no download needed
• Mixamo for the character animations. I went in myself to choose and fit every walk, run and reaction, so the kids move like real kids
• Rapier for physics, so the child doesn’t walk through walls or get trapped behind the bread seller’s table (more on that later 👀)
• Vite + TypeScript for a fast, typed codebase that could keep up with daily updates
• ElevenLabs for the voices: Mama, the sellers, and the drivers shouting “Comot for road!” Honestly, this part was stressful. Getting the voices to sound truly Nigerian took so many tries, and a lot of takes sounded more London than Lagos 😅 I listened to every single line and kept only the ones that felt right
• A static site with a serverless backend for game stats, player votes, feedback and a private admin dashboard I use to see where players drop off

And the most important part of the workflow: I built it with an AI coding agent as my engineering team.

Now, before anybody says “so the AI built it”: no. The agent typed a lot of the code, the way a calculator does a lot of the maths. But it didn’t decide what to build, how it should feel, or when it was good enough. That was me.

Here’s what my side of the work actually looked like:

• Designing the game. The errands, counting your change, Mama’s patience running out, the trust rating, Bingo, the friends’ games that tempt you off your errand. The idea, the rules and the feel of it all.
• Making it feel Nigerian. An AI doesn’t know that a seller says “thank you, go well” after you buy, not before, or that “Comot for road!” hits different from “Please move.” Every street detail, voice line and memory went through me.
• Writing very precise instructions. Not “make the camera better”, but “when the child turns, the camera must follow behind them quickly; one-finger drag only turns the view and never zooms; most players are not gamers.” Turns out a technical writing background is a superpower here.
• Setting the rules. No real brands. No adult is ever hostile to a child. Children are never shown doing heavy labour. Nothing goes live until I say the word “push”.
• Running releases like a real product. Preview links for every change, version numbers, rollbacks ready, a stats dashboard locked behind secure sign-in, and beta testers before big updates.
• Testing like my life depended on it. On my phone, in different browsers, inside different apps, held upright and sideways.
• Asking for proof. This one I learned the hard way. “Done” and “done and verified” are not the same thing. So I started asking for screenshots and screen recordings of every fix, plus an honest table of what was verified, what was not verified and what was hidden.

It felt a lot like being a product manager, a game designer, a QA tester, a writer and a very strict Nigerian aunty, all at once.

Launch night: we broke the free tier 🎉

I posted the game on X, went to bed happy, and woke up to my stats dashboard throwing errors.

The reason? People were actually playing, and on day one I’d hit my hosting provider’s free limit of 1,000 database writes a day. Every game start, every vote and every bit of feedback was a write. I upgraded to the $5 plan, made the dashboard read without writing, and batched the counts.

Was it annoying? Yes. Was it also the best problem to have on launch day? Also yes. 🥹

The bug that was hiding in plain sight

A few days after launch, a player messaged me: the game was stuck on “Turn your phone sideways to play”. Even after turning their phone. Since launch.

And here’s the crazy part: I had seen this myself. I’d opened my own link from X, got the same screen, tapped “Open in browser”, and moved on. I genuinely thought it was just my phone.

It wasn’t my phone. It was everybody.

When you tap a link inside X, TikTok, Instagram or WhatsApp, it doesn’t open in Safari or Chrome. It opens in the app’s own mini browser. Many of them never rotate, or they rotate but never tell the page it happened. My game was waiting patiently for a “the phone is sideways now” signal that was never going to come. So people were stuck at the door.

My dashboard had been trying to tell me too. There were 188 bounces on the title screen. People came, got stuck, and left without saying a word.

That taught me two things I won’t forget:

1. If you hit something weird and work around it, your players will hit it too, and most of them won’t know the workaround. Your little workarounds are clues.
2. Most players don’t report bugs. They just leave. For every person who messages you, assume many more quietly closed the tab.

The quick fix was to check the screen’s width and height every half second instead of waiting for a rotation event. The real fix was bigger: rebuild the game to play upright. If the game works holding your phone normally, it doesn’t matter what the app’s browser does.

Before, held upright, the game was squashed. After the phone-first rebuild:

What the players (and the numbers) told me

In the first week: 140 games started and 40 new players, and that’s not counting most of launch day, when my stats were the thing that broke 😅. It also doesn’t count everyone who never made it past the title screen because of the sideways bug. But of those who did play, only 31% finished the first errand, and only 2 games made it through a full day of errands.

Ouch. But useful ouch. Combine that with the feedback and the picture got very clear:

• “The conversations are too slow.”
• “I got stuck behind the bread seller’s table and had to leave the game.”
• “When I lost my money and found it, going home was the only option, but my time was running out.”
• “My energy wears out too fast.”

Some of these weren’t just annoying, they were blockers. If you get stuck behind a table with no way out, you don’t send feedback. You close the tab.

And when I sat down and played for an hour on my phone, I found even more:

• the seller said “thank you, go well” before I’d even bought anything
• a driver shouted three different lines at me, back to back, while I was standing at a table, not even on the road
• a goat walked straight through the wall of a gutter 🐐
• my friends invited me to play police and thief, said “oya let’s go!”… and then we all just stood there
• football was being played on top of the suwe grid
• running out of time sent me on the exact same errand again, with the same list and the same shop. That one hurt, because the whole point of the game is that every errand feels different

So I made a few rules for myself that I’d now apply to any product:

• One message on screen at a time. Ever.
• Max about 12 words on a card. If they have to read, they won’t play.
• No pop-up bigger than ~60% of the screen.
• A player must never be stuck, confused, or overwhelmed. Not for one second.

The update: share your funniest moments

The newest update plays upright, opens properly from any app, follows you with a smoother camera, gives drivers their own (very dramatic) voices, and lets you save your funniest moments as short clips: Bingo chasing you, a close call with an okada, coming home late and facing Mama…

…and then share them straight to WhatsApp, TikTok or X.

What I learned

If you remember nothing else from this post:

1. Test where your users actually are. Not on your laptop. On a phone, from inside the apps people will share your link in.
2. Your dashboard is your quiet users talking. Bounces and drop-offs are feedback. Read them like messages.
3. If it feels weird to you, it’s broken for them. I worked around a bug myself and assumed it was just me. Your little workarounds are your players’ dead ends.
4. Working with AI is a skill. Be specific, set rules, and ask for proof. “It says it’s done” is not a test.
5. Never ship what you haven’t touched. Preview links, a quick play on my own phone, and a rollback ready every single time. The one time I rushed, I got a squashed game on live.
6. Ship, then listen. I found more in one week of real players than in weeks of building alone. Finding a big bug days after launch isn’t failure; that’s exactly what an MVP is for.
7. Make it personal. The bits people loved most were never the tech. It was Bingo, “Up NEPA!”, and Mama’s report card lines.

What’s next

Players get to vote on what comes next in the game, and “Up NEPA!” is currently winning with 60% of the vote. 💡 So yes, there will be a light-is-back moment. Also on my list: more errand types, more friends’ games (suwe is coming back once I get the hopping right), and more memories to collect.

It’s been a busy few weeks, so I’m taking a short break before the next update. But the game is live and free to play.

👉🏾 Play Pikin Days: pikindays.com

And tell me in the comments: what’s the most nostalgic thing you remember from your childhood errands? Mine is the walk home, counting the change three times, praying the seller didn’t cheat me. 😅

Originally published at https://dev.to on November 2, 2026.

With everything happening around AI, coding agents, automation, and shifting hiring trends, I found myself thinking seriously about the future of technical writing.

Not from a place of fear but from a place of responsibility.

If the industry is changing this quickly, then it makes sense to pause and ask: what is this role evolving into? And what skills will matter most over the next few years?

After observing trends, reading industry conversations, experimenting with AI tools, and reflecting on my own experience in developer-focused environments, one thing feels clear:

The role of the technical writer is not disappearing.

It is becoming more structured, more strategic, and more technical.

The Shift Is Already Happening

For a long time, documentation was primarily written for humans. The goal was clarity, flow, and pedagogy.

Now documentation has multiple consumers:

• Developers
• Large Language Models used for training
• AI agents retrieving information in real time

That changes the game.

AI systems do not “read” documentation the way humans do. They retrieve chunks, infer structure, and fill in gaps. When documentation is inconsistent, ambiguous, or loosely structured, agents compensate. And compensation often leads to hallucination.

This means documentation is no longer just explanatory content. It is becoming a reliability layer.

Well-structured documentation reduces incorrect API usage, lowers support tickets, improves onboarding, and increasingly affects how AI systems interact with products.

That is a significant shift.

From Content Producer to Documentation Architect

The traditional view of technical writing focused on producing clear guides and references.

The emerging version of the role looks different.

It includes:

• Designing structured knowledge systems
• Thinking in terms of schemas and information architecture
• Ensuring canonical references are consistent and versioned
• Writing with both human and machine consumption in mind
• Collaborating closely with engineering on accuracy and edge cases

In many ways, documentation is becoming infrastructure.

And infrastructure requires systems thinking.

AI Does Not Replace the Role. It Raises the Bar.

There is a common narrative that AI will replace writers.

What I am seeing instead is that AI raises the standard.

If anything, weak documentation becomes more exposed in an AI-driven environment. Ambiguity becomes more costly. Inconsistent naming becomes more visible. Missing edge cases become more problematic.

This does not eliminate the need for technical writers.

It demands stronger ones.

Skills Technical Writers Should Consider Building

Based on current trends, here are areas that I feel are increasingly important:

1. Information Architecture

Clear structure is no longer optional. Writers need to think in terms of:

• Explicit hierarchies
• Stable terminology
• Clear input and output examples
• Deterministic instructions

Structure supports both humans and machines.

2. API Literacy

Understanding how APIs are designed, versioned, and consumed makes documentation stronger. Writers do not need to become backend engineers, but comfort with technical specifications is becoming more valuable.

3. Docs-as-Code Workflows

Version control, pull requests, structured content, and collaboration within engineering workflows are becoming standard expectations in many organizations.

4. Understanding AI Retrieval Behavior

Writers do not need to build machine learning models. But understanding how AI systems retrieve and use documentation helps in designing content that is less ambiguous and more reliable.

This includes awareness of:

• Chunking
• Context windows
• Retrieval-Augmented Generation systems
• Evaluation-driven improvements

5. Strategic Thinking

Documentation impacts adoption, support load, onboarding speed, and now AI accuracy. Being able to articulate that impact elevates the role from cost center to strategic function.

Where I Think the Role Is Heading

If I had to summarize it simply, I’d say:

Technical writing is evolving from writing documents to designing knowledge systems.

It is becoming more cross-functional.
-> More structured.
-> More technical.
-> More influential.

And that is not a downgrade. It is an expansion.

The industry is shifting. The tools are evolving. Expectations are changing.

The opportunity is to evolve intentionally alongside them.

I am curious how others see this shift.

What do you think technical writing is becoming in the age of AI and agents?

These include product overviews, quick reference guides, getting started tutorials, and more.

Understanding these topics is crucial because it helps you organize the information in your technical documentation.

By reading this article, you will learn about these conceptual topics.

What are Conceptual Topics in Documentation?

Conceptual Topics provide users with a comprehensive understanding of how to use the API (Application Programming Interface).

They don’t just serve as mere reference materials; they provide guidance and context for the users to understand and use the API. They include:

• Product Overviews
• Getting Started Tutorials
• Authentication and Authorization
• Status and Error codes
• Rate limiting and Thresholds
• Quick Reference Guides
• Glossaries

Next, let’s discuss these conceptual topics in detail.

Product Overviews

Behind every technical documentation is a need or problem it’s trying to solve.

The company behind the documentation has a product or solution to market to its target audience.

And they do this by exposing the products via their API. But there’s a roadblock here, which is the target audience understanding the purpose of the API and how it solves their problem.

Now, this is where “Product Overviews” come in.

The first thing the users do when they visit the documentation is to understand the API’s purpose and functionality.

So, the Product Overview is like the initial point of contact for the users, describing how the API addresses the users’ needs or challenges.

For example, the Squarespace documentation provides a product overview as highlighted below:

From reading the Product API overview of Squarespace, you can tell its purpose and functionality.

In addition, the product overview also contains information about the limitations, use cases, and technical requirements.

Getting Started Tutorials

Okay! Now, the users understand the purpose of the API, its functionality, use cases, limitations, and technical requirements, but these are all just theories, right?

There’s no action yet. Some of the users will be curious to try the API out quickly.

This is where the Getting Started Tutorials come in.

Usually, you’ll have a link to the Getting Started Tutorials page immediately after the Product Overview page.

So, what’s the purpose of the Getting Started Tutorials?

It involves several key steps, which include obtaining API keys, setting up a development environment, and making basic API calls.

If you’re not a developer, these may sound a bit vague, so let’s go into them a little bit to see what happens in each step:

Obtaining API keys

API keys are like the secret keys that give you access to an API; you can call them unique identifiers.

When a user tries requesting the API, they are required to possess an API key, which grants them access by authenticating their request.

Getting an API key depends on the API provider, but we’re not going into that.

But usually, you would find information on how to get the API key in the API documentation.

Setting up a development environment

For users to be able to interact with the API, they would certainly need to set up a development environment, which would involve installing the necessary software and libraries.

Making basic API calls

Once the users have their API key and development environment set up, the next step is to make basic API calls. Making API calls means sending HTTP requests to the API’s endpoints and handling the responses.

A good example of documentation that includes a Getting Started Tutorial is the Google Maps JavaScript Documentation. It does the following:

• Explains the purpose of API keys and how they work in the context of the Google Maps JavaScript API
• Guides users through the process with step-by-step instructions on how to create an API key
• Guides users through the initial steps of setting up their development environment and making basic API calls by explaining how to use the API key in their projects.

With this, developers can quickly get up and running with the Google Maps JavaScript API. Look at how it looks below:

Authentication and Authorization

The companies want to ensure that only legitimate users or applications can access the API or carry out specific actions.

They want to protect their data and resources from unauthorized access. Achieving this requires documentation of information about authentication and authorization.

What are they?

Authentication is the process of verifying that the requester of the API, whether it be a user or application, is who they claim to be.

As discussed earlier, one common method of authentication is through the use of API keys.

This section in the documentation explains how to authenticate requests. For example, in a request made to an API like “https://api.example.com/data?key=YOUR_API_KEY”, the API key is added as a query parameter or can be included in the request header.

Sometimes, authentication may fail due to invalid or expired API keys. This section also covers what error messages to expect in such situations, known as “Error handling.”

Authorization, on the other hand, determines the actions an authenticated user or application is permitted to perform.

Users must be authorized or granted permission before accessing specific resources or performing actions within the API.

Authorization can be based on different access levels, such as free and pro tiers, each with distinct permissions.

In essence, this section should guide users on handling authorization.

It should include information on how users can specify their access level or permissions when making requests, such as adding additional headers or parameters like an access token or a specific flag indicating desired permissions.

Check out the GitHub API documentation to see these in action:

Status and Error codes

The outcome of the API requests made by developers would vary.

So, it’s important to provide information about the outcome of the API requests. These include status and error codes.

By providing information about the status and error codes, developers can understand whether their requests were successful, how to fix issues, or what went wrong.

What are these status codes?

You can call them standard HTTP Status codes. They are predefined codes that indicate the general outcome of an HTTP request.

For example, “200 OK” means the request was successful, while “404 Not Found” indicates that the requested resource could not be found. These are just some examples of status codes.

Also, note that API documentation often defines its own status and error codes.

This is where custom status and error codes come in.

They provide specific feedback to developers. They are called custom because they are unique to the API and can provide detailed information about the request’s outcome.

For example, an API might return a custom “429 Too Many Requests” status code when a rate limit has been exceeded.

To see an example of documentation with well-documented status and error codes, check out the Mailchimp API documentation:

Rate limiting and Thresholds

Companies or API providers worry about the reliability and performance of the API and ensuring that DoS (Denial of Service) attacks are prevented.

They do this by limiting the number of requests a user or application can make to the API within a certain timeframe.

This process is called “rate limiting”. It ensures that all users get a fair usage of the API and protects the API from abuse or overuse. It also saves the cost of transmitting data and maintaining servers.

So, this section of the documentation provides information about how the limits are enforced and how users can manage their usage to avoid being blocked.

For example, GitHub’s API Documentation provides rate limits for unauthenticated requests, authenticated requests, and requests made using OAuth tokens.

The unauthenticated requests are limited to 60 per hour, while authenticated requests have higher limits depending on the type of token used. This is how the rate limit section looks:

Quick Reference Guides

Some users are experienced and wouldn’t want to go through the detailed documentation to find what they are looking for.

These users would prefer quickly looking up an accessible resource in the documentation that they can read or glance through to understand the API’s structure, endpoints, parameters, and responses.

This accessible resource is called the “Quick Reference Guides” because it concisely summarizes the API’s endpoints, parameters, and responses.

Check out Stripe API documentation. It has a user-friendly Quick Reference Guide, as shown below:

Glossaries

Many terminologies will be used throughout the documentation, and some of these terms may be difficult for users, especially those new to the technology, to understand.

To ensure that every user can understand the technical terms and concepts, including a “Glossary” section is important.

In other words, the Glossary is a comprehensive resource that defines technical terms and concepts used throughout the documentation.

For example, the documentation for Apigee includes a great Glossary section, as shown below:

What’s more?

You’ve learned so far about the conceptual topics with real-world examples. Another section that can fall under the conceptual topics is “Best Practices.”

This section provides recommendations on better API use, including handling errors and optimizing performance. This section aims to help the users avoid common pitfalls and follow recommended patterns for using the API.

Review the Documentation samples mentioned in this article to become more familiar with how these conceptual topics are written!

Many organizations have realized in recent years that using the set of practices involved in DevOps is the key to a faster release cycle of quality software, including collaboration between Developers and Operations teams.

This article will teach you about DevOps, the Software Development Life Cycle (SDLC), its limitations, and the advantages of DevOps over the traditional system. You’ll also learn DevOps practices, terminology, and case studies.

Table of Contents

What is DevOps?

Understanding the SDLC

A system architecture for an e-learning platform

Limitations of the Traditional SDLC

Benefits of DevOps over the traditional system

Set of Practices and Terms used in DevOps

Case Studies: Examples of Companies implementing DevOps practices

Conclusion

Resources

What is DevOps?

DevOps is a set of practices that fosters collaboration between IT teams and software developers to automate the operations involved in both development and IT to achieve faster software deployment and code quality.

**I know, that’s a lot of buzzwords, but don’t worry, you’ll understand better as you read on**

You must first understand the Software Development Life Cycle process before diving into DevOps.

Understanding the SDLC

The Software Development Life Cycle comprises processes/stages that follow a hierarchical pattern. These stages are as follows:

• Planning Stage — — This is where the project’s scope (features and functions) and everything needed to develop the project are defined.

• Analysis Stage — This is where we analyze the requirements that have been gathered, which could be the components (i.e. the building blocks that would make up the system). For example, the hardware, software, data exchange mechanisms, data itself, interfaces that promote interaction between the components and sub-systems, and network infrastructure for the application’s running and deployment.

Then, we define their use cases and apply our findings to conceptualize the system architecture, which defines how the system components will collaborate to achieve the project’s end goal.

See the illustration below to understand better what a system architecture entails:

A system architecture for an e-learning platform

• Design stage — The next stage is to create a detailed design from the software architecture, which includes the user interface and database schema.

Below is an illustration of a System design:

• Implementation stage — This is where the integration of the components that have been designed happens — the writing of the code and unit tests.

• Testing stage — This is the stage where the software is tested to find errors or bugs before production.

• Deployment stage — This is when the application is made available for users to install.

• Maintenance stage — This is where the software is monitored to detect problems, fix them, or make necessary updates.

The stages listed above can be carried out using different methodologies, such as the Waterfall model (which employs a sequential approach) and the Agile methodology (which uses an iterative approach).

The Waterfall model requires the completion of each stage before moving on to the next. In contrast, Agile focuses on continuous feedback and communication between a team of developers and customers to ensure that the software developed meets the needs and requirements of the customers.

I’ll emphasize the Agile methodology because it is DevOps's SDLC method. What kind of practices happens in the Agile methodology?

• Continuous planning and prioritization of work
• Continuous integration and testing of code
• Continuous delivery of working software
• Regular retrospectives to evaluate and improve the process

Limitations of the Traditional SDLC

The Waterfall model was the traditional SDLC methodology before DevOps, and it has several limitations, including the following:

• Lack of flexibility: When changes are made to the software later on, there is no going back to make any updates because the model uses a linear approach. It would mean restarting the entire SDLC from scratch.
• Lack of customer involvement: When developing a product for human consumption, including customers in the SDLC process is critical to ensure that the product meets the customer’s needs. **I mean, what’s the point of a product that customers don’t find useful, right?**
• Slow development: The Waterfall model’s architecture makes it much more challenging to develop and make software available to users.
• High Cost: With the sequential approach to SDLC, a significant amount of testing, which is costly, will be required because there is no going back if an error occurs in the future.

Because of these limitations, many organizations have shifted to an iterative approach to SDLC management. DevOps, on the other hand, employs a flexible and iterative approach — the Agile methodology.

Let’s look at some of the advantages DevOps provides to compensate for the limitations of traditional SDLC.

Benefits of DevOps over the traditional system

DevOps has several benefits compared to traditional SDLC (Software Development Life Cycle). They include the following:

• Flexibility: DevOps is designed to be flexible, compensating for the lack of flexibility caused by traditional SDLC methodologies. The speed with which DevOps responds to and updates software demonstrates flexibility.
• Collaboration: DevOps encourages teamwork and collaboration between development and operations teams.
• Quality: DevOps enhances code quality through automated testing and infrastructure as code.
• Customer satisfaction: DevOps allows customers to participate in the SDLC process, resulting in software that meets the customer’s needs.
• Cost: DevOps significantly reduces costs by employing an iterative rather than a sequential approach, which typically necessitates rework.
• Faster release cycles: DevOps reduces the time it takes to release software by automating collaboration between development and operations teams.

Next, let’s look at some of the DevOps practices and terminologies

Set of Practices and Terms used in DevOps

As you learn DevOps, you will come across these terms, and it is good practice to understand what they mean and how they work. Let’s look at some of them:

• Continuous Integration & Continuous Delivery (CD/CD):: DevOps ensures that every piece of code tested by developers is integrated as soon as possible. Also, DevOps ensures software changes are automatically built, tested, and deployed to production.

• Infrastructure as Code (IAC): To configure and manage infrastructures, DevOps employs tools such as Ansible, Puppet, and Chef.

• Automated Testing: DevOps automates testing such as unit testing, integration testing, and acceptance testing.

• Monitoring and Logging: DevOps also monitors the system’s performance to identify any problems or errors affecting the system’s overall performance.

• Collaboration and Communication: DevOps promotes teamwork and communication between development and operations teams.

• Agile Methodologies: DevOps employs Agile methodologies such as Scrum to respond to software changes and provide continuous customer feedback.

• Automation Tools: I’ve mentioned several times that DevOps uses automation. Several tools, including Jenkins, Docker, and Kubernetes, automate the process.

• Version Control: A code change management system allowing developers to track changes and collaborate.

**Before learning a new technology, it is critical to understand real-world applications of the technology. It provides a better idea of what you can create with that technology!**

Next, we’ll look at some real-world DevOps use cases.

Case Studies: Examples of Companies implementing DevOps practices

These organizations use DevOps practices such as Continous Integration and Delivery, automated testing, and containerization to easily and quickly deliver new services, features, and high-quality software.

• Google

• Microsoft

• Netflix

• Amazon

Conclusion

In this article, we explored what DevOps is, the limitations of the traditional SDLC and the benefits DevOps offers. We also covered the set of practices in DevOps and showed some real-world case studies.

Resources

You may find the following resources useful:

• Continuous Integration & Continuous Delivery (CI/CD)
• Infrastructure as Code (IAC)
• Automated testing
• Monitoring and Logging
• Collaboration and Communication
• Agile Methodologies
• Automation Tools
• Version Control

I became a member of the Developers Student Club, a Program organized by Google Developers that is present in various Universities across the globe, in my first year as a Computer Science Student at the University of Port Harcourt. My goal was to apply the basic knowledge of Programming that I was being taught by Lecturers in my Department and become very good at Programming.

When I joined DSC in the year 2018, I met a lot of awesome and friendly Students, most were in same Department, Computer Science. Being a friendly person, It didn’t take me a long time to get acquainted with all the DSC members.

We had Meetups, Workshops as well as Hackathons at the Computer Science Lab in my School. Ray Okaah was the DSC Lead at that time. I did my best to attend all the meetups I was able to. I wasn’t conversant with any Programming Language when I became a member of DSC, I was just keen on learning.

During the meetups, We were paired into groups according to our stacks and levels in Technology (Newbie, Beginner and Intermediate levels) and were assigned mentors to lead each group. I always paid attention and loved how things were done by the previous DSC Lead, Ray Okaah. I didn’t know that one day, I will be the DSC Lead for my School! 😃.

On some days of the meetups we had, I would volunteer to help teach the Newbies in frontend Web Development, HTML and CSS (which was what I was good at to some extent at that time). To be honest, I was so excited doing that.

On a particular evening, Ray Okaah, the previous DSC Lead, reached out to me and informed me that his tenure as the DSC Lead was coming to an end and he will be replaced with someone else capable of leading the community. He said he has noticed me and felt that I would make a good Leader for the DSC.

I was astonished and at the same time glad that he considered me, but still tensed about being a Lead!😱😱 I told him that I wasn’t sure I would be able to lead a whole Club of about 100+ persons. I mentioned that I didn’t feel good enough and lacked enough experience in Programming and Tech in general to be able to lead a club with Tech Professionals. Ray convinced me that it wasn’t as difficult as it seemed and he sees a good leader in me. I was still tensed and hardly convinced. So, he gave me some time to think about it after assuring me that he will help me in the Application process and I should not be scared. Phewww….😥😪😪

I decided that I was going to take the shot 😊😊 and I started the application process. I made a YouTube Application Video, which was part of the DSC Lead application requirements. 👇💗💗

It was an interesting process 😊💗😃💗. So my interview was scheduled, and I had a video interview. The questions asked were basically what was asked in the application form. So I had no issues answering the questions the interviewer asked. 😊

After a few months, I received a congratulatory email from DSC, saying that I had been chosen as the DSC Lead for my school!!!😍🥰🥰💃💃I was introduced by Ray to the club as his successor DSC Lead at a meetup.

Then I was invited to a Google Summit in Accra, Ghana at Swiss Spirit Hotel Alisa Accra.

I was so excited! as my trip was being sponsored out of Nigeria to meet and connect with Google Developer Relations Sub-Saharan Africa, Women Tech Makers Ambassadors as well as the rest of the DSC leads. I was really excited! That was my first trip in a plane and first time traveling outside Nigeria!😂💃

The summit was a success and a thrilling experience! never to be forgotten💗😍😊. I met and made friends with a lot of Developers and Google Developers Relations Team. I must say it was an amazing experience!💗💗💗

During the summit at Accra, sessions were held at the halls with all the Developers Student Club Leads, we had speakers and hosts, Erica Hanson(Developer Relations Program Manager, Google, Global Lead for Developers Student Club) Auwal MS(Program Manager Google Developers @DSCSSA) , Ada Nduka Oyom, Aniedi Udo and some other Google Developers.

We also had some of the past DSC Leads as speakers, share their experience as DSC Leads and we were also told what we were expected to do as DSC Leads in our various schools when we returned to our various Countries.😊

I also attended the DevFest at Accra. It was a wonderful experience! I learnt a lot.

I traveled back to Nigeria, and back to my University. I began with choosing my Core Team Members, who were active members of the DSC. I chose them according to the different departmental levels in school, and the various technology stacks. My aim was to be able to work with my Core Team and reach out to Students in the various departments and levels, with different technology stacks and interests. My Core Team members were excited to volunteer and to help.

I organized my first meetup with the help of my Core Team Members. The first meetup was an Info Session for old and new club members. During the meetup, I introduced my Core Team members to the Club, and with their help, I enlightened the Club about the aim of DSC, which is to create a mentoring or learning environment for Students interested in learning or acquiring a skill in Technology using some tools provided by Google.

The Info Session was successful with a good number of attendees. My Core Team and I grouped the members of the Club into different stacks such as; Web Development, Android Development, Cloud Engineering, Artificial Intelligence, Design, e.t.c. and we assigned Mentors(members of the club with more experience in each stack) to each group.

Still with my Core Team Members, I organized more Workshops/Meetups, with each workshop focused on a particular technology several times in a month at the Computer Science Lab in Uniport.

I urged the members of DSC to attend the DevFest Port Harcourt that happened on the 16th of November 2019, and a lot of them attended and were glad they did!

The time for the Google Solution Challenge came, and in conjunction with my core team members; Ikeh Akinyemi, Fortune Ikechi, Melvin Nnamani and the assistance of the Former DSC lead, Ray Okaah, We came up with a solution idea to build a Blood Donation App that connects blood donors with local hospitals to reduce the rate of deaths in hospitals as a result of lack of blood or lack of a blood type. We took interest in our University of Port Harcourt Teaching Hospital(UPTH) which is one of the largest hospitals in Southern Nigeria.

We decided to go and interview the section of the hospital in charge of blood donation called Haematology Laboratory.

Below are random pictures taken at the Hospital premises during our group research, of Ikeh Akinyemi, Fortune Ikechi, Melvin Nnamani and myself!

Life Saver - Apps on Google Play

However, there were some challenges I faced as DSC Lead, which included organizing meetups during exam periods and overseeing all the sub-groups that were functioning in DSC.

I am so glad! that as the DSC Lead of University of Port Harcourt, I was able to help a lot of students acquire innumerable skills in their various interests. I am grateful to have had the opportunity to contribute to the growth of the club and to have made a lot of positive impact in the development and aspirations of members of DSC Uniport.