4 ms·

> So basically you want to hire non-technology-lovers who simply "GSD" and don't care about things like long term maintainability or test coverage (or test runt

> So basically you want to hire non-technology-lovers who simply "GSD" and don't care about things like long term maintainability or test coverage (or test runtime, or code quality, or...) because at the end of the day that's just added fees you can charge to the client when you have to revisit the codebase in the future. I see. No, you have it exactly wrong. What you describe are good development practices that provide actual long term business value. What you want to avoid is someone saying "yeah I'm excited to use the nested lambdas and variants and callbacks and asynchronous systems" because this shows they just want to play with toys, not solve problems the business has like too many bugs, or slow runtime, or missing features. Engineering is about solving problems, and technologies are tools to solve them.

mynameisvlad 4y ago
> What you want to avoid is someone saying "yeah I'm excited to use the nested lambdas and variants and callbacks and asynchronous systems" because this shows they just want to play with toys, not solve problems the business has like too many bugs, or slow runtime, or missing features. How does that sentence show that, exactly? All it shows is that they're interested in new technologies. That says nothing about whether or not they are interested in "[solving] problems the business has like too many bugs, or slow runtime, or missing features". Those two are not mutually exclusive; one can certainly care about both. Taking it a step further, who gets excited about "[solving] problems the business has like too many bugs, or slow runtime, or missing features". That certainly sounds like what someone would say to please their interviewer more than anything.
- snovv_crash 4y ago
  > How does that sentence show that, exactly? On its own, it doesn't. But if they don't show some interest in what the business is doing as well, it's a red flag, because they will probably end up building something the business doesn't want or need, or fulfill requirements without foresight or understanding into future business direction, but rather based on what they find stimulating (aka more complicated than necessary, at the limits of their understanding). > Taking it a step further, who gets excited about "[solving] problems the business has like too many bugs, or slow runtime, or missing features". That certainly sounds like what someone would say to please their interviewer more than anything. Anybody working in a small team where you have embedded people from all aspects of the business and work together to make the company successful. So, me, and everyone I'm interested in working with? If you're in a giant company and the only satisfaction you can get from your work is the toys you get to play with, to me it's just a sign of corporate disfunction and misalignment between business and engineering.
pmarreck 4y ago
But interestingly, some of those examples you cited are literally solutions to some of the problems you cited, so... For example, a language like Elixir that has "trivial concurrency and immutability" enables a test suite that can run across all of your cores at once and is deterministically guaranteed (assuming you watch how you touch shared mutable state outside that code, such as a database) to not step on itself while doing so. Compare this to any one of a number of mutable languages (such as Ruby) that claim concurrency but in actuality often contain deep software bugs that result in flagging, nondeterministic tests UNLESS they are run single-core. That is absolutely a solved engineering problem that then may prevent other mitigations like having to run the test suite across 25+ cloud machines (in single-core mode) and waiting 25 minutes for a test result before being able to continue, which then directly increases developer productivity. Also, being interested in those 2 things is not mutually-exclusive. I LIKE that this is a tangible business result of a fundamental language design decision.
- mrkurt 4y ago
  If you're after feedback, nothing in this post sounds like a tangible business result to me. It sounds like fun technical wizardry.
  - pmarreck 4y ago
    Being able to run a test suite in parallel on your own machine is massively more useful than having to run it across a bunch of machines in the cloud. First of all, clouds go down (the external-dependency problem), or become unavailable when Internet isn't available (and also cost extra money). Secondly, you get instant (more or less) feedback on whether you broke anything, and that allows you to maintain velocity without having to backpedal. Thirdly, if the suite is run concurrently in a deterministically-random fashion (where it outputs the seed before the suite starts), you can often identify reproducible concurrency bugs that will NOT (or be very unlikely to) show up on your multi-VM cloud test runner (which run all the tests single-threaded on separate machines). Fourthly, if we're talking a functional immutable language, those types of bugs (which are some of the worst and most costly of bugs to track down and fix... I know this from experience, a nondeterministic session-loss bug at Desk that it took me a month to fix likely lost thousands of customers, not to mention the cost of essentially benching me for a month plus the benching cost of the previous devs that took a stab at it and failed) are rarely found to begin with. Every one of these leads to either more productive employees, lower ongoing costs, or happier customers. How are these not tangible business results?

mynameisvlad 4y ago

> What you want to avoid is someone saying "yeah I'm excited to use the nested lambdas and variants and callbacks and asynchronous systems" because this shows they just want to play with toys, not solve problems the business has like too many bugs, or slow runtime, or missing features. How does that sentence show that, exactly? All it shows is that they're interested in new technologies. That says nothing about whether or not they are interested in "[solving] problems the business has like too many bugs, or slow runtime, or missing features". Those two are not mutually exclusive; one can certainly care about both. Taking it a step further, who gets excited about "[solving] problems the business has like too many bugs, or slow runtime, or missing features". That certainly sounds like what someone would say to please their interviewer more than anything.

snovv_crash 4y ago
> How does that sentence show that, exactly? On its own, it doesn't. But if they don't show some interest in what the business is doing as well, it's a red flag, because they will probably end up building something the business doesn't want or need, or fulfill requirements without foresight or understanding into future business direction, but rather based on what they find stimulating (aka more complicated than necessary, at the limits of their understanding). > Taking it a step further, who gets excited about "[solving] problems the business has like too many bugs, or slow runtime, or missing features". That certainly sounds like what someone would say to please their interviewer more than anything. Anybody working in a small team where you have embedded people from all aspects of the business and work together to make the company successful. So, me, and everyone I'm interested in working with? If you're in a giant company and the only satisfaction you can get from your work is the toys you get to play with, to me it's just a sign of corporate disfunction and misalignment between business and engineering.

pmarreck 4y ago

But interestingly, some of those examples you cited are literally solutions to some of the problems you cited, so... For example, a language like Elixir that has "trivial concurrency and immutability" enables a test suite that can run across all of your cores at once and is deterministically guaranteed (assuming you watch how you touch shared mutable state outside that code, such as a database) to not step on itself while doing so. Compare this to any one of a number of mutable languages (such as Ruby) that claim concurrency but in actuality often contain deep software bugs that result in flagging, nondeterministic tests UNLESS they are run single-core. That is absolutely a solved engineering problem that then may prevent other mitigations like having to run the test suite across 25+ cloud machines (in single-core mode) and waiting 25 minutes for a test result before being able to continue, which then directly increases developer productivity. Also, being interested in those 2 things is not mutually-exclusive. I LIKE that this is a tangible business result of a fundamental language design decision.

mrkurt 4y ago
If you're after feedback, nothing in this post sounds like a tangible business result to me. It sounds like fun technical wizardry.
- pmarreck 4y ago
  Being able to run a test suite in parallel on your own machine is massively more useful than having to run it across a bunch of machines in the cloud. First of all, clouds go down (the external-dependency problem), or become unavailable when Internet isn't available (and also cost extra money). Secondly, you get instant (more or less) feedback on whether you broke anything, and that allows you to maintain velocity without having to backpedal. Thirdly, if the suite is run concurrently in a deterministically-random fashion (where it outputs the seed before the suite starts), you can often identify reproducible concurrency bugs that will NOT (or be very unlikely to) show up on your multi-VM cloud test runner (which run all the tests single-threaded on separate machines). Fourthly, if we're talking a functional immutable language, those types of bugs (which are some of the worst and most costly of bugs to track down and fix... I know this from experience, a nondeterministic session-loss bug at Desk that it took me a month to fix likely lost thousands of customers, not to mention the cost of essentially benching me for a month plus the benching cost of the previous devs that took a stab at it and failed) are rarely found to begin with. Every one of these leads to either more productive employees, lower ongoing costs, or happier customers. How are these not tangible business results?