Startup environments make this worse. The pressure to ship fast, the small team sizes, and the absence of senior engineers to review your decisions means mistakes happen quietly until they become outages, data loss events, or security incidents that cost the company thousands of dollars and weeks of recovery time.

This article is a direct breakdown of the ten most costly DevOps mistakes engineers make early in their careers at startups. For each mistake, you will get the real-world scenario, the business impact, and the concrete fix you can apply immediately.

Whether you are setting up your first production environment or auditing an existing one, this guide will help you build systems that are reliable, secure, and aligned with what the business actually needs.

Table of Contents

• Who This Article Is For

• Why Startups Are a Different Environment

• Mistake 1: Deploying Without Understanding What You're Deploying

• Mistake 2: Using Production as a Development Environment

• Mistake 3: Hardcoding Secrets and Credentials

• Mistake 4: Overengineering for Problems You Don't Have Yet

• Mistake 5: No Observability Before Launch

• Mistake 6: Treating Security as a Final Step

• Mistake 7: Manual Deployments in Production

• Mistake 8: No Disaster Recovery Plan

• Mistake 9: No Documentation or Runbooks

• Mistake 10: Solving Technical Problems Without Understanding the Business

• The System Thinking Framework Every DevOps Engineer Needs

• Your Production Readiness Checklist

• Conclusion

Who This Article Is For

• Early-career DevOps and cloud engineers who are building or maintaining production infrastructure at a startup.

• Backend developers who have recently taken on DevOps responsibilities.

• Engineers joining a startup who want to understand what operational discipline actually looks like in a fast-moving environment.

You do not need to be an expert in any specific tool to follow this article. The focus is on decision-making patterns and operational discipline, not tool configuration.

Why Startups Are a Different Environment

Before getting into the mistakes, you have to understand why startups produce them in the first place.

In a large company, you typically have dedicated security engineers, an SRE team, a platform team, and multiple reviewers for every infrastructure change. In a startup, you mostly likely have one engineer responsible for all of that simultaneously.

This creates four specific pressure points:

1. Speed pressure. The business needs features shipped now. Operational discipline gets treated as optional because nobody is watching closely yet.

2. Budget constraints. Every infrastructure decision has a direct impact on company runway. Engineers optimize for the cheapest option rather than the most reliable one.

3. Absent guardrails. There is no senior engineer reviewing your Terraform plans. There is no security audit before launch. The absence of immediate consequences can make bad decisions feel like good ones.

4. Constantly changing requirements. The architecture you design today may need to support a completely different product in six months. None of these pressures are excuses for poor decisions. But understanding them helps you see why the following mistakes happen so consistently.

Mistake 1: Deploying Without Understanding What You're Deploying

The Scenario

A junior engineer is asked to deploy the company's Node.js API to AWS. They find a tutorial for Elastic Beanstalk, follow it, and it works. Two weeks later, traffic increases. They try to scale "the same way as in the tutorial." The application goes down. They cannot debug it because they never understood what the deployment was actually doing.

The Business Impact

When production breaks and the person who deployed the system cannot explain how it works, diagnosis takes hours instead of minutes. The longer the incident runs, the higher the cost in customer trust, team morale, and potentially direct revenue loss.

The Fix

Before you deploy anything to production, you should be able to answer these five questions in writing:

1. What compute type is running my code? (EC2, Lambda, Fargate, container?)

2. How does a new version replace the old one? (Rolling? Blue/green? All-at-once?)

3. Where does configuration and secrets come from? (SSM? Secrets Manager? Environment file?)

4. What downstream services depend on this? (Database connections? Other APIs? Cache?)

5. How do I roll back in under five minutes if this breaks?

If you cannot answer all five, do not deploy until you can. The tutorial that got it running is not the documentation for how it operates.

"It is better to spend two hours understanding a system before deploying it than two days debugging it after something breaks."

Personally, when learning a new technology, tool, or implementing something I have not worked with before, I usually focus on three core questions: What, Why, and How.

• The first question is: What is this technology or concept about?
  This helps me build a solid foundation by doing deep research, studying the official documentation, understanding the core principles, and sometimes even learning the history behind the tool or technology. I believe having a well-grounded understanding before implementation is very important.

• The second question is: Why do we need it?
  I try to understand the value the technology brings, why it should be implemented, what problem it solves, and how it benefits the team or organization. This helps me make informed technical decisions instead of just implementing tools without understanding their purpose.

• The third question is: How should it be implemented?
  There are usually multiple approaches to solving a problem or implementing a technology, so I focus on understanding the best and most practical approach based on the use case and expected outcome.

This structured approach has helped me learn new technologies quickly, adapt fast, and implement solutions effectively in real-world environments.

Mistake 2: Using Production as a Development Environment

The Scenario

To save time, an engineer tests a new deployment script directly in the production AWS account. They accidentally run a command that terminates the production database instance. Automated backups exist but were misconfigured. Six hours of customer data is unrecoverable.

This scenario happens more often than you would expect. The reasoning is always the same: "It will only take a minute."

The Business Impact

A single test-in-production incident can result in data loss, hours of downtime, and a customer communication crisis. In a startup, that can permanently damage the company's reputation before it has had the chance to build one.

The Fix

You need at minimum three separate environments and ideally three separate AWS accounts:

Using separate AWS accounts (not just separate VPCs) gives you account-level isolation. A permission error in the dev account cannot accidentally touch production infrastructure at the API level.

Infrastructure as Code (Terraform or CloudFormation) makes this affordable, you write the configuration once and apply it three times with different variable files.

# terraform/environments/prod/main.tf
module "app" {
  source      = "../../modules/app"
  environment = "production"
  instance_type = "t3.medium"
  db_instance_class = "db.t3.medium"
  multi_az          = true
}

# terraform/environments/staging/main.tf
module "app" {
  source      = "../../modules/app"
  environment = "staging"
  instance_type = "t3.small"
  db_instance_class = "db.t3.small"
  multi_az          = false
}

The module is the same. The environment-specific variables are different. Separate environments are not a luxury, they are the minimum operating standard for any team running real software.

Mistake 3: Hardcoding Secrets and Credentials

The Scenario

A new engineer joins a startup and clones the repository. Inside they find a .env file committed to Git containing the production database password, the Stripe secret key, and an AWS access key with admin permissions. The repository has been public for six months.

GitHub's automated secret scanning never triggered because the secrets were inside a .env file rather than raw in the code. The credentials had been valid and actively used for over six months.

The Business Impact

Automated scanners run by attackers find exposed credentials within minutes of them being pushed to a public repository. A single exposed AWS access key with admin permissions can result in:

• Crypto-mining workloads generating thousands of dollars in cloud bills overnight

• Complete exfiltration of customer data from every S3 bucket

• Privilege escalation: the attacker creates new admin users and locks you out of your own account

• AWS account suspension while the investigation runs

According to GitHub's annual security report, millions of secrets are exposed in public repositories every year. The average time to detect a compromised cloud credential is 197 days.

The Fix

Step 1: Never commit secrets to Git. Not temporarily. Not in a branch. Not in a private repository.

Step 2: Add .gitignore before you create the first file. Check in the .gitignore with the first line of code before any .env files exist.

# .gitignore
.env
.env.*
*.pem
*.key
secrets/

Step 3: Use AWS Secrets Manager or SSM Parameter Store for all production secrets. Your application reads secrets at runtime:

# Python example — fetch secret at runtime, never at build time
import boto3
import json
 
def get_secret(secret_name: str, region: str = "us-east-1") -> dict:
    client = boto3.client("secretsmanager", region_name=region)
    response = client.get_secret_value(SecretId=secret_name)
    return json.loads(response["SecretString"])
 
# Usage
db_config = get_secret("prod/myapp/database")
DATABASE_URL = db_config["connection_string"]

Step 4: Scan your existing repositories immediately. You may already have a problem:

# Install trufflehog to scan for exposed secrets in your repo history
pip install trufflehog
 
# Scan the entire commit history of your repository
trufflehog git file://.
 
# Or scan a remote GitHub repo
trufflehog github --repo https://github.com/your-org/your-repo

Step 5: Add a pre-commit hook to prevent future accidents:

pip install pre-commit

# .pre-commit-config.yaml
repos:
  - repo: https://github.com/awslabs/git-secrets
    rev: master
    hooks:
      - id: git-secrets
  - repo: https://github.com/Yelp/detect-secrets
    rev: v1.4.0
    hooks:
      - id: detect-secrets

pre-commit install
# Now the hook runs before every commit and blocks detected secrets

There is no recovery from a publicly exposed database password. The fix takes ten minutes upfront. The incident takes weeks.

Mistake 4: Overengineering for Problems You Don't Have Yet

The Scenario

A five-person startup with 200 users decides to build a microservices architecture on Kubernetes because "Netflix uses it." They spend three months setting up Kubernetes, Istio service mesh, ArgoCD, Vault, Prometheus, and Grafana. Their product has not shipped a new feature in three months. A competitor with a monolith on a single EC2 instance shipped twelve new features in the same period.

The Business Impact

Every layer of infrastructure you add is a layer that can break, a layer that requires expertise to operate, and a layer that slows down every future change. Kubernetes is the right answer for organizations with the scale and team size to operate it. For a five-person startup, it is an expensive distraction.

Premature complexity does not just cost engineering time. It costs the competitive advantage that speed provides in the early stage.

The Fix

Match your infrastructure to your actual stage:

The question to ask before every infrastructure decision is: "What specific, measurable problem does this solve today that my current setup cannot solve?"

Amazon, Netflix, and Uber did not start with microservices. They started with monoliths and extracted services only when the monolith became the actual bottleneck. You are not Netflix. You are solving the problems in front of you today.

Use managed services wherever possible, RDS instead of self-hosted Postgres, Fargate instead of self-managed Kubernetes, ElastiCache instead of self-hosted Redis. Managed services let your team focus on the product instead of the infrastructure.

Mistake 5: No Observability Before Launch

The Scenario

A startup's checkout flow breaks on a Friday evening. Users are abandoning their carts and the company is losing revenue. The DevOps engineer finds out 45 minutes later because a customer sent a direct message to the CEO on Twitter.

The engineer has no dashboards, no log aggregation, and no alerting. They SSH into the production server and scroll through raw log files. Two hours later, they find the issue: a database connection pool was exhausted by a memory leak introduced in that morning's deployment.

Business Impact

Without observability:

• You find out about production problems from users, not from your systems

• Incidents take 10x longer to resolve because diagnosis is guesswork

• You cannot tell whether a deployment improved or degraded performance

• You have no data for making better architecture decisions

The Fix

Implement the four golden signals before any service goes to production. These come from Google's Site Reliability Engineering book:

1. Latency: How long requests take to complete (p50, p95, p99)

2. Traffic: How many requests per second the system is handling

3. Errors: The rate of failed requests (5xx responses per minute)

4. Saturation: How close the system is to its limits (CPU, memory, connection pool)

Here is a minimal CloudWatch alarm setup using the AWS CLI:

# Alert when error rate exceeds 1% for 5 consecutive minutes

aws cloudwatch put-metric-alarm \
  --alarm-name "high-error-rate-production" \
  --alarm-description "Error rate exceeded 1% for 5 minutes" \
  --metric-name "5XXError" \
  --namespace "AWS/ApplicationELB" \
  --statistic "Average" \
  --period 60 \
  --evaluation-periods 5 \
  --threshold 0.01 \
  --comparison-operator "GreaterThanOrEqualToThreshold" \
  --alarm-actions "arn:aws:sns:us-east-1:123456789:pagerduty-production" \
  --dimensions Name=LoadBalancer,Value=app/my-alb/1234567890abcdef

Every application should also expose a /health endpoint that returns 200 OK when healthy:

# FastAPI example

from fastapi import FastAPI
from sqlalchemy import text
 
app = FastAPI()
 
@app.get("/health")
async def health_check():
    # Check database connectivity
    try:
        db.execute(text("SELECT 1"))
        db_status = "healthy"
    except Exception:
        db_status = "unhealthy"
 
    return {
        "status": "healthy" if db_status == "healthy" else "degraded",
        "database": db_status,
        "version": os.getenv("APP_VERSION", "unknown")
    }

Your load balancer checks this endpoint. Your uptime monitor checks it. You check it after every deployment.

You do not get to say a system is working unless you have data to prove it. "Nobody complained" is not the same as "nothing is broken."

Mistake 6: Treating Security as a Final Step

The Scenario

A startup rushes to launch their MVP. Security reviews are "planned for after launch." Six months later, a potential enterprise customer requires a security audit before signing a contract. The audit reveals:

• S3 buckets publicly accessible by default

• EC2 instances with port 22 open to 0.0.0.0/0

• IAM users with AdministratorAccess for the entire team

• No encryption on the database at rest

• JWT secrets hardcoded in environment variables The audit fails. The enterprise deal worth $120,000 annually is lost. Remediation takes four weeks of engineering time.

The Business Impact

Security debt is the most expensive technical debt you can accumulate. Unlike performance debt that degrades gradually, security vulnerabilities cause sudden, catastrophic events: data breaches, ransomware, account takeovers, and regulatory fines. At a startup, any one of these can end the company.

The Fix

Apply these six security controls before the first line of production code ships:

1. Principle of Least Privilege every IAM role gets only what it needs:

One of the most common security mistakes in AWS is granting roles more permissions than they need either out of convenience (s3:*) or uncertainty about what the service actually requires. This creates unnecessary risk: if a role is compromised, the attacker inherits every permission you granted.

The fix is simple: look at what your service actually does, then write a policy that allows exactly that.

If your app uploads and reads files from a specific S3 bucket, the policy should say exactly that:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": "arn:aws:s3:::my-app-uploads/*"
    }
  ]
}

Notice the Resource is scoped to my-app-uploads/* not all S3 buckets. And the Action list covers only GetObject and PutObject not DeleteObject, not s3:*. If the service gets compromised, the attacker can read and write to that one bucket. That is it. The rest of your account is untouched.

2. Block all S3 public access by default:

AWS S3 buckets are private by default when created but that can be overridden at the bucket level, the object level, or through a bucket policy. Misconfigured S3 buckets are one of the most common causes of data breaches, and they are almost always accidental.

The safest approach is to enable the "Block Public Access" setting at the account level, which overrides all other settings and prevents any bucket from being made public even if someone tries:

aws s3api put-public-access-block \
  --bucket my-app-bucket \
  --public-access-block-configuration \
    "BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true"

Run this for every bucket you create. Better yet, enable it at the AWS account level so it applies automatically to all future buckets by default.

3. Never open SSH to the internet, use AWS Systems Manager Session Manager instead:

Port 22 open to 0.0.0.0/0 is an attack surface that exists on thousands of AWS instances right now. Brute-force bots scan the internet continuously looking for open SSH ports. Even with a strong key, the exposure is unnecessary because AWS provides a better alternative.

AWS Systems Manager Session Manager gives you full shell access to any EC2 instance without opening a single inbound port on the security group. There is no port to scan, no port to attack, and every session is logged automatically to CloudTrail:

# Start a session on an EC2 instance without port 22 open
aws ssm start-session --target i-0123456789abcdef0

To use Session Manager, the EC2 instance needs the SSM Agent installed (included by default on Amazon Linux 2 and Ubuntu 20.04+) and an IAM instance profile with the AmazonSSMManagedInstanceCore policy attached. Once that is set up, you can close port 22 on the security group entirely.

4. Enable MFA for all IAM users and enforce it via policy:

A leaked IAM username and password with no MFA is a fully compromised account. Multi-factor authentication is the single most effective control against credential theft, and it costs nothing to enable.

Enforce it through an IAM policy that denies all actions when MFA is not present, except the actions needed to set up MFA in the first place. This means even if a set of credentials is stolen, the attacker cannot do anything without the second factor.

The AWS documentation provides the Complete Deny Without MFA Policy, attach it to every IAM user or group in your account. This is a one-time setup that permanently raises your account's security baseline.

5. Enable CloudTrail in all regions:

Without CloudTrail, you have no record of who did what in your AWS account. If a credential is compromised, you cannot investigate what the attacker accessed. If an engineer accidentally deletes a resource, you cannot trace it. You are operating blind.

CloudTrail logs every AWS API call who made it, from which IP, at what time, and what the response was. Enable it across all regions so activity in regions you do not actively use is also captured:

aws cloudtrail create-trail \
  --name production-audit-trail \
  --s3-bucket-name my-cloudtrail-logs \
  --is-multi-region-trail \
  --enable-log-file-validation

The --enable-log-file-validation flag generates a digest file for each log that lets you verify the log has not been tampered with, this is important if you ever need to use these logs in a security investigation or compliance audit. Once this is running, every AssumeRole, every DeleteBucket, and every RunInstances call in your account is permanently recorded.

6. Run AWS Security Hub from day one:

Most teams only discover security misconfigurations after a breach or a compliance audit. Security Hub inverts this, it continuously scans your AWS environment against industry-standard frameworks (CIS AWS Foundations Benchmark, AWS Foundational Security Best Practices) and surfaces findings before they become incidents.

Enabling it takes a single command:

aws securityhub enable-security-hub

Within minutes, Security Hub gives your account a compliance score and a prioritized list of findings. A finding might tell you that a security group has port 22 open to the world, that an S3 bucket has logging disabled, or that root account credentials were recently used. Each finding includes the affected resource and a remediation guide.

Treat every Security Hub finding the same way you treat a production bug: assign it a priority, assign an owner, and close it. A finding sitting unaddressed for 30 days is a known vulnerability you chose to leave open.

Mistake 7: Manual Deployments in Production

The Scenario

A startup's deployment process is documented in a Notion page that is four months out of date. It involves SSH-ing into the server, running git pull, running npm install, and restarting the PM2 process. Different engineers do it slightly differently. One engineer, rushing a late-night release, skips npm install. The application starts crashing because a new dependency is missing.

The Business Impact

Manual deployment processes are inherently unreliable. Humans under pressure skip steps, perform steps in the wrong order, and remember procedures differently. Every manual step in a production deployment process is a scheduled incident waiting for the right moment of stress.

The Fix

If a deployment step is performed manually more than twice, it needs to be automated. Here is a minimal but complete GitHub Actions deployment workflow for an ECS Fargate service:

# .github/workflows/deploy.yml
name: Deploy to Production
 
on:
  push:
    branches:
      - main
 
permissions:
  id-token: write   # Required for OIDC authentication with AWS
  contents: read
 
jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: production
 
    steps:
      - name: Checkout code
        uses: actions/checkout@v4
 
      - name: Configure AWS credentials via OIDC
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: ${{ secrets.AWS_DEPLOY_ROLE_ARN }}
          aws-region: us-east-1
 
      - name: Login to Amazon ECR
        id: login-ecr
        uses: aws-actions/amazon-ecr-login@v2
 
      - name: Build and push Docker image
        id: build
        env:
          ECR_REGISTRY: ${{ steps.login-ecr.outputs.registry }}
          IMAGE_TAG: ${{ github.sha }}
        run: |
          docker build -t \(ECR_REGISTRY/my-app:\)IMAGE_TAG .
          docker push \(ECR_REGISTRY/my-app:\)IMAGE_TAG
          echo "image=\(ECR_REGISTRY/my-app:\)IMAGE_TAG" >> $GITHUB_OUTPUT
 
      - name: Deploy to Amazon ECS
        uses: aws-actions/amazon-ecs-deploy-task-definition@v1
        with:
          task-definition: task-definition.json
          service: my-app-service
          cluster: production
          wait-for-service-stability: true

Notice wait-for-service-stability: true. Without this, the workflow reports success the moment ECS accepts the new task definition before the containers are actually healthy. With it, the workflow fails if the new containers crash. You want to know immediately, not discover it from user reports thirty minutes later.

Mistake 8: No Disaster Recovery Plan

The Scenario

A startup's production database runs on a single RDS instance with no Multi-AZ configuration. Automated backups are enabled but have never been tested. The EBS volume backing the instance fails. AWS provisions a new instance from the last snapshot, which is 18 hours old. 18 hours of customer data is permanently lost.

The startup had no disaster recovery plan, no tested recovery procedure, and no communication template ready for customers.

The Business Impact

The question is not whether your infrastructure will fail. It will fail. Every database, every server, every availability zone experiences failures. The question is whether you have a tested plan for when it does.

Data loss of any magnitude is serious. For startups that handle financial data, healthcare data, or anything under GDPR, even partial data loss can trigger regulatory consequences.

The Fix

Define your RTO and RPO before you design anything:

• RTO (Recovery Time Objective): How long can the business survive without this system? A payment API might have an RTO of 15 minutes. An internal analytics dashboard might have an RTO of 4 hours.

• RPO (Recovery Point Objective): How much data loss is acceptable? Zero means real-time replication. One hour means hourly snapshots are sufficient. This directly determines your backup frequency and architecture.

Enable RDS Multi-AZ for all production databases:

# Terraform
resource "aws_db_instance" "production" {
  identifier        = "prod-postgres"
  engine            = "postgres"
  engine_version    = "15.4"
  instance_class    = "db.t3.medium"
  allocated_storage = 100
 
  # Multi-AZ: automatic failover to standby in a different AZ
  # No data loss. Automatic failover in ~60-120 seconds.
  multi_az = true
 
  # Encryption at rest — non-negotiable
  storage_encrypted = true
 
  # Automated backups with 7-day retention
  backup_retention_period = 7
  backup_window           = "03:00-04:00"
 
  # Enable deletion protection in production
  deletion_protection = true
 
  tags = {
    Environment = "production"
  }
}

Test your backups on a schedule. Create a monthly calendar event: "Restore production backup to staging and verify data integrity." An untested backup is not a backup, it is a hope.

# Restore a snapshot to a test instance and verify
aws rds restore-db-instance-from-db-snapshot \
  --db-instance-identifier recovery-test \
  --db-snapshot-identifier rds:prod-postgres-2025-01-15 \
  --db-instance-class db.t3.medium \
  --no-multi-az
 
# Connect and verify row counts
psql -h recovery-test.xxxx.rds.amazonaws.com -U admin -d mydb \
  -c "SELECT COUNT(*) FROM users; SELECT COUNT(*) FROM orders;"

For official guidance on RDS backup and restore, refer to the AWS RDS Backup and Restore documentation.

Mistake 9: No Documentation or Runbooks

The Scenario

The startup's most experienced DevOps engineer takes two weeks of vacation. On day three of their holiday, the staging environment goes down. Nobody else knows how it was built, the engineer set it up manually over six months with no documentation, no Terraform, no notes. The team spends four days trying to reconstruct the environment from memory and guesswork. The engineer gets messages on their vacation every day. When they return, they rebuild the environment in four hours.

The Business Impact

Undocumented infrastructure creates single points of failure not in your systems, but in your team. It makes onboarding new engineers take weeks instead of hours. It makes incident response depend on specific people being available. When that person leaves the company, the knowledge walks out with them.

The Fix

Documentation for an engineering team means three specific things:

1. Infrastructure as Code is the highest form of documentation. The Terraform that defines your infrastructure IS the documentation for what exists and how it is configured. If something is not in code, it should not exist in production.

2. A runbook for every operational task. A runbook is a step-by-step procedure written well enough that someone in their first week at the company can follow it during an incident:

# Runbook: Production Database Connection Exhaustion
 
## Symptoms
- Application logs: "too many connections" errors
- 500 error rate spike on database-dependent endpoints
- pg_stat_activity shows max connections reached
 
## Diagnosis
# Check current connection count
psql -h \(DB_HOST -U \)DB_USER -c "SELECT COUNT(*) FROM pg_stat_activity;"
 
# See connections by application
psql -h \(DB_HOST -U \)DB_USER \
  -c "SELECT application_name, COUNT(*) FROM pg_stat_activity GROUP BY 1 ORDER BY 2 DESC;"

## Resolution
1. Identify and restart the service causing the connection leak
2. If immediate relief needed: kill idle connections older than 10 minutes
3. Long-term: review connection pool settings in application config

## Escalation
If unresolved in 30 minutes: page the on-call backend engineer.

1. An architecture README in every repository. Every engineer who clones your repository should be able to understand what it does, how to run it locally, how to deploy it, and what it depends on without asking anyone.

Mistake 10: Solving Technical Problems Without Understanding the Business

The Scenario

A startup is experiencing slow page loads. A DevOps engineer decides to solve it by migrating to Kubernetes with horizontal pod auto-scaling. The migration takes six weeks. Page loads improve slightly. But 80% of the slowness was caused by unoptimized database queries that had nothing to do with the infrastructure layer. The six-week migration solved 20% of the problem.

The Business Impact

Technical solutions to misdiagnosed problems are extraordinarily expensive. Every hour spent building the wrong solution is an hour not spent on the right one. Infrastructure is a tool for delivering business outcomes not an end in itself.

The Fix

Before making any infrastructure decision, answer these four questions:

1. What is the actual, measured bottleneck? Instrument before you act. The bottleneck is almost never where you assumed it was.

2. What does success look like, and how will you measure it? "Pages are faster" is not measurable. "p95 page load time drops below 1.2 seconds" is measurable.

3. What is the full cost of this solution? Time to implement, ongoing operational burden, team learning curve. Is this cost justified by the measured impact?

4. Can a simpler solution solve 80% of the problem in 20% of the time?

Always profile and measure before you rebuild:

# Check slow queries in PostgreSQL before any infrastructure changes
psql -h \(DB_HOST -U \)DB_USER -d $DB_NAME -c "
SELECT
  query,
  calls,
  total_exec_time / calls AS avg_ms,
  rows / calls AS avg_rows
FROM pg_stat_statements
ORDER BY avg_ms DESC
LIMIT 10;
"

Nine times out of ten, slow applications have slow queries, missing indexes, or an N+1 query problem, none of which require a new infrastructure layer to fix.

The System Thinking Framework Every DevOps Engineer Needs

Most of the mistakes above share a common root cause: the engineer was thinking about one component in isolation instead of the full system.

A system thinker asks six questions before making any change in production:

This is not a checklist you run through slowly. It is a thinking habit that becomes automatic with practice. Senior engineers do not spend more time on deployments than junior engineers do, they spend their time on different things, and this is one of them.

Your Production Readiness Checklist

Use this checklist before any production system goes live. Mark each item as done, in progress, or not yet started.

Infrastructure

• Infrastructure is defined as code (Terraform or CloudFormation) and version-controlled in Git

• Separate dev, staging, and production environments exist with separate credentials

• All production changes go through an automated CI/CD pipeline, no manual SSH deployments

• You can rebuild the entire production environment from code in under two hours

Security

• No secrets, credentials, or API keys exist in any Git repository

• All production secrets are in Secrets Manager or SSM Parameter Store

• All IAM roles follow the principle of least privilege

• S3 buckets have public access blocked by default

• Port 22 is not open to 0.0.0.0/0 on any security group

• CloudTrail is enabled in all regions

• All IAM users have MFA enabled

• AWS Security Hub is enabled and findings are reviewed weekly

Observability

• Every service has a /health endpoint that monitoring checks continuously

• Alerts fire within five minutes of a production error rate spike

• Dashboards exist showing latency, error rate, and resource utilization

• Logs are centralized and searchable, not scattered across individual servers

Reliability

• Production database has Multi-AZ enabled

• Backup restoration has been tested in the last 30 days

• Written runbooks exist for the three most likely failure scenarios

• RTO and RPO requirements are documented and the architecture meets them

Documentation

• Every repository has a README explaining what it does and how to deploy it

• A new engineer could understand the production architecture from documentation alone

• No single engineer holds critical knowledge that lives only in their head

Conclusion

None of the mistakes in this article require rare misfortune to experience. They are the predictable result of decisions that feel reasonable under startup pressure but accumulate into real operational risk over time.

The good news is that every single one of them is preventable with the right awareness and the right habits applied early.

You do not need a perfect infrastructure from day one. You need a correct one: version-controlled, automated, observable, secure, and documented. Start with that foundation. Add complexity only when a specific, measured problem requires it. Always connect technical decisions to business outcomes.

The goal of DevOps in a startup is not to build impressive infrastructure. It is to build reliable systems that support product growth safely, efficiently, and sustainably and to make sure that when something does break, you can recover faster than anyone notices.

Want to Go Deeper?

If this article resonated with you, The Startup DevOps Field Guide covers these principles in full depth with complete infrastructure blueprints, security frameworks, CI/CD pipeline templates, and the end-to-end decision-making playbook for engineers building DevOps practices in startup environments from scratch.

It is written specifically for the engineer who wants to do this right from the beginning not the one rebuilding everything after the first major incident.

These tips will not only make your code cleaner and more reliable, but they also aim to make your development experience easier and overall more enjoyable.

Give these techniques a try in your React projects today!

Replace Redux with React Query

As your application gets larger it becomes harder to manage state across your components. So you may reach for a state management library like Redux.

If your application relies on data that you get from an API, you often use Redux to fetch that server state and then update your application state.

This can be a challenging process – not only do you have to fetch data, but you also need to handle the different states, depending on whether you have the data or are in a loading or error state.

Instead of using Redux to manage data you get from a server, use a library like React Query.

First of all, React Query gives you greater control over making HTTP requests in your React apps through helpful hooks, along with the ability to easily refetch data. And it also enables you to seamlessly manage state across your app components, often without having to manually update state yourself.

Here's how you set up React Query in your index.js file:

import { QueryClient, QueryClientProvider } from 'react-query'
import ReactDOM from "react-dom";

import App from "./App";

const queryClient = new QueryClient()

const rootElement = document.getElementById("root");
ReactDOM.render(
  <QueryClientProvider client={queryClient}>
    <App />
  </QueryClientProvider>,
  rootElement
);

Here, we are setting up a query client which will set up a cache for us to effortlessly manage any requests that we have made in the past. We also set up a query client provider component to pass it down the entire component tree.

How to make requests with React Query

You can make requests with the useQuery hook, which takes an identifier for your query (in this case, since we are fetching user data, we will call it 'user'), plus a function that is used to fetch that data.

import { useQuery } from "react-query";

export default function App() {
  const { isLoading, isError, data } = useQuery("user", () =>
    fetch("https://randomuser.me/api").then((res) => res.json())
  );

  if (isLoading) return "Loading...";
  if (isError) return "Error!";

  const user = data.results[0];
  return user.email;
}

As you can see, React Query takes care of managing these various states that can take place when we fetch our data. We no longer need to manage these states ourselves, we can just destructure them from what is returned from useQuery.

Where does the state management part of useQuery come into play?

Now that we have fetched the user data and have it stored in our internal cache, all we need to do to be able to use it across any other component is to call useQuery() with the 'user' key that we associated with it:

import { useQuery } from "react-query";

export default function OtherComponent() {
  const { data } = useQuery('user');

  console.log(data);
}

Make React Context Easier with a Custom Hook

React Context is a great way to pass data across our component tree. It allows us to pass data into whatever component we like without having to use props.

To consume context in a React function component, we use the useContext hook.

However, there is a slight downside to doing so. In every component that we want to consume data that has been passed down on context, we have to import both the created context object and import React to grab the useContext hook.

Instead of having to write multiple import statements every time we want to read from context, we can simply create a custom React hook.

import React from "react";

const UserContext = React.createContext();

function UserProvider({ children }) {
  const user = { name: "Reed" };
  return <UserContext.Provider value={user}>{children}</UserContext.Provider>;
}

function useUser() {
  const context = React.useContext(UserContext);
  if (context === undefined) {
    throw new Error("useUser in not within UserProvider");
  }
  return context;
}

export default function App() {
  return (
    <UserProvider>
      <Main />
    </UserProvider>
  );
}

function Main() {
  const user = useUser();

  return <h1>{user.name}</h1>; // displays "Reed"
}

In this example, we are passing down user data on our custom UserProvider component, which takes a user object and is wrapped around the Main component.

We have a useUser hook to more easily consume that context. We only need to import that hook itself to consume our User Context in any component we like, such as our Main component.

Manage Context Providers in a Custom Component

In almost any React application that you create, you will need a number of Context providers.

We not only need context providers for React Context that we are creating, but also from third party libraries that rely upon it (like React Query) in order to pass their tools down to our to the components that need them.

Once you've started working on your React project for a while, here's what it tends to look like:

ReactDOM.render(
  <Provider3>
    <Provider2>
      <Provider1>
        <App />
      </Provider1>
    </Provider2>
  </Provider3>,
  rootElement
);

What can we do about this clutter?

Instead of putting all of our context providers within our App.js file or index.js file, we can create a component called ContextProviders.

This allows us to use the children prop, then all we have to do is put all these providers into this one component:

src/context/ContextProviders.js

export default function ContextProviders({ children }) {
  return (
    <Provider3>
      <Provider2>
        <Provider1>
          {children}
        </Provider1>
      </Provider2>
    </Provider3>
  );
}

Then, wrap the ContextProviders component around App:

src/index.js

import ReactDOM from "react-dom";
import ContextProviders from './context/ContextProviders'
import App from "./App";

const rootElement = document.getElementById("root");
ReactDOM.render(
  <ContextProviders>
    <App />
  </ContextProviders>,
  rootElement
);

Pass props more easily using the object spread operator

When it comes to working with components, we normally pass down data with the help of props. We create a prop name and set it equal to its appropriate value.

However, if we have a lot of props that we need to pass down to a component, do we need to list them all individually?

No, we don't.

A very easy way to be able to pass down all the props that we like without having to write all of the prop names and their corresponding values is to use the {...props} pattern.

This involves putting all of our prop data in an object and spreading all of those props individually to the component we want to pass it to:

export default function App() {
  const data = {
    title: "My awesome app",
    greeting: "Hi!",
    showButton: true
  };

  return <Header {...data} />;
}

function Header(props) {
  return (
    <nav>
      <h1>{props.title}</h1>
      <h2>{props.greeting}</h2>
      {props.showButton && <button>Logout</button>}
    </nav>
  );
}

Map over fragments with React fragment

The .map() function in React allows us to take an array and iterate over it, then display each element's data within some JSX.

However, in some cases, we want to iterate over that data but we do not want to return it within a closing JSX element. Maybe using an enclosing JSX element would modify our applied or we simply don't want to add another element to the DOM.

A little known tip to be able to iterate over a set of data, and not have the parent element as an HTML element, is to use React.Fragment.

To use the longhand form of React fragments can provide it the key prop which is required for any element over which we are iterating.

import React from 'react'

export default function App() {
  const users = [
    {
      id: 1,
      name: "Reed"
    },
    {
      id: 2,
      name: "John"
    },
    {
      id: 3,
      name: "Jane"
    }
  ];

  return users.map((user) => (
    <React.Fragment key={user.id}>{user.name}</React.Fragment>
  ));
}

Note that we cannot use the required key prop for the shorthand fragment's alternative: <></>.

Become a Professional React Developer

React is hard. You shouldn't have to figure it out yourself.

I've put everything I know about React into a single course, to help you reach your goals in record time:

Introducing: The React Bootcamp

It’s the one course I wish I had when I started learning React.

Click below to try the React Bootcamp for yourself:

Click to get started

But a few weeks ago, while I was preparing some JavaScript tips to start my YouTube journey, I wrote this list of time-saving tips. I hope they help you as they've helped me.

In this article, I'm going to share with you 5 useful JavaScript tips (are you ready to dive in? 😀).

And now, guess what? Some of these tips are on my YouTube channel📹! (here is the playlist.

Object Destructuring

Destructuring is a feature that was introduced in ES6. It's one of the features you will use daily once you know how.

It helps you deal with three main issues:

• Repetition. Every time you want to extract one object property and create a new variable, you create a new line.

const user = {
  firstName: "John",
  lastName: "Doe",
  password: "123",
};

// Wow... should we display
// John's password like that?

const firstName = user.firstName;
const lastName = user.lastName;
const password = user.password;

• Accessibility. Each time you want to access an object property, you should write the path to it. (example: user.firstName, user.family.sister, and so on).
• Usage. As an example, when you create a new function, and you are only working with one property of an object.

Now that you've seen what these three issues with objects are, how do you think you can solve them?

How to Solve the Repetition Issue

const user = {
  firstName: "John",
  lastName: "Doe",
  password: "123",
};

const { firstName, lastName, password } = user;

console.log(firstName, lastName, password);
// Output: 'John', 'Doe', '123'

Destructuring is the process of extracting a property from an object by its key. By taking an existing key in your object, then placing it between two brackets ({ firstName }) you tell JavaScript:

"Hey JavaScript, I want to create a variable with the same name as my property. I want to create a variable firstName for the firstName property of my object."

Note: If you want to destructure an object, you should always use an existing key. Otherwise, it will not work.

How to Solve the Accessibility Issue

const user = {
  firstName: "John",
  lastName: "Doe",
  password: "123",
  family: {
    sister: {
      firstName: "Maria",
    },
  },
};

// We access to the nested object `sister`
// and we extract the `firstName` property
const { firstName } = user.family.sister;

console.log(firstName);
// Output: 'Maria'

When you work with nested objects, it can become quite repetitive and wastes a lot of time accessing the same property many times.

Using destructuring, in one line only, you can reduce the property path to one variable.

How to Solve the Usage Issue

Now that you know how to destructure an object, let me show you how to extract properties directly in your function parameter definition.

If you know React, you're probably already familiar with it.

function getUserFirstName({ firstName }) {
  return firstName;
}

const user = {
  firstName: "John",
  lastName: "Doe",
  password: "123",
};

console.log(getUserFirstName(user));
// Output: 'John'

In the above example, we have a getUserFirstName function, and we know that it will only use one property of our object, firstName.

Rather than passing the whole object or creating a new variable, we can destructure the object's function parameters.

How to Merge Objects in ES6

In programming, you often have to tackle issues with data structures. Thanks to the spread operator introduced in ES6, object and array manipulations are more straightforward.

const user = {
  firstName: "John",
  lastName: "Doe",
  password: "123",
};

const userJob = {
  jobName: "Developer",
  jobCountry: "France",
  jobTimePerWeekInHour: "35",
};

Let's imagine that we have two objects:

• User. An object defining general information about the user.
• UserJob. An object defining job information of the user.

We want to create one object that only contains the properties of these two objects.

const user = {
  firstName: "John",
  lastName: "Doe",
  password: "123",
};

const userJob = {
  jobName: "Developer",
  jobCountry: "France",
  jobTimePerWeekInHour: "35",
};

const myNewUserObject = {
  ...user,
  ...userJob,
};

console.log(myNewUserObject);
// Output:
//{
//  firstName: 'John',
//  lastName: 'Doe',
//  password: '123',
//  jobName: 'Developer',
//  jobCountry: 'France',
//  jobTimePerWeekInHour: '35'
//}

Using the spread operator (...), we can extract all the properties of one object to another.

const user = {
  firstName: "John",
  lastName: "Doe",
  password: "123",
};

const myNewUserObject = {
  ...user,
  // We extract:
  // - firstName
  // - lastName
  // - password
  // and send them to
  // a new object `{}`
};

How to Merge Arrays

const girlNames = ["Jessica", "Emma", "Amandine"];
const boyNames = ["John", "Terry", "Alexandre"];

const namesWithSpreadSyntax = [...girlNames, ...boyNames];

console.log(namesWithSpreadSyntax);
// Output: ['Jessica', 'Emma', 'Amandine', 'John', 'Terry', 'Alexandre']

Like objects, the spread operator (...) extracts all the elements from one array to another.

const girlNames = ["Jessica", "Emma", "Amandine"];

const newNewArray = [
  ...girlNames,
  // We extract:
  // - 'Jessica'
  // - 'Emma'
  // - 'Amandine'
  // and send them to
  // a new array `[]`
];

How to Remove Array Duplicates

Because arrays are lists, you can have many items of the same value. If you want to remove duplicates in your array, you can follow one of the examples below.

One of them will be only one line thanks to ES6, but I let the "old" example in there so you can compare.

How to remove array duplicates "the old way"

const animals = ["owl", "frog", "canary", "duck", "duck", "goose", "owl"];

const uniqueAnimalsWithFilter = animals.filter(
  // Parameters example: 'owl', 0, ['owl', 'frog', 'canary', 'duck', 'duck', 'goose', 'owl']
  (animal, index, array) => array.indexOf(animal) == index
);

console.log(uniqueAnimalsWithSet);
// Output: ['owl', 'frog', 'canary', 'duck', 'goose']

In the above example, we want to clean the animals array by removing all duplicates.

We can do that by using the function filter with indexOf inside it.

The filter function takes all elements of the animals array (animals.filter). Then for each occurrence it provides:

• the current value (example: duck)
• the index (example: 0)
• the initial array (example: the animals array => ['owl', 'frog', 'canary', 'duck', 'duck', 'goose', 'owl'])

We will apply indexOf on the original array for each occurrence and give as a parameter the animal variable (the current value).

indexOf will return the first index of the current value (example: for 'owl' the index is 0).

Then inside of the filter, we compare the value of indexOf to the current index. If it's the same, we return true otherwise false.

filter will create a new array with only the elements where the returned value was true.

So, in our case: ['owl', 'frog', 'canary', 'duck', 'goose'].

How to remove array duplicates "the new way"

Well, the "old way" is interesting to understand, but it's long and a bit hard. So let's check out the new way now:

const animals = ["owl", "frog", "canary", "duck", "duck", "goose", "owl"];

const uniqueAnimalsWithSet = [...new Set(animals)];

console.log(uniqueAnimalsWithSet);
// Output: ['owl', 'frog', 'canary', 'duck', 'goose']

Let's separate out the different steps:

// 1
const animals = ["owl", "frog", "canary", "duck", "duck", "goose", "owl"];

// 2
const animalsSet = new Set(animals);

console.log(animalsSet);
// Output: Set { 'owl', 'frog', 'canary', 'duck', 'goose' }

// 3
const uniqueAnimalsWithSet = [...animalsSet];

console.log(uniqueAnimalsWithSet);
// Output: ['owl', 'frog', 'canary', 'duck', 'goose']

We have an animals array, and we convert it into a Set, which is a special type of object in ES6.

The thing that's different about it is that it lets you create a collection of unique values.

Note: Set is a collection of unique values, but it's not an Array.

Once we have our Set object with unique values, we need to convert it back to an array.

To do that, we use the spread operators to destructure it and send all the properties to a new Array.

Because the Set object has unique properties, our new array will also have unique values only.

How to Use Ternary Operators

Have you already heard about a way to write small conditions in only one line?

If not, it's time to remove a lot of your if and else blocks and convert them to small ternary operations.

Let's look at an example with console.log to start. The idea is to check the value of a variable and conditionally display an output.

const colour = "blue";

if (colour === "blue") {
  console.log(`It's blue!`);
} else {
  console.log(`It's not blue!`);
}

This example is a typical case where you can use the ternary operator to reduce these 5 if and else lines to only one!

One line to rule them all!

const colour = "blue";

colour === "blue" ? console.log(`It's blue!`) : console.log(`It's not blue!`);
// [condition] ? [if] : [else]

Ternary operators replace if and else for small conditions.

Note: It's not recommended to create complex conditions with ternary operators because it can reduce readability.

Below is another example that uses ternary operators, but this time in the return of a function.

function sayHelloToAnne(name) {
  return name === "Anne" ? "Hello, Anne!" : "It's not Anne!";
}

console.log(sayHelloToAnne("Anne"));
// Output: 'Hello, Anne!'

console.log(sayHelloToAnne("Gael"));
// Output: "It's not Anne!"

Want to Contribute? Here's How.

You are welcome to contribute to this GitHub repository. Any contribution is appreciated, and it will help each of us improve our JavaScript skills. GitHub: JavaScript Awesome Tips

Conclusion

I hope you learned some new things about JavaScript while reading this post.

If you want more content like this, you can follow me on Twitter where I tweet about web development, self-improvement, and my journey as a full stack developer!

As front end developers, most of our time is spent in the browser with DevTools open (almost always, unless we are watching YouTube ... sometimes even then).

One of the major sections in DevTools is the network tab. There are a couple of things you can do in the network tab, like the following:

• Find network requests by text
• Find network requests by regex expression
• Filter (exclude) out network requests
• Use the property filter to see network requests by a certain domain
• Find network requests by resource type

For the purposes of this tutorial I am using freeCodeCamp's home page, freecodecamp.org/news. Simply go to the page and open the network tab.

You can see the network tab by hitting cmd + opt + j on your Mac or ctrl + shift + j in Windows. It will open up the console tab in DevTools by default.

Clicking "cmd + opt + j" opens up console panel in DevTools

Once the console tab is open, simply click on the network tab to make it visible.

Clicking on the "network" tab will show you all network requests being made for a certain page

Once the network tab is open we can begin our tutorial.

Let's begin

Make sure the correct page is open (freecodecamp.org/news) and the "network" tab panel is open in DevTools:

Illustration on where the filter bar is in network panel.

• The green box here illustrates the icon that can hide/show the filter area in the network panel tab.
• The red box here illustrates the filter area box. With this box we can filter out network requests.

Find network request by text

Type analytics into the Filter text box. Only the files that contain the text analytics are shown.

Find network request by regex expression

Type /.*\min.[c]s+$/. DevTools filters out any resources with filenames that end with a min.c followed by 1 or more s characters.

Filter (exclude) out network request

Type -min.js. DevTools filters out all files that contain min.js. If any other file matches the pattern they will also be filtered out and won't be visible in the network panel.

Use property filter to see network request by a certain domain

Type domain:code.jquery.com into the filter area. It will only show network requests that belong to the URL code.jquery.com.

Find network request by resource type

If you only want to see which font(s) file is being used on a certain page click Font:

Filtering network requests by "font" type files only

Or if you only want to see the web socket files being loaded on a certain page click WS:

Filtering network requests by "web socket" type files only

You can also go one step further and view both Font & WS files together. Simply click on Font first and then cmd click on WS to multi-select tabs. (If you are on a Windows machine you can multi-select by using ctrl click).

Multi selecting multiple resource types by "cmd` click on types

That is it for this tutorial. If you found it useful do share it with your colleagues and let me know what you think as well on twitter.com/adeelibr.

Working as a developer means you need to know how to dive into existing code bases. When you inherit a project, there are a lot of specifics that you don't know, like why some of the code is written a certain way.

So when it's time to go into a hand off meeting, you need to know what questions to ask. This is the best time you will have to get the information you need to get up and running.

These questions come up in every project. You could be starting a new job or working on a different project at your current company. Regardless, here are a few things you should bring up in transfer meetings.

Know what it's supposed to do

What exactly is this application used for and who uses it? Without this context, it's going to be really hard figuring out how to implement new features or fix bugs.

Ask about the overall use of the app. Learn about the workflow for different parts of the app and how users move through it. If there's a task list, get a walk-through or more details about each of the items on the list.

This is one of the rare moments everyone is prepared to focus on answering questions about the project. So if there is anything you're unclear on, don't leave that meeting without getting a better understanding of it.

Of course things come up once you start digging in, but this is your chance to preempt a large chunk of confusion. Try and get a high level understanding of the app before you dive into specific questions. Learning about the industry the app operates in can help answer questions that come up in your development as well.

Know how source control is handled

While most projects use Git, not everyone uses GitHub. Some projects could be hosted in BitBucket, Azure DevOps, or even on a SVN. You need to know where code is kept in version control so you can pull it down to your machine and also so you can do troubleshooting when those inevitable production bugs appear.

Make sure that you have access to the code repository and that you have the right level of permissions to do the work you need. When you receive the your login credentials, check them immediately.

The sooner you can find little problems like these, the smoother the project will go in the long run. Fix a small bug and do a quick commit to make sure that you can push up your local branches to wherever the remote repository is.

Also, take a quick look at everyone who has access to the repository. This will be useful info when it's time for pull requests and code reviews. This is also the time to ensure that only the necessary people have access to the code.

Note any users you are unfamiliar with and check with a project manager or someone to see if they still need access.

Know how to run the project

The hardest part of taking on a new project can be getting it set up and running on your machine the first time. There are a lot of one-time commands that can be lost if the process hasn't been well documented.

A few things you need to check that might not be obvious include your env variables, the versions of the software you're running, and the file names you are referencing.

Other things that might come up are setting up a new local database and loading the seed data and changing any connection strings to APIs or databases.

REACT_APP_NAME="Boogaloo"
REACT_APP_API="https://not-staging.morwl.com/api"
API_KEY=ij2i0r9j02tt904tn93

If you are going through setup and you notice yourself running into issues, make sure you're documenting them so that it's easier for the next developer to do it. Plus you never know when you'll need to factory reset your computer and those notes will come in handy.

Once you have the app running, check that everything is functioning like it does in development or production. You should see the same behavior across all of the environments until people start pushing changes.

Know the testing process

There are many different forms of testing that your app can go through and you need to know how that process works. Unit tests are common in most projects to some degree so always check for those. Some companies do integration testing to make sure no breaking changes sneak into the build or deploy pipelines.

Other places even have dedicated software testers that will run through user scenarios to see how things will work when real users see the updates. You need to be aware of all the steps your app will go through.

When you start this new project, looking at the tests can give you a good idea of how the app works. If there aren't any tests in the project then this is your chance to start adding them. Having some code coverage sets the tone for the app in the future that there should probably be more tests added as the code developed.

import React from 'react';
import ReactDOM from 'react-dom';
import { configure, shallow } from 'enzyme';
import Adapter from 'enzyme-adapter-react-16';
import Items from '../src/components/Items';
import CreateItemModal from '../src/components/CreateItemModal';

configure({ adapter: new Adapter() });
jest.mock('../__mocks__/getAllItemsMockRequest.js');

describe('Items component works', () => {
    it('Items renders without crashing', () => {
        const div = document.createElement('div');
        ReactDOM.render(<Items />, div);
        ReactDOM.unmountComponentAtNode(div);
    });

    it('should toggle CreateItemModal', () => {
        const div = document.createElement('div');
        const ItemComponent = shallow(<Items />, div);
        ItemComponent.find('#add-item-icon').simulate('click');
        expect(ItemComponent.contains(<CreateItemModal />)).toBe(true);
        ReactDOM.unmountComponentAtNode(div);
    });
});

Working with software testers is usually a more involved process. There's typically some kind of system in place like Jira or Basecamp where bugs and features can be discussed and tracked through sprints. Follow the process they have in place and it'll help get your code to the deploy phase faster and more consistently.

Know the deploy process

Although cloud services have just about taken over the hosting needs for most companies, you might still need to work with a physical server. Having this information will help you understand the deploy strategy you will be working with.

Is there a continuous build/deploy process in place or will you need to do manual deploys from your machine? Know how migrations should be handled across the different environments. Get all of the common parts of deploying an app clarified for this particular app.

Little wonky things happen with the cloud services that only the people who handled the deploys before know about so make sure you ask if there is any weird behavior you should look out for. Since you've already fixed a small bug to check that you can push up your changes, go ahead and deploy that small fix to the development environment.

version: 2
jobs:
  build:
    docker:
      - image: circleci/<language>:<version TAG>
    steps:
      - checkout
      - run: <command>
  test:
    docker:
      - image: circleci/<language>:<version TAG>
    steps:
      - checkout
      - run: <command>
workflows:
  version: 2
  build_and_test:
    jobs:
      - build
      - test

This is your test to see if you really understand how the deploys will work. Hopefully you won't have to do many manual deploys and you'll work with CI/CD pipelines so the process will stay consistent.

Know who you can turn to for different parts of the project

Unless you are responsible for the entire application from the front-end all the way to the database, there are probably other people who cover parts of the code or system you'll never touch. It's important to know who those people are so you know who to turn with questions.

Plus this is a great way to get to know other teams that work on the project and learn what they do. If it's just you working on every part of a project, make sure that you get every login credential that you can because it'll be up to you to answer all the questions.

Know which third-party services the project uses

When you start debugging issues, knowing where to turn for documentation is the fastest way to fix things. That means knowing what services the application uses and where they're used. One way to find this is to check the package.json or App.config file of your project to see what's installed.

{
    "name": "dog-finder",
    "version": "0.1.0",
    "scripts": {
        "build": "npm install",
        "start": "npm run build && concurrently --kill-others \"node ./server.js\" \"http-server\""
    },
    "dependencies": {
        "concurrently": "^5.1.0",
        "cors": "^2.8.5",
        "express": "^4.17.1",
        "johnny-five": "^1.4.0",
        "path": "^0.12.7"
    }
}

This will help you sort out a lot of issues that come up in production and it'll help you ask better questions. You'll also need credentials for most services so that will likely come up when you try to run the project the first time.

A few big advantages to looking at the third-party services early are to learn about any version compatibility changes and any known issues.

A common complaint you'll run into on older projects is that the app doesn't work the way it used to and no one knows why. Looking at these services is a quick and easy place to start looking while you get ready to take over.

Know the best way to get in touch with the decision makers

Even though you are taking over the primary development of a project, there will still be someone like a project manager that will guide the tasks you work on. Get their contact information as soon as you get approval to start on the project. This is one of the people that will be able to get your high level questions answered.

If you're working with a smaller company it would also be good to have the contact info of someone like the CEO or CTO because they will be able to give you a direct yes or no on many of the questions you have.

For example, if you've researched a new database service that will decrease their bill by 10% and increase the overall performance of the app, you want to know if you can make those changes or not.

Learn who the people are that can give you approval or guidance for the next steps you take and then save their emails and phone numbers.

One instance this is especially crucial is if there's a fire in production. When you can get those quick decisions immediately, that can save a company thousands of dollars so they will understand if you call them.

Know what your timeline is

Sometimes it's so easy to get wrapped up in the minute details that when a timeline is thrown out, agreeing makes sense.

Before you fully commit to any length of work, make sure that you've done a proper evaluation of what you are being asked to do with the resources you're provided. Do a quick code sweep to get an idea of what you'll be working with and see how long it takes for people to respond to your initial questions.

That way when you are given a deadline you can explain why it is or isn't reasonable for the amount of work being asked. You always want to give realistic estimates on so that your client or project manager doesn't get other people's hopes up. It's better to tell them upfront if something will take longer or not as long as they expect.

When you have reasonable expectations, it makes the whole project flow better for everyone. There aren't as many panicked sessions of coding and you are able to deliver quality code that won't have to be debugged in production.

Know what the scope of your work is

The scope of projects tends to slowly expand as you make progress. You start getting a little feedback here and there about "little tweaks" that should be made. Then it turns into a question of what takes priority over what and it's not the original work you started with.

One way to prevent scope creep is to agree on a set list of tasks or a specific functionality that needs to be implemented. Anything else can be written down and brought up in another part of the project work, but not right now.

Once the work has been agreed on, then there should be a clear finish state that the project will be in at the end.

Final Thoughts

Taking over an existing project is a special skill because it's not something you do all the time. Some people work on one product or product line for a bulk of their career, so setting up new projects only happens every now and then.

Although if you ever do consulting or freelance work, you'll need to know how to do this with confidence on a regular basis. Usually there are small configuration changes that you have to figure out and once you set them you never have to worry about them again.

These are just a few things I try to check for when I'm setting up a new project. Some of these tips apply to open source projects as well. Do you have anything you always check for when you're getting set up?

I write about other random stuff in tech too, like air guitars and VR. You should follow me on Twitter to learn about that cool stuff.

Hi, fellow coders! You may have heard of the Vim code editor before, or even used it a bit.

There are plenty of resources out there that cover the basics of Vim and I don't want to just do another rewrite of those here. Instead, I want to share some quick tips that I've learned from others while using Vim full time at work.

These are tiny things that you can learn quickly that will make a big difference in your day-to-day work in Vim. They'd definitely made my life easier.

Remember: Vim comes pre-installed on Mac and Linux. You just need to open up your terminal and type "vim" in the command prompt, and you'll open Vim. If you have a Windows computer, follow these instructions to install Vim on your PC.

Before we begin

If you're interested in Vim but haven't started yet, these are the resources I'd like to recommend:

• OpenVim - Interactive Vim Tutorial
• vimtutor - this is an interactive command line tutorial that's available and installed on Macs and some Linux distros. Just type vimtutor in your terminal
• VimAdventures - First couple of levels are free, and if you like the format, and the full license is $25

If you like Vim but it's too much to run it on its own, install a Vim extension for your favourite editor, like VS Code or Sublime or any other. That way you get to use the quick actions and shortcuts of Vim and a friendlier interface you're more used to.

One important realization I had about learning and working with Vim: you don't need to master everything (which is practically impossible anyway) to start using it.

Once you figure out the basics, every time you have a question or a block throughout your workday, write it down, and then go through that list and search the Internet for how to do that in Vim.

This way, you will incrementally fill any gaps you might have and will become better with each new little thing you add to your repertoire (these micro-improvements will be similar to the tips in this article below).

Now let's proceed to the fun stuff – the tips and tricks. You don't have to have any Vim plugins installed to take advantage of these.

1. How to start writing on a line at correct indentation

Before I learned this, I used to jump on a new line and go to insert mode, TAB to the right indentation and start typing code. With this little trick, you won't have to do do all the extra tabbing, it will just place you in insert mode at the right indentation.

RECIPE: S (SHIFT+s)

DEMO:

2. Resize windows automatically

Very often we do something with windows inside Vim that causes them to be resized incorrectly, sometimes one being way too wide and the other way too narrow.

The easiest way to see that effect is to open 3 windows in one Vim tab and resize the terminal window in which you opened Vim.

You want to resize the windows to all be the same size, with available space evenly distributed. Good news is, you don't have to do it manually.

RECIPE: CTRL+w =

The combination of CTRL+w, followed by pressing the equals sign key will equalize the windows.

DEMO:

3. Jump to the matching bracket/brace

With your cursor on a square [ or round ( bracket or a curly brace {, press % (SHIFT+5) to jump to its matching symbol. Press it again to jump back (toggle between them).

if (condition) {
  // code
}
// If your cursor was on {, and you pressed %, you'd jump to }

RECIPE: % with your cursor on the character you want to find a match to.

DEMO:

4. Indent/Unindent a line or multiple lines

>> ⁠– indents a line
<< ⁠– unindents a line

When you have multiple lines selected (in VISUAL LINE mode), you only need to press > or < once to indent or unindent the lines (as shown in demo below)

It doesn't matter where your cursor is positioned in the line when indenting - it will still work. After indent is done, cursor is auto-positioned on first non-empty character in the line.

RECIPE: One line: >>, <<. Multiple lines: >, <.

DEMO:

5. Fix indentation in the whole file

Start in the top of a file (to get there, press gg anywhere in the file.). Then press =G, and Vim will fix the indentation in the whole file. If you don't start in the beginning of the file, it will fix indentation from current line to the bottom of file.

RECIPE: =G

Press the equals sign, followed by SHIFT+G

DEMO:

6. Basics of working with tabs

Often you want to be looking at multiple files or contexts at the same time. Vim tabs are very handy but underutilized feature for this. I don't know of any other editor that supports this (but I'm sure there is a way to do it elsewhere).

For example, I like to keep my code related files in my main tab, and in another tab: README with a TODO list and a place I can jot down further ideas.

To write the commands to work with tabs, you will need to be in command mode. To start writing the command, press : and type. The command will show up in the left bottom corner of the editor as you are typing. Press enter to execute.

RECIPE:
:tabnew creates a new tab
gt - go to next tab
gT - go to previous tab
:tabo - close all other tabs besides the active one

DEMO:

7. How to quickly go back to a previous file

Often, when you edit a file with code, you open another one in the same window. Then it's not so easy to come back to the one you just worked on. You could list buffers and navigate to the previous one but you need to remember its name for that and spend your precious time. Vim users don't like to spend too much time on actions. :) So you can use CTRL+o for this.

All it does is that it finds a previous position of your cursor - and if it happened to be in a different file (the one you just lost by opening a new one), it jumps us right back there.

Thank you for reading and I hope these tips serve you well!

? If you want to follow my adventures, here's my Twitter :)

? I write a weekly newsletter that covers topics like learning to code, changing habits, personal finance, book recommendations & key takeaways, minimalism, starting a business, psychology and more. For those of you who are interested: join 1K+ like-minded people passionate about self-improvement and learning.
Subscribe here

? These days I am working on my side project - an app called "Zerno". Sign up to get early access very soon!
ZERNO app

Dear Self,

You just graduated and you are ready to start your career in the IT field. I cannot spoil anything, but I assure you it will be an interesting ride.

I'm writing you this letter because I want to give you some advice that will help you be a better professional. These are all things you'll learn yourself in the next few years, but this list contains everything I wish someone had told me when I started my career. They are not ordered by any means and are all equally important.

Run a marathon, not a sprint.

The road to becoming a good software engineer is a long one. Don't rush things, and don't give up just because you are not getting an easy and fast win.

Take your time to learn and become proficient in the topics you are interested in. Remember that this is a marathon, not a sprint.

Be humble, not stupid.

It is good -- sorry, it is fundamental -- to be humble. There is always something to learn from others, even when you are an experienced professional.

But this doesn't mean that everyone is better than you. You have to respect yourself and your skills.

When you don't respect yourself you become stupid, not humble.

Compare with yourself, not others.

There is no point in comparing yourself with others. There will always be someone better than you in your job. And there will always be someone better than the one that is better than you. And there will... ok, you get the point. Just do your best.

If you think someone is a better engineer than you are, learn from them. Keep doing your best, and eventually, you will be a reference for someone else.

Respect people, not titles.

During your career, you will work with exceptional professionals. Most importantly, you will meet exceptional human beings. Respect people for who they are, not for the title they have.

If foo is the "Principal Senior Lead Engineering Chief Architect", that doesn't mean that he deserves more respect than bar who is a junior software developer.

Choose the challenge, not comfort.

The road will be full of crossroads. There may be multiple choices, but everything boils down to a choice: stay in your comfort zone, or go outside your comfort zone.

There may be a moment in your life -- hopefully after decades of work -- when you will feel the need to cool down a bit because you will be satisfied with what you achieved. Until that moment, try to go out of your comfort zone. It will make you a better professional and you will feel more satisfied with your career.

Remember that the best things often happen outside your comfort zone.

Jump on the whiteboard, not on the keyboard.

When you have to design a new feature or a new system, don't jump on the keyboard to start coding. The "muscle" you have to train and use as an engineer is your brain, not your fingers. Always think before you act.

For this reason, jump on the whiteboard instead of the keyboard, and start thinking of what you should implement. Better if you have a sparring partner to challenge your thoughts.

Oh, when I say "the whiteboard" I mean "anything that can help you think", be it pen and paper, a notebook application, draw.io, and so on.

Deliver value, not code.

Please don't be affected by the NIH syndrome. There is no point in reinventing the wheel. Avoid wasting time on something that is already out there.

If you can achieve your goal simply gluing some tools together, just do it. What you should deliver as a software engineer is value to your business, not lines of code.

Choose life, not work.

In the IT field, it is easy to focus too much on work. After all, for most of us, it is not just a job, it is our passion. Remember that work is important, but life is more important.

Live a meaningful and rich life. Play sports, read books, find hobbies, travel and see the beautiful world we are living in. Hang out with friends, find a partner for your life and give to your partner all the love, attention, and support that you can. You'll be surprised how much having a rich life will improve you as a professional.

That's all I can tell you right now. I still have a lot to learn.

One last note: enjoy the ride! ?

With love, (a more experienced) You.

You can read other articles like this on my blog, florio.dev.

I've recently asked on the Instagram of HereWeCode the following question: "What small tutorials do you want to see on the account?". One of the followers answered "How to make coding interesting?". I was surprised because I'd never asked this myself.

After a few hours of searching, I wanted share with you different ways to make programming more fun.

Why coding is exciting

In my opinion, IT in general is exciting. We live in a world where computers are one of the most important things.

As we speak, programming is not a skill that everyone has. Being able to develop your own project is this world gives you a chance. Everything is possible thanks to Information Technology, and we live in a key period where there are not enough developers to satisfy the need.

Coding is a creative skill, and it's exciting to be a part of a project. Although mobile apps and websites are everywhere, I talked with a lot of people who don't know how they work.

My speech so far may seem a bit over-sold and over-played, but it's the reason why coding is exciting for me.

It's one of the reasons why I take so much pleasure in creating educational content.

How to make it more fun

After thinking about it, although programming is now a passion for me, I remembered that it hasn't always been fun for me.

Mostly when I started, I would get stuck for days on a problem. Sometimes I would completely lose hope and say: "This is not for me. I tried everything, and it still does not work. I'm not that good."

If that's the case with you, I can tell you – everybody's been there.

This situation can also happen for many other reasons. For example, when you are bored with a language or a framework because you've used it too much.

Anyway, don't worry too much about it. Here, I've listed a few tips to give you a dose of fun when you need it.

Practice

Writing code is like playing golf. When you start, it's not fun. You need to learn everything: which driver to use for hitting the ball in such a way, how to position yourself, and so on. The pleasure will come as you go along, begin to understand things, and start to have fun with them.

Don't just read code, run it

Following along with lessons by simply reading the code can be a significant problem when people start programming.

When you are learning how to code, you should try to write and run it by yourself. Take the time to do it – you will understand it better, and you will have fun trying to modify the code to create your programs.

Here's another example: when you are searching for a code on GitHub, why not try it out? It can be fun to understand someone else's work and be able to integrate it into your project.

Add a dose of fun to your projects or apprenticeships

When you are bored with one technology or if you want to increase your knowledge, you can learn a new library, framework, or language. This can be an interesting process and can help you to try new things and have fun doing them.

However, I don't recommend that you only learn from and follow along with a course. If you do so, after a few days you will be bored. Every day or with every new chapter, create small projects to encourage yourself, and let your creativity run free.

Try to find some fun projects to work on. For example, imagine you are learning the basics of JavaScript. Even if these skills are the most important, learning them won't be enjoyable. Once you know how to get user inputs and print in the console, why not trying to create a simple "chatbot" that answers user questions?

Chatbot example

When I was doing my search to answer this question, I found this story from a Quora user, and I liked it. It's an excellent example of how to put fun into your apprenticeships.

"Another thing - the worst is learning a new thing - it is usually very challenging, and your progress is much slower than you wish it were. To make that fun, I typically trick my brain.

For example, when I was learning about assembly language, and we had a project to program a tiny hardware display - well first, it was very dull. You had to study the hardware manual, it had inputs and outputs, and all you could achieve was a few letters to appear on the screen.

But I challenged myself to master that thing, and to do that, I came up with my own "special exercise". Instead of merely writing 10101 on display, I came up with the idea to write something more stupid, more childish. Something like - ——CALL -ME - NOW -XXXX — flashing and moving over the screen - this was WAY more advanced than the actual task we had been assigned in class. I just used this stupid thing to motivate myself to learn everything I could about assembly languages, and boy, this worked out well! :)"

— Marcus Biel

Always challenge yourself

When you are a developer, you always need to learn new things to stay up to date. Everything is evolving quickly, and you can't be left behind. Boredom or lack of fun occurs when you no longer feel like you are growing or learning.

To counteract this feeling, you can try to achieve goals that you have not yet met.

For example, if you have never participated in an open-source project, you can search on GitHub and contribute for the first time.

Your sense of satisfaction will be increased when you succeed in having your work accepted within the project. Perhaps you will help dozens, even hundreds of people, by fixing a previously unresolved problem.

You can also participate in coding competitions or use coding websites such as HackerRank, CodingGame, or Project Euler to challenge yourself.

Create a personal project from scratch

It can be frustrating to be a developer when you're only working on a small part of a project for your company.

Maybe you have always dreamed about a project, but you've never taken the time to work on it. Why not try to code it? You will see – it's fun to start the project of your dreams. It's also a worthy goal to make your programming habit stick.

If you don't have any ideas, try to find a theme you like, for example:

• If you like video games, you can try to create a game.
• If you are into education, why not create tutorials around code?
• If you love hardware and electronics, why not build an Arduino or a raspberry pi?

"Programming is like writing - in the main subject matters much more than the writing itself." — lifeisstillgood

Define a goal

This point always returns in all of my productivity articles. You must define goals.

Without goals, it's challenging to feel comfortable and enjoy what you are doing as a developer.

Find a mentor

A mentor can be motivating if you don't find coding fun anymore.

A mentor can give you a goal to follow and teach you the best practices. They can also help you improve your programming skills and stimulate your professional career.

Perhaps you are wondering how to ask your "hero" to become your mentor.

Well, just send a message and them to be your mentor.

Yeah yeah, it's that simple. Maybe, they will be pleased to know that you value their skills enough to mentor you. In most cases, they will be delighted to accompany you in your development.

Sleep more

When you are in a downward spiral, programming becomes less fun. Sometimes it can be difficult for you to move forward and thrive in your work.

Go to bed earlier for a few nights or sleep later in the morning for a few days, and everything should improve dramatically.

Show your work

What's worse than being a developer and losing all hope because you're alone in your basement? It's a bit of a cliché but, believe me, when you work alone for a long time on a project and never show it to anyone, it becomes less fun right away.

This tip is close to the previous ones. Once you share your work, people will make suggestions or ask questions. It's going to be challenging for you and will help you set new goals.

Conclusion

I tried to round up some essential tips to help you have fun while programming. If you have any other advice or suggestions to make it more fun, feel free to leave a comment or send me a message.

Why do you think programming is exciting? How do you make programming more fun?

Feel free to share this article if you liked it.

If you want more content like this, you can follow me on Twitter, where I tweet about web development, self-improvement, and my journey as a full stack developer!

What Should You Choose - Paid or Free Content?

This question is widespread, and everyone has asked it at one point.

I've thought about it for a long time and have reviewed my habits to understand why someone would be more interested in paid rather than free content.

Most of the time paid content is qualified by:

• All-in-one content. You pay to get all the information in the same place (for example, on Udemy).
• More detail. When I pay for a book or a course, I expect a bunch of information from the creator. I want to really understand why and how to use something.
• A warranty on knowledge. You are guaranteed to know all the basic necessary information on a subject when you finish a course. Indeed, when I take a "Learn Flutter and Firebase with concrete examples" course, I know I will see all the critical concepts surrounding these two technologies. I'll also be able to develop a small application using these technologies. Sometimes, when I use YouTube for this kind of search, I don't get all the necessary details, and I need to find another video.
• Time savings. You don't have to search for other online resources. You can focus only on the course.
• Quality. Usually when you pay for content, the sound quality and recording are much better.
• Community support. People pay for content to support a creator, or to contribute to the development of a community. If you buy a course on a new technology, you encourage the creator to develop more resources on the technology.

My recommendations to learners

All types of content are great. I personally use both free and paid content at the same time.

I think certain types of people are more likely to choose one type of content over another.

If you choose primarily paid content:

• You are a beginner, and you know what you want to learn.
• You are a beginner, and you don't want to waste time searching for content or looking at many tutorials and videos to find a solution to your problem. DISCLAIMER: Being able to search for a solution to a problem in programming is a crucial concept. It will happen–one day you're going to have to look for content to solve a specific problem. If you use paid content, be sure you know how to search for potential errors yourself.
• You are a beginner, and you don’t know how to search for the right resources.
• You want to learn a subject quickly and globally to accomplish a task (for example, I watched a course on Instagram to launch HereWeCode on the social network) .
• You don't have a lot of time (for example, you need to learn a new technology for your company in one week).
• You like to read books and understand all the details of the technology.

If you choose primarily free content:

• You are a beginner, and you have a lot of time. In my opinion, this is the best way to learn how to code. For example, this works great if it's as a hobby or if you know you have 1-2 years to retrain yourself and find work. Nothing is better than taking your time to learn programming. I took almost 3 years to be comfortable in computer development and I still have a lot to learn. You'll feel like you're taking a long time, but I guarantee it's worth it. Searching, testing, failing, retrying and so on is the key to success.
• You have been a developer for some time, and you know how to search efficiently on Google.

Note that these profiles are only examples of people who may be inclined to pay for content or search for it for free. It's up to you to do what you want. I just hope this helps people decide what kind of content they should use.

A Case Study: My Own Learning Path

To show you that this subject is complex and very personal, I will tell you what I did.

I have been coding for more than three years. It's my hobby, and I like to share my knowledge to help people to learn how to code. These reasons pushed me to create HereWeCode.

Period with only free content

The goal of this period: Learn programming and critical concepts to be able to switch quickly from one language to another.

When I started to code three years ago, I was in a school with a project pedagogy. I learned development with online resources such as StackOverflow, YouTube, freeCodeCamp, and blogs.

This period was hard for me, but it was also exciting. It was an essential part of my life as a developer. By learning with free content, I was forced to search a lot and understand where I could easily find answers to my questions. Nowadays, I'm able to explore everything efficiently on the internet.

It may not seem like it, but searching on the internet is not easy for everyone. I can tell you because I'm teaching students on a French platform, and most of the time, the beginners don't know how to find the answer to fix an error.

Period with free and paid content

For one year now I've been using both types of content. And it just depends on my goals with each technology.

I like to use paid courses on Udemy when I want to learn quickly and have a showcase of that new technology.

For example, my Instagram course allowed me to understand a new social network, define a strategy, and deploy a professional account in a few weeks. I reached my goal with this course, which was to share a new type of content as soon as possible.

When I want to learn technology deeply, I like to read books. Most of the time, there are books with lots of details you can't find in any other content.

I still use free content daily to answer a question, find a code example, understand a specific concept in a few minutes, and so on.

Bonus: The Seemingly PAID but Actually FREE content

In my opinion, there is another type of content which I call "paid but free" content.

This is the name I've given to a platform offering free content with a premium paid quality.

There are very few of them, and the most famous is freeCodeCamp.

It's quite incredible to imagine that so many hours of training are free. You can even get certified!

I know people who have changed their lives thanks to freeCodeCamp, and all for free.

I'm writing this last paragraph to give thanks for the work done by the whole team and the contributors to the platform.

If you want to do a kind act and help develop free content, you can support freeCodeCamp.

"When you donate to freeCodeCamp, you help people learn new skills and provide for their families. You also help us create new resources for you to use to expand your technology skills." - freeCodeCamp's Donate Page

Conclusion

This topic is not easy to answer, and it's the first time I've discussed something like this. I'll be honest with you: I was scared when I hit the publish button. It's quite an engaging topic, and I'll be waiting for your opinions.

I think nowadays there are so many ways to learn new things. This diversity comes from the need to satisfy all different types of learners.

It's like when you were in school – some people learned by reading, others by drawing, reading aloud, answering quizzes, and so on.

Choose the content that best suits your situation and goals.

What type of content do you use? Do you sometimes switch between paid and free content? If so, why?

If you want more content like this, you can follow me on Twitter, where I tweet about web development, self-improvement, and my journey as a full stack developer!

Learning to code by following tutorials works for many people. And yet there tends to be a separate learning curve when you're trying to move out of the tutorial ecosystem and into creating your own projects.

I've written elsewhere about how to escape tutorial purgatory and make progress as a programmer. But to summarize here, it's a necessary step in your growth as a developer to venture out into the wild west of programming and build something. This will expose you to the ins and outs of your chosen coding ecosystem.

Here are five tips to help you move out of those tutorials and into making real progress as a developer by building projects.

1. Choose a Project

Whether you're coding from a book or working through online tutorials, your first step upon leaving the safety of your nest is to choose a project that is specific to your field of interest.

If you're an aspiring front end developer, that might mean creating a basic website. If you're learning Python, that could look like a simple web scraper. Find something that interests you, and research examples to get an idea of what your project might look like when it's complete.

2. Set Up an IDE

If you've been learning from online tutorials which provide a console that handles all of the back end work for you, take some time to set up an integrated development environment (IDE) that is specific to your intended project and ecosystem.

The actual form of your IDE will vary greatly depending on your project. You could be cobbling together a workflow that includes a code editor, command line interface, version control system, and package manager. Or, on the other hand, you might install a game engine that has all of the stuff that you need built-in for you.

The important component of this step is to become comfortable coding in an environment that is standard for the type of work you want to do. This helps you move away from only coding in a browser or following a book.

3. Get Comfortable with Documentation

Here's a glimpse of a familiar workflow when you're beginning a new project:

1. Set up your IDE
2. Code
3. Get stuck or forget the syntax for something
4. Google some half-formed question about the issue
5. Find the official documentation and a handful of Stack Overflow posts
6. Check social media for no reason
7. Return to the documentation and Stack Overflow to find your answer
8. Return to step 2

Unless you're a super expert in your field, chances are that you'll get stuck trying to figure out a solution to some aspect of your project. The official documentation for the library or framework that you're using will likely have some sort of answer - even if it's an obscure one - for whatever's puzzling you. But if it doesn't, someone has probably asked a similar question on Stack Overflow or elsewhere.

Even if there are no answers out there for your specific question, there will be a breadcrumb somewhere that'll lead you to an approach for how to solve your problem.

If you're trying to use ES6 classes in some obscure JavaScript framework, for example, you might not find the exact answer you're looking for. But there will be plenty of similar resources out there that can help you come up with a solution yourself.

4. Ask for Help

One of the best things you can do for yourself as an aspiring developer is to make friends with other developers in your field. They can look at your code and provide feedback about how to make it better.

For some people, the idea of sharing their work and having it critiqued is an anxiety-inducing experience. I recommend working as diligently as you can to overcome this emotion as it will stagnate your growth as a programmer.

When you're starting out with your own projects, it can be extremely helpful to have someone who's already walked the path to look at your work and offer constructive criticism. Even if doing so requires you to rewrite whole sections of code. In many cases, you might be trying to recreate the wheel while other options already exist. There, you'll benefit greatly from learning best practices from experts that have experience in the field.

5. Identify Other Areas for Growth

One project usually leads to another, and you'll quickly identify areas in which you're able to grow as a developer. This might mean that you'll move from front end development to back end, or vice versa, or hop from 2D game programming into 3D.

It might also mean that you need to keep building your skill set just to complete the initial project that you've chosen. There's no shame in learning C#, for example, then deciding to build the back end of a web app, and having to learn all about ASP.NET and Razor Pages before actually making any progress!

Happy coding!

If you enjoyed this article, please consider checking out my games and books, subscribing to my YouTube channel, or joining the Entromancy Discord.

M. S. Farzan, Ph.D. has written and worked for high-profile video game companies and editorial websites such as Electronic Arts, Perfect World Entertainment, Modus Games, and MMORPG.com, and has served as the Community Manager for games like Dungeons & Dragons Neverwinter and Mass Effect: Andromeda. He is the Creative Director and Lead Game Designer of Entromancy: A Cyberpunk Fantasy RPG and author of The Nightpath Trilogy. Find M. S. Farzan on Twitter @sominator.

It was happening to me every time before I start reading a lot on this and searching for ways to improve my productivity. I was like you, but today everything is over. When I focus on a task, nothing can disturb me anymore.

“Stop wasting time, start investing time for that is the only way to greatness.”― Sunday Adelaja, How To Become Great Through Time Conversion: Are you wasting time, spending time or investing time?

What are the bad habits?

When I started coding every day, a few years ago, my productivity was so weak. Unconsciously each thing was a trigger to me: a noise, my social networks, my emails, someone speaking next to me, etc.

I think most of us know this; you are starting to work on something, then suddenly you have the wrong idea to open a webpage and start reading one, two, three articles. Then you close your browser, a half-hour later, and ask yourself where I was? Your brain takes a few times to remember everything before you start working again.

Other examples of my daily habits, 30-45 minutes of social networks right after waking up, 5-10 minutes of youtube videos at the toilet, 20 minutes of news each break, etc.

Do you recognize yourself? So, you are like me: you waste your time and decrease your productivity considerably.

“Time should be invested instead of wasting it or spending it.” — Sunday Adelaja, How To Become Great Through Time Conversion: Are you wasting time, spending time or investing time?

In fact, why is it a problem?

Once you are dependent on these bad habits, you are doing multitasking.

In a first thought, we can say that multitasking is a good thing. We can achieve many things at the same time, and my productivity is incredibly huge.

But it’s false. Unfortunately, humans are not computers, and our brains can’t handle it correctly.

When I was writing this article, I was looking for a multitasking definition, and I found something funny.

“Multitasking, in an operating system, is allowing a user to perform more than one computer task (such as the operation of an application program) at a time. The operating system is able to keep track of where you are in these tasks and go from one to the other without losing information.” - WhatIs.com

Multitasking is in a first search, a computer skill.

Indeed, it seems like a great way to finish a lot of things at once, but researchers have shown that our brains can’t do it. By doing it, you will lose a lot of focus and also IQ.

"According to a study by the Institute of Psychiatry at the University of London, e-mailing while talking on the phone reduce your IQ by 10 points. Researchers studied 1,100 workers at a British company and found that multitasking with electronic media caused a greater decrease in IQ than smoking pot or losing a night's sleep." — Chicago Tribune

Much more than that, some research found that a typical office worker gets only 11 minutes between each interruption and can take an average of 25 minutes to return to the original task after interruption.

Did you remember the last time you were working on something, and a colleague asked you to finish another task quickly? Try to remember the time you took to come back to your first task.

"Gloria Mark of the University of California, Irvine, found that a typical office worker gets only 11 minutes between each interruption, while it takes an average of 25 minutes to return to the original task after an interruption." — NYTime

It’s not too late to change your habits

What I want to show in the previous part is that we do a lot of things by habits, without really thinking about it. If a practice is right, this is fine, but in these cases, our patterns are wrong, and we need to find solutions to break them.

I will help you to stop multitasking and increase your productivity by giving you the tips which helped me.

Define your time wasters

The first thing you need to do is define your time wasters. As I explained precedently, in my case, it was social applications most of the time.

You need to take a break and write on paper all the triggers that make you unfocused on a task. Try to remember the last time you worked or tried to learn something. Once you do that, you make a considerable improvement to your future improved productivity.

Tips to stop wasting time

I’ve sorted my advice in 3 categories:

• General: Tips that everyone can use to improve productivity.
• Low time-waster: If you lost a bit of time and you want to make some improvements without blocking everything.
• Hard time-waster: If you already tried many times to stop being distracted, but nothing is working.

General

Parkinson’s law

This law follows the principle of work expands to fill the time available for its completion. It explains why you are more productive when you do last-minute work. Your brain will focus more because you know it’s the last limit, and you can’t exceed it.

If you want to counter this law, you need to create constraints of time in your tasks. For example, you should finish a task in one month, try to do it in two weeks.

The constraint will give you a clear objective and make it easier for you to concentrate.

Parkinson's law

The Pomodoro Technique

This method of work helps a lot of people (developers, project managers, etc.), and it’s the most simple productivity method to implement in your daily life.

Only 5 simple steps are required to accomplish this method.

As simple as it may seem, the timer will create a sense of urgency. Unconsciously, you will focus more on your task because you want to reach your goal.

If you are distracted while doing Pomodoro, for example, a colleague is talking to you, you need to postpone your timer and start it again when you can focus again.

Free Pomodoro timer (Online, Android, or IOS):

• Clockwork Tomato (Android)
• Forest (Android and IOS)
• Tomato-Timer (Online)

“For many people, time is an enemy. We race against the clock to finish assignments and meet deadlines. The Pomodoro Technique teaches you to work with time, instead of struggling against it. A revolutionary time management system, it is at once deceptively simple to learn and life-changing to use.” — The Pomodoro Technique

Noise canceling headset

This advice is simple but efficient. For most people, noise can be a trigger to concentration. Your brain will have a lot of difficulties to stay concentrated if you work in a noisy workplace (co-working, coffee, etc.).

When I started coding, I decided to invest in a noise-canceling headset. It was a bit expensive, but by making this purchase, my productivity has exponentially improved.

You can find a lot of headsets or earphones with this feature at different prices. My article will not give you what is the best one, but a few examples.

1. Sony WH-1000XM3
2. Bose Noise Cancelling Headphones 700
3. Sony WH-1000XM2
4. Bose QuietComfort 35 II
5. Sony WF-1000XM3 True Wireless Earbuds
6. Jabra Elite 85H
7. Philips Fidelio NC1
8. Bose QuietComfort 25
9. Bowers and Wilkins PX Wireless
10. Sennheiser HD 4.50 BTNC
11. JBL Live 650BTNC
12. Microsoft Surface Headphones

Low time-waster

Disable data connectivity for useless apps

A few months ago, I received many hundreds of notifications a day. I was always looking at my phone. Most of these notifications were not interesting: who liked my last twitter post, an advertisement by email, games, etc.

I disabled data connectivity in the background for all my not essential applications.

You must know that all smartphones are always synching notifications in the background. It's why you receive them even if everything is closed.

On IOS and Android, you can select for each application if you want this feature or not. What I recommend is to disable data fetching for every social network, news, and games.

It does not mean that you will not be able to use these applications. You will receive notifications when you open them only.

Besides, it will save your battery power!

Unsubscribe from useless emails

It's a bit similar to the previous tip. Most of your email notifications are advertising, don't be overwhelmed and use the "unsubscribe" option at the bottom of useless emails.

After a few weeks of doing this, your phone will stop ringing constantly.

Use "do not disturb" mode

If you can't control yourself and unlock your phone regularly, you can enable "do not disturb" mode. It will prevent your phone from the light on when you receive a notification, and you will not leave your task to watch your mobile.

Hard time-waster

Block time-wasting website and applications It’s for me the most important thing, and I still use it today.

If you want to force yourself to focus on your task, you should remove every distraction. Some companies and developers created blockers on smartphones and computers to remove access to distracting websites or applications.

When I feel distracted, I switch-on, and I don’t have anything else to do. You can be safe; you can call and answer with your phone if it’s needed.

Some applications (Windows, Mac, Android, and IOS) you can use:

• Focus (Mac)
• Freedom (Windows, Mac, Android, and IOS)
• SelfControl (Mac)
• Forest (Android and IOS)
• ColdTurkey (Windows and Mac)

Switch off your phone or use “airplane” mode

If your phone is a real distraction, you can switch it off or use the “airplane” mode to stay concentrated. It can be useful when you are learning a new thing or working on your examinations.

Sleep more

Lack of sleep negatively affects your way of thinking and your productivity. If it’s hard for you to be focused daily, it can be because you don’t sleep enough.

For high-performance work, it’s essential to have a healthy life. If your life is not qualitative, you can’t focus.

Don’t escape the rule

I hope that this article has helped you to find ways to avoid wasting time.

One last tip is: don’t escape the rule. If you keep these new habits in your daily tasks, you will succeed!

If these habits help you, feel free to share this article and your feedback.

If you want more content like this, you can follow me on Twitter, where I tweet about web development, self-improvement, and my journey as a full stack developer!

I read and tried a lot of things, and I want to share some of my top tips with you. So if you are looking for ways to become a better developer, you're in the right place!

In this post, you will discover a summary of what I've learned over the past few years of programming.

I also launched my YouTube channel recently and created a video version of this post. If you want to check it out here it is:

Here are my top 5 tips for becoming a better programmer

1. Establish goals for yourself.

Setting goals can boost your productivity as a developer. Ask yourself the following questions:

• Why did you start programming? • What are your programming goals? • What dream do you want to achieve by becoming a developer?

Everyone has their own personal goals, but I created a small list of ideas for you:

• Create your website • Get a new job • Work as a freelancer • Work remotely • Challenge yourself • Attain better financial health

Remember to save a slot for one of the most important goals: the personal project. For me, it's one of the most essential things in coding. If you want to succeed and stay motivated, you should create projects.

But you don't always have to finish them. The idea is to achieve small goals in your projects.

I'll give you an example. If you want to learn how to use a database, you can start a blog project. But if your interest is just learning how to add something to a database, you can create a simple form (a title and description) to add a record to the database.

I know this is simple, but once you do it, you've achieved your goal. It's crucial to use projects to achieve goals because it leads you to work on more concrete examples (life examples). What could be more motivating than that?

2. Do it again… and again!

Once you choose your goals, work on them as much as possible! The more your practice, the more you learn.

Learning to code is a skill, and you can compare it to doing sports. If you want to be good at it and perform well at work, you should practice a lot.

Try to practice coding daily, during your lunch break or after work. Even if it is only for one hour, if you create a habit and stick to it, you will see daily improvements.

“Repetition is the mother of learning, the father of action, which makes it the architect of accomplishment.” (Zig Ziglar - Twitter)

3. Share what you learn/create.

It's the best way to learn new things.

Some ideas for sharing what you do: • Write blog articles • Join conferences or local meetups • Ask for feedback on StackOverflow • Tweet your progress every day with the #100DaysOfCode hashtag

A bit of storytelling: Do you know why I created HereWeCode.io?

I am fascinated by code and knowledge sharing. Over the past few years, I read a lot of articles on different platforms: freeCodeCamp, dev.to, and so on. I learned that everyone could share what they learn and create, even if it's just a small thing.

I created HereWeCode for a few reasons: • Share my knowledge to become a better developer • Help beginners understand key concepts • Create simple and concrete examples for everyone • To do what I love and have fun

Everyone can do it! I started simple. First I created a small article on Medium called "Discover what an API is!", then a second one on Docker called "A beginner's guide to Docker — how to create your first Docker application", and so on.

By writing for others, you will improve your programming skills a lot. Being able to explain a concept and how it works is a crucial skill as a developer.

Remember: You don't need to be a domain expert to write about something!

4. Read code

Everything you read about code will improve your programming skills. You'll discover a lot!

Here's what you can read: • Code on Github • Books • Articles • Newsletters

You can learn a lot from other people's code. You can find experts in your field or use GitHub to find code that's similar to your own. It's exciting to discover how other developers write code and solve problems. You will develop your critical thinking skills. Is the method they use better than yours?

Similar to programming every day, why don't you try to read at least one article or a few pages of a programming book daily?

Some well-known books: • Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin • The pragmatic programmer: from Journeyman to Master • Deep Work by Cal Newport

5. Ask questions.

Don't be shy about asking too much!

It can be helpful when you don't understand something. You can reach out to your team or friends. If you don't know anyone you can ask, use programming forums.

Sometimes, you need a different explaination to understand a concept. It's good to stay stuck and search for an answer on the internet, but at some point, you need to ask other developers.

Take advantage of another person's knowledge to improve yourself. And if you ask another developer, there is a high chance that they will appreciate it.

Conclusion

You can save this article and refer to it every time you need to become a better developer.

Now it's your turn. What are your tips to improve your programming skills?

If you want more content like this, you can follow me on Twitter, where I tweet about web development, self-improvement, and my journey as a full stack developer!

If you have a Windows machine, you can just use the familiar CTRL+ALT+DEL sequence to force quit whatever program is misbehaving. But that doesn't work on a Mac.

Don't worry, though - there is one super simple way to force quit on a Mac (and a couple other methods you can keep in your back pocket as well). Let's learn what that is.

How to force quit on a Mac

The easiest way to force a program to quit on your Mac is a simple key sequence similar to ctrl+alt+delete. Just tap COMMAND+OPTION+ESC, in that order. Here's where those keys are located on a typical Mac keyboard:

This will bring up a task manager type window that looks like this:

Command+Option+ESC brings you here

Then just select the non-responsive program and hit "Force Quit" which will stop that program from running.

Note: since you'll be forcing that program to quit in the middle of whatever you were doing, any unsaved data might be lost. Make sure you enable auto-saving, back up your projects often, and keep your computer clean and up to date.

An alternative method

Why learn just one way to force quit when you can learn two? Click the Apple logo at the top left of your screen in the menu bar. Scroll down to "Force Quit" and it'll bring up the same task manager.

It'll suggest whatever program you're currently using

Simple as that!

Now that you've dealt with your crashing application, you can get back to work. :)

My current configuration hugely improves my workflow, and saves me well over 50% of the keystrokes I would have to employ without it! Let’s look at some examples of aliases, functions, and prompt configurations that can improve our workflow by helping us be more efficient with fewer key presses.

Bash aliases

A smartly written .bashrc can save a whole lot of keystrokes. We can take advantage of this in the literal sense by using bash aliases, or strings that expand to larger commands. For an indicative example, here is a Bash alias for copying files in the terminal:

# Always copy contents of directories (r)ecursively and explain (v) what was done
alias cp='cp -rv'

The alias command defines the string we’ll type, followed by what that string will expand to. We can override existing commands like cp above. On its own, the cp command will only copy files, not directories, and succeeds silently. With this alias, we need not remember to pass those two flags, nor cd or ls the location of our copied file to confirm that it’s there! Now, just those two key presses (for c and d) will do all of that for us.

Here are a few more .bashrc aliases for passing flags with common functions.

# List contents with colors for file types, (A)lmost all hidden files (without . and ..), in (C)olumns, with class indicators (F)
alias ls='ls --color=auto -ACF'
# List contents with colors for file types, (a)ll hidden entries (including . and ..), use (l)ong listing format, with class indicators (F)
alias ll='ls --color=auto -alF'

# Explain (v) what was done when moving a file
alias mv='mv -v'
# Create any non-existent (p)arent directories and explain (v) what was done
alias mkdir='mkdir -pv'
# Always try to (c)ontinue getting a partially-downloaded file
alias wget='wget -c'

Aliases come in handy when we want to avoid typing long commands, too. Here are a few I use when working with Python environments:

alias pym='python3 manage.py'
alias mkenv='python3 -m venv env'
alias startenv='source env/bin/activate && which python3'
alias stopenv='deactivate'

For further inspiration on ways Bash aliases can save time, I highly recommend the examples in this article.

Bash functions

One downside of the aliases above is that they’re rather static - they’ll always expand to exactly the text declared. For a Bash alias that takes arguments, we’ll need to create a function. We can do this like so:

# Show contents of the directory after changing to it
function cd () {
    builtin cd "$1"
    ls -ACF
}

I can’t begin to tally how many times I’ve typed cd and then ls immediately after to see the contents of the directory I’m now in. With this function set up, it all happens with just those two letters! The function takes the first argument, $1, as the location to change directory to, then prints the contents of that directory in nicely formatted columns with file type indicators. The builtin part is necessary to get Bash to allow us to override this default command.

Bash functions are very useful when it comes to downloading or upgrading software, too. I previously spent at least a few minutes every couple weeks downloading the new extended version of the static site generator Hugo, thanks to their excellent shipping frequency. With a function, I only need to pass in the version, and the upgrade happens in a few seconds.

# Hugo install or upgrade
function gethugo () {
    wget -q -P tmp/ https://github.com/gohugoio/hugo/releases/download/v"$@"/hugo_extended_"$@"_Linux-64bit.tar.gz
    tar xf tmp/hugo_extended_"$@"_Linux-64bit.tar.gz -C tmp/
    sudo mv -f tmp/hugo /usr/local/bin/
    rm -rf tmp/
    hugo version
}

The $@ notation simply takes all the arguments given, replacing its spot in the function. To run the above function and download Hugo version 0.57.2, we use the command gethugo 0.57.2.

I’ve got one for Golang, too:

function getgolang () {
    sudo rm -rf /usr/local/go
    wget -q -P tmp/ https://dl.google.com/go/go"$@".linux-amd64.tar.gz
    sudo tar -C /usr/local -xzf tmp/go"$@".linux-amd64.tar.gz
    rm -rf tmp/
    go version
}

Or how about a function that adds a remote origin URL for GitLab to the current repository?

function glab () {
    git remote set-url origin --add git@gitlab.com:"$@"/"${PWD##*/}".git
    git remote -v
}

With glab username, we can create a new origin URL for the current Git repository with our username on GitLab.com. Pushing to a new remote URL automatically creates a new private GitLab repository, so this is a useful shortcut for creating backups!

Bash functions are really only limited by the possibilities of scripting, of which there are, practically, few limits. If there’s anything we do on a frequent basis that requires typing a few lines into a terminal, we can probably create a Bash function for it!

Bash prompt

Besides directory contents, it’s also useful to see the full path of the directory we’re in. The Bash prompt can show us this path, along with other useful information like our current Git branch. To make it more readable, we can define colours for each part of the prompt. Here’s how we can set up our prompt in .bashrc to accomplish this:

# Colour codes are cumbersome, so let's name them
txtcyn='\[\e[0;96m\]' # Cyan
txtpur='\[\e[0;35m\]' # Purple
txtwht='\[\e[0;37m\]' # White
txtrst='\[\e[0m\]'    # Text Reset

# Which (C)olour for what part of the prompt?
pathC="${txtcyn}"
gitC="${txtpur}"
pointerC="${txtwht}"
normalC="${txtrst}"

# Get the name of our branch and put parenthesis around it
gitBranch() {
    git branch 2> /dev/null | sed -e '/^[^*]/d' -e 's/* \(.*\)/(\1)/'
}

# Build the prompt
export PS1="${pathC}\w ${gitC}\$(gitBranch) ${pointerC}\$${normalC} "

Result:

~/github/myrepo (master) $

Naming the colours helps to easily identify where one colour starts and stops, and where the next one begins. The prompt that we see in our terminal is defined by the string following export PS1, with each component of the prompt set with an escape sequence. Let’s break that down:

• \w displays the current working directory,
• \$(gitBranch) calls the gitBranch function defined above, which displays the current Git branch,
• \$ will display a “$” if you are a normal user or in normal user mode, and a “#” if you are root.

The full list of Bash escape sequences can help us display many more bits of information, including even the time and date! Bash prompts are highly customizable and individual, so feel free to set it up any way you please.

Here are a few options that put information front and centre and can help us to work more efficiently.

For the procrastination-averse

Username and current time with seconds, in 24-hour HH:MM:SS format:

export PS1="${userC}\u ${normalC}at \t >"

user at 09:35:55 >

For those who always like to know where they stand

Full file path on a separate line, and username:

export PS1="${pathC}\w${normalC}\n\u:"

~/github/myrepo
user:

For the minimalist

export PS1=">"

>

We can build many practical prompts with just the basic escape sequences; once we start to integrate functions with prompts, as in the Git branch example, things can get really complicated. Whether this amount of complication is an addition or a detriment to your productivity, only you can know for sure!

Many fancy Bash prompts are possible with programs readily available with a quick search. I’ve intentionally not provided samples here because, well, if you can tend to get as excited about this stuff as I can, it might be a couple hours before you get back to what you were doing before you started reading this post, and I just can’t have that on my conscience. ?

We’ve hopefully struck a nice balance now between time invested and usefulness gained from our Bash configuration file! I hope you use your newly-recovered keystroke capacity for good.

There are plenty of beginner tutorials around that help you learn command line basics, such as cd, ls, pwd and so on...but what about that fancy magic you've seen more experienced developers use?

Here are my five favourite terminal commands and utilities (in no particular order), to help you feel like the wizard you aspire to be! This is based on Ubuntu, but should be similar across other platforms (with maybe a little Googling).

If you want to mention how to achieve similar results on MacOS or Windows, or there are other terminal tricks you would like to share, let me know in the comments below.

This is adapted from my recent YouTube video, which you can view to see these tricks in action!

sudo !!

sudo !! (or as I like to shout SUDO BANG BANG) will repeat the last command you typed, but with sudo in front of it.

If you have ever forgotten to use your sudo privilege when doing something that needs your administrator credentials (such as apt updatefor example), then sudo !! is a handy way to correct it without having to type the whole command again.

tig

tig and tig status are probably the tools I use most often in my day-to-day work.

The eagle-eyed among you may have noticed that this is git spelled backwards, and indeed tig is an excellent git utility.

One of gits shortcomings for me is the lack of interactivity available in some of the basic actions. For example, while git log and git status give me useful information, it requires more manual git commands to do anything useful with that information.

tig acts like git log, but allows you to navigate up and down the log, and examine the contents of each commit from the command line.

tig status acts like git status except that it also allows for the same navigation as tig, and it also allows you to add files to staging easily from the command line.

Both commands can be navigated using the j and k keys to move up and down, and pressing enter will open the information about the file (such as the commit diff). q also exits out of each command.

To add or remove specific files from your staging area in git, simply press u.

Now when you go to git commit... as usual, your files have already been added, so no need to use the git add command.

grep

This is a very well known 'trick' but it's incredibly useful all the same.

grep allows you to return the relevant lines from text output that match a particular pattern you pass it.

For example, if you are looking in a long .log file for an error, it can be hard to see amongst all irrelevant output. Grep can narrow down your search to only the relevant lines.

E.g. grep error system.log

With other commands that produce lots of terminal output, you can pipe it to grep error to do the same. For example, if you wanted to look at your Rails routes, but you were only interested in those related to admin you could do this:

rake routes | grep admin

history

history simply returns every command you have ever typed into your terminal. Why is this useful? Well, if, like me, you are super forgetful, the history command can show you what you've done before to jog your memory.

For example, whenever I have to restore a database back-up, I can never remember the syntax. history | grep pg_restore will show me every time I've used the pg_restore command, with the exact flags and arguments I had to use.

Notice the use of grep to narrow down the search? Work smart, not hard!

spd-say

This one can be achieved a number of ways, and with various tools on each platform. spd-say is the default Ubuntu text-to-speech utility.

Using your terminal's ability to chain commands, you can use your speech utility tool of choice to tell you when a long running process has finished.

Example: sudo apt update; spd-say done

Notice the ; between the commands? This will basically run the apt update to completion and then invoke the next command. In this case it will helpfully say 'done' when it's finished.

Feel free to make it say 'booyah!' if you feel like your day needs more celebrations of tiny wins in it.

Share yours with me!

Devs love two things: laptop stickers and snazzy terminal commands. I've run out of room for stickers, but I'd love to hear your favourite terminal commands in the comments below!

You can also connect with me on Twitter @JacksonBates