6 ms·

I think there's a big cultural challenge with adopting duplication. It goes against most people's career growth objectives. Being able to effectively create cl

I think there's a big cultural challenge with adopting duplication. It goes against most people's career growth objectives. Being able to effectively create clean, re-usable abstractions is a measure of being a "senior" engineer at many places. In other words, to be viewed as senior, you need to be able to effectively write abstraction frequently. It's hard to measure an abstraction in the moment, so a lot of people assume that the senior simply knows better. I find this extends to a lot of programming. Seniors will often use unnecessary tricks or paradigms simply because they can. It can make it extremely difficult for junior developers to grok code. Often this re-enforces seniority. "If only the seniors can work on a section of code, then they are senior". Likewise, there are so many books on crazy architectures and patterns. It's really neat to understand, but I've determined those books are pretty much self-serving. ---- I've found that my work is often far more limited by the domain/business logic than any sort of programming logic. I'll happily write code that looks really basic - because I know ANYBODY can come in and work with that code. If I write code that a junior needs to ask me questions like "what is this pattern?" or "what does this mean?", I've written bad code. ----- With all that being said, every single job interview I've ever had expects me to write code at the level of complexity that my title will be at. They'd much rather see me build some sort of abstract/brittle concept than using some constants and switch statements. The prior looks cool, the latter looks normal.

leto_ii 6y ago
> I think there's a big cultural challenge with adopting duplication. It goes against most people's career growth objectives. My experience is the complete opposite :D. What I've noticed is that the people who 'deliver' quickly (without much regard for what might be called code quality) and fulfill business requirements without much questioning are perceived as more valuable. > I've found that my work is often far more limited by the domain/business logic than any sort of programming logic. I broadly agree with this statement. However, just like a good carpenter knows how to properly build a bookcase, a table, a roof etc. a good developer should understand the programming logic and know how to apply it. Business requirements need to be fulfilled, but it's up to us to decide how to do that. More so, I think it's up to us to push back when we feel business requirements don't make sense from a technical point of view, or even from a business point of view.
Tainnor 6y ago
I find statements such as this to be profoundly anti-intellectual. It suggests that we can't become better at what we do and need to be stuck at the level of "a beginner can understand that". Now, I agree that simplicity is a virtue and that some people go overboard with crazy stuff just because they find it cool. But, as Rich Hickey says, there is a difference between simple and easy. If a junior dev doesn't understand "map", then we should explain them what "map" is, instead of going to back to writing everything with for loops.

leto_ii 6y ago

> I think there's a big cultural challenge with adopting duplication. It goes against most people's career growth objectives. My experience is the complete opposite :D. What I've noticed is that the people who 'deliver' quickly (without much regard for what might be called code quality) and fulfill business requirements without much questioning are perceived as more valuable. > I've found that my work is often far more limited by the domain/business logic than any sort of programming logic. I broadly agree with this statement. However, just like a good carpenter knows how to properly build a bookcase, a table, a roof etc. a good developer should understand the programming logic and know how to apply it. Business requirements need to be fulfilled, but it's up to us to decide how to do that. More so, I think it's up to us to push back when we feel business requirements don't make sense from a technical point of view, or even from a business point of view.

Tainnor 6y ago

I find statements such as this to be profoundly anti-intellectual. It suggests that we can't become better at what we do and need to be stuck at the level of "a beginner can understand that". Now, I agree that simplicity is a virtue and that some people go overboard with crazy stuff just because they find it cool. But, as Rich Hickey says, there is a difference between simple and easy. If a junior dev doesn't understand "map", then we should explain them what "map" is, instead of going to back to writing everything with for loops.