DEV Community: Oluwafemi Josephine

Tracing the Evolution of Intelligence: From Symbolic Systems to Generative AI

Oluwafemi Josephine — Wed, 15 Jan 2025 19:04:36 +0000

Table of Contents

What Is AI, Really?
Chasing Intelligence: The Book Metaphor
Will GenAI Take Our Jobs or Supercharge Them? Programmers Journalists Content Creators
GenAI and the Gartner Hype Cycle
Large Language Models
What’s Next?

What Is AI, Really?

In its most basic form, Artificial Intelligence (AI) is the science and engineering of making machines perform tasks that normally require human intelligence. If you picture AI as a big circle in a Venn diagram, within it lie overlapping fields like symbolic reasoning (which gave us the early “expert systems”), machine learning (where computers learn from data), and deep learning (where neural networks mimic the layered structure of our brains). Sitting at the cutting edge of it all is Generative AI, which doesn’t just analyze data—it creates brand-new content from it.

Chasing Intelligence: The Book Metaphor

Imagine you pick up a textbook on a very specific topic—say, medical diagnosis. Page one states the core definition: “Diagnose patient symptoms accurately.” Pages two onward? That’s where the approach differs depending on the era. In the symbolic approach, we wrote if-then rules; with expert systems, we compiled human expertise into a knowledge base. Then came the data-hungry revolution of machine learning, leading to deep learning methods that find patterns in ways humans rarely anticipate.
And now, we’re opening the GenAI chapter, where systems can create new text, images, and even code, potentially rewriting how we define “intelligent” behavior in the first place.

Is GenAI the final frontier in AI’s epic saga? Perhaps. Or maybe it’s just another chapter in a book that hasn’t reached its conclusion yet. The quest to replicate, enhance, or even surpass human intelligence isn’t over—but GenAI sure feels like the biggest leap forward so far.

Will GenAI Take Our Jobs or Supercharge Them?
No discussion about AI is complete without a little debate: Will it be a tool that augments human capabilities, or will it eventually make entire professions obsolete?

Programmers

Naval Ravikant famously tweeted, “AI won’t replace programmers, but rather make it easier for programmers to replace everyone else.” Far from being automated away, skilled developers now wield a powerful ally—code-generation tools that can handle some of the grunt work, letting them focus on architecture and creative solutions.

Journalists

Automated story outlines, quick fact checks, or even first drafts can help newsrooms break stories faster. Journalists who learn to harness GenAI for research and early drafting will produce deeper, more insightful reporting.

Content Creators

Social media managers, copywriters, and designers can all tap into GenAI for fresh ideas and faster output. The real magic happens when a human’s originality merges with AI’s speed and range, catapulting creativity to another level.
The takeaway? Resistance is futile—or at least unproductive. GenAI isn’t here to destroy jobs; it’s here to shift how we work. The earlier we make it our ally, the bigger the win for everyone.

GenAI and the Gartner Hype Cycle

New technology is often fueled by lofty expectations, sending it rocketing up the Gartner Hype Cycle. We’ve seen it before: big promises, sometimes a crash of disappointment, and then a leveling-out phase where real, sustainable innovation emerges.

Right now, GenAI is at—or near—the peak of inflated expectations. People are racing to see what it can do, sometimes overestimating its present abilities. Yet as the hype settles, meaningful, game-changing applications of GenAI will keep growing in almost every industry.

Example is the Blockchain Technology Blockchain technology offers a perfect example of the Gartner Hype Cycle in action.

Innovation Trigger: Blockchain emerged as the backbone of cryptocurrencies like Bitcoin, generating excitement with its potential for secure, decentralized transactions.
Peak of Inflated Expectations: Businesses and media touted blockchain as a revolution for nearly every industry, from finance to supply chain management, with startups promising unprecedented transparency and efficiency.
Trough of Disillusionment: Many projects failed to deliver on their promises, either because of technical limitations, scalability issues, or a lack of understanding of where blockchain was truly valuable.
Slope of Enlightenment: Gradually, industries began to identify practical use cases, like cross-border payments, smart contracts, and tokenization of assets.
Plateau of Productivity: Today, blockchain is integrated into mainstream applications, especially in finance and logistics, proving its long-term value despite the initial hype.

Large Language Models

So, what makes GenAI so potent? One major ingredient is Large Language Models (LLMs). Unlike older language models that performed simple text completion or classification, LLMs—think GPT-4, PaLM, or LLaMA—are trained on massive datasets and billions of parameters, giving them an uncanny flair for human-like text generation, code-writing, and even image or audio creation when paired with the right architecture.
Their scale and complexity let them “understand” context and nuance in ways we couldn’t have imagined just a few years ago.

What’s Next?
I’ve only scratched the surface of GenAI’s capabilities. In my next post, we’ll dive under the hood to explore the GenAI pipeline—the building blocks, training strategies, and optimization techniques that make these systems hum. Think of it as turning the page to the next chapter in our ever-evolving “AI as a book” analogy, where you’ll finally peek at the “how” behind GenAI’s endless creation.
For now, remember this: GenAI is not just a technology—it’s a new lens through which we can imagine and build our future. If you join forces with it, you might just write the next great chapter yourself.

The 10 fastest programming languages in the world

Oluwafemi Josephine — Wed, 15 Jan 2025 19:01:47 +0000

In the current and future world where the amount of information is very large: Big Data there is a notable need for tools that match this reality, which is why the speed of programming languages is essential.

There are several ways to test the speed of languages, among them there is a simple way which is to check with the command GNU time the execution time, for example, of a for loop to perform 1000 cycles. And we've already done this in a series with 3 videos on Youtube:

I Tested the Performance of 10 Programming Languages with Ranking
I Tested the Performance of 10 Programming Languages with Ranking - Part 2
I Tested the Performance of 10 Programming Languages - Ranking FINAL > The videos are in Portuguese, but you can understand them even without audio. If this bothers you, use YouTube's automatic translation. Note: Since the tests were performed on video, the screencast was turned on and the performance with screen recording is slightly higher than if it is done without it. And this is not a detail, but rather necessary information. The tests performed above were performed with 30 programming languages, including: C++, C, JavaScript, Python, Lua, Swift, Java, Go, and others. We did not make comparisons with Assembly, because Assembly would certainly be in first place. Although C, C++, Zig and others transpile the final code to Assembly, it is not the same as writing in pure Assembly, since these languages create a dynamic link to other code, which in the end greatly influences the final result, which is why Assembly is always the fastest. However, the final ranking had some surprises and in this article we will see, in descending order, the 10 fastest programming languages according to this test. Remember that I did the same test with some that are not on the list and that performed well and we will include them in the list, since they were in the TOP10.

10th POSITION: Dlang

Dlang or simply: D, is a general-purpose programming language designed by Walter Bright of Digital Mars.
It is mostly based on C++, although it is not just a variant. The stable version of the first specification (v1.0) was released in January 2007. Native D code is generally as fast as the code.

09° POSITION: Swift

Swift is a compiled, multi-paradigm, high-level, general-purpose programming language created by Chris Lattner in 2010 for Apple Inc. and maintained by the open source community.
Swift compiles to machine code and uses a compiler based on LLVM, also created by Chris Lattner. Swift was first released in June 2014.
Swift replaced all of Apple's Objective-C and Objective-C++ code in just a few months of existence, which ended up encouraging Rust (based on Swift's ideas) to try the same feat, that is, to try to replace C and C++ code, but the community has not yet embraced this idea as Apple, which is a closed and private company.
Today, Swift is available for any operating system and architecture, and not just for Apple devices.
After the release of the new versions of Swift, I redid the tests and it moved up in position!

08° POSITION: Lua

Lua is an interpreted, high-level scripting programming language, with dynamic and multiparadigm typing, reflective and lightweight, designed by Tecgraf of PUC-Rio (created by Brazilians) in 1993 to expand applications in general, in an extensible way (which unites parts of a program made in more than one language), for prototyping and to be embedded in complex software, such as games. It resembles Python, Ruby and Icon*, among others.

7th POSITION: Rust

Rust is a general-purpose programming language that emphasizes performance, type safety, and concurrency. Rust's performance is directly linked to the use of LLVM which took about 20 years to complete and is written in C++.
Rust based its ideas on Swift (automatically sanitizes memory) and mixed the syntax of languages such as: C++ (use of std, main, ...) and OCaml.
In 2022, Rust was involved in controversy due to its logo, which was declared copyrighted, an attitude that led to problems with the operating system: Debian GNU/Linux, which does not accept this type of license.

06° POSITION: Perl

Perl is a family of two multiplatform programming languages, Perl 5 and Perl 6i, and later renamed: Raku.
Perl was originally developed by Larry Wall in 1987.
Perl is considered the fastest scripting programming language ever created to date. Perl was also the basis for the development of the programming language: PHP, with a very similar syntax.

05th POSITION: Ada

Ada is a high-level, structured, statically typed, imperative, object-oriented programming language inspired by Pascal and other languages.
It was the first programming language designed for Memory Safe (or more correctly: Memory Sanitize), that is, it makes it easier for the programmer to dynamically deallocate data, test for overflow at compile time, and automatically destroy unused objects.
Ada was originally designed by a team led by French computer scientist Jean Ichbiah from Honeywell under contract with the United States Department of Defense (DoD) from 1977 to 1983 to replace more than 450 programming languages used by the DoD at that time.
Ada was named after Ada Lovelace (1815–1852), who is credited as the first computer programmer.

04° POSITION: Vala

Vala is an object-oriented programming language with a self-hosted compiler that generates C code and uses the GObject system.
Vala is syntactically similar to C#.
It was developed by GNOME and aims to bring modern features to GNOME developers without imposing any additional runtime requirements and without using a different ABI.

03° POSITION: Fortran

Fortran, an acronym for IBM Mathematical FORmula TRANslation System, is a programming language aimed at scientific and technical computing and specially designed for efficient runtime execution on a wide variety of processors.
It was initially developed in the 1950s and standardized in 1966. It is currently the third most popular programming language in high-performance computing

02nd POSITION: C

C is considered the mother of almost all modern programming languages.
The initial development of C took place at AT&T Bell Labs between 1969 and 1973, created solely by Dennis Ritchie. The first book on the C Language had the help of Brian Kernighan. This book is the best-selling book in the world when it comes to programming.

1st POSITION: C++

And in the very first place was C++.
C++ is a programming language that is based on the Simula and C programming languages (and also compiles C code).
Originally C++ was called "C with Classes", but soon after it was changed to C++ (an enhanced C: ++, like a for loop, for example).
I created my own programming language with C++:

How to Create a Good Pull Request Template

Oluwafemi Josephine — Wed, 15 Jan 2025 16:42:22 +0000

I wasn’t in tech when Pull Requests (PRs) were first introduced by GitHub back in 2008. And when I graduated from bootcamp four years ago, I had probably created only a handful of PRs. I quickly learned how vital PRs were when I started my first job on a team though. And my appreciation for a good Pull Request has only increased as I spend more time as a maintainer.

The great things about Pull Requests are that they allow for collaboration between contributors and maintainers, offer an opportunity to communicate changes that have been made and why they are important, and the ability for maintainers to provide feedback. Because contributors come from different backgrounds, have varying degrees of experience, and speak different languages, sometimes creating good PRs can be tricky. But there are some ways to optimize the experience for everyone–including adding gifs.

How to Create a Pull Request Template

Maintainers can help to improve the experience for both reviewing Pull Requests and for contributors submitting them by creating a template.

I like to think of Pull Request templates as a kind of contributor onboarding. It helps to guide them through the process of writing a good pull request and communicating with the maintainers. Although good templates may vary according to different organizations, their standards, and their needs, there are some basic checklists that you can use to generate your own.

To create a PR template in GitHub, create a .github folder in the root of your repository and a file called PULL_REQUEST_TEMPLATE.md.

At OpenSauced, we used forem’s Pull Request template for inspiration for our template.

GIF

You can use markdown to create your template, and include sections like:

What type of PR is this?
Description of the changes
Related Tickets & Documents
Mobile & Desktop Screenshots/Recordings
Tests
Documentation
Post-deployment tasks
What gif best describes this PR or how it makes you feel? Let Them Add Gifs! That last one might seem out of place to you, but it can actually make the PR experience more fun, engaging, and effective. Here's why:
Gifs can bridge language gaps and help contributors express themselves more clearly.
Gifs can showcase contributors' personalities and add a personal touch to the PR.
Gifs can increase engagement and make the review process more enjoyable for everyone. How to add Gifs to Your PR If you’re a contributor, you might be wondering, “What’s the easiest way to add a gif?” I use the GIFs for GitHub chrome extension. Once it’s installed, you’ve got a quick way to add all your favorite gifs to enhance that PR experience. Just search for the gif you want, and click it. You can even add a caption to describe the gif or explain how it relates to the PR 👏 You can read more about PRs with @’ post on Tips for getting your Pull Request reviewed on GitHub. Or check out the hottest repos and how they handle PRs on OpenSauced hot repositories. And if you have tips for creating great pull requests, let us know in the comments below.

Open Source for Everyone: How to Contribute Without Writing Code

Oluwafemi Josephine — Wed, 15 Jan 2025 16:41:00 +0000

One of the first pieces of advice I got before graduating from bootcamp was to get involved in open source. I browsed around GitHub. I looked at issues. I peeked into code bases. I was overwhelmed. I didn’t quite feel like I had the capabilities to jump in and start working on an issue. Skill-wise, could I? Maybe, depending on the repository. Confidence-wise? No way. I was a career-changer with ten years of expertise in English and zero years of expertise in coding. But, if someone would have told me that I could start where I was most comfortable, without writing code, I think I could have eased my way into the open source waters sooner. Open source projects don’t always require code contributions; in fact, non-code contributions can be as valuable as code contributions.
Non-Code Contributions to Open Source

Documentation

Good documentation helps users understand how to use the software, troubleshoot issues, and contribute to the project. Contributing to documentation is a great way to get involved in open source without needing to know how to code. Sometimes documentation needs to be updated. Other times directions need to be clarified–if you’re struggling to understand something as part of the documentation process, chances are that someone else is too. Sometimes it needs to be written.

Project Highlight: The Odin Project

The Odin Project is a free, open-source curriculum for learning web development. It’s designed to be self-directed and project-based, and covers a wide range of topics, including HTML, CSS, JavaScript, and Ruby on Rails.
One way to contribute to The Odin Project is by helping to improve their documentation. You can contribute to their curriculum repository by suggesting improvements, reporting errors, or adding new documentation. They also have a great Contributing Guide to help onboard new contributors.
User Experience (UX) Design & Accessibility
User experience (UX) design is another valuable non-code contribution. UX designers can help OSS projects improve their user interfaces, making them more intuitive, accessible, and user-friendly. This could involve reviewing the project's design and identifying any accessibility issues, such as color contrast or font size, and suggesting improvements. You could also help create accessible design elements, like icons or buttons for the project.

Project Highlight: WordPress

WordPress is an open source content management system and has a dedicated team of UX designers who work on improving the user experience of the platform. They advertise their vision for getting designers involved in their all-volunteer team and highlight ways to do that on their Make WordPress Design page.
They also have a Make WordPress Accessible page that outlines how volunteers can get involved to improve accessibility.
Translation
Because so much of the code we write is for a global user base, many repositories actively seek translations to reach a broader audience and provide a better experience for non-native speakers.

Project Highlight: OpenStreetMap

OpenStreetMap is a collaborative project that aims to create a free and editable map of the world. It’s built by a community of mappers who contribute and maintain data about roads, buildings, landmarks, and other points of interest around the world. Within their documentation on how to contribute, they include a section on Translate! to provide access to more users and provide directions on the translation contributing process.

Content

Supporting open source projects is more than code and documentation. There are users who need supported and developers who need to learn more. There’s always a way to create a safer and more stable space for the community. You can do this by sharing projects you enjoy using, writing blog posts that include their product, speaking about their product at meetups and conferences, and providing feedback to the maintainers.

Project Highlight: Appwrite

Appwrite is a backend platform for developing Web, Mobile, and Flutter applications. Their CONTRIBUTING.md file highlights all of the different non-code ways that contributors can help to support their project.

Community

A strong and welcoming community often leads to a healthy open source project. Community can be one of the most time-consuming parts of maintaining a project. Questions need answered, examples need to be created, clarifying information, and creating clear paths of communication are all important to supporting a community. Often open source projects rely on volunteers to ensure the community is supported and thriving.

Project Spotlight: Directus

Directus is a real-time API and App dashboard for managing SQL database content. Within their contributing doc, Directus shares that one way to contribute is by Helping Others.
You don’t have to know how to code to get involved in open source, and contributing isn’t just for developers. We all use products that use open source software. Finding ways to give back that’s within our skillset benefits the projects, the tech community, and everyone who’s using products that use open source software. This is a short list of projects and examples that accept non-code contributions. If you want to see a longer list, check out the Twitter thread here. If you want to explore more repositories, check out OpenSauced Insights.

The True Price of Free: The Importance of Open Source Sustainability

Oluwafemi Josephine — Wed, 15 Jan 2025 16:34:11 +0000

According to Manuel Hoffmann, Frank Nagle and Yanuo Zhou, in The Value of Open Source Software for the HBS Working Paper Series:

We estimate the supply-side value of widely-used OSS is $4.15 billion, but that the demand-side value is much larger at $8.8 trillion. We find that firms would need to spend 3.5 times more on software than they currently do if OSS did not exist. The top six programming languages in our sample comprise 84% of the demand-side value of OSS. Further, 96% of the demand-side value is created by only 5% of OSS developers.
This figures alone should alert us to the critical importance of open source software. But somehow, despite this incredible value, the open source ecosystem still faces major sustainability challenges that will impact its future, and us all.

Beyond the numbers, open source enables innovation, creates opportunities for global collaboration, and provides critical digital infrastructure relied upon by businesses, governments, and people around the world. Projects like the Linux kernel, Python, Kubernetes, Node.js, and countless others create the foundation for everything from cloud computing and AI to mobile apps and IoT devices.

Despite the advancements we've made via open source, we're still facing a crisis of sustainability. As Nadia Eghbal outlined in “Working in Public,” open source often suffers from a tragedy of the commons: while everyone benefits from open source software, the burden of maintaining it falls on a small group of often unpaid or underpaid individuals.
**
Understanding the Tragedy of the Commons**

The tragedy of the commons originates from economics and ecology. It describes a situation where individual users, acting independently according to their own self-interest, deplete or use up a shared resource, even though it's not in anyone’s long-term interest for this to happen. The “commons” refers to resources available to all members of a society, like air, water, or, in this context, open source software.

Application to Open Source Software

In open source, the “commons” is the collective body of software that is freely available for anyone to use, modify, and distribute. While this model encourages innovation and reduces barriers to entry, it also presents challenges:

Unequal Contribution to Benefit Ratio: Many organizations and individuals use open source software in their products and services, gaining significant benefits in terms of cost savings and faster development. However, the responsibility of maintaining and updating these projects often falls on a small group of maintainers who may not receive adequate compensation or recognition for their work.
Maintenance Burden: As software projects grow in popularity, the demands on maintainers increase. They have to address bug reports, security vulnerabilities, feature requests, and support inquiries, which can become overwhelming without sufficient resources.
Sustainability Challenges: Without proper funding or support, maintainers may experience burnout, leading to neglected projects. This can result in security risks, decreased software quality, and ultimately, a decline in the utility of the software for all users.
To learn more about what happens when maintainers leave a project, check out The Silent Crisis in Open Source: When Maintainers Walk Away.

Economic Implications

The difference between those who benefit from open source software and those who maintain it raises economic concerns as well:

Free Riders: Companies often use open source software extensively without contributing back, either through code contributions, funding, or other support.
Lack of Incentives: The traditional market mechanisms that incentivize product improvement and maintenance are weaker in open source projects, because the software is freely available. The tragedy of the commons in open source software reflects an imbalance between widespread usage and concentrated maintenance responsibilities. While everyone benefits from the collaborative and open nature of these projects, without proactive measures to support maintainers, the sustainability of open source is at risk. Let's think about this from another perspective. What if our fire departments were all volunteers. They spend the countelss hours training, they're often on call 24/7 to protect our communities from fires and other emergencies, and they aren't paid.

But we also need to recognize that companies build skyscrakers, factories, and complexes that are also protected by these unpaid firefighters. In this scenario, these companies also might be able to forego fire safety systems and insurance, while they still get the benefits of the volunteer labor of the firefighters.

The firefighters would probably have to find a way to bring in income to pay their own bills, so they may end up being exhausted from essentially working two jobs - including one that's incredibly physically demanding. So now, we're left with exhausted fire fighters who might end up making mistakes, having a slow response time, or may be burnt out and quit.
It's pretty clear that this is not a safe situation. And yet, this is what we're accepting in open source. We're creating an environment that's setting us all up for failure.

The Challenge of Funding and Recognition

Part of the sustainability problem is the funding crisis. The 2024 Tidelift State of the Open Source Maintainer Report reveals that 60% of maintainers remain unpaid for their work. Considering the importance maintainers play in maintaining the digital infrastructure that powers our world, this lack of financial support is problemmatic at best.
The Tidelift report also showed that maintainers overwhelmingly prefer predictable, recurring income over one-time payments to better manage their ongoing work. So even when funding is available, it may not be given in a way that best supports the maintainers who need it most.
In “Working in Public: The Making and Maintenance of Open Source Software,” Eghbal emphasizes how open source maintainers are often underappreciated and face burnout. She argues that maintaining a healthy ecosystem requires both financial support and community appreciation for those who contribute regularly. The invisible labor behind these projects keeps them operational and secure, but it often goes unrecognized.

The OSS Pledge: Sentry’s Model for Direct Impact
Sentry’s OSS Pledge serves as a model for how companies can take concrete steps to support open source sustainability. The Pledge calls for companies to pay a minimum of $2000 per year per full-time equivalent developer on their staff to open source maintainers of their choosing. This approach aims to create a new social norm in the tech industry of companies paying open source maintainers directly, addressing the one of the root causes of maintainer burnout and related security issues.

While other forms of support like hiring developers to work on open source or providing in-kind gifts are valuable, the Pledge emphasizes the importance of direct cash payments. This focus ensures that underpaid and overworked maintainers of critical open source projects can pay their bills, leading to a healthier, fairer, more stable, and more secure open source ecosystem.

Open Source and Sustainable Development
It's not just economic and technological impacts that make open source important; open source has the potential to play a major role in addressing global challenges. The Linux Foundation’s Open Source for Sustainability report examines how open source projects can significantly advance the United Nations Sustainable Development Goals (SDGs).
For instance, projects like AgStack help farmers make data-driven decisions to increase yields, contributing to goals like Zero Hunger and Responsible Consumption. Open standards, open AI models, and open data allow for more collaboration, reduce waste, and improve transparency across various sectors.
However, to be able to actualize this potential, we have to prioritize the sustainability of both the projects and their maintainers. According to Eghbal, the perpetual nature of open source development needs continuous support, because without it, these projects are at risk of stagnation or worse, abandonment.

The Security Imperative

The sustainability crisis in open source isn’t just about funding—it’s also a matter of security. The Tidelift report reveals that paid maintainers are significantly more likely to implement critical security practices. This is becoming more and more important as security threats continue to grow in sophistication. (Read more about new legislation to improve cybersecurity for NASA.)
The Log4j vulnerability heightened concerns, with many maintainers feeling less trustful of contributors. We need secure, well-maintained projects. Paid maintainers can generally spend more time on security improvements and maintenance.

Eghbal points out that many essential open source projects are maintained by individuals or small teams with limited resources. This fragile support system can make widely-used software vulnerable to security breaches, as maintainers may not have the bandwidth to address every vulnerability or request. Prioritizing financial and structural support is necessary to decrease these risks.

Solutions

So, what can be done? First, we need a paradigm shift in how we think about and support open source work. Companies that benefit from open source need to step up their financial support. The Linux Foundation’s work in creating funding models and governance structures for open source projects is a step in the right direction, but we need more widespread adoption is needed.

Governments also have a responsibility to consider the long-term impact of their dependence on open source. Recognizing open source as critical national infrastructure and providing funding and support could help ensure its long-term viability.
For individual developers and users of open source, consider contributing back—whether through code, documentation, or financial support. If you're in a position to influence your company's policies, advocate for supporting open source projects through consistent sponsorships or by creating employee time for contributions to the projects they use.
Take time to look at and understand your dependencies. Create an SBOM Workspace and look at the security ratings of your dependencies. Identify the lottery factor of the projects. If you see there's a high lottery factor, then those projects might need to be the priority for your support.

Thriving and Advancing in Tech (Especially as a Minority)

Oluwafemi Josephine — Wed, 15 Jan 2025 16:31:33 +0000

"Break into tech" started as a well-intentioned movement to democratize the software engineering industry. Today, the phrase has devolved into a marketing gimmick for money-hungry course creators.

I'm guilty of trying to sell this dream as well. Because I had such a financially life-changing experience, I wanted to share it with others. For four years, I ran a non-profit where I helped at least 150 women and nonbinary people of color get their first developer jobs. But every few years, an alum would let me know they had quit or were getting fired. In hindsight, I failed to prepare them for the hard parts: staying and growing in tech.

Tech’s struggle to retain talent

That reality is especially harsh for Black women in tech. While Black women are the most educated demographic in the United States, only 3% of us hold tech roles. In 2020, less than 0.5% of us held leadership roles in Silicon Valley.
These numbers tell a story of systemic barriers beyond entering tech — they reveal why retaining talent matters as much as attracting it. The conversations I have with underrepresented minorities echo this truth, each story revealing patterns of stalled growth and lost potential as we repeatedly discuss the same problem: how to stop being junior.

My struggle to stay in tech

I empathize because this question plagued my career for years. It's a layered question that goes beyond titles. What I was really asking was: Do I belong? Do I bring value? How do I thrive in a space where I'm so different from everyone else?
Moreover, I was disappointed that after spending months of sleepless nights to pursue a role that promised "a better life," I found myself at jobs where I felt lonely, disrespected, and useless. It's easy to dismiss these struggles, but work stress can manifest physically. For instance, I remember sitting on the bus one day, so burdened by my poor work performance that my muscles were too tense to stand up when I reached my stop.

People often diagnose this as imposter syndrome, but it's a different issue that our industry hasn't adequately defined or addressed yet. The obvious go-to solutions are to try harder and build relationships at work. However, this advice is vague and generally unhelpful. Does trying harder mean sitting longer at your laptop to complete a task? When it comes to writing code, taking breaks is typically more productive. And how do you build relationships when you face cultural disconnects, like struggling to relate to teammates who make kombucha and spend weekends free climbing?

Clashing communication styles can add another layer of isolation. For example, I grew up with a direct communication style - Caribbean people are blunt. Additionally, my neurodivergent mind is wired for candor. However, tech culture operates through indirect cues and subtle gestures. My attempts to adapt backfired. I overcompensated (and sometimes still do) by writing detailed Slack messages no one wanted to read.

From survival to growth

It took me years to realize I needed a more nuanced approach to building a sustainable career in tech. Finally, at GitHub, I learned to balance authenticity with technical growth and team impact. Everyone at GitHub, including Brian Douglas, Martin Woodward, the CEO Thomas Dohmke, and the CEO's Deputy Chief of Staff, Cole Driver, made me feel accepted, heard, and valued. Now, as a Staff Developer Advocate at Block, under the leadership of Angie Jones, I've had opportunities to demonstrate my strategic vision. These environments were the first where I wasn't labeled a 'diversity hire,' seen as a forever junior, or made to feel like I was bringing the team down.

In hindsight, there were moments when I unintentionally set myself up for failure. But I've now discovered ways to navigate these challenges and position myself for growth. In this post, I'll share my evolving playbook for staying and thriving in tech, especially as someone from an underrepresented background.

My "How to Grow in Tech" Playbook

Before you even search for a job
- Learn in public
On the job hunt
- Apply to non-junior roles
- Interview with confidence
- Choose your team wisely
Your first weeks on the job
- Take notes
- Read the codebase
- Read Slack, GitHub issues, GitHub PRs
- Ask for clarity
Establish a positive reputation
- Learn how to use AI
- Practice
- Receive feedback gracefully
- Share your perspective
Map your career growth
- Understand your team goals and company goals
- Know your career ladder
- Advocate for yourself
- Enable your teammates
Exercise peace for long-term sustainability
- Still have a life
- Find community
- Be patient
- Let go of the need for acceptance
- Know when to pivot Before you even search for a job

Learn in public

Many people hesitate to share their work publicly, thinking it means presenting as an expert. I take a literal approach: "here's what I learned today." Learning in public helps hiring managers track your progress and understand your learning style. When opportunities arise.

On the job hunt

Apply to non-junior roles
I spent five years only applying to internships and junior roles, scared of higher-level interviews and thinking of myself as junior. But I discovered once you join as junior, that perception sticks - even after promotion. When I finally applied for a Staff position, despite it looking ambitious on paper, I came in and operated at that level. Now I don't have to fight to shake the junior label. I treat job applications like college admissions: have reach positions, perfect fits, and safety roles (to meet your financial needs).
Interview with confidence
Your interview is their first impression of you. You don't need to lie about your skills; remember you have valuable contributions to offer the team.

Choose your team wisely

You're interviewing the company as much as they're interviewing you. Look for a team that will invest in your growth and uplift your skills. For minorities, it's easier to join teams where you're not the first of your underrepresented group. While the current economy might limit options, and teams can appear less toxic during interviews than they truly are, aim to find a team that cares about your success.
Your first weeks on the job

Take notes

Taking notes helps you avoid repeatedly asking for help and gives you context for better questions when you do need support. You can start on day 1 with your local environment setup. Document any hurdles and solutions - ideally in team documentation or at least in personal notes.

Read the codebase

Reading the codebase helps you understand how various components connect. Use your IDE and GitHub's search to trace how methods are called and why. Start when you join and continue your research throughout your time at the company.
Read Slack, GitHub issues, GitHub PRs
To supplement reading the codebase, read past discussions to understand your team's architectural decisions.

Ask for clarity

The silliest thing I do is stress out when I don't understand someone's feedback or response, but I get work done faster when I ask, "I'm interpreting your response as X - is that what you mean?"
Establish a positive reputation

Learn how to use AI

Mindlessly copying AI-generated code can be a sign of an immature developer. Instead, use it to understand code and concepts. When I joined Block, I used my company's custom GPT plugin to help me grasp complex functions and confirm my assumptions without constantly asking busy teammates. Beyond code, I use AI to help refine emails for clarity and tone. Here's an example of me using ChatGPT to understand a concept that was new to me:

Practice
Doing your day job isn't always enough for growth - coding is a craft that needs sharpening. Realistically, you may not have time to do extra coding, but you can find ways to practice that fit into your life, like:

Listen to tech podcasts while doing chores.
Contribute to open source when you can.
Work with your manager to gradually take on more challenging tasks. Receive feedback gracefully I used to resist feedback out of ego until I realized feedback helps me grow. Gracefully receiving feedback can mean accepting it, discussing it to find a middle ground, or respectfully pushing back to maintain authenticity. Share your perspective Start small with code reviews - suggest ways to make code clearer, regardless of the author's experience level. As you gain confidence, share your broader thoughts. Your unique perspective might help the team see things differently. Map your career growth Understand your team goals and company goals Pay attention to how your company makes money and how your team contributes. To make a big impact, I look for ways my strengths can complement my teammates and help reach team goals.

Know your career ladder

Each company defines levels differently. Work with your manager to understand promotion requirements and create a plan while recognizing that business needs affect timing.
Advocate for yourself
Your manager can't read your mind. Good work isn't enough - you need to clearly express your goals and ask what it takes to achieve them. My husband and I interned at the same company: he did good work but stayed silent, while I asked what I needed to do to go full-time. His silence led our manager to assume he wanted to leave, while I received a full-time offer.

Enable your teammates

As you gain more knowledge and expertise, it's time to share it with your teammates. Empowering others avoids bottlenecks, strengthens the team, showcases your expertise, and protects you from burnout.
Exercise peace for long-term sustainability
Still have a life
Don't let career growth consume your whole life. Regular breaks and activities outside of work prevent burnout and actually make you a better engineer. Your career should adapt to your life choices, not vice versa. This includes major life decisions - when I chose motherhood, I knew my career might slow down, but I'm at peace with that.
Find community
In a world where you often feel like you don't belong, connect with others who share your experience. I found my people through my bootcamp Resilient Coders, Hack.Diversity, and by starting BlackRel, a community for Black DevRel professionals. The right community can provide both emotional support and career guidance.

Be patient

Sometimes, staying at your level longer gives you space to grow stronger. Plus, being junior gives you the advantage of having teammates eager to help you learn.
Let go of the need for acceptance
I used to want to fit in at work, but embracing what makes me different created unexpected impact. For example, posting my tech themed nails on social media at GitHub Universe started a trend that outlasted my time there. While others had worn fun nails to conferences before me, sharing it on social media helped normalize combining tech with personal style.

Know when to pivot

Leaving a role or company isn't failure—it's growth. Some of my best career moves came when I recognized it was time to move on. I've explored roles like phlebotomy, IT support, front-end development, DevOps, developer advocacy, and different companies until I found my fit. Sometimes, staying too long stifled my growth, and leaving opened new doors. It's okay to pivot for progress.

Your turn
These are just a few of the ways I've learned to take control of my career. What strategies do you use to help you stay and grow in tech?
Map your career growth
Understand your team goals and company goals
Pay attention to how your company makes money and how your team contributes. To make a big impact, I look for ways my strengths can complement my teammates and help reach team goals.

Know your career ladder
Each company defines levels differently. Work with your manager to understand promotion requirements and create a plan while recognizing that business needs affect timing.

Advocate for yourself

Your manager can't read your mind. Good work isn't enough - you need to clearly express your goals and ask what it takes to achieve them. My husband and I interned at the same company: he did good work but stayed silent, while I asked what I needed to do to go full-time. His silence led our manager to assume he wanted to leave, while I received a full-time offer.

Enable your teammates

Find community

In a world where you often feel like you don't belong, connect with others who share your experience. I found my people through my bootcamp Resilient Coders, Hack.Diversity, and by starting BlackRel, a community for Black DevRel professionals. The right community can provide both emotional support and career guidance.

**
Be patient**

Why are people growing inside containers?

Oluwafemi Josephine — Wed, 15 Jan 2025 16:16:23 +0000

Nine years ago, in March 2013, Solomon Hykes and his cofounders revolutionized how we do software development with an open source platform called Docker. Although the creators of Docker didn't invent containers, they popularized them. Thanks to Docker, engineers can create tools, like GitHub Codespaces, that enable us to code in a development container hosted in the cloud.

I’ll admit that when I first heard about development containers, I had two questions:

Why are people developing inside containers?
What are containers? If you have similar questions, this post is for you. In this blog post, I'll explain what containers are, how they benefit engineers, and how to setup devcontainers in GitHub Codespaces. What does it mean to develop inside a container? Raise your hand if you’ve ever uttered the words, "It works on my machine." (Don’t worry; you're not alone)!

GIF

If you're not familiar with this phrase, it's a meme, but it's also a real phrase developers find themselves saying if they work in a codebase where the environments vary. Although working in varying environments is not ideal, it does happen. From my experience, situations like this occur when my local environment, my coworkers' local environments, staging, and production all have slight differences. Because the environments had slightly different configurations, bugs existed in one environment but didn’t exist in the other environment. It can feel so embarrassing and frustrating to build a feature or fix a bug that works locally but doesn't work in production or staging.

However, containers solve the issue of inconsistent developer environments. Containers enable software engineers to program in a consistent environment. Now, your coding environment can mirror production by using the same operating system, configurations, and dependencies. This ensures bugs and features behave the same across all environments relieving developers from the embarrassment of saying, "It works on my machine."

Now that we understand the purpose of containers, let’s explore how Codespaces leverages containers.
GitHub Codespaces takes software and cloud development to the next level
GitHub Codespaces allows you to code in a container hosted in the cloud. In this context, the cloud is an environment that doesn't reside on your computer but rather on the internet.
Faster onboarding
Typically, software engineers are responsible for setting up their local environment when they join a team. Local environment setup includes installing the required dependencies, linters, environment variables, and more. Developers may spend up to a week configuring their environment, depending on the quality of the documentation. When I was purely a software engineer, it took me about 2 days to set up my environment, and the experience was painful because I wanted to start coding immediately. Instead, I had to seed my database and edit my .zshrc file.
Fortunately, organizations can automate the onboarding process using GitHub Codespaces to configure a custom environment. When a new engineer joins the team, they can open a codespace and skip the local environment setup because the required extensions, dependencies, and environment variables exist within the codespace.
**
Code from anywhere
**
With Codespaces, I can code anywhere that I have internet access. If I switch devices or forget my laptop at home, I can easily resume my work on an iPad while I’m on the plane without cloning a repository, downloading my preferred IDE, and setting up a local environment. This is possible because Codespaces opens a Visual Studio Code-like editor inside the browser. The best part is Codespaces can autosave my code even if I forget to push my changes to my repository.
**
Consistent environments**

As mentioned in the paragraphs above, containers allow you to work in a mirrored production environment. Because GitHub Codespaces uses containers, you can get the same results and developer experience in your local environment as you would in your production environment.
Additionally, sometimes when changes happen to the codebase, such as infrastructure enhancements, local environments can break. When local environments break, it’s up to the developer to restore their developer environment. However, GitHub Codespaces use of containers brings uniformity to developer environments and reduces the chances of working in a broken environment.

Three files you may need to configure a Codespace
You can leverage three files to make the Codespaces experience works for you and your teammates: the devcontainer.json file, the Dockerfile, and the docker-compose.yml file. Each of these files lives in the .devcontainer directory at the root of your repository.

The devcontainer.json file
The devcontainer.json file is a configuration file that tells GitHub Codespaces how to configure a codespace. Inside a devcontainer file, you can configure the following:

Extensions
Environment variables
Dockerfile
Port forwarding
Post-creation commands
And more
This means that whenever you or someone opens a codepspace, the extensions, environment variables, and other configurations you specify in the devcontainer.json file will automatically install when they open a codespace in the specified repository. For example, if I wanted folks to have the same linter and extensions as me, I could add the following to my devcontainer.json file: devcontainer.json 
{
"name": "Node.js",
"build": {
"dockerfile": "Dockerfile",
// Update 'VARIANT' to pick a Node version: 18, 16, 14.
// Append -bullseye or -buster to pin to an OS version.
// Use -bullseye variants on local arm64/Apple Silicon.
"args": { "VARIANT": "16-bullseye" }
},

// Configure tool-specific properties.
"customizations": {
// Configure properties specific to VS Code.
"vscode": {
// Add the IDs of extensions you want installed when the container is created.
"extensions": [
"dbaeumer.vscode-eslint", // this is the exentension id for eslint
"esbenp.prettier-vscode", // this is the extension id for prettier
"ms-vsliveshare.vsliveshare", // this is the extension id for live share
]
}
},

// Use 'forwardPorts' to make a list of ports inside the container available locally.
// "forwardPorts": [],

// Use 'postCreateCommand' to run commands after the container is created.
// "postCreateCommand": "yarn install",

// Comment out to connect as root instead. More info: https://aka.ms/vscode-remote/containers/non-root.
"remoteUser": "node"
}

You can learn more about the devcontainer.json file here.
The Dockerfile
The Dockerfile is a configuration file that tells GitHub Codespaces how to build a container. It contains a list of commands that the Docker client calls while creating an image. Dockerfiles are used to automate the installation and configuration of a container. For example, if I wanted to install Node.js in a container, I could add the following to my Dockerfile: Dockerfile 
FROM node:16-bullseye

You can learn more about Dockerfiles here, and you can learn more about setting up a node.js in Codespaces here.
The docker-compose.yml file
You don't need a docker-compose.yml file in a Codespace, but it's useful if you want to run multiple containers. For example, if you want to run a database and a web server in a Codespace, you can use the docker-compose.yml file to run both containers. You can learn more about docker-compose.yml files here. Here's an example of what a docker-compose.yml file that's connecting to a database might look like: docker-compose.yml 
version: '3.8'

services:
app:
build:
context: ..
dockerfile: .devcontainer/Dockerfile
args:
VARIANT: "3"
NODE_VERSION: "none"

volumes:
  - ..:/workspace:cached

command: sleep infinity

network_mode: service:db

db:
image: postgres:latest
restart: unless-stopped
volumes:
- postgres-data:/var/lib/postgresql/data
hostname: postgres
environment:
POSTGRES_DB: my_media
POSTGRES_USER: example
POSTGRES_PASSWORD: pass
POSTGRES_HOST_AUTH_METHOD: trust
ports:
- 5432:5432

volumes:
postgres-data: null

Codespaces is not the same as GitHub’s web editor
GitHub Codespaces is not the same as GitHub’s web editor. The web editor is the editor that appears when you press "." in a repository. It is a lightweight editor that allows you to edit files in your repository. The web editor is great for making minor changes to a file, but it’s not ideal for writing and running full stack web applications. This is because the GitHub web editor does not have a terminal. However, Codespaces allows you to run a full-fledged IDE in the browser equipped with a terminal and more.

See the below image to understand the differences between GitHub's web editor and GitHub Codespaces. This image is from the GitHub official documentation. You can read more details here.