Forem: David Brooks

The First 90 Days as a Software Developer: What Actually Matters

David Brooks — Tue, 13 Jan 2026 23:48:59 +0000

The First 90 Days as a Software Developer: What Actually Matters

Your first job as a software developer can feel overwhelming.

You finally made it — but now:

The codebase is massive
The tickets are vague
Everyone else seems faster than you
You’re worried about asking “dumb” questions

The good news?

Success in your first 90 days has very little to do with being the best coder on the team.

Here’s what actually matters when you’re getting started in a real-world engineering role.

1. Learn the Codebase, Not the Framework

Junior developers often focus on mastering the tech stack first:

The framework
The libraries
The tooling

But what matters more early on is understanding how your team’s system works.

That means learning:

Where data comes from
How features flow through the app
What parts of the system are fragile
Which areas people avoid touching

Reading existing code — even when it’s messy — will teach you more than tutorials ever will.

2. Ask “Why” Before You Ask “How”

It’s tempting to jump straight to implementation questions:

“How do I fix this bug?”

“How do I build this feature?”

But better questions often start with why:

Why does this work this way?
Why was this decision made?
Why is this edge case important?

Understanding why something exists helps you avoid breaking it — and leads to better solutions.

Asking thoughtful questions is a strength, not a weakness.

3. Ship Small Wins Early

You don’t need to land a massive feature in your first month.

In fact, it’s better to:

Fix small bugs
Improve logging
Clean up minor UI issues
Add tests in low-risk areas

Small wins build trust quickly.

They show your team that you can:

Navigate the codebase
Follow conventions
Deliver without drama

Reliability beats heroics early on.

4. Communicate More Than You Think You Need To

One of the fastest ways junior developers get into trouble is by staying quiet too long.

If you’re:

Blocked
Confused
Unsure about scope
Behind schedule

Say something early.

Good communication looks like:

Posting regular updates
Calling out risks ahead of time
Asking for clarification before assumptions harden

Most managers would rather hear “I’m stuck” on day one than “I’m still working on it” a week later.

5. Your Job Is Not to Be Brilliant — It’s to Be Reliable

Many junior developers feel pressure to prove themselves by being impressive.

In reality, teams value developers who:

Finish what they start
Write readable code
Accept feedback well
Improve consistently

Being reliable builds confidence.

Confidence leads to autonomy.

Autonomy leads to better work.

Brilliance can come later.

Final Thoughts

The first 90 days aren’t about mastering everything — they’re about building trust.

If your teammates know they can rely on you, you’re doing great.

Focus on:

Learning the system
Communicating clearly
Delivering steady progress

The rest will come faster than you think.

About the Author

I’m a full-stack developer with a strong focus on frontend development. I write practical, real-world advice for early-career developers navigating their first few years in the industry.

If you’re interested in technical writing or frontend development, feel free to connect with me on LinkedIn.

What Junior Developers Get Wrong About “Clean Code”

David Brooks — Tue, 13 Jan 2026 23:39:03 +0000

What Junior Developers Get Wrong About “Clean Code”

If you’re a junior developer, you’ve probably heard the phrase “clean code” thrown around a lot.

Write clean code.

This isn’t clean.

Can you refactor this to be cleaner?

Early on, it’s easy to internalize the idea that clean code means clever, abstract, or impressive. In reality, many junior developers overcorrect—and end up making their code harder to understand, not easier.

Let’s talk about what clean code actually means in real-world software teams, and what junior developers commonly get wrong.

1. Clean Code Is Not Clever Code

One of the biggest traps junior developers fall into is trying to be too smart.

You learn:

Advanced language features
Fancy one-liners
Patterns that reduce lines of code

And suddenly this:

ts

if (user && user.isActive && user.hasPermission('ADMIN')) {
  enableAdminPanel();
}

Becomes this:

ts

user?.isActive && user?.hasPermission?.('ADMIN') && enableAdminPanel();

Is it shorter? Yes.
Is it more readable? For most teams — no.

Clean code prioritizes clarity over cleverness. If someone has to slow down to understand it, you’re already losing.

Readability Beats DRY (Especially Early)

“Don’t Repeat Yourself” is a great principle — but junior developers often apply it too aggressively.

This happens a lot:

ts 

function handleUserState(user: User) {
  return isActiveAdmin(user)
    ? getAdminConfig(user)
    : getDefaultConfig(user);
}

Now the reader has to jump:

To isActiveAdmin
Then to getAdminConfig
Then back again

Sometimes repetition is intentional clarity.

In real codebases, teams often prefer a bit of duplication if it keeps logic easy to follow. DRY is a guideline, not a law.

3. Over-Abstraction Is Usually a Smell

A common junior instinct is to “future-proof” everything.

You might think:

“This might change later, so I should abstract it now.”

That often leads to:

Interfaces with only one implementation
Services that wrap a single function
Config-driven logic no one actually asked for

For example:

ts

interface ButtonBehavior {
  execute(): void;
}

When all you really needed was:

ts

onClick() {
  saveForm();
}

Abstractions should exist to solve real problems, not hypothetical ones. Premature abstraction is one of the fastest ways to make a codebase harder to understand and maintain.

A good rule of thumb:

If you can’t clearly explain why an abstraction exists today, it probably shouldn’t exist yet.

4. Naming Is More Important Than Patterns

Junior developers often focus heavily on structure:

Design patterns
Architecture diagrams
Folder layouts

But experienced developers tend to obsess over naming.

Consider this function:

ts

function processData(data: any) {}

ts

Now compare it to:

function calculateWeeklyStartGoals(jobs: Job[]) {}

The second example immediately tells you:

What the function does
What kind of data it expects
Why it exists

Clear naming:

Reduces the need for comments
Makes code reviews faster
Helps new teammates ramp up more easily
Prevents misunderstandings before they happen

Before reaching for a new pattern or abstraction, ask yourself:

“Would better names make this clearer?”

In many cases, improving names does more for code quality than introducing additional structure.

5. Code Is for Humans, Not Your Resume

A tough lesson many junior developers learn over time is that code is rarely judged in isolation.

Your code will be read by:

Teammates reviewing your pull request
Engineers maintaining it months later
Developers who didn’t write it in the first place

The goal isn’t to show how much you know — it’s to make the next person successful.

That usually means:

Writing boring, predictable code
Being explicit instead of clever
Following team conventions
Letting your code blend into the codebase

“Boring” code is often excellent code.

If someone can understand your changes quickly and confidently, you’ve done your job well — even if the solution isn’t the most impressive one you could have written.

Final Thoughts

Clean code isn’t about being impressive or using advanced language features. It’s about writing code that clearly communicates intent and behaves predictably over time.

If you’re early in your career, focus less on writing “perfect” code and more on writing understandable code. Clarity compounds. The developers who grow the fastest are the ones whose code is easiest to read, review, and maintain.

You don’t need to be the smartest person on the team — you need to be the most reliable.

About the Author

I’m a full-stack developer with a strong focus on frontend development. I write practical, real-world advice for early-career developers navigating their first few years in the industry.

If you’re interested in technical writing or frontend development, feel free to connect with me on LinkedIn.

5 Common Angular Pitfalls and How to Avoid Them

David Brooks — Sun, 11 Jan 2026 22:49:42 +0000

Beware

Angular is a powerful framework, but even experienced developers can fall into common traps that hurt performance, maintainability, or readability. Falling victim to these small issues can quietly fuel that all-too-familiar developer ailment: imposter syndrome.

In this article, I’ll walk through five common Angular pitfalls I see in real-world applications and show how to avoid them with practical examples and best practices.

1. Misusing Lifecycle Hooks (`ngOnInit`, `ngOnChanges`)

The problem:

Many developers overuse ngOnInit or put heavy logic in ngOnChanges, causing unnecessary re-renders or complicated debugging.

The solution

Keep lifecycle hooks focused on initialization or change detection that actually depends on input changes
Move business logic to services instead of components

Bad example:

ts 


ngOnInit() {
  this.loadData();
  this.processData(); // heavy computation here
}

Better example

ts


ngOnInit() {
  this.loadData();
}

private loadData() {
  this.dataService.getData().subscribe(data => {
    this.processData(data);
  });
}

Why it matters:

Separating concerns keeps components lightweight, testable, and easier to maintain.

2. Overusing Two-Way Binding (`[(ngModel)]`)

The problem

Two-way binding is convenient, but overusing [(ngModel)]—especially in larger forms—can lead to hidden side effects and messy validation logic.

The solution

Use Reactive Forms for anything non-trivial
Reserve ngModel for very simple inputs

Reactive forms example

ts


form = new FormGroup({
  name: new FormControl('', Validators.required),
  email: new FormControl('', [
    Validators.required,
    Validators.email
  ])
});

html


<form [formGroup]="form">
  <input formControlName="name" />
  <input formControlName="email" />
</form>

Why it matters:

Reactive forms make validation, testing, and debugging much more predictable as your app grows.

3. Improper State Management (BehaviorSubject vs Signals)

The problem

Many Angular applications rely heavily on BehaviorSubject for all state, even when the state is simple. This can lead to unnecessary RxJS boilerplate and more complex code than needed.

The solution

Use Signals (Angular 16+) for simple reactive state
Use BehaviorSubject or NgRx for shared or complex state
Keep state logic in services, not components

Signals example

ts 


import { signal } from '@angular/core';

export class CounterService {
  counter = signal(0);

  increment() {
    this.counter.update(value => value + 1);
  }
}

Why it matters:

If you’re already deep into NgRx, Signals won’t replace it—but they’re a great fit for local or service-level state.

Signals provide clean, readable reactivity without the overhead of observables when your state doesn’t require complex streams or operators.

4. Forgetting `trackBy` in `*ngFor`

The problem

When rendering lists without a trackBy function, Angular destroys and recreates DOM elements whenever the list changes—even if only one item was updated. This can cause unnecessary re-renders and performance issues, especially with larger lists.

The solution

Always provide a trackBy function when iterating over collections

Good practice example

html


<li *ngFor="let item of items; trackBy: trackById">
  {{ item.name }}
</li>

ts


trackById(index: number, item: { id: number }) {
  return item.id;
}

Why it matters:

Using trackBy ensures Angular only updates the elements that actually changed, significantly improving rendering performance.

5. Inefficient Change Detection

The problem

Default change detection can cause unnecessary checks across the component tree, which leads to degraded performance in larger applications.

The solution

Use ChangeDetectionStrategy.OnPush
Pass immutable data to components
Avoid unnecessary template bindings

Example

ts


import { ChangeDetectionStrategy, Component, Input } from '@angular/core';

@Component({
  selector: 'app-user-card',
  templateUrl: './user-card.component.html',
  changeDetection: ChangeDetectionStrategy.OnPush
})
export class UserCardComponent {
  @Input() user!: User;
}

Why it matters:

OnPush dramatically reduces unnecessary change detection cycles and helps keep your UI fast and responsive.

Key takeaways:

Avoid common lifecycle hook misuse
Prefer Reactive Forms over excessive ngModel
Use Signals for simple state
Optimize lists with trackBy
Boost performance with OnPush change detection

About the Author

I’m a full-stack developer with a strong focus on frontend development, specializing in Angular and technical writing. I write practical, example-driven guides based on real-world experience.

If you’re looking for a freelance technical writer, feel free to connect with me on LinkedIn.

Forem: David Brooks

The First 90 Days as a Software Developer: What Actually Matters

The First 90 Days as a Software Developer: What Actually Matters

1. Learn the Codebase, Not the Framework

2. Ask “Why” Before You Ask “How”

3. Ship Small Wins Early

4. Communicate More Than You Think You Need To

5. Your Job Is Not to Be Brilliant — It’s to Be Reliable

Final Thoughts

About the Author

What Junior Developers Get Wrong About “Clean Code”

What Junior Developers Get Wrong About “Clean Code”

1. Clean Code Is Not Clever Code

Readability Beats DRY (Especially Early)

3. Over-Abstraction Is Usually a Smell

4. Naming Is More Important Than Patterns

5. Code Is for Humans, Not Your Resume

Final Thoughts

About the Author

5 Common Angular Pitfalls and How to Avoid Them

Beware

1. Misusing Lifecycle Hooks (ngOnInit, ngOnChanges)

The problem:

The solution

Why it matters:

2. Overusing Two-Way Binding ([(ngModel)])

The problem

The solution

Reactive forms example

Why it matters:

3. Improper State Management (BehaviorSubject vs Signals)

The problem

The solution

Signals example

Why it matters:

4. Forgetting trackBy in *ngFor

The problem

The solution

Good practice example

Why it matters:

5. Inefficient Change Detection

The problem

The solution

Example

Why it matters:

About the Author

1. Misusing Lifecycle Hooks (`ngOnInit`, `ngOnChanges`)

2. Overusing Two-Way Binding (`[(ngModel)]`)

4. Forgetting `trackBy` in `*ngFor`