What do developers actually care about?

What do developers actually care about?

Developers care about the quality of what they build, the reputation their work earns, the tools they build with, the leverage their work can reach, and the uninterrupted time building requires. Salary matters the way it matters to anyone, and it sits alongside these other currencies rather than above them. A developer weighing an offer is pricing all of them at once.

Leverage deserves a word, because it is the currency with no equivalent in most professions. Code runs without its author present. A tool one developer writes can be run by a million people the same afternoon, and a library one developer maintains can sit inside ten thousand products. Developers feel that multiplier, and many will choose the role where their work compounds over the role that pays a little more. It is why "how many people use what I build" comes up in their decisions as often as title does.

This is the fact that makes developer behavior legible. The free nights spent on someone else's project, the strong reaction to a tech stack mismatch, the refusal of a take-home from a well-paid senior, the calendar blocked against afternoon calls, the move after twenty months at a company they liked: each one looks strange against a playbook built for other professions, and each one is a rational trade in one of these currencies.

This guide is the map of those motives. The lessons in this module take them one at a time: how a hundred developers share one public codebase, why the work is given away, why the tools carry so much weight, what a meeting really costs, why parts of an interview process get refused, why people leave and hop, and why most outreach gets ignored. The sections below tie them into one picture and link each lesson where it belongs.

What is GitHub, and why is it public?

GitHub is the website where most of the world's shared code lives. It hosts repositories, and around them it hosts the conversation: the proposed changes, the reviews, the arguments, the decisions. Nearly every major open project is on it, and most professional teams use it or something shaped like it for their private work.

The public half of GitHub works like a public square. Anyone can read the code, see who wrote which commit, and follow how a disagreement about a change was settled. That visibility is the point. A lawyer's best brief is confidential and a salesperson's best deal is a private number, but a developer's contribution to a public project is signed, dated, and readable by any future employer. It is one of the few professions where a portion of the work product doubles as a permanent public portfolio.

That permanence explains why reputation there is worth real effort. It also sets up the most common misreading of the whole platform: most employed developers do most of their work in private repositories their employer owns, so the public record is a sample rather than a census. The GitHub lesson covers the mechanics, what a fork and a star literally are, and why an empty public profile can belong to an excellent engineer.

Why do people give their work away?

Because the gift pays. Free public work is the behavior that breaks the normal playbook hardest, and it has three returns behind it.

The first is reputation. A contribution accepted into a respected open source project was reviewed by strangers who had no reason to be kind, and they took it. That is a public credential no resume line can match, and it travels between employers the way a byline travels between newspapers.

The second is self-interest in the tools. Developers build on shared libraries and frameworks, so a bug fixed in a shared tool is a bug fixed in their own product and in thousands of others. Companies fund open source for the same reason: the shared foundation is cheaper to maintain together than to rebuild alone.

The third is the craft itself. On a public project the developer picks the problem, sets the standard, and keeps no deadline. For many people that is the most satisfying programming they do all week. A profile full of evening commits to an unpaid project is evidence of appetite for the work, and the gift economy lesson goes into how that economy runs and what a license has to do with it.

Why does the stack matter so much to them?

Because the stack is two things at once: the material the developer works in every day, and the position the market will price them on next. What is a stack covered the first meaning. This module adds the second.

Skills in this field depreciate. A technology can go from default choice to legacy in five or six years, and the market pays a premium for the current thing. So when a developer hesitates at a role on an aging stack, they are reading a chart. Two years deep in a declining technology can mean re-entering the market with a skill set employers have stopped searching for. The reverse also holds: a role on a rising stack is partly paid in future employability, and some developers will trade salary for it.

There is taste in it too. Developers spend eight hours a day inside these tools, and the difference between a stack they enjoy and one they endure is the difference between a good workshop and a bad one. The tools lesson unpacks both halves, including why a candidate may decline a strong offer over this one line of the job description.

Why is time protected so strongly?

Because building software means holding a model of the system in your head, and that model is expensive to load and cheap to lose. A developer deep in a problem is tracking dozens of moving parts at once: what calls what, which cases are handled, where the current change ripples. Reaching that state takes somewhere between fifteen minutes and an hour. Losing it takes one interruption.

This is why a thirty-minute meeting at 2pm costs more than thirty minutes. It splits the afternoon into two fragments, each too short to reload the full model, and the deep work slides to tomorrow. It is also why developers guard mornings, batch their calls, and answer messages in bursts. The behavior reads as unavailability, and it is closer to the way a surgeon guards the operating room.

The same mental-model problem explains a second famous behavior: estimates that miss. A task's true size only becomes visible once the developer is inside the system, which is after the estimate was given. The 2pm meeting covers both, along with what sprints and story points were invented to contain. For scheduling, the practical fact is that a developer who offers 8am, noon, or 5pm for a call is protecting their best hours, and taking one of those slots costs the relationship nothing.

Why do strong candidates refuse parts of a process?

Because the process is evidence, and candidates read it the way you read a resume. Every stage of an interview tells the candidate something about how the company treats engineers: what it tests is what it values, and what it demands is what it will keep demanding after the start date.

The refusals follow from supply and demand. A take-home assignment costs four to ten unpaid hours. A candidate running five processes at once is being billed those hours five times, and the strongest candidates, the ones already well employed and lightly job-searching, are the first to decline. A whiteboard round that tests memorized puzzle algorithms measures something a senior engineer has spent fifteen years never needing, and many read it as a sign the company cannot evaluate real work. The refusal is a market position, and it arrives most often from exactly the people the search is for.

The useful inversion: a heavy process does still fill the role. It fills it from the pool that stayed, which skews toward candidates with fewer options. Judged by the interview walks through each common stage, what it signals, and what the companies that compete best for engineers run instead.

Why do developers leave?

Mostly on a cycle, and mostly for reasons the other sections already named. Tenure in software runs short: two years at a company is normal, four is long, and a resume of 18-to-30-month stints is an ordinary career shape rather than a warning. Three forces drive the cadence.

Compensation resets. Raises inside a company trail the market, while a move reprices the developer at current rates, and the gap compounds. Staying loyal has a literal price, and engineers know the number.

Stack refresh. The depreciation from the stack section works on tenure too. A developer who senses their daily tools going stale will move to stay current, sometimes at flat pay, because the move protects their next five years.

Growth ceilings. Once the interesting problems at a company are solved, the remaining work is maintenance, and the craft currency stops paying. The strongest builders leave at exactly that point, which is why departures cluster after a big project ships.

The shape worth reading across a string of moves is scope: whether each stop involved bigger systems, harder problems, or more ownership than the last. Why they leave and why they hop treats retention and the hop pattern in full, and the career shapes lesson later in the path turns this into profile reading. From there, the motives in this module become working knowledge: outreach that lands applies all of them to the first message a developer receives from you.