I keep seeing job listings for software engineers, but the descriptions all sound different and I’m getting confused about what the role really involves day to day. Is it just coding, or does it include design, architecture, and talking to clients or stakeholders too? I’m trying to decide if this career fits my skills and goals, so I’d really appreciate a clear breakdown of what a software engineer actually is and what they’re responsible for in modern tech teams.
Short version. Software engineer means “person who builds and maintains software,” but what that looks like depends a lot on company size, product, and level.
Common day to day stuff:
- Coding
- Writing new features
- Fixing bugs
- Refactoring old code
- Writing tests
- Doing code reviews for other devs
This is most of the day for many engineers, especially juniors. Maybe 60–80 percent of their time.
- Design
- Breaking a feature into smaller tasks
- Deciding data structures and APIs
- Talking with other engineers about how things fit together
- Choosing where to put logic in the system
At big companies, “design” often means writing a design doc that explains the approach, tradeoffs, and risks. At smaller ones, it is more whiteboard or quick talks in chat.
- Architecture
- More common for senior engineers or tech leads
- Deciding how services talk to each other
- Picking storage types and patterns
- Thinking about scale, reliabilty, monitoring, security
You will touch some of this as you grow, even if your title stays “software engineer” and not “architect.”
- Communication
- Daily standups
- Planning meetings (sprint planning, grooming, retro)
- Writing tickets and documentation
- Explaining tradeoffs to product or design
- Pair programming sometimes
If you hate talking to people at all, the job gets harder. You do not need to be a performer, but you need to explain your work and ask questions.
- Product work
- Reading specs or user stories from product managers
- Giving estimates on how long tasks take
- Pushing back when something is unclear or impossible with current system
- Suggesting simpler options
Good engineers help shape the solution, not only type code.
- Operations
- Deploying code
- Watching logs and dashboards
- On-call rotations for outages
- Writing runbooks, alerts
This shows up more in backend and infrastructure roles, or in smaller startups where everyone does a bit of everything.
Why job posts look different:
- Small startup: “Software engineer” does coding, some product thinking, a bit of DevOps, maybe some data work. More chaos, more variety.
- Medium company: More defined teams. You focus on a specific area, like web frontend, backend APIs, mobile, data pipeline.
- Big tech: Job is narrower. A “backend engineer” focuses on services and APIs. “Frontend” on UI. “SRE” on reliability. Titles split, but job posts still say “software engineer.”
If you want to picture your week as a mid level engineer on a product team:
- 4 days: mostly coding, reviews, design discussions, helping others
- 1 day: meetings for planning, grooming, retro, 1:1 with manager
- Occasionally: on call shift, incident fix, writing or updating docs
How to read a job description:
Look for these keywords:
- “Languages / stack”: tells you tech you will use
- “Own features end to end”: you will do design, coding, testing, maybe deployment
- “Cross functional”: you will talk to product, design, QA
- “On call, SRE, DevOps”: expect operations work
- “Architecture, system design, scaling”: skew toward senior level
If you want more coding heavy work, focus on “individual contributor,” “feature development,” “strong coding skills” and fewer mentions of “stakeholder management,” “roadmap,” “strategy.” Those hint at more senior or lead responsibilities.
If you are starting out, expect:
- Mostly coding and bug fixing
- Some design under guidance
- Many code reviews and feedback
- Learning existing systems and patterns
So no, it is not “only coding,” but for most engineers coding and reviewing code stay the core of the job, with design, architecture, and product input increasing as your seniority grows.
Short version: it’s a job family, not a single job.
Where I’ll slightly push back on @himmelsjager is on the “60–80% coding” thing. That’s true in many places, but the real split depends on:
- Your level
- Your company size
- How chaotic the org is
I’ve had roles where:
- Junior: 80–90% hands-on coding, bugs, small features, tests
- Mid-level: ~60% coding, rest planning, reviews, grooming tickets
- Senior: some weeks <30% coding because of design docs, helping others, incidents, meetings, etc.
So if you imagine “day to day = headphones on, code 7 hours straight,” that’s rarely real outside small startups or very dev-focused teams.
What it actually includes in practice, beyond what was already said:
-
Reading terrible code and ancient docs
Nobody advertises this, but you will spend a huge chunk of time:- Reading old code to figure out what the system actually does vs what the spec says
- Hunting down who last touched a thing
- Reverse engineering behavior from logs when there is no doc
-
Dealing with ambiguity
A lot of “design” is:- The ticket is vague or missing edge cases
- Product says “just make it work like X app”
- You decide details, argue for or against scope, and write down what you’ll actually do
That’s not pure coding, but it’s still core engineering work.
-
Tradeoffs, constantly
Software engineering is basically structured compromise:- Fast vs maintainable
- Fancy architecture vs “we ship this quarter”
- Perfect tests vs “we just need a basic safety net”
You’re expected to recognize when “textbook clean” is overkill and when a hack is going to hurt you in 3 months.
-
Owning your stuff after it ships
This is where a lot of people get surprised:- Your feature breaks at 2 AM
- Monitoring alerts go off
- Support escalates a customer issue
You don’t just write code and walk away. In decent orgs, “engineer” implies you’re on the hook for reliability and debugging too, even if there’s a separate ops/SRE team.
-
Political & social layer (that nobody mentions in job posts)
Not “office politics” in a drama sense, but:- Getting buy-in for a refactor
- Convincing PMs to reduce scope
- Negotiating deadlines
- Helping juniors without becoming the bottleneck
If you ignore this part, your good ideas die quietly and your life gets harder.
-
Job descriptions are marketing
A lot of your confusion is justified because JDs are:- Written by recruiters who don’t do the job
- Copy pasted from other roles
- Packed with buzzwords like “ownership,” “end to end,” “move fast,” “wear many hats”
Rough translation: - “Wear many hats” = we’re understaffed
- “Move fast” = expect half-baked requirements
- “High ownership” = your failures are yours, your wins are “the team’s”
If you’re trying to figure out what you would actually do, here’s a decent mental picture for a typical product team role:
- Morning: standup, look at board, pick up a task
- Block of time: read some code, tweak design with another dev, implement, write tests
- Interruption: answer a Slack question, help debug a bug, do a code review
- Another block: finish coding, push, wait for CI, respond to comments on your PR
- Occasionally: join a planning meeting, refine tickets, write a short doc, maybe help recover from an outage
So no, it’s not only coding, but coding is the spine that everything else hangs off of. As you get more senior, the job tilts from “I write code” to “I make sure the right code gets written and doesn’t burn the place down later.”