Forem: Manuchim Oliver

Terraform Provisioners: The Most Misunderstood Feature in IaC

Manuchim Oliver — Sun, 22 Mar 2026 11:22:51 +0000

Most engineers don’t start with Terraform provisioners.

They arrive there naturally.

You provision an EC2 instance.

You SSH into it.

You install what you need.

Then you think:

“Why not automate this part too?”

So you reach for provisioners.

remote-exec to run commands
file to copy scripts
local-exec to glue workflows together

And for a moment — everything feels clean and automated.

Until it doesn’t.

The Moment Things Break

You update your script.

Run:

terraform apply

And… nothing happens.

No commands run.
No changes applied.
No errors.

Just silence.

This is the moment most people think something is broken.

But nothing is broken.

Terraform is doing exactly what it was designed to do.

The Core Misunderstanding

Terraform is declarative.

It cares about the state of infrastructure — not the steps to configure it.

Provisioners, on the other hand, are imperative.

They introduce instructions like:

Run this command
Copy this file
Execute this script

That’s a completely different model.

What Provisioners Actually Are

Provisioners are not part of your normal workflow.

They are:

Lifecycle hooks that run once, during resource creation (or destruction).

That’s it.

They are not:

Continuous configuration tools
Script runners
Update mechanisms

The Three Types (Quick Context)

1. local-exec

Runs on your local machine.

Useful for:

Logging
Triggering external systems
Quick integrations

2. remote-exec

Runs on the instance via SSH.

Useful for:

Bootstrapping
Installing packages
Initial setup

3. file

Copies files to the instance.

Usually paired with remote-exec.

None of these are inherently bad.

The problem is how they’re used.

Why Senior Engineers Avoid Overusing Provisioners

It’s not about rules. It’s about experience.

1. They Don’t Rerun

Provisioners run only during creation.

If you change the script, Terraform won’t care.

To rerun them, you have to:

bash terraform taint aws_instance.example terraform apply

You’re now destroying infrastructure just to rerun a script.

That’s friction — and a signal.

2. They Depend on SSH

remote-exec and file require connectivity.

That introduces:

Network dependencies
Timing issues
Authentication complexity

At scale, this becomes fragile.

3. They Break the Declarative Model

Terraform is designed to describe what should exist.

Provisioners introduce how things should happen.

That shift seems small — but it compounds quickly.

4. They Don’t Scale Cleanly

What works for one instance:

Doesn’t work the same for 10
Or 100
Or across environments

Provisioners don’t give you consistency guarantees.

So When Should You Use Them?

Provisioners are still useful — when used intentionally.

Good use cases:

Quick bootstrapping in prototypes
Small automation gaps
One-time setup tasks

Not for:

Full configuration management
Ongoing system changes
Production-critical workflows

Better Alternatives

Instead of pushing everything into Terraform:

Use user_data / cloud-init for instance initialization
Use Packer to bake images
Use configuration management tools for system setup
Use SSM for remote execution without SSH

Each tool has a clear responsibility.

The Real Shift

The biggest lesson isn’t about provisioners.

It’s about thinking in layers.

Instead of asking:

“How do I make this run in Terraform?”

Ask:

“Where does this responsibility belong?”

Infrastructure → Terraform
Instance setup → cloud-init / images
Configuration → dedicated tools

Final Thought

Provisioners are not the problem.

Misusing them is.

A senior engineer doesn’t avoid tools blindly —
they understand the boundaries where each tool is strongest.

And design systems that respect those boundaries.

Blue-Green Deployment on AWS: Step-by-Step Guide to Zero-Downtime Releases (2026 guide)

Manuchim Oliver — Wed, 04 Mar 2026 20:13:35 +0000

Your Deployment Just Took Down Production. Again. Here's How to Never Let That Happen.

It was a Thursday afternoon. The kind where you're mentally halfway out the door, maybe already thinking about the weekend.

Then Slack lights up.

"Hey… the app is down."

You deployed thirty minutes ago. A "small" hotfix. Two lines. "It'll be fine."

If you've been in production engineering long enough, you've lived this story. If you haven't yet — you will. The question isn't whether a bad deployment will happen. The question is: when it does, how fast can you recover?

That's the problem Blue-Green deployment solves. And today I'm walking you through exactly how to implement it on AWS using Elastic Beanstalk and Terraform — zero downtime, instant rollbacks, infrastructure-as-code from day one.

What Blue-Green Actually Means (And Why Most Explanations Miss the Point)

Most articles define it like this:

"You have two identical environments. Blue is live. Green is staging. You swap them."

Technically correct. Completely useless without context.

Here's the mental model that actually sticks:

Imagine your production environment is a patient on an operating table — heart beating, users connected, traffic flowing. Every deployment you push to that live environment is open-heart surgery while the heart is still running. One wrong cut and the patient flatlines. 3am pages. Slack on fire. The works.

Blue-Green says: stop operating on the live patient.

Instead, spin up an identical second patient — your green environment. Do all your surgery there. Test it. Benchmark it. Validate every edge case. When you're 100% confident, flip a switch. One DNS record change. Traffic moves from blue to green. The old patient sits warm and healthy as your fallback.

Something goes wrong in production with the new version? Flip the switch back. Your previous version was never touched.

That's the real power — not just "two environments." It's the ability to deploy with confidence because your escape hatch is always one click away.

The Architecture: What We're Building

Two fully independent Elastic Beanstalk environments, each with its own ALB, Auto Scaling group, health monitoring, and application version stored in S3:

┌──────────────────────────────────────────────────────────────┐
│                 Elastic Beanstalk Application                │
├──────────────────────────────────────────────────────────────┤
│                                                              │
│  ┌──────────────────────┐    ┌──────────────────────┐       │
│  │  Blue Environment    │    │  Green Environment   │       │
│  │  (Live Production)   │    │  (Staging / Next)    │       │
│  │  Version 1.0         │    │  Version 2.0         │       │
│  │  ALB + Auto Scaling  │    │  ALB + Auto Scaling  │       │
│  │  Health Checks       │    │  Health Checks       │       │
│  └──────────────────────┘    └──────────────────────┘       │
│             │                           │                   │
│             └─────────────┬─────────────┘                   │
│                           ▼                                 │
│               CNAME Swap ← this is the magic                │
└──────────────────────────────────────────────────────────────┘

The "swap" is literally swapping two DNS CNAME records. Elastic Beanstalk handles this natively — one API call, no custom load balancer gymnastics needed.

The Terraform Setup

If it's not in code, it doesn't exist. Let's walk through the meaningful parts.

IAM: The Foundation Nobody Talks About

Before a single instance spins up, Beanstalk needs two distinct IAM roles — and confusing them is the #1 reason I see environments fail to provision.

# Role for EC2 instances (so Beanstalk can manage them)
resource "aws_iam_role" "eb_ec2_role" {
  name = "${var.app_name}-eb-ec2-role"
  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Action    = "sts:AssumeRole"
      Effect    = "Allow"
      Principal = { Service = "ec2.amazonaws.com" }
    }]
  })
}

# Attach the three managed policies Beanstalk needs
resource "aws_iam_role_policy_attachment" "eb_web_tier" {
  role       = aws_iam_role.eb_ec2_role.name
  policy_arn = "arn:aws:iam::aws:policy/AWSElasticBeanstalkWebTier"
}

The eb_ec2_role lets instances do their job. The service role (separate) lets Beanstalk itself make AWS API calls on your behalf — health reporting, managed updates, scaling events. Both are required. Most tutorials only mention one.

S3: Your App's Artifact Store

resource "aws_s3_bucket" "app_versions" {
  # Account ID in the name = globally unique without hardcoding
  bucket = "${var.app_name}-versions-${data.aws_caller_identity.current.account_id}"
}

resource "aws_s3_bucket_public_access_block" "app_versions" {
  bucket                  = aws_s3_bucket.app_versions.id
  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

Your deployment artifacts are not public content. Lock the bucket down from day one. The aws_caller_identity data source ensures the bucket name is account-scoped — no manual uniqueness wrangling.

The Blue Environment (Production)

resource "aws_elastic_beanstalk_environment" "blue" {
  name          = "${var.app_name}-blue"
  application   = aws_elastic_beanstalk_application.app.name
  version_label = aws_elastic_beanstalk_application_version.v1.name
  tier          = "WebServer"

  # Rolling deploys: only redeploy 50% of instances at a time
  setting {
    namespace = "aws:elasticbeanstalk:command"
    name      = "DeploymentPolicy"
    value     = "Rolling"
  }
  setting {
    namespace = "aws:elasticbeanstalk:command"
    name      = "BatchSize"
    value     = "50"
  }

  # Never fly blind
  setting {
    namespace = "aws:elasticbeanstalk:healthreporting:system"
    name      = "SystemType"
    value     = "enhanced"
  }

  tags = merge(var.tags, {
    Environment = "blue"
    Role        = "production"
  })
}

The green environment is structurally identical — same ALB, same scaling config, same health checks — with one difference: it points to v2 of the application. That's the whole point. Production parity is not optional.

The Swap: One Command, Zero Downtime

You've validated green. Smoke tests pass. Load tests pass. You've slept on it. Time to ship.

AWS CLI:

aws elasticbeanstalk swap-environment-cnames \
  --source-environment-name my-app-blue \
  --destination-environment-name my-app-green \
  --region us-east-1

Console: Elastic Beanstalk → App → Blue Environment → Actions → Swap Environment URLs → Select Green → Swap.

Beanstalk modifies the Route 53 configuration. Within 60-90 seconds, traffic that was hitting your blue URL is now served by your green environment. The environment names stay the same. The URLs swap. Users experience nothing — no error pages, no dropped connections, no 502s.

The Rollback That Doesn't Require a Hero

Here's what makes this strategy genuinely production-grade: your rollback is identical to your deployment.

Green is now production. Something's wrong — a memory leak that only appears under real user load, a third-party integration that behaves differently, anything. Run the swap again. Your v1 environment is still running, still healthy, still warm. That's a 30-second rollback with zero redeployment.

No terraform apply. No container rebuild. Just a DNS flip.

When to Use Blue-Green (And When Not To)

Blue-Green is not a universal answer. Part of being a senior engineer is knowing which tool fits the job.

Reach for Blue-Green when:

Zero downtime is a hard requirement
You need instant rollback capability (regulated industries, payment systems, healthcare)
Your app is stateful or tightly coupled to a DB schema — gradual rollouts get complicated fast

Consider Canary Deployments when:

You want to validate with 5-10% of real traffic before full rollout
You're doing ML model deployments or high-risk feature releases
You have enough traffic volume to get statistically meaningful signal from a subset

Consider Rolling when:

Cost is a hard constraint — Blue-Green effectively doubles your infrastructure spend during deployment windows
Your background jobs make "two live versions simultaneously" operationally complex

The Cleanup Reminder (Seriously, Don't Skip This)

Two full Elastic Beanstalk environments with load balancers run roughly $50-100/month. For a learning exercise, spin it up, validate the swap, tear it down.

terraform destroy

The Terraform code is your infrastructure. You can recreate the whole thing in under 20 minutes. That's the point of infrastructure-as-code — your environment is disposable. Your knowledge of it isn't.

The Real Takeaway

Blue-Green deployments aren't about Elastic Beanstalk. Or ECS. Or Kubernetes. The platform changes. The principle doesn't.

The real takeaway is this: production deployments should be boring.

The most dangerous deployment is the one that "should be fine." The hotfix at 4pm on a Thursday. The one-liner that touches the payments table. The change a developer calls "trivial."

Boring means predictable. Boring means you have a plan when things go wrong — not if. Boring means your on-call engineer isn't doing open-heart surgery on a live patient at 2am.

Blue-Green gives you boring deployments. In production, boring is the highest compliment you can receive.

Full Terraform source code in the repo linked below. Questions? Drop them in the comments — I read everything.

Code Repository

Your Silent Superpower: Why Bash is Still the Most Dangerous Tool in Your Arsenal

Manuchim Oliver — Thu, 29 Jan 2026 20:56:24 +0000

I didn’t “learn Bash” this week.
I remembered it.

It was my first time doing "real" DevOps work, manually typing the same commands for the third time that week. grep "ERROR" application.log. Then I'd count the errors with grep -c "ERROR" application.log. Switch to system.log. Repeat. A senior engineer walked by, watched me for about 12 seconds, and said: "You know you can script that, right?"

The conversation we had after that changed everything.

Here's what nobody tells you about Bash scripting: It's not about being a programming wizard. It's about recognizing that if you're doing something more than twice, you're doing it wrong.

The Real Power Isn't in the Code—It's in the Mindset Shift

Let me show you what I mean. My daily log analysis used to look like this:

Check which log files changed in the last 24 hours (manual)
Scan application.log for errors, fatal issues, critical alerts (manual)
Repeat for system.log (manual)
Mentally track everything (exhausting)
Hope I don't get interrupted and lose my place (and I always did)

Time investment: 30-45 minutes

Error rate: High (because humans aren't designed for repetitive tasks)

Job satisfaction: Approaching zero

But now? One command. Three seconds. A clean report that tells me if anything needs my immediate attention.

The Journey from Commands to Intelligence

What started as a simple script—just a few grep commands saved in a file—evolved into something genuinely intelligent. Here's what that progression looked like:

Stage 1: Basic Automation
Save the commands. Make them executable. Run once instead of ten times.
Stage 2: Smart Variables
Stop hardcoding everything. Use variables for directories, file names, error patterns. Change one line instead of rewriting everything.
Stage 3: Dynamic Loops
Why analyze two files when your script can detect and analyze every relevant file automatically? Loops transform rigid code into flexible automation.
Stage 4: Conditional Intelligence
This is where it gets interesting. My script doesn't just dump data—it evaluates. More than 10 critical errors? It flags me immediately. Otherwise? Save the report and move on.

The Real Lesson: Bash Scripts Are Living Documentation
Here's something I didn't expect: my automation scripts became the best documentation our team ever had. New engineer joins? They read the backup script and immediately understand our backup strategy. Someone asks about our deployment process? The script tells the story better than any wiki ever could.

This is what DevOps pioneers meant by "everything as code." It's not just about version control—it's about making your processes tangible, shareable, and improvable.

What You Can Automate Today (No, Seriously—Today)
If you're thinking "this sounds great but I'm not a programmer," stop right there. Neither was I when I started. Here's what you can automate with basic Bash scripting:

Environment setup: New laptop? One script installs everything, configures your tools, clones your repos, and sets up your databases. From zero to productive in minutes.

Disk space management: Automatically compress old logs, delete ancient ones, email you when space runs low. Set it and forget it.
Deployment checks: Pre-deployment validation that runs every time, catches issues before they hit production.

Backup verification: Don't just create backups—verify them. Automatically.

The Business Case (Just in Case Your Manager Asks)
Let's do the math:

45 minutes daily on manual tasks × 20 work days = 15 hours per month
15 hours × 12 months = 180 hours per year
That's 4.5 weeks of work time spent on tasks a script can do in seconds

And that's just one workflow. Multiply that across your team, across multiple repetitive tasks, and you're looking at hundreds of recovered hours.

Start Small, Think Big
You don't need to automate everything tomorrow. Start with the task that annoys you most. That thing you groan about every time you have to do it? That's your first script.

Mine was log analysis. Yours might be environment setup, or deployment, or backup validation, or test data generation. It doesn't matter what it is—what matters is that you start.

Because here's the truth: in 2026, manual repetitive work isn't just inefficient. It's a waste of human potential. We have brains capable of solving complex problems, designing systems, and creating value. Using those brains to repeatedly type the same commands is like using a Ferrari to go get the mail.

The Bottom Line
Bash isn't just a tool—it's a mindset. It's the difference between being a human task-runner and being an engineer who builds systems that run tasks. It's the difference between spending your day in the weeds and spending your day solving actual problems.

That senior engineer who showed me my first script? They gave me more than automation. They gave me time back. They gave me the mental space to think strategically instead of tactically. They gave me a superpower.

And now I'm passing it on to you.
Start scripting. Your future self will thank you.

From cronjobs to controllers: Building a production-grade Kubernetes Backup & Restore Operator

Manuchim Oliver — Sun, 25 Jan 2026 08:17:19 +0000

There’s a moment every infrastructure engineer remembers.

You’re calm. Confident. Someone asks, “Can we restore from last night’s backup?”
You nod. Of course you can.

Then you test the restore.

The archive is incomplete. The job logs are gone. You’re not even sure when the backup last ran — only that a CronJob exists and no one has touched it in months.

In that moment, “we run nightly backups” stops being a reassurance. It becomes a liability.

This project started there — with the realization that backups are not a task. They’re a system, and systems demand design.

Why CronJobs Fail in Production (and Why We Pretend They Don’t)

CronJobs are Kubernetes’ sharpest double-edged sword. They’re easy to create and hard to operate.

In real clusters, they introduce quiet failure modes:

Opacity: kubectl get cronjob tells you that something is scheduled, not what actually happened
Silent drift: retention logic lives in shell scripts no one audits
Restore anxiety: partial writes, permission mismatches, and irreversible state
No lifecycle semantics: success, failure, retries, ownership — all implied, none enforced

Most teams discover these problems during an incident. By then, it’s too late.

I wanted to turn that uncertainty into confidence.

Design Goal: Make Backups a First-Class Kubernetes API

I’m a senior full-stack engineer who’s been intentionally ramping into SRE and platform engineering. One thing becomes obvious as you move closer to production systems:

Reliability doesn’t come from tools.
It comes from interfaces.

So I set three non-negotiable principles for this operator:

Safety over convenience
Observability over assumptions
Automation over tribal knowledge

The result is a Kubernetes Backup & Restore Operator built with controller-runtime best practices and designed for real-world clusters — not demos.

The Core Insight: Backups Should Be Resources, Not Side Effects

Instead of scripts and schedules, this operator models backups as Kubernetes-native APIs:

BackupPolicy — intent
Backup — execution
Restore — recovery

This single decision unlocks everything else.

When backups are resources:

You can kubectl get them
You can kubectl describe them
You can watch their status, conditions, and events
You can reason about lifecycle, ownership, and safety

Backups stop being something that happens.
They become something you can operate.

A Small Example with Big Implications

apiVersion: platform.example.com/v1
kind: BackupPolicy
metadata:
  name: daily-backups
spec:
  schedule: "0 2 * * *"   # daily at 02:00
  retention:
    keepLast: 3
  target:
    pvcSelector:
      matchLabels:
        app: postgres

This isn’t configuration glue. It’s an API contract.

From this policy, the controller:

Calculates the next run using cron parsing
Schedules reconciliation using RequeueAfter (no polling)
Spawns concrete Backup resources
Enforces retention only after success
The system does exactly what the user asked — and nothing more.
Execution Model: Jobs, But with Guardrails
Each Backup creates a Kubernetes Job with strict safety constraints:
Source PVCs mounted read-only
Backup artifacts written as tar.gz to shared storage

Explicit phase transitions:

Pending → Running → Completed | Failed

No hidden state. No implicit success.

Every transition is surfaced via:

.status.phase

Kubernetes Events

Humans and automation see the same truth.

Observability Isn’t Optional — It’s the Interface

If you want operators to trust a system, it must explain itself.

A completed backup tells a story:

Events:
  Normal  BackupStarted     Backup execution started
  Normal  JobCreated        Created backup job my-backup-job
  Normal  BackupCompleted   Backup completed successfully in 6s
  Normal  CleanupTriggered  Deleted 2 old backups (keepLast=3)

This is deliberate.

No one should have to dig through Pod logs during a restore.
The control plane should already know what happened.

Retention as Policy, Not a Script

Retention is where many systems quietly corrupt themselves.

This operator treats retention as a post-success policy:

Only Completed backups are eligible
Running or failed backups are never touched
Cleanup happens immediately after success
Deletion is deterministic and auditable
Retention stops being a best effort and becomes a guarantee.
Restore Is a First-Class Concern (Not an Afterthought)
Backups without restores are just storage costs.

Restores in this system:

Can only reference completed backups
Are validated before execution
Run as tracked Jobs with explicit status
Refuse unsafe operations by default

This flips the mental model:

A restore is not an emergency script — it’s a rehearsed operation.

Back to SRE Principles (On Purpose)

Google’s SRE discipline emphasizes:

Reducing toil
Making failure visible
Designing systems that are safe by default

Backups are a classic source of hidden toil.
They only demand attention when they fail — usually during an incident.

By modeling backups as:

Observable
Automated
Policy-driven

…you remove ambiguity and human error — exactly what SRE systems are meant to do.

Production Engineering Patterns Used

This project intentionally applies patterns you’d expect in mature controllers:

Idempotent reconciliation — safe requeues and restarts
OwnerReferences — automatic garbage collection
Least-privilege RBAC — nothing more, nothing less
Race-safe Job creation — no duplicate execution
Terminal state enforcement — no half-finished resources

These aren’t academic choices. They’re scars from operating systems at scale.

Current Limitations (and Why They’re Explicit)

Production systems earn trust by admitting what they don’t do yet.

Planned improvements include:

Backup integrity verification (checksums)
Restore guards for non-empty PVCs
Prometheus metrics and SLO-driven alerts
Automated restore drills and canarying

Each item is tracked intentionally — because reliability is a roadmap, not a checkbox.

The Bigger Lesson

This project isn’t really about backups.
It’s about treating operational workflows as products:

With APIs
With UX
With safety guarantees
With observability as a feature

You can check it out yourself here: Code Repository

If you’re building platforms, enabling SRE teams, or tired of backups being a leap of faith — this is the shift that matters.

Don’t ask whether backups run.
Design systems that can prove they did.

Kubernetes Is Not a Container Platform (And That Changes Everything)

Manuchim Oliver — Sat, 10 Jan 2026 14:11:38 +0000

Most people learn Kubernetes backwards.
We start with:

Pods
Deployments
Helm charts
Copy-pasting YAML

But Kubernetes was never designed to be “a container orchestrator”.

It was designed as:

An extensible, declarative API backed by control loops.

The Core Idea

Kubernetes works like this:

You declare desired state (YAML / JSON)
The API server stores it
Controllers continuously reconcile reality to match it
Nothing “runs” just because YAML exists.
Controllers do the work.

Why CRDs Exist

Kubernetes only knows built-in types:
Pods, Services, Nodes, etc.

CRDs let you say:
“Here is a new type of thing Kubernetes should understand.”

Example:

kind: Backup

But CRDs alone do nothing.

They’re nouns.

Why Operators Exist

Operators are controllers that understand your CRDs.

They turn:

kind: Backup

into:

Jobs
Snapshots
S3 uploads
Retention logic

They are verbs.

Why Helm Isn’t Special

Helm doesn’t “deploy apps”.

It:

Renders templates
Outputs YAML
Sends it to the Kubernetes API

That’s it.

The intelligence lives inside controllers, not tools.

The Mental Model That Changed Everything for Me

Kubernetes is:

An API
A database (etcd)
A set of controllers

Containers are just one workload type.

Once I understood this:

Operators stopped feeling scary

Kubernetes felt simple (not easy — simple)

And once you see it this way, you stop fighting YAML and start designing operators, CI/CD flows, and observability that actually work at scale.

A Day in the Life of a Lead Software Engineer

Manuchim Oliver — Wed, 06 Sep 2023 14:39:33 +0000

With a projected 24 percent growth by 2026, the software engineering field boasts stunning job prospects. If you’re interested in coding, software engineering is an industry you should consider in 2023, but what does an actual day in the life of a software engineer look like?

Before we dive in, we should add two disclaimers: Obviously, the job varies day to day. Also, every company has its own culture and quirks.

I started off as a Civil Engineer, but as time went by and I began exploring my passions, I realized I was doing the wrong line of work.

Pursuing a career in software engineering was a daunting task at the time as I was fully engaged at my engineering job and later in my country’s National Youth Service Corps (NYSC) program. My approach was highly unconventional too. I never explicitly learned any programming languages. All I had was the determination to pick up projects I loved, read documentation, fail more times than I could count, and learn on the go. And somehow, it worked out.

All I can say today is, it requires perseverance, curiosity, and a genuine desire to be a good software engineer.

What quickly became apparent to me was that a background in civil engineering was extremely useful for a career in tech because I was already good at math (somewhat) and I’d picked up interpersonal communication at my job. I’d say that the additional responsibility of being a Lead comes with the additional requirement to be a good communicator.

Anyway, on to the day-to-day stuff.

Now this honestly varies for every company and is something I think about a lot, but this is my experience at my company.

There are two distinct aspects of my day.

The first is the time I spend actually writing code, building features and solving bugs. That time is incredibly fun, something I cherish during my day, and allows me to have stimulating conversations with coworkers and gain more experience writing code.

It also tends to be more of a solo operation. The difficulty of professional software engineering is considering the architecture and side-effects of any code you’re going to write. Once you have a design and implementation ready to go, going off to write the code can be a relaxing and stimulating experience.

Number two is my responsibilities as a team-lead, (less so as a regular engineer, but still relevant) is what I call gathering requirements and defending decisions.

My job as a team lead is to provide insight into what my team can and can’t do in regards to pushing a product forward. That might mean a few ad-hoc meetings a day, or conversation with other team leads in regards to the system as a whole.

I think that software engineering has a reputation as a non-interactive profession, but that couldn’t be further from the truth. I’m more successful at my job because I already had to interact with people in an engineering setting previously. Ultimately, the main strength of a developer is understanding business constraints in order to help the company be successful.

I’ll give you a schedule that I usually follow:

9 AM — 11:30 — I try to pick up what I was doing the day before, usually by looking at a failed test or note that I left myself to remind myself. It’s difficult to get all the context that you lost back, so leaving these little breadcrumbs to follow is largely a satisfying way to jump right back into it. This usually involves finishing up a feature, fixing a bug, writing a test, or looking at the priority for the day to determine what has to happen next.

11:30 AM — 2 PM — Meetings with other team leads in order to determine priority start. Since we’re a startup, it’s hard to define what will be the most important thing from week to week, although we use Atlassian stack for some of these. When that’s working, it’s easy to know what to work on next, but there can be times when collaboration in my department is needed.

I usually find some time for lunch in there somewhere.

2 PM — 4 — I like to pair program, which basically means working on a single feature or bug with another engineer. We’d usually jump on a huddle on Slack to get this done. The general idea looks like this: One engineer thinks about the implementation, and the other writes the code. It’s a nice way to learn about the other engineer's perspective and a great time to pick up some new information and knowledge!

4 PM — 5 — I usually buckle down for the rest of the day, and work on features/bugs that are part of my product roadmap or the priorities that were set earlier in the day. I get a lot done here. The pressure of the day closing is a nice motivating factor to get loose ends tied up.

5 PM — 5:30 — This is where I start thinking about the break point I can find in order to clean up from the day, and where I try to leave myself a starting point for the next day that I mentioned earlier.

With all this said, there’s always something unexpected that comes up. I try to stick to a schedule, but the main thing I feel every day is that Software Development is a rewarding field that allows the people in it to directly contribute to a companies success or failure. It can be full of pressure sometimes, but that also leads to an immense amount of satisfaction.

I’m happy to answer any questions you might have about my routine or time at Kiko!

Questions and comments are always welcome. You can read more about me and some of my other articles here.