3 ms·

> Over time they lean more and more on that knowledge and the extent of their software development is mostly spotting patterns in the existing codebase and regu

> Over time they lean more and more on that knowledge and the extent of their software development is mostly spotting patterns in the existing codebase and regurgitating those patterns repeatedly. That's what the majority of all the industries on the planet are doing. Repeating the correct patterns in the right place and right time. The value is knowing the right patterns and repeating them at the right time and place. And it makes sense - how many different ways are there to iterate and manipulate a given set of data that contains customer/user records, orders, social post meta or whatever is commonly used in modern tech? Aside from very specialized organizations that are working on the cutting edge of the tech in this or that specific sub-specialization, most of what we are doing is juggling data in the same way everyone does. The chances of anybody bringing a totally new way to juggle that data through exemplary and precise knowledge of the language are ultra slim. And if that ever happens, everyone would soon know and start using that method anyway. Which brings us to the point below: > I'm recruiting problem solvers, and I think it's necessary to understand the tools The problem solvers would know that we are living in 2023, and not only the abstractions that we use, but also the stacks and languages that we use have evolved to handle as much as they can to make our work easier, including data types and their manipulation. The memory space inside a developer's mind that is allocated to knowing those data types and manipulating them manually is memory space that is wasted and not being used for remembering other things and increasing his or her impact. If your logic held out, we would still be manually allocating memory in our programs. We dont. Those who need to know allocating memory on a daily basis and needing to not letting that knowledge atrophy are those who work on hardware, low level hardware-softare interfaces, those who build and maintaing languages, packages, or stacks for industry-wide use. Not the developer who solves !business! problems. > Frankly, I think developers are getting good at combining Google search results into a codebase that reads more like a ransom note of copied-and-pasted snippets than a deliberate engineering effort Yes. And that's what enables them to take on the ownership of increasingly broader features and systems. In the same way it enables even fewer founders to bootstrap or launch more complex startups. Everything we do in tech is for automating, optimizing and making easier a given level of problems to be able to rely on that automation to move on to the next level. > Sure, tools and language (e.g. Javascript) often abstracts much of the details away Yes. They do. Every stack, language, framework does. That's what amplifies productivity. Not holding on to knowledge you will rarely ever use. ... The difficulty of modern tech is in creating reliable, user-friendly and cheap systems that bring advanced technology to the masses. Anything that prioritizes specialized knowledge on what is already handled by the existing technology stack is more academic than anything practically engineering related. Such approaches could exist inside gigantic old-school organizations like IBM when they had their heyday, and they did exist inside tech gians which literally made themselves a continuation of the colleges which their founders graduated from, fueled and floated by zero-interest investor money, prioritizing only 'growth' without paying attention to the business fundamentals. But in the new, non-zero-interest economy, they can hardly be justified.

trentnix 4y ago
> The value is knowing the right patterns and repeating them at the right time and place. And that discernment, at least in part, comes from understanding what that code is really doing. I get 45 minutes face-to-face to develop an opinion as to whether or not a candidate can do the job well. I value candidates who’ve not only asked “what?” but have also asked “why?” I’ve no doubt my approach has filtered out people who would have done good work. I’ve certainly passed people through that didn’t work out for various reasons. But generally, my approach has served me well so far.
- unity1001 4y ago
  > comes from understanding what that code is really doing It does come from understanding the !business code! that is involved. Not the rarely important features of the underlying language that the stack, the framework or the models handle. Which makes that argument further moot - you should not be messing with how the models or the framework handle those data types. There is a reason why they were built and deployed.

trentnix 4y ago

> The value is knowing the right patterns and repeating them at the right time and place. And that discernment, at least in part, comes from understanding what that code is really doing. I get 45 minutes face-to-face to develop an opinion as to whether or not a candidate can do the job well. I value candidates who’ve not only asked “what?” but have also asked “why?” I’ve no doubt my approach has filtered out people who would have done good work. I’ve certainly passed people through that didn’t work out for various reasons. But generally, my approach has served me well so far.

unity1001 4y ago
> comes from understanding what that code is really doing It does come from understanding the !business code! that is involved. Not the rarely important features of the underlying language that the stack, the framework or the models handle. Which makes that argument further moot - you should not be messing with how the models or the framework handle those data types. There is a reason why they were built and deployed.