4 ms·

Your comment implies juniors are only juniors for a temporary amount of time. I've worked with many SWEs (some with years of FAANG experience) who consistently

Your comment implies juniors are only juniors for a temporary amount of time. I've worked with many SWEs (some with years of FAANG experience) who consistently code like juniors. They are aware of things like the separation of concerns, but as soon as they run into a situation wheres its easier for them to leak one layer's concern into another they will do so. Consistently doing this over months erodes the quality of a codebase.

deleted 4y ago
[deleted]
simplotek 4y ago
> They are aware of things like the separation of concerns, but as soon as they run into a situation wheres its easier for them to leak one layer's concern into another they will do so. That says nothing without context. If you want to move fast then it's ok to break things, and leaking layers is far from a non-negotiating tradeoff. Software is soft, and you can always revisit a piece of code to refactor it to suit someone's architectural tastes. It makes no sense to criticize someone for focusing where it matters the most and actually deliver critical features without delay if the tradeoff is some legacy debt, and that by no mean implies they're junior. One important skill of a senior is being able to keep their eyes on the prize and be smart about tradeoffs. Prioritizing subjective opinions over software architecture over delivering value is more in line with a junior way of thinking about software than not, and to me doesn't sound like a position to criticize others.
- bcrosby95 4y ago
  I'm gonna call bullshit on all of this. The time tax on not leaking layers in an application that doesn't already leak layers is nearly zero. The problem is people don't want to expend the very minor extra amount of effort. So you do it once. Then the next person does it because hey we already do it there so the code is not even subjectively worse, it's objectively the same, cuz you already crossed that line. After a while you have a giant festering pile of shit that you just keep making bigger and bigger and now people are talking about rewriting it. In my experience you start actively losing velocity in this situation very quickly. If you're doing this when you still your have 3+ months on a project, you're likely making poor decisions. I'm not saying you need to constantly gold plate your architecture. But it should be palatable. The subjective part is what is palatable. But I don't know anyone who thinks steaming turdpiles are palatable.
  - turdprincess 4y ago
    In my experience, codebases never maintain their level of quality. Unless you are taking deliberate action to improve the codebase with every commit, it's actively getting worse like you described above. The interesting thing is that this isn't a technical problem, it's a human problem. Most folks want to clock in, do their job and clock out, and going the extra mile to improve things isn't worth the effort. I think its the same human tendency that leaves so much pee on the toilet floor - some humans will clean up their own, but almost none will clean up someone else's.
    - mixedCase 4y ago
      And that's why you don't let any bullshit in, exercise eternal vigilance and rely on static analysis tools to stem the turd wave in an automatic fashion as much as you can. The solution is not to accept "it is what it is".
    - ornornor 4y ago
      > Most folks want to clock in, do their job and clock out, and going the extra mile to improve things isn't worth the effort. I suspect this is because it’s almost never rewarded. Either because nobody up the chain of command understands and values quality beyond “it’s working and making us money right now so it’s fine” and also because doing things right is tiring. Why should I spend energy on this and not have that energy when I’m off the clock if I’m not going to get more money/recognition/time off for it and I’ll probably get laid off or move on in a couple years anyway. I don’t think anyone deliberately starts a job or task thinking they’ll do the absolute minimum. People generally want to do their best but the system moderates this desire and that’s the result. I don’t really have a solution, just pointing it out.
    - awill88 4y ago
      I too like to use the metaphor a codebase is like a public toliet. Gotta clean it or it’s gonna get gross!
  - andrewflnr 4y ago
    I mostly agree, BUT, it's very possible to end up with a situation where your current layers, even if they don't leak, are ill-designed for the feature you're working on. It can be a lot of work at that point to keep it non-leaking. You should still do it, but it won't be "nearly zero" cost.
- fshbbdssbbgdd 4y ago
  This possibly be true in some case, but I find it to mostly be wrong. The best time to fix up some code is when you are already modifying it, because that’s when you are already fully in context to understand the effects. Going back later to clean stuff up is much less likely, because you have to pay that marginal comprehension cost again and again for each issue you fix (and are less likely to even notice the problem). If you’re making this excuse, that suggests you have internalized that it’s ok to makes your codebase worse and you are probably degrading it progressively.
  - thih9 4y ago
    > This possibly be true in some case, but I find it to mostly be wrong. Yes. That’s why it’s an important skill for an engineer to know when to make that tradeoff. Sounds like you’re agreeing with the grandparent comment?
machinawhite 4y ago
"Separation of concerns" as in splitting a simple thing into 12 files because you've had too many books about architecture?
- Dudeman112 4y ago
  As in not making a 10k lines function that does everything because you didn't read any books about architecture I get it, you've been burned out by Enterprise(tm) code. Going to the very edge of the other side isn't any better
  - machinawhite 4y ago
    A 10k loc function is just a program wrapped in a function. I find it somewhat fun to refactor those. And you're god damn right I cannot deal with this eldritch horror you architecture astronauts come up with anymore, I'll take the dumb code please :-) YAGNI + KISS >>>>> SOLID all day every day
    - Dudeman112 4y ago
      >I find it somewhat fun to refactor those I don't. I like to feel productive instead of having to do laundry before getting to the actual work because someone just went ahead without any regard for quality control >YAGNI + KISS > SOLID Agreed Monster architectures are monster architectures, and yet going from Enterprise(tm) architecture to chaos architecture so you can't know anything about the system without carefully going over hundreds of lines of code isn't any better

deleted 4y ago

[deleted]

simplotek 4y ago

> They are aware of things like the separation of concerns, but as soon as they run into a situation wheres its easier for them to leak one layer's concern into another they will do so. That says nothing without context. If you want to move fast then it's ok to break things, and leaking layers is far from a non-negotiating tradeoff. Software is soft, and you can always revisit a piece of code to refactor it to suit someone's architectural tastes. It makes no sense to criticize someone for focusing where it matters the most and actually deliver critical features without delay if the tradeoff is some legacy debt, and that by no mean implies they're junior. One important skill of a senior is being able to keep their eyes on the prize and be smart about tradeoffs. Prioritizing subjective opinions over software architecture over delivering value is more in line with a junior way of thinking about software than not, and to me doesn't sound like a position to criticize others.

bcrosby95 4y ago
I'm gonna call bullshit on all of this. The time tax on not leaking layers in an application that doesn't already leak layers is nearly zero. The problem is people don't want to expend the very minor extra amount of effort. So you do it once. Then the next person does it because hey we already do it there so the code is not even subjectively worse, it's objectively the same, cuz you already crossed that line. After a while you have a giant festering pile of shit that you just keep making bigger and bigger and now people are talking about rewriting it. In my experience you start actively losing velocity in this situation very quickly. If you're doing this when you still your have 3+ months on a project, you're likely making poor decisions. I'm not saying you need to constantly gold plate your architecture. But it should be palatable. The subjective part is what is palatable. But I don't know anyone who thinks steaming turdpiles are palatable.
- turdprincess 4y ago
  In my experience, codebases never maintain their level of quality. Unless you are taking deliberate action to improve the codebase with every commit, it's actively getting worse like you described above. The interesting thing is that this isn't a technical problem, it's a human problem. Most folks want to clock in, do their job and clock out, and going the extra mile to improve things isn't worth the effort. I think its the same human tendency that leaves so much pee on the toilet floor - some humans will clean up their own, but almost none will clean up someone else's.
  - mixedCase 4y ago
    And that's why you don't let any bullshit in, exercise eternal vigilance and rely on static analysis tools to stem the turd wave in an automatic fashion as much as you can. The solution is not to accept "it is what it is".
  - ornornor 4y ago
    > Most folks want to clock in, do their job and clock out, and going the extra mile to improve things isn't worth the effort. I suspect this is because it’s almost never rewarded. Either because nobody up the chain of command understands and values quality beyond “it’s working and making us money right now so it’s fine” and also because doing things right is tiring. Why should I spend energy on this and not have that energy when I’m off the clock if I’m not going to get more money/recognition/time off for it and I’ll probably get laid off or move on in a couple years anyway. I don’t think anyone deliberately starts a job or task thinking they’ll do the absolute minimum. People generally want to do their best but the system moderates this desire and that’s the result. I don’t really have a solution, just pointing it out.
  - awill88 4y ago
    I too like to use the metaphor a codebase is like a public toliet. Gotta clean it or it’s gonna get gross!
- andrewflnr 4y ago
  I mostly agree, BUT, it's very possible to end up with a situation where your current layers, even if they don't leak, are ill-designed for the feature you're working on. It can be a lot of work at that point to keep it non-leaking. You should still do it, but it won't be "nearly zero" cost.
fshbbdssbbgdd 4y ago
This possibly be true in some case, but I find it to mostly be wrong. The best time to fix up some code is when you are already modifying it, because that’s when you are already fully in context to understand the effects. Going back later to clean stuff up is much less likely, because you have to pay that marginal comprehension cost again and again for each issue you fix (and are less likely to even notice the problem). If you’re making this excuse, that suggests you have internalized that it’s ok to makes your codebase worse and you are probably degrading it progressively.
- thih9 4y ago
  > This possibly be true in some case, but I find it to mostly be wrong. Yes. That’s why it’s an important skill for an engineer to know when to make that tradeoff. Sounds like you’re agreeing with the grandparent comment?

machinawhite 4y ago

"Separation of concerns" as in splitting a simple thing into 12 files because you've had too many books about architecture?

Dudeman112 4y ago
As in not making a 10k lines function that does everything because you didn't read any books about architecture I get it, you've been burned out by Enterprise(tm) code. Going to the very edge of the other side isn't any better
- machinawhite 4y ago
  A 10k loc function is just a program wrapped in a function. I find it somewhat fun to refactor those. And you're god damn right I cannot deal with this eldritch horror you architecture astronauts come up with anymore, I'll take the dumb code please :-) YAGNI + KISS >>>>> SOLID all day every day
  - Dudeman112 4y ago
    >I find it somewhat fun to refactor those I don't. I like to feel productive instead of having to do laundry before getting to the actual work because someone just went ahead without any regard for quality control >YAGNI + KISS > SOLID Agreed Monster architectures are monster architectures, and yet going from Enterprise(tm) architecture to chaos architecture so you can't know anything about the system without carefully going over hundreds of lines of code isn't any better