[jacurtis]

> But for the other 85+% of people in the profession its basically a game of AdLibs

This is so true. I work at a fairly small organization (~35 devs). Large enough to see roles form but small enough that I can tangibly see everyone's contributions. I work SRE, so I see lots of code from all the teams and ultimately talk to almost all the devs.

In our impressive enterprise-level codebase (our SaaS product has average annual subscriptions in the range of $1.5M per customer), there are probably 3 developers that wrote 80% of the codebase. I can name them all and call them up. But I said we have 35 devs in the organization. So what do they do? Mostly little things. Flipping a conditional or making a slightly more explicit test case to fix an unexpected edge case we experienced.

Most of these 32 other engineers are solving simple problems, basic refactoring, and so forth. Not too different from the adlib, fill-in-the-blank analogy you provide.

Also, to be clear, it isn't like we hired 3 seniors and expect them to write all the code. These are just groups people fall into naturally.

The reality is most software engineers have only ever done the adlib style work and have built an entire career around never solving any real problems. They know just enough syntax in a language to solve the little problems and with software, there is a near infinite supply of these little problems.

[snickell]

Sounds like SRE has afforded you a unique "who's writing what code small-org-wide" semi-impartial perspective. Thanks for sharing!

I'm curious if the ~three devs that "wrote 80% of the codebase" mutually recognize one another? i.e. do you think they think of themselves as in a "writes a lot of code" category along with the other ~two devs? Do they think of themselves as "writes a lot of code"? Does management recognize this and/or plan around it?

I've sometimes been one of the "people writing a lot of code" in a small org. When I'm in that mode/context, I find myself daily appreciating the types of contributions made by the larger body of folks less deep in the woods. They do a different and complementary type of work, and I've found both types bring something valuable (and different) to the codebase.

[whstl]

When I was a developer I hated it. I was almost always the #1 in LOC, Jira Tickets, Scrum Points, you name it. I was naturally good at it, but the environment was always very competitive and the other top performers would brush it off as just me being lucky with "LOC Heavy" tasks. And it would piss me off that I would get paid the same as a guy who wrote 200 LOC a month and wasn't doing much more than those lines.

Being a manager/lead developer today, I enjoy the people doing small work. I just let them pick tasks as they wish, and it takes longer, but they eventually pull through.

The problem is just that they're a bit unpredictable, so if something has a tight deadline, we gotta assign to someone else.

[austin-cheney]

As a developer I don't mind that other people don't do work. If they want to stagnate in their career that is their problem, but it certainly isn't a problem for me... until they make it my problem. This typically happens when entitlement sets in and the baseline lowers so dramatically that not doing work becomes a mandatory expectation only shattered by the crying when conveniences are peeled away.

Worse than that are the people who work their ass off, but just aren't good at it. I would rather work with people who prefer to not do work. The output is generally the same, but the people who work their asses off cannot see the difference and believe they somehow deserve more.

In my career the single biggest failure that I see repeated EVERYWHERE is confusion about what software really is. There is only one purpose to any of this: automation. In that mantra actually not doing work is supremely desirable so long as the output meets expectations.

[whstl]

Agreed.

I think the biggest risk with the people who work their asses off more than they should (doesn't matter if it's good or bad code) is that they end up with a non-sustainable output. Productivity is artificially high, and often achieved by overtime, working weekends, and overworking themselves. Eventually that leads to burnout, lower quality, and it becomes hard to replace. When it's people working too much and delivering bad code it's probably not as bad, though.

At my current company we have someone in this situation, with work affecting their day-to-day stress levels very much, to the point of damaging their personal relationships. Their manager is young and inexperienced, and doesn't see the issue, but he was flagged by HR and I hope something gets done.

[intelVISA]

This is why the tech interview is still an unsolved problem (for non-tech ppl).

How does a non-tech role sift through the 32 devs who did 10YOE flipping bools vs. the 3 that built the entire system? They'd look similar on paper and in superficial conversation.

[zerbinxx]

This is the plague of hiring senior engineers, and one of the reasons we needed a new code test/challenge to get fewer bool flippers in our senior engineer hiring process. If you make them do something complicated/complex you get a lot more signal than if the test is bool flipping/a simple project from scratch