Tenure in this field is short enough that most devs are renters, not owners, so the mortgage isn't your problem.

I suspect that drives a lot of the problems.

Everywhere I have worked has about the same average engineer tenure (between 1.5-2 years), but had massive differences in code quality.

Also, super-long-tenured engineers can be detrimental. There can be a tendency to not document anything when you can always just ask one of the oracles of knowledge that originally built it.

The wrong type of super-long-tenured engineer is just going to be defensive and full of excuses about why something was built one way, even when the pain of using what they built is dragging down the whole organization.

They will push back on anything new and choose to add incremental blobs of crap code to their existing pile of crap instead of breaking things down and using their learnings to help design the new system

> The wrong type of super-long-tenured engineer

Once you start thinking about the code in terms of memorization you’re a hazard to your coworkers. It’s one of the reasons I like to try to move about on projects.

When you built the code you had to think about two or three concepts at once. Then new functionality added another concern, and another, and another. For you, each addition was one more thing on a pile you already knew.

For someone new looking at that code, they have to now juggle ten things at once, so they either run away, or they learn by breaking things. Which the frustrated tenured person may use as confirmation bias about how all the new hires are worthless and we should only trust senior people. When really the entire situation is your fucking fault.

That's an interesting take- how long do you think it takes before an average tenure becomes detrimental? Honestly, I haven't worked in environments where you have people there for 10 years, and even 5 is a real rarity in my experience (I am getting close to doing this for 20 years now as well). Its much more common to have the average turnover be about 2 years, and in most places I have worked, it takes about that long before you start to get really good- at least to the point where someone asks you to make a change, and you can more or less visualize what changes need to be made in what places and have a very good idea of how long it will take.

> The wrong type of super-long-tenured engineer is just going to be defensive and full of excuses about why something was built one way, even when the pain of using what they built is dragging down the whole organization.

I'm pretty guilty of this. The way I see it, I can either tell someone now why things are, or I can let them waste time figuring it out for themselves.

If you stick around long enough, eventually you become partially responsible for a collection of projects built by people who came, did a passable job, then left. I'm not keen on spending months rewriting a system just because the current one has some issues. And if it needs a new feature/update, I have no problem tossing a turd on the pile of crap.

Granted, I see the appeal of rewriting things. You get to spend 12-18 months building a new project the way that you want it, then leave once it is built and the maintenance responsibilities kick in. These people have never had to actually maintain software before, so they have no idea how to even write maintainable software.

I get the problem with the guy who was there 20 years, but every project I have worked on has not made it to the end with the same engineers as those who started on the team.

They don't need to stay 20 years, but at least someone should still be there from beginning to end of a 5 year or even 2 year project.

> The wrong type of super-long-tenured engineer is just going to be defensive and full of excuses about why something was built one way, even when the pain of using what they built is dragging down the whole organization.

Haha. So true. Isn’t the adage you’re either changing or dying?

Not just developers but managers.

I still maintain that most of the legacy of the dot com boom bust cycle was not developers learning bad habits, but managers figuring out enough lines of bullshit they can tell people to string them along for 18-24 months and getting promoted or a new job after everyone figures out everything you said is empty (lies).

That’s IMO the root of the tech debt problem. Devs ate it up, but they were coached as well.

Yep. It was insane to me how often leadership of projects turned over when I graduated. I thought one person would shepherd it from start to completion (within reason) and that companies would incentivize this close management.

Not even close. Can easily have three people manage the same project in a two year period.

And you can't automatically assume that when the new person feeds you the same line as the last guy, that they're lying too.

That would be somewhere between stereotyping and pernicious pessimism, and at your tender age you don't want to think about yourself in either of those ways, so we'll wait to see if this person will actually deliver or not. Great route to burnout.

I don't understand it. It takes months to get even minimally productive and years to decades to grok your code base. You would think that companies would be dying to retain programmers and blacklisting anyone who leaves any company in less than five years.

Blacklisting sounds extreme.

Wouldn’t we also need to blacklist a company that loses a programmer before the five year mark?

You are right that blacklisting is too strong of a word. It would be enough to just look at early leaving like a resume gap. It won't stop you, but you will be asked about it. Have enough to show a pattern and you are essentially out.

Technically true, but quality control must be part of the leadership and culture if it is to mean anything. People come and go, but culture endures.

Can culture survive everyone being replaced?

Ever since I first started working as a developer, I've wanted to preach the idea that code UX is important.

Some issues I found: 1) It took me years to clearly specify what clean code is. 2) I still haven't learned to effectively articulate its importance. 3) Except maybe onboarding time, I don't know how to measure its importance. 4) Cleaning up code is not rewarded. 5) Writing dirty code is often rewarded with promotions.

> code UX

Agreed, the usability of tooling is important. Code is not just a tool to do a task, it is at once the tool and the communication to future developers.

Programmers, like anyone else passing through an educational system, self-select for strengths and avoid their weaknesses. Thinking is prized among programmers; thinking about how others think is most manifestly not prized.

There is also a demographic phenomenon. Each group rebels against something. (Parentheses, compilation time, memory management.) If the rebellion makes sense, it may result in progress. But to be well-designed, a rebellion must be consistent in its principles.

Safe code that still compiles and runs unchanged after decades is a measure of the real value of the design. Tooling that is partially or completely broken, or chasing faddish delights, is a sign of profoundly indifferent design.

I take this _very_ seriously but didn't have a name for it until now.

I totally agree that many/most software organizations don't take it seriously. But I don't think that it's because of a lack of desire, I think it's a lack of even knowing it's a thing.

I put my skills in writing clean code in my most recent performance review but I didn't do a good job of describing it. It's also not something that is apparent to higher ups, but is readily apparent to colleagues who describe the code as a "joy" to work with.

I think we need to get better as an industry at measuring "Code UX" in a quantified way, and then that can start to be a meaningful area of progress that engineers can use in their career, which will motivate them to improve on that metric.

I think the term that has been coined already is DevEx. We have definitely needed to think of it as a first class concern for a very long time.

1) Yes

2) Unfortunately solving the problem isn't as straightforward as it sounds, because notions like "intuitive" and "clear" are hard to define objectively. Explicitness, constraints, and simplicity are pretty objective. But intuitiveness has to be considered in relation to the current and future team (languages/idioms they're likely to have in their head, domain concepts and background knowledge they're likely to have, etc) and will always be imperfect. Of course we should still try, and as you point out, many people don't.

Here’s the thing. You don’t have to solve this stuff objectively. That’s a lovely long term goal but what you need right now is for the coworkers you already have to understand what a new bit of code is doing. And you can investigate that by running 1:1 usability studies. By pairing with them on using the new code.

Instead of jumping in every time they get stuck, make notes while they struggle a little bit. If they still don’t get it then intervene, acknowledge this seems to be more opaque than you hoped, bail them out, then take more notes about the interaction.

Maybe all you need is to switch to a synonym you mentioned in your explanation, or to homogenize argument order between some functions, or pluralize an argument as an affordance. Maybe you used jargon from a problem domain (eg, graph theory, linear algebra) and you need to think about whether you really expect everyone on the team to learn that jargon on top of everything else or maybe you should instead use terms from the requirements or application domain and leave the theoretical terms as comments in the code, or local variable names.

Or maybe your whole theory of organization is inside out and backward and you need a very different API that hides or telegraphs implementation details.

Could you recommend any open source projects which demonstrate good code UX as you describe? I would like to read through some such source code.

Not OP, but I would recommend backboneJS[1] or underscore[2]:

  [1]https://backbonejs.org/docs/backbone.html
  [2]https://underscorejs.org/docs/underscore-esm.html

The .NET framework is fantastic at this, you don't even need the underlying code, usually just the function signatures and Visual Studio autocompletion allows you to guess your way into finding the right classes and functions. Everything has long descriptive names (without the AbstractProxyFactory bloat from Java), follows conventions, arranged in a logical hierarchy and ample documentation available in intellisense.

I’m willing to bet that descriptive names is a red herring, and the real difference in code quality were engineers who cared enough to review for such things.

Having worked on a pre-Fortran77 code base, names are a big fucking deal. Half the code was written before variable names could be longer than six characters.

The pendulum is swinging back from the overreaction to that, Java's famous AbstractSingletonProxyFactoryBean. As awful as that name is, I will take it any day over L(IH+GV).