Your First 90 Days as a Junior Developer in Nairobi

Your first month is about absorbing information, not producing output. This feels counterintuitive because you want to prove you deserve the job. But the developers who try to ship major features in week one almost always make a bigger mess than the ones who spend that time learning.

Week 1: Setup and orientation. You will spend most of your first week setting up your development environment, getting access to repositories and tools, and meeting people. This process is more complex than you expect. Enterprise codebases have dependencies, environment variables, database connections, and deployment pipelines that take time to configure. Do not be embarrassed if your setup takes two or three days. Ask for help if you are stuck for more than an hour on any setup step. There is always some undocumented configuration that only someone on the team knows about.

Weeks 2 and 3: Exploring the codebase. Open the main repository and start reading code. Not all of it (that would take months), but follow the flow of a single feature from the frontend to the backend to the database. Pick something simple, like "what happens when a user logs in?" and trace every file and function involved. This exercise teaches you more about the architecture than any documentation. While exploring, write down things that confuse you. These become your questions for your mentor or team lead.

Week 4: Your first small contribution. By the end of your first month, you should aim to submit at least one pull request. It does not need to be impressive. Fixing a typo in the UI, updating a README, or resolving a small bug that nobody else has prioritized are all valid first contributions. The goal is to learn the team's workflow: how to branch, commit, push, create a PR, respond to review comments, and merge. The content of the change matters less than demonstrating you can follow the process.

What your team actually expects. In most Nairobi tech companies, the expectation for a junior developer in the first month is this: set up your environment, start understanding the codebase, ask good questions, and show up consistently. That is it. If you accomplish these four things, your team lead is satisfied. The bar is not high because they know you are learning. Meet it reliably and you build the foundation for everything that follows.

In your second month, you shift from observer to contributor. You still have enormous amounts to learn, but you should be picking up real tickets and delivering working code.

Taking on real tickets. Your team lead will start assigning you small, well-defined tasks. Bug fixes, minor feature additions, UI adjustments. These are not glamorous, but they are exactly what you need. Each ticket forces you to understand a specific part of the codebase, interact with the testing process, and go through code review. Treat every ticket as a learning opportunity, not just a task to complete.

Estimating work (and being honest about it). You will be asked to estimate how long a task will take. As a junior developer, your estimates will be wrong. That is expected. The key is to be honest and transparent. If you think something will take two days, say two days. If it ends up taking four, communicate that early: "This is taking longer than I estimated because I discovered X. I expect to finish by Thursday." Surprises are worse than delays. A team lead who knows a task is delayed can plan around it. A team lead who finds out on the deadline that the work is not done has a problem.

Code reviews: giving and receiving. You will receive feedback on your pull requests. Some of it will be about style and conventions ("we use camelCase here, not snake_case"). Some will be about approach ("this query would be more efficient as a join instead of two separate calls"). Do not take review comments personally. They are about the code, not about you. Respond to every comment, either with the change they suggested or a question if you do not understand the reasoning. Also start reviewing other people's PRs, even if you feel unqualified. You will learn from reading other people's code, and asking clarifying questions in reviews is a legitimate contribution.

Building relationships with your team. Go to lunch with your colleagues. Join the team WhatsApp group. Participate in standup meetings actively (not just "I am working on ticket X"). Ask about the product domain, not just the code. Understanding why a feature exists helps you build it better. In Nairobi's tech scene, relationships matter as much as skills. The developers who integrate into their team socially are the ones who get better assignments, more mentorship, and stronger references.

Your third month is when things start clicking. You know the codebase well enough to navigate without help for most tasks. You understand the team's patterns. You can estimate more accurately. This is when you shift from "the new person" to "a contributing member of the team."

Taking ownership of a feature or area. By month three, aim to own something. Not the entire product, but a specific feature or section of the codebase that you understand deeply. Maybe it is the notification system, or the user settings page, or the reporting module. When someone has a question about that area, you should be the person who can answer it. Ownership demonstrates initiative and gives you depth in a specific area while you continue building breadth across the codebase.

Proactive communication. By now, your team lead should not need to ask you for status updates. You should be providing them proactively. A brief message at the end of each day or a thorough update at each standup: what you completed, what you are working on next, and any blockers. This level of communication is what separates junior developers who get promoted from those who stay junior for years. It is not about the code. It is about making your manager's job easier.

The probation review. Many Kenyan companies have a three-month probation period. Your review at the end of this period determines whether you are confirmed as a permanent employee. The criteria are rarely purely technical. They are looking at reliability (do you show up on time and deliver what you promise?), communication (do you ask questions and provide updates?), growth (are you learning and improving?), and cultural fit (do you work well with the team?). If you have followed the approach in this guide, you should pass this review comfortably.

Starting to think about what is next. Now that you are past the survival phase, think about your growth trajectory. What skills do you want to develop? What part of the stack interests you most? Are there senior developers on the team you want to learn from? Have a conversation with your team lead about your development plan. Most good managers appreciate a junior developer who is thinking about their growth, and they will often provide resources, mentorship, or stretch assignments to support it.

These patterns show up consistently among new developers at Nairobi companies. Knowing about them in advance gives you a real advantage.

1. Suffering in silence. You are stuck on a bug for three hours. You have tried everything you know. But you do not ask for help because you are afraid of looking stupid. Meanwhile, a senior developer could have pointed you in the right direction in five minutes. The rule of thumb: if you have been stuck for more than 30 minutes without progress, ask for help. Frame your question well ("I have tried X, Y, and Z, and I am still getting this error. Here is what I have found so far. Any ideas?"), and nobody will think less of you. They will think more of you for being efficient with your time.

2. Trying to rewrite everything. You look at the codebase and see code that is messy, outdated, or written in a style you disagree with. Your instinct is to refactor everything. Resist this. That "messy" code has been running in production for months or years. It has edge cases baked in that you do not understand yet. Rewriting it introduces risk and disrupts your team's priorities. Focus on writing clean, well-tested code for new features. As you gain experience and context, you can propose specific, targeted refactors with a clear justification.

3. Not writing tests. If your team writes tests (and they should), you should be writing tests for every piece of code you submit. "It works on my machine" is not a testing strategy. Writing tests feels slow at first, but it catches bugs before they reach production and demonstrates that you take code quality seriously. If your team does not have a strong testing culture, writing tests anyway is one of the best ways to stand out as a junior developer.

4. Overcommitting to deadlines. Your team lead asks "can you finish this by Friday?" and you say yes because you want to seem capable. Then Friday arrives and you are only halfway done. The better response: "Let me look at the requirements and give you an estimate by end of day." Then provide an honest timeline. If they need it faster, they will tell you, and you can discuss what to cut or who can help. A realistic estimate followed by on-time delivery beats an optimistic promise followed by a missed deadline every single time.

5. Comparing yourself to senior developers. You watch a senior developer debug an issue in ten minutes that would have taken you a full day. You feel inadequate. Stop. That senior developer has been coding for five, ten, maybe fifteen years. They have seen that bug pattern hundreds of times. You are comparing your beginning to their middle. Focus on your own progress. Are you faster this month than last month? Are you asking better questions? Are you understanding more of the codebase? That is what matters.

Technical skills get you the job. Soft skills determine whether you keep it and grow. At the junior level, trust is the most valuable currency you have, and it is built through consistent small actions, not grand gestures.

Be on time, every time. This sounds basic, but it matters more than you think. If standup is at 9:00 AM, be there at 8:55. If you have a meeting at 2:00 PM, join at 1:58. Being consistently punctual signals reliability. Being consistently late signals that you do not respect other people's time. In Nairobi's traffic, this means planning your commute with buffer time. If you are working remotely, there is no excuse for joining a meeting late.

Follow through on what you say. If you say "I will look into that and get back to you by tomorrow," do it. Even if the answer is "I looked into it and I do not know yet, but here is what I have found so far." The follow-through matters more than the answer. People stop trusting developers who say they will do things and then forget. Keep a list of commitments you have made and check them off. A simple note-taking system (even Apple Notes or Google Keep) prevents things from falling through the cracks.

Admit mistakes quickly. You will break something. Maybe you push code that breaks the staging environment. Maybe you accidentally delete data in a development database. Maybe you misunderstand a requirement and build the wrong thing. When it happens, tell your team lead immediately. "I made a mistake. Here is what happened. Here is what I have done to fix it so far. Do you have any advice?" This response builds trust because it shows integrity. Trying to hide a mistake and hoping nobody notices is the fastest way to destroy trust.

Show gratitude for help. When a senior developer spends thirty minutes helping you debug an issue, thank them genuinely. When your team lead gives you constructive feedback, acknowledge it and apply it. When a colleague covers for you during a difficult week, recognize it. People remember how you made them feel, and gratitude costs nothing but creates goodwill that pays dividends throughout your career.

Be curious about the business, not just the code. Ask questions about why the product works the way it does. Who are the users? What problems are they solving? Why was this feature prioritized over that one? Understanding the business context makes you a better developer because you make better decisions about trade-offs, priorities, and user experience. It also positions you as someone who thinks beyond the code, which is exactly what companies look for when deciding who to promote.

The Nairobi tech scene has its own dynamics that generic career advice does not cover. Here are things specific to working as a developer in the city.

Commute planning is a real skill. Nairobi traffic can turn a 30-minute commute into a two-hour ordeal. If your office is in Westlands, Upper Hill, or the CBD, plan your schedule around traffic patterns. Many developers leave home before 6:30 AM or after 9:30 AM to avoid the worst of it. Some companies offer flexible start times specifically because of traffic. Ask about this during onboarding. If your company offers remote or hybrid work options, take advantage of them.

Power and internet backup matters. If you are working from home (hybrid or fully remote), invest in a reliable internet backup and power solution. A portable router with a backup SIM card and a small UPS or power bank for your router will save you from the embarrassment of dropping off a meeting or losing unsaved work during an outage. Some developers maintain two different ISP connections for redundancy. At minimum, have a mobile hotspot ready.

The salary conversation. Junior developer salaries in Nairobi vary widely. Startups typically pay KES 40,000-80,000/month for juniors, while established companies and banks can offer KES 60,000-120,000+. If you feel underpaid after your probation period, it is appropriate to have a salary discussion with your manager. Come prepared with evidence of your contributions and market data. Our Nairobi developer salary guide has current ranges by experience level.

Building your network alongside your job. Your first job is not just a job. It is the start of your professional network. The colleagues you work with today will be the people who recommend you for opportunities, co-found startups with you, or hire you at their next company. Invest in these relationships. Attend team socials. Connect with colleagues on LinkedIn. Join local tech communities. Our networking guide covers how to do this without being awkward.

If you are preparing for your first developer role and want to make sure your technical foundation is solid before day one, McTaba's Full-Stack Software and AI Engineering course (KES 120,000) covers everything from React and Node.js to deployment and database design. Graduates enter their first job with production-level project experience, which significantly shortens the onboarding learning curve.