4 ms·

> There are developers great at solving business problems, which is what the vast majority of companies actually want. Many developers find themselves in a pos

> There are developers great at solving business problems, which is what the vast majority of companies actually want. Many developers find themselves in a position of being a subject matter expert in a particular business or industry, and that becomes the primary value they deliver. They remember where that error message originates or why that column in the database is named so strangely. They know the lingo and business quirks inherent to their industry. 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. Their programming muscles atrophy while their subject matter expertise grows. But that knowledge doesn't always transfer well. I've fallen prey to this trap (personally) on more than one occasion, getting lost in what I was doing instead of seeking to better understand what I do. > What are you recruiting? Language experts, or coding experts? As you seem to be confusing the two. I'm recruiting problem solvers, and I think it's necessary to understand the tools you are using to solve problems at least one level deeper than autocomplete shows. 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. When I ask a candidate to convert an input string of digits to its output integer (e.g. "001234500" to 1234500) equivalent and they don't seem to discern that's an important distinction, it raises red flags. Sure, tools and language (e.g. Javascript) often abstracts much of the details away, but my experience is that those developers with a familiarity of those details and why they matter (even if they might need an occasional reminder from a search engine) are a cut above.

justhadtoo 4y ago
> When I ask a candidate to convert an input string of digits to its output integer (e.g. "001234500" to 1234500) equivalent and they don't seem to discern that's an important distinction, it raises red flags. Why do you feel this is important? To clarify, what are you testing here?
- layer8 4y ago
  It’s important because "001234500" and "01234500" are two strings that don’t compare equal (and that sort in a specific way), but after conversion to an integer they do compare equal. When you use such a value as an ID, for example, the type you use makes an important difference here. It shows that you understand how equality relates to values and data types, and that changing the type of something can make the same conceptual operation behave differently. This is the kind of fundamental technical understanding and precise thinking you want a developer to be absolutely familiar with.
  - mattmanser 4y ago
    Actually, in the old days a string number with a leading 0 in javascript got parsed as an octal. You used to have to do parseInt('0012345', 10) to get it to parse properly. That's what I assume the GP is referring to. They changed it in ECMAScript 5. More details here: https://eslint.org/docs/latest/rules/radix https://eslint.org/docs/latest/rules/radix
    - sdf4j 4y ago
      Faced a similar issue in Java. Someone decided it was a good idea to convert string postal codes to int. For sorting... Using Integer.decode()... Everything was ok until a "09677" show up.
unity1001 4y ago
> 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.

justhadtoo 4y ago

> When I ask a candidate to convert an input string of digits to its output integer (e.g. "001234500" to 1234500) equivalent and they don't seem to discern that's an important distinction, it raises red flags. Why do you feel this is important? To clarify, what are you testing here?

layer8 4y ago
It’s important because "001234500" and "01234500" are two strings that don’t compare equal (and that sort in a specific way), but after conversion to an integer they do compare equal. When you use such a value as an ID, for example, the type you use makes an important difference here. It shows that you understand how equality relates to values and data types, and that changing the type of something can make the same conceptual operation behave differently. This is the kind of fundamental technical understanding and precise thinking you want a developer to be absolutely familiar with.
- mattmanser 4y ago
  Actually, in the old days a string number with a leading 0 in javascript got parsed as an octal. You used to have to do parseInt('0012345', 10) to get it to parse properly. That's what I assume the GP is referring to. They changed it in ECMAScript 5. More details here: https://eslint.org/docs/latest/rules/radix https://eslint.org/docs/latest/rules/radix
  - sdf4j 4y ago
    Faced a similar issue in Java. Someone decided it was a good idea to convert string postal codes to int. For sorting... Using Integer.decode()... Everything was ok until a "09677" show up.

unity1001 4y ago

> 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.