> When you enter a new company with a large codebase that you have to ramp up on, you're not only required to learn the language or 3rd party frameworks and libraries that they use ... you need to ramp up on THEIR "framework."
I think you could turn the responsibility the other way around quite as easily, and I think you're mistaken grown complexity, one that is inherent in a company's system (accidental or not), when you outline what you mean as "framework" here.
Frameworks are documented building blocks, so are programming languages and libraries - those things are meant to be used as foundations and are designed with the thought that anyone could ramp up with progress easily. If they wouldn't be documented in a somewhat usable form, then there is a high chance that they wouldn't be used as building blocks in the first place. Companies are nothing like that(!), be it because their inherent system has not been designed as useful tool (that's the focus of their products after all), be it because their projects haven't been created out of passion and just need to bring in some money, or be it because of multiple other reasons I could mention.
In every company I've had the pleasure to be joining so far, I've always encountered that something (even sometimes more) gets written from scratch and will just stay undocumented (even untested). If a company is anything but a hobby project there is always this overload on tooling, because someone wanted to dabble in ___domain A but didn't want to learn building block A, so they just put building block B also into ___domain A, or even introduced their new interest: building block C - NIH[0] is also a real thing. We humans have a very short attention span and are surprisingly overconfident when it comes to the design of complex systems. It's also significant harder to read code than it is to write code yourself, and if you had the luxury to grow with the codebase of a company, then you'll also show a natural tendency to just overlook some of its inherent complexity. And those are just the technical aspects of it all, mind you. There are social, cultural and economic changes in each company that affects its complexity just as well (going from MVP to sustainable product, CRMs, outsourcing etc.).
> Every business, but some more so than others, has time pressure. [...] If you come into a company unfamiliar with the languages and tools that they use, you are essentially coming in handicapped.
The true capital of a company is its people. If you have the chance to bring someone in that you'll trust wholeheartedly, then that's a huge gain for the whole team and even outlives any visionary business prospects of any kind.
> All problems are people problems.
Agree!
> It's not that the company needs people who know how to code in the language or tool ... they need someone who has worked on enough different projects with that tool that they can navigate the completely fucked up ways that THIS company uses it.
Here's the interesting bit: If this candidate would have already learned that their tool of choice is used in a fucked up way in THAT company, then what incentive would the candidate have to join THAT company in the first place? Is that company even fully aware of its fucked up usage of that tool?
Tools need to be learned for problems to be solved. This hypothetical candidate might have learned enough already and would like to focus on the problem at hand, but now has to deal with the annoyances of "making the fucked up state visible" instead. Or, considering the fucked up state is already well recognized, now just needs to do what feels like chores before it gets interesting again, but doesn't want to live with the fucked up usage in THAT company.
> The company doesn't need someone who can write the Hello World tutorial in the language or framework, they need someone who can evaluate the good decisions vs the bad ones in an existing codebase.
Agree, and that somehow contradicts everything you wrote previously.
> I think you could turn the responsibility the other way around quite as easily, and I think you're mistaken grown complexity, one that is inherent in a company's system (accidental or not), when you outline what you mean as "framework" here.
No I'm not. I'm not reading the rest of your reply because you completely misunderstood me here and then proceeded to give me an insulting definition of what a framework means while completely ignoring the broader point I was trying to make.
In fact, I did the following to add clarity:
1. I put the word "framework" in quotes to make it clear that I was using the term colloquially
2. I elaborated that I was talking about custom supporting code and other tooling that was developed by the company in order to solve ___domain-specific problems.
I have built frameworks. I continue to build frameworks for my employer on a Platform team. We work with 3rd party frameworks and we need to build on our own. This is just normal encapsulation, building higher level APIs on top of lower level ones.
So when I say "the company's framework" I'm referring to the stuff that was buit in house in order order to develop highly ___domain specific functionality with a higher level API than what the 3rd party frameworks are providing out of the box.
A framework's super-power is that it applies the Holly Principle: don't call us, we'll call you. That's what distinguishes a framework from a library. Libraries sit there passively waiting for you to consume them. But in our industry, like the word "hacker" and "troll"... people start using the term colloquially. And in this case we're talking about the specific APIs that the company has developed which you need to ramp up on even if you are highly experienced in the specific 3rd party frameworks that they use.
And even if we take the word framework absolutely literally as you did in your comment, companies still build "literal frameworks" internally in order to try and simplify. But you gotta ramp up on those.
At my existing employer, we have even taken 3rd party frameworks and libraries, and forked them and developed our existing custom tooling with them because our ___domain specific requirements brought us to that level. So now you're coming in to our shop not only needing to ramp up on those 3rd party frameworks, but you gotta learn and understand how we changed them too for our purposes.
I think you could turn the responsibility the other way around quite as easily, and I think you're mistaken grown complexity, one that is inherent in a company's system (accidental or not), when you outline what you mean as "framework" here.
Frameworks are documented building blocks, so are programming languages and libraries - those things are meant to be used as foundations and are designed with the thought that anyone could ramp up with progress easily. If they wouldn't be documented in a somewhat usable form, then there is a high chance that they wouldn't be used as building blocks in the first place. Companies are nothing like that(!), be it because their inherent system has not been designed as useful tool (that's the focus of their products after all), be it because their projects haven't been created out of passion and just need to bring in some money, or be it because of multiple other reasons I could mention.
In every company I've had the pleasure to be joining so far, I've always encountered that something (even sometimes more) gets written from scratch and will just stay undocumented (even untested). If a company is anything but a hobby project there is always this overload on tooling, because someone wanted to dabble in ___domain A but didn't want to learn building block A, so they just put building block B also into ___domain A, or even introduced their new interest: building block C - NIH[0] is also a real thing. We humans have a very short attention span and are surprisingly overconfident when it comes to the design of complex systems. It's also significant harder to read code than it is to write code yourself, and if you had the luxury to grow with the codebase of a company, then you'll also show a natural tendency to just overlook some of its inherent complexity. And those are just the technical aspects of it all, mind you. There are social, cultural and economic changes in each company that affects its complexity just as well (going from MVP to sustainable product, CRMs, outsourcing etc.).
> Every business, but some more so than others, has time pressure. [...] If you come into a company unfamiliar with the languages and tools that they use, you are essentially coming in handicapped.
The true capital of a company is its people. If you have the chance to bring someone in that you'll trust wholeheartedly, then that's a huge gain for the whole team and even outlives any visionary business prospects of any kind.
> All problems are people problems.
Agree!
> It's not that the company needs people who know how to code in the language or tool ... they need someone who has worked on enough different projects with that tool that they can navigate the completely fucked up ways that THIS company uses it.
Here's the interesting bit: If this candidate would have already learned that their tool of choice is used in a fucked up way in THAT company, then what incentive would the candidate have to join THAT company in the first place? Is that company even fully aware of its fucked up usage of that tool?
Tools need to be learned for problems to be solved. This hypothetical candidate might have learned enough already and would like to focus on the problem at hand, but now has to deal with the annoyances of "making the fucked up state visible" instead. Or, considering the fucked up state is already well recognized, now just needs to do what feels like chores before it gets interesting again, but doesn't want to live with the fucked up usage in THAT company.
> The company doesn't need someone who can write the Hello World tutorial in the language or framework, they need someone who can evaluate the good decisions vs the bad ones in an existing codebase.
Agree, and that somehow contradicts everything you wrote previously.
[0]: https://en.wikipedia.org/wiki/Not_invented_here