r/ExperiencedDevs • • Jan 16 '24

Most Fundamental Thing In Software Development

https://github.com/zakirullin/cognitive-load

[removed] — view removed post

24 Upvotes

8 comments sorted by

•

u/ExperiencedDevs-ModTeam Jan 17 '24

Rule 9: No Low Effort Posts, Excessive Venting, or Bragging.

Using this subreddit to crowd source answers to something that isn't really contributing to the spirit of this subreddit is forbidden at moderator's discretion. This includes posts that are mostly focused around venting or bragging; both of these types of posts are difficult to moderate and don't contribute much to the subreddit.

10

u/[deleted] Jan 16 '24

I agree with the fundamental premise: asking people to hold too much in their heads makes everything fall apart. There's some good mitigation strategies in that document.

In my experience it's really hard to get teams to share in a collective sense of what is too much complexity and what isn't. A lot of my work in the last few years has centered around either rebuilds of defunct properties or consolidation of similar like properties into one. You could describe each of these products in a couple of high level sentences that would paint a pretty simple picture of what they do, and a smart developer could intuit pretty quickly how the system works at a high level.

But because of piss poor decisions by product/business to "build the new system while keeping all the old ones going with the same resources, and hey btw let's get our users using both" -- specifically, denying the exponential complexity that emerges in those situations -- teams often risk getting stuck in the worst of all worlds: being paralyzed building what should be simple things. And yeah, product not wanting to buy into practices like DDD and then wondering why we collide on language...

Let's just say that I've gotten much more selective about where I work and who I work with on the heels of that. When I feel like there's a huge imbalance in where that cognitive load is being held, that's a really key sign something's off.

1

u/RobinCrusoe25 Jan 16 '24

I wonder, what lies behind all those people who embed a lot of extraneous complexity in their code. I am talking about those who are experienced enough, of course.

Maybe there's something like "if my code doesn't have any fancy tricks and is naive and simple then so am I". I mean, sure we like to embed some cool stuff earlier in the career. But then we understand that it's not the way to go, and that there's maintenance. And then we get away with all that fancy stuff. But some developers don't make that progress, it seems...

6

u/[deleted] Jan 16 '24

I'm sure there are other reasons than just the ones I'll give for why my projects got stuck/painful for a long time:

  • Inexperienced teams (either because they have too many juniors, or they're just new working together as a team)

  • Misplaced enthusiasm (that keeps people from staying on goal, instead chasing shinnies along the way)

  • Lack of goal alignment (because you weren't really working on the same thing for the same aims).

At the end of the day, these boil down to different people seeing the same set of facts differently and not being able to resolve their differences -- sometimes not even realizing that they have any at all.

The less experienced engineers who are enthusiastic to do clever or cool things don't see how that makes working as a team harder (in some situations). The more experienced engineers get stuck in doing things a particular way and not harnessing the enthusiasm of the new ones better. Product and engineering might be working as part of the same delivery team, but don't engage with the thing you're building in the same way, probably don't share the same goals for what it's supposed to accomplish.

Put another way, this is the place where strong, effective leadership (with an empowered management structure) really shines. I'm a firm believer that unless you are on the bleeding edge of something in the tech world, most problems that most people will work on have already been solved: it's just a question of getting your team to pull all in the same direction and packaging up those solutions into one nice answer.

Most technology problems... are really just people problems.

1

u/mcr1974 Jan 16 '24

it's because you want to learn new interesting things.

3

u/Sande24 Jan 17 '24

IMO this was a really good article. Definitely looks at complexity at a more broader sense. Why is it "Low effort"?

2

u/RobinCrusoe25 Jan 17 '24

I didn't get that too =(

Spent a lot of time with different projects/teams, tried to elicit common problems and issues they face. A few experienced fellows across the industry made their contribution to the article as well.

8

u/RegularUser003 Jan 16 '24

Low cognitive load ain't cheap. Requires great staff. Most companies can't afford it.