diff options
Diffstat (limited to 'src/content/blog/2020/10')
| -rw-r--r-- | src/content/blog/2020/10/05/cargo2nix-demo.tar.gz | bin | 59565 -> 0 bytes | |||
| -rw-r--r-- | src/content/blog/2020/10/05/cargo2nix.adoc | 72 | ||||
| -rw-r--r-- | src/content/blog/2020/10/05/cargo2nix.tar.gz | bin | 53327 -> 0 bytes | |||
| -rw-r--r-- | src/content/blog/2020/10/05/swift2nix-demo.tar.gz | bin | 61691 -> 0 bytes | |||
| -rw-r--r-- | src/content/blog/2020/10/05/swift2nix.adoc | 194 | ||||
| -rw-r--r-- | src/content/blog/2020/10/05/swift2nix.tar.gz | bin | 57917 -> 0 bytes | |||
| -rw-r--r-- | src/content/blog/2020/10/19/feature-flags.adoc | 306 | ||||
| -rw-r--r-- | src/content/blog/2020/10/20/wrong-interviewing.adoc | 340 |
8 files changed, 0 insertions, 912 deletions
diff --git a/src/content/blog/2020/10/05/cargo2nix-demo.tar.gz b/src/content/blog/2020/10/05/cargo2nix-demo.tar.gz Binary files differdeleted file mode 100644 index 43677ec..0000000 --- a/src/content/blog/2020/10/05/cargo2nix-demo.tar.gz +++ /dev/null diff --git a/src/content/blog/2020/10/05/cargo2nix.adoc b/src/content/blog/2020/10/05/cargo2nix.adoc deleted file mode 100644 index a2d478e..0000000 --- a/src/content/blog/2020/10/05/cargo2nix.adoc +++ /dev/null @@ -1,72 +0,0 @@ -= cargo2nix: Dramatically simpler Rust in Nix -:sort: 1 - -:empty: -:swift2nix: link:swift2nix.html -:cargo2nix: link:cargo2nix-demo.tar.gz - -In the same vein of my earlier post on {swift2nix}[swift2nix], I was able to -quickly prototype a Rust and Cargo variation of it: {cargo2nix}[cargo2nix]. - -The initial prototype is even smaller than swift2nix: it has only 37 lines of -code. - -Here's how to use it (snippet taken from the repo's README): - -[source,nix] ----- -let - niv-sources = import ./nix/sources.nix; - mozilla-overlay = import niv-sources.nixpkgs-mozilla; - pkgs = import niv-sources.nixpkgs { overlays = [ mozilla-overlay ]; }; - src = pkgs.nix-gitignore.gitignoreSource [ ] ./.; - cargo2nix = pkgs.callPackage niv-sources.cargo2nix { - lockfile = ./Cargo.lock; - }; -in pkgs.stdenv.mkDerivation { - inherit src; - name = "cargo-test"; - buildInputs = [ pkgs.latest.rustChannels.nightly.rust ]; - phases = [ "unpackPhase" "buildPhase" ]; - buildPhase = '' - # Setup dependencies path to satisfy Cargo - mkdir .cargo/ - ln -s ${cargo2nix.env.cargo-config} .cargo/config - ln -s ${cargo2nix.env.vendor} vendor - - # Run the tests - cargo test - touch $out - ''; -} ----- - -That `cargo test` part on line 20 is what I have been fighting with every -"*2nix" available for Rust out there. I don't want to bash any of them. All I -want is to have full control of what Cargo commands to run, and the "*2nix" tool -should only setup the environment for me. Let me drive Cargo myself, no need to -parameterize how the tool runs it for me, or even replicate its internal -behaviour by calling the Rust compiler directly. - -Sure it doesn't support private registries or Git dependencies, but how much -bigger does it has to be to support them? Also, it doesn't support those *yet*, -there's no reason it can't be extended. I just haven't needed it yet, so I -haven't added. Patches welcome. - -The layout of the `vendor/` directory is more explicit and public then what -swift2nix does: it is whatever the command `cargo vendor` returns. However I -haven't checked if the shape of the `.cargo-checksum.json` is specified, or -internal to Cargo. - -Try out the demo (also taken from the repo's README): - -[source,sh] ----- -pushd "$(mktemp -d)" -wget -O- https://euandre.org/static/attachments/cargo2nix-demo.tar.gz | - tar -xv -cd cargo2nix-demo/ -nix-build ----- - -Report back if you wish. diff --git a/src/content/blog/2020/10/05/cargo2nix.tar.gz b/src/content/blog/2020/10/05/cargo2nix.tar.gz Binary files differdeleted file mode 100644 index d7224d9..0000000 --- a/src/content/blog/2020/10/05/cargo2nix.tar.gz +++ /dev/null diff --git a/src/content/blog/2020/10/05/swift2nix-demo.tar.gz b/src/content/blog/2020/10/05/swift2nix-demo.tar.gz Binary files differdeleted file mode 100644 index cc8b4f1..0000000 --- a/src/content/blog/2020/10/05/swift2nix-demo.tar.gz +++ /dev/null diff --git a/src/content/blog/2020/10/05/swift2nix.adoc b/src/content/blog/2020/10/05/swift2nix.adoc deleted file mode 100644 index 9a3c6fe..0000000 --- a/src/content/blog/2020/10/05/swift2nix.adoc +++ /dev/null @@ -1,194 +0,0 @@ -= swift2nix: Run Swift inside Nix builds -:sort: 0 - -:empty: -:nix: https://nixos.org/ -:swift2nix: link:swift2nix.tar.gz - -While working on a Swift project, I didn't find any tool that would allow Swift -to run inside {nix}[Nix] builds. Even thought you _can_ run Swift, the real -problem arises when using the package manager. It has many of the same problems -that other package managers have when trying to integrate with Nix, more on this -below. - -I wrote a simple little tool called {swift2nix}[swift2nix] that allows you trick -Swift's package manager into assuming everything is set up. Here's the example -from swift2nix's README file: - -[source,nix] ----- -let - niv-sources = import ./nix/sources.nix; - pkgs = import niv-sources.nixpkgs { }; - src = pkgs.nix-gitignore.gitignoreSource [ ] ./.; - swift2nix = pkgs.callPackage niv-sources.swift2nix { - package-resolved = ./Package.resolved; - }; -in pkgs.stdenv.mkDerivation { - inherit src; - name = "swift-test"; - buildInputs = with pkgs; [ swift ]; - phases = [ "unpackPhase" "buildPhase" ]; - buildPhase = '' - # Setup dependencies path to satisfy SwiftPM - mkdir .build - ln -s ${swift2nix.env.dependencies-state-json} .build/dependencies-state.json - ln -s ${swift2nix.env.checkouts} .build/checkouts - - # Run the tests - swift test - touch $out - ''; -} ----- - -The key parts are lines 15~17: we just fake enough files inside `.build/` that -Swift believes it has already downloaded and checked-out all dependencies, and -just moves on to building them. - -I've worked on it just enough to make it usable for myself, so beware of -unimplemented cases. - -== Design - -What swift2nix does is just provide you with the bare minimum that Swift -requires, and readily get out of the way: - -. I explicitly did not want to generated a `Package.nix` file, since - `Package.resolved` already exists and contains the required information; -. I didn't want to have an "easy" interface right out of the gate, after - fighting with "*2nix" tools that focus too much on that. - -The final actual code was so small (46 lines) that it made me think about -package managers, "*2nix" tools and some problems with many of them. - -== Problems with package managers - -I'm going to talk about solely language package managers. Think npm and cargo, -not apt-get. - -Package managers want to do too much, or assume too much, or just want to take -control of the entire build of the dependencies. - -This is a recurrent problem in package managers, but I don't see it as an -intrinsic one. There's nothing about a "package manager" that prevents it from -_declaring_ what it expects to encounter and in which format. The _declaring_ -part is important: it should be data, not code, otherwise you're back in the -same problem, just like lockfiles are just data. Those work in any language, -and tools can cooperate happily. - -There's no need for this declarative expectation to be standardized, or be made -compatible across languages. That would lead to a poor format that no package -manager really likes. Instead, If every package manager could say out loud what -it wants to see exactly, than more tools like swift2nix could exist, and they -would be more reliable. - -This could even work fully offline, and be simply a mapping from the lockfile -(the `Package.resolved` in Swift's case) to the filesystem representation. For -Swift, the `.build/dependencies-state.json` comes very close, but it is internal -to the package manager. - -Even though this pain only exists when trying to use Swift inside Nix, it sheds -light into this common implicit coupling that package managers have. They -usually have fuzzy boundaries and tight coupling between: - -. resolving the dependency tree and using some heuristic to pick a package - version; -. generating a lockfile with the exact pinned versions; -. downloading the dependencies present on the lockfile into some local cache; -. arranging the dependencies from the cache in a meaningful way for itself - inside the project; -. work using the dependencies while _assuming_ that step 4 was done. - -When you run `npm install` in a repository with no lockfile, it does 1~4. If -you do the same with `cargo build`, it does 1~5. That's too much: many of those -assumptions are implicit and internal to the package manager, and if you ever -need to rearrange them, you're on your own. Even though you can perform some of -those steps, you can't compose or rearrange them. - -Instead a much saner approach could be: - -. this stays the same; -. this also stays the same; -. be able to generate some JSON/TOML/edn which represents the local expected - filesystem layout with dependencies (i.e. exposing what the package manager - expects to find), let's call it `local-registry.json`; -. if a `local-registry.json` was provided, do a build using that. Otherwise - generate its own, by downloading the dependencies, arranging them, _etc._ - -The point is just making what the package manager requires visible to the -outside world via some declarative data. If this data wasn't provided, it can -move on to doing its own automatic things. - -By making the expectation explicit and public, one can plug tools _à la carte_ -if desired, but doesn't prevent the default code path of doing things the exact -same way they are now. - -== Problems with "*2nix" tools - -:node2nix: https://github.com/svanderburg/node2nix - -I have to admit: I'm unhappy with most of they. - -They conflate "using Nix" with "replicating every command of the package manager -inside Nix". - -The avoidance of an "easy" interface that I mentioned above comes from me -fighting with some of the "*2nix" tools much like I have to fight with package -managers: I don't want to offload all build responsibilities to the "*2nix" -tool, I just want to let it download some of the dependencies and get out of the -way. I want to stick with `npm test` or `cargo build`, and Nix should only -provide the environment. - -This is something that {node2nix}[node2nix] does right. It allows you to build -the Node.js environment to satisfy NPM, and you can keep using NPM for -everything else: - -[source,sh] ----- -ln -s ${node2nix-package.shell.nodeDependencies}/lib/node_modules ./node_modules -npm test ----- - -Its natural to want to put as much things into Nix as possible to benefit from -Nix's advantages. Isn't that how NixOS itself was born? - -But a "*2nix" tool should leverage Nix, not be coupled with it. The above -example lets you run any arbitrary NPM command while profiting from isolation -and reproducibility that Nix provides. It is even less brittle: any changes to -how NPM runs some things will be future-compatible, since node2nix isn't trying -to replicate what NPM does, or fiddling with NPM's internal. - -**A "*2nix" tool should build the environment, preferably from the lockfile -directly and offload everything else to the package manager**. The rest is just -nice-to-have. - -swift2nix itself could provide an "easy" interface, something that allows you to -write: - -[source,sh] ----- -nix-build -A swift2nix.release -nix-build -A swift2nix.test ----- - -The implementation of those would be obvious: create a new -`pkgs.stdenv.mkDerivation` and call `swift build -c release` and `swift test` -while using `swift2nix.env` under the hood. - -== Conclusion - -Package managers should provide exact dependencies via a data representation, -i.e. lockfiles, and expose via another data representation how they expect those -dependencies to appear on the filesystem, i.e. `local-registry.json`. This -allows package managers to provide an API so that external tools can create -mirrors, offline builds, other registries, isolated builds, _etc._ - -"*2nix" tools should build simple functions that leverage that -`local-registry.json`{empty}footnote:local-registry[ - This `local-registry.json` file doesn't have to be checked-in the repository - at all. It could be always generated on the fly, much like how Swift's - `dependencies-state.json` is. -] data and offload all the rest back to the package manager itself. This allows -the "*2nix" to not keep chasing the package manager evolution, always trying to -duplicate its behaviour. diff --git a/src/content/blog/2020/10/05/swift2nix.tar.gz b/src/content/blog/2020/10/05/swift2nix.tar.gz Binary files differdeleted file mode 100644 index a22aaa0..0000000 --- a/src/content/blog/2020/10/05/swift2nix.tar.gz +++ /dev/null diff --git a/src/content/blog/2020/10/19/feature-flags.adoc b/src/content/blog/2020/10/19/feature-flags.adoc deleted file mode 100644 index 972f693..0000000 --- a/src/content/blog/2020/10/19/feature-flags.adoc +++ /dev/null @@ -1,306 +0,0 @@ -= Feature flags: differences between backend, frontend and mobile -:categories: presentation -:updatedat: 2020-11-03 - -:empty: -:slides: link:../../../../slides/2020/10/19/feature-flags.html FIXME -:fowler-article: https://martinfowler.com/articles/feature-toggles.html - -_This article is derived from a {slides}[presentation] on the same subject._ - -When discussing about feature flags, I find that their costs and benefits are -often well exposed and addressed. Online articles like -"{fowler-article}[Feature Toggle (aka Feature Flags)]" do a great job of -explaining them in detail, giving great general guidance of how to apply -techniques to adopt it. - -However the weight of those costs and benefits apply differently on backend, -frontend or mobile, and those differences aren't covered. In fact, many of them -stop making sense, or the decision of adopting a feature flag or not may change -depending on the environment. - -In this article I try to make the distinction between environments and how -feature flags apply to them, with some final best practices I've acquired when -using them in production. - -== Why feature flags - -:atlassian-cicd: https://www.atlassian.com/continuous-delivery/principles/continuous-integration-vs-delivery-vs-deployment - -Feature flags in general tend to be cited on the context of -{atlassian-cicd}[continuous deployment]: - -____ -A: With continuous deployment, you deploy to production automatically - -B: But how do I handle deployment failures, partial features, _etc._? - -A: With techniques like canary, monitoring and alarms, feature flags, _etc._ -____ - -Though adopting continuous deployment doesn't force you to use feature flags, it -creates a demand for it. The inverse is also true: using feature flags on the -code points you more obviously to continuous deployment. Take the following -code sample for example, that we will reference later on the article: - -[source,javascript] ----- -function processTransaction() { - validate(); - persist(); - // TODO: add call to notifyListeners() -} ----- - -While being developed, being tested for suitability or something similar, -`notifyListeners()` may not be included in the code at once. So instead of -keeping it on a separate, long-lived branch, a feature flag can decide when the -new, partially implemented function will be called: - -[source,javascript] ----- -function processTransaction() { - validate(); - persist(); - if (featureIsEnabled("activate-notify-listeners")) { - notifyListeners(); - } -} ----- - -This allows your code to include `notifyListeners()`, and decide when to call it -at runtime. For the price of extra things around the code, you get more -dynamicity. - -So the fundamental question to ask yourself when considering adding a feature -flag should be: - -____ -Am I willing to pay with code complexity to get dynamicity? -____ - -It is true that you can make the management of feature flags as straightforward -as possible, but having no feature flags is simpler than having any. What you -get in return is the ability to parameterize the behaviour of the application at -runtime, without doing any code changes. - -Sometimes this added complexity may tilt the balance towards not using a feature -flag, and sometimes the flexibility of changing behaviour at runtime is -absolutely worth the added complexity. This can vary a lot by code base, -feature, but fundamentally by environment: its much cheaper to deploy a new -version of a service than to release a new version of an app. - -So the question of which environment is being targeted is key when reasoning -about costs and benefits of feature flags. - -== Control over the environment - -:fdroid: https://f-droid.org/ -:bad-apple: https://www.paulgraham.com/apple.html - -The key differentiator that makes the trade-offs apply differently is how much -control you have over the environment. - -When running a *backend* service, you usually are paying for the servers -themselves, and can tweak them as you wish. This means you have full control do -to code changes as you wish. Not only that, you decide when to do it, and for -how long the transition will last. - -On the *frontend* you have less control: even though you can choose to make a -new version available any time you wish, you can't -force{empy}footnote:force[ - Technically you could force a reload with JavaScript using - `window.location.reload()`, but that not only is invasive and impolite, but - also gives you the illusion that you have control over the client when you - actually don't: clients with disabled JavaScript would be immune to such - tactics. -] clients to immediately switch to the new version. That means that a) clients -could skip upgrades at any time and b) you always have to keep backward and -forward compatibility in mind. - -Even though I'm mentioning frontend directly, it applies to other environment -with similar characteristics: desktop applications, command-line programs, -_etc_. - -On *mobile* you have even less control: app stores need to allow your app to be -updated, which could bite you when least desired. Theoretically you could make -you APK available on third party stores like {fdroid}[F-Droid], or even make the -APK itself available for direct download, which would give you the same -characteristics of a frontend application, but that happens less often. - -On iOS you can't even do that. You have to get Apple's blessing on every single -update. Even though we already know that is a {bad-apple}[bad idea] for over a -decade now, there isn't a way around it. This is where you have the least -control. - -In practice, the amount of control you have will change how much you value -dynamicity: the less control you have, the more valuable it is. In other words, -having a dynamic flag on the backend may or may not be worth it since you could -always update the code immediately after, but on iOS it is basically always -worth it. - -== Rollout - -:kubernetes-deployment: https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#creating-a-deployment -:play-store-rollout: https://support.google.com/googleplay/android-developer/answer/6346149?hl=en -:app-store-rolllout: https://help.apple.com/app-store-connect/#/dev3d65fcee1 - -A rollout is used to _roll out_ a new version of software. - -They are usually short-lived, being relevant as long as the new code is being -deployed. The most common rule is percentages. - -On the *backend*, it is common to find it on the deployment infrastructure -itself, like canary servers, blue/green deployments, {kubernetes-deployment}[a -kubernetes deployment rollout], _etc_. You could do those manually, by having a -dynamic control on the code itself, but rollbacks are cheap enough that people -usually do a normal deployment and just give some extra attention to the metrics -dashboard. - -Any time you see a blue/green deployment, there is a rollout happening: most -likely a load balancer is starting to direct traffic to the new server, until -reaching 100% of the traffic. Effectively, that is a rollout. - -On the *frontend*, you can selectively pick which user's will be able to -download the new version of a page. You could use geographical region, IP, -cookie or something similar to make this decision. - -CDN propagation delays and people not refreshing their web pages are also -rollouts by themselves, since old and new versions of the software will coexist. - -On *mobile*, the Play Store allows you to perform fine-grained -{play-store-rollout}[staged rollouts], and the App Store allows you to perform -limited {app-store-rollout}[phased releases]. - -Both for Android and iOS, the user plays the role of making the download. - -In summary: since you control the servers on the backend, you can do rollouts at -will, and those are often found automated away in base infrastructure. On the -frontend and on mobile, there are ways to make new versions available, but users -may not download them immediately, and many different versions of the software -end up coexisting. - -== Feature flag - -A feature flag is a _flag_ that tells the application on runtime to turn on or -off a given _feature_. That means that the actual production code will have -more than one possible code paths to go through, and that a new version of a -feature coexists with the old version. The feature flag tells which part of the -code to go through. - -They are usually medium-lived, being relevant as long as the new code is being -developed. The most common rules are percentages, allow/deny lists, A/B groups -and client version. - -On the *backend*, those are useful for things that have a long development -cycle, or that needs to done by steps. Consider loading the feature flag rules -in memory when the application starts, so that you avoid querying a database or -an external service for applying a feature flag rule and avoid flakiness on the -result due to intermittent network failures. - -Since on the *frontend* you don't control when to update the client software, -you're left with applying the feature flag rule on the server, and exposing the -value through an API for maximum dynamicity. This could be in the frontend code -itself, and fallback to a "just refresh the page"/"just update to the latest -version" strategy for less dynamic scenarios. - -On *mobile* you can't even rely on a "just update to the latest version" -strategy, since the code for the app could be updated to a new feature and be -blocked on the store. Those cases aren't recurrent, but you should always -assume the store will deny updates on critical moments so you don't find -yourself with no cards to play. That means the only control you actually have -is via the backend, by parameterizing the runtime of the application using the -API. In practice, you should always have a feature flag to control any relevant -piece of code. There is no such thing as "too small code change for a feature -flag". What you should ask yourself is: - -____ -If the code I'm writing breaks and stays broken for around a month, do I care? -____ - -If you're doing an experimental screen, or something that will have a very small -impact you might answer "no" to the above question. For everything else, the -answer will be "yes": bug fixes, layout changes, refactoring, new screen, -filesystem/database changes, _etc_. - -== Experiment - -An experiment is a feature flag where you care about analytical value of the -flag, and how it might impact user's behaviour. A feature flag with analytics. - -They are also usually medium-lived, being relevant as long as the new code is -being developed. The most common rule is A/B test. - -On the *backend*, an experiment rely on an analytical environment that will pick -the A/B test groups and distributions, which means those can't be held in memory -easily. That also means that you'll need a fallback value in case fetching the -group for a given customer fails. - -On the *frontend* and on *mobile* they are no different from feature flags. - -== Operational toggle - -An operational toggle is like a system-level manual circuit breaker, where you -turn on/off a feature, fail over the load to a different server, _etc_. They -are useful switches to have during an incident. - -They are usually long-lived, being relevant as long as the code is in -production. The most common rule is percentages. - -They can be feature flags that are promoted to operational toggles on the -*backend*, or may be purposefully put in place preventively or after a -postmortem analysis. - -On the *frontend* and on *mobile* they are similar to feature flags, where the -"feature" is being turned on and off, and the client interprets this value to -show if the "feature" is available or unavailable. - -== Best practices - -=== Prefer dynamic content - -Even though feature flags give you more dynamicity, they're still somewhat -manual: you have to create one for a specific feature and change it by hand. - -If you find yourself manually updating a feature flags every other day, or -tweaking the percentages frequently, consider making it fully dynamic. Try -using a dataset that is generated automatically, or computing the content on the -fly. - -Say you have a configuration screen with a list of options and sub-options, and -you're trying to find how to better structure this list. Instead of using a -feature flag for switching between 3 and 5 options, make it fully dynamic. This -way you'll be able to perform other tests that you didn't plan, and get more -flexibility out of it. - -=== Use the client version to negotiate feature flags - -After effectively finishing a feature, the old code that coexisted with the new -one will be deleted, and all traces of the transition will vanish from the code -base. However if you just remove the feature flags from the API, all of the old -versions of clients that relied on that value to show the new feature will go -downgrade to the old feature. - -This means that you should avoid deleting client-facing feature flags, and -retire them instead: use the client version to decide when the feature is -stable, and return `true` for every client with a version greater or equal to -that. This way you can stop thinking about the feature flag, and you don't -break or downgrade clients that didn't upgrade past the transition. - -=== Beware of many nested feature flags - -Nested flags combine exponentially. - -Pick strategic entry points or transitions eligible for feature flags, and -beware of their nesting. - -=== Include feature flags in the development workflow - -Add feature flags to the list of things to think about during whiteboarding, and -deleting/retiring a feature flags at the end of the development. - -=== Always rely on a feature flag on the app - -Again, there is no such thing "too small for a feature flag". Too many feature -flags is a good problem to have, not the opposite. Automate the process of -creating a feature flag to lower its cost. diff --git a/src/content/blog/2020/10/20/wrong-interviewing.adoc b/src/content/blog/2020/10/20/wrong-interviewing.adoc deleted file mode 100644 index 4b8d855..0000000 --- a/src/content/blog/2020/10/20/wrong-interviewing.adoc +++ /dev/null @@ -1,340 +0,0 @@ -= How not to interview engineers -:updatedat: 2020-10-24 - -:bad-article: https://defmacro.substack.com/p/how-to-interview-engineers -:satire-comment: https://defmacro.substack.com/p/how-to-interview-engineers/comments#comment-599996 -:double-down: https://twitter.com/spakhm/status/1315754730740617216 -:poes-law: https://en.wikipedia.org/wiki/Poe%27s_law -:hn-comment-1: https://news.ycombinator.com/item?id=24757511 - -This is a response to Slava's "{bad-article}[How to interview engineers]" -article. I initially thought it was a satire, {satire-comment}[as have others], -but he has [doubled down on it]: - -____ -(...) Some parts are slightly exaggerated for sure, but the essay isn't meant as -a joke. -____ - -That being true, he completely misses the point on how to improve hiring, and -proposes a worse alternative on many aspects. It doesn't qualify as -provocative, it is just wrong. - -I was comfortable taking it as a satire, and I would just ignore the whole thing -if it wasn't (except for the technical memo part), but friends of mine -considered it to be somewhat reasonable. This is a adapted version of parts of -the discussions we had, risking becoming a gigantic showcase of {poes-law}[Poe's -law]. - -In this piece, I will argument against his view, and propose an alternative -approach to improve hiring. - -It is common to find people saying how broken technical hiring is, as well put -in words by a phrase on {hn-comment-1}[this comment]: - -____ -Everyone loves to read and write about how developer interviewing is flawed, but -no one wants to go out on a limb and make suggestions about how to improve it. -____ - -I guess Slava was trying to not fall on this trap, and make a suggestion on how -to improve instead, which all went terribly wrong. - -== What not to do - -=== Time candidates - -:hammock-driven-talk: https://www.youtube.com/watch?v=f84n5oFoZBc - -Timing the candidate shows up on the "talent" and "judgment" sections, and they -are both bad ideas for the same reason: programming is not a performance. - -What do e-sports, musicians, actors and athletes have in common: performance -psychologists. - -For a pianist, their state of mind during concerts is crucial: they not only -must be able to deal with stage anxiety, but to become really successful they -will have to learn how to exploit it. The time window of the concert is what -people practice thousands of hours for, and it is what defines one's career, -since how well all the practice went is irrelevant to the nature of the -profession. Being able to leverage stage anxiety is an actual goal of them. - -That is also applicable to athletes, where the execution during a competition -makes them sink or swim, regardless of how all the training was. - -The same cannot be said about composers, though. They are more like book -writers, where the value is not on very few moments with high adrenaline, but on -the aggregate over hours, days, weeks, months and years. A composer may have a -deadline to finish a song in five weeks, but it doesn't really matter if it is -done on a single night, every morning between 6 and 9, at the very last week, or -any other way. No rigid time structure applies, only whatever fits best to the -composer. - -Programming is more like composing than doing a concert, which is another way of -saying that programming is not a performance. People don't practice algorithms -for months to keep them at their fingertips, so that finally in a single -afternoon they can sit down and write everything at once in a rigid 4 hours -window, and launch it immediately after. - -Instead software is built iteratively, by making small additions, than -refactoring the implementation, fixing bugs, writing a lot at once, _etc_. all -while they get a firmer grasp of the problem, stop to think about it, come up -with new ideas, _etc_. - -Some specifically plan for including spaced pauses, and call it -"{hammock-driven-talk}[Hammock Driven Development]", which is just artist's -"creative idleness" for hackers. - -Unless you're hiring for a live coding group, a competitive programming team, or -a professional live demoer, timing the candidate that way is more harmful than -useful. This type of timing doesn't find good programmers, it finds performant -programmers, which isn't the same thing, and you'll end up with people who can -do great work on small problems but who might be unable to deal with big -problems, and loose those who can very well handle huge problems, slowly. If -you are lucky you'll get performant people who can also handle big problems on -the long term, but maybe not. - -An incident is the closest to a "performance" that it gets, and yet it is still -dramatically different. Surely it is a high stress scenario, but while people -are trying to find a root cause and solve the problem, only the downtime itself -is visible to the exterior. It is like being part of the support staff -backstage during a play: even though execution matters, you're still not on the -spot. During an incident you're doing debugging in anger rather than live -coding. - -Although giving a candidate the task to write a "technical memo" has potential -to get a measure of the written communication skills of someone, doing so in a -hard time window also misses the point for the same reasons. - -=== Pay attention to typing speed - -:dijkstra-typing: https://www.cs.utexas.edu/users/EWD/transcriptions/EWD05xx/EWD512.html -:speech-to-text: https://www.youtube.com/watch?v=Mz3JeYfBTcY -:j-lang: https://www.jsoftware.com/#/ - -Typing is speed in never the bottleneck of a programmer, no matter how great -they are. - -As {dijkstra-typing}[Dijkstra said]: - -____ -But programming, when stripped of all its circumstantial irrelevancies, boils -down to no more and no less than very effective thinking so as to avoid -unmastered complexity, to very vigorous separation of your many different -concerns. -____ - -In other words, programming is not about typing, it is about thinking. - -Otherwise, the way to get those star programmers that can't type fast enough a -huge productivity boost is to give them a touch typing course. If they are so -productive with typing speed being a limitation, imagine what they could -accomplish if they had razor sharp touch typing skills? - -Also, why stop there? A good touch typist can do 90 WPM (words per minute), and -a great one can do 120 WPM, but with a stenography keyboard they get to 200 -WPM+. That is double the productivity! Why not try -{speech-to-text}[speech-to-text]? Make them all use {j-lang}[J] so they all -need to type less! How come nobody thought of that? - -And if someone couldn't solve the programming puzzle in the given time window, -but could come back in the following day with an implementation that is not only -faster, but uses less memory, was simpler to understand and easier to read than -anybody else? You'd be losing that person too. - -=== IQ - -:determination-article: https://www.paulgraham.com/determination.html -:scihub-article: https://sci-hub.do/https://psycnet.apa.org/doiLanding?doi=10.1037%2F1076-8971.6.1.33 - -For "building an extraordinary team at a hard technology startup", -intelligence is not the most important, -{determination-article}[determination is]. - -And talent isn't "IQ specialized for engineers". IQ itself isn't a measure of -how intelligent someone is. Ever since Alfred Binet with Théodore Simon started -to formalize what would become IQ tests years later, they already acknowledged -limitations of the technique for measuring intelligence, which is -{scihub-article}[still true today]. - -So having a high IQ tells only how smart people are for a particular aspect of -intelligence, which is not representative of programming. There are numerous -aspects of programming that are covered by IQ measurement: how to name variables -and functions, how to create models which are compatible with schema evolution, -how to make the system dynamic for runtime parameterization without making it -fragile, how to measure and observe performance and availability, how to pick -between acquiring and paying technical debt, _etc_. - -Not to say about everything else that a programmer does that is not purely -programming. Saying high IQ correlates with great programming is a stretch, at -best. - -=== Ditch HR - -Slava tangentially picks on HR, and I will digress on that a bit: - -____ -A good rule of thumb is that if a question could be asked by an intern in HR, -it's a non-differential signaling question. -____ - -Stretching it, this is a rather snobbish view of HR. Why is it that an intern -in HR can't make signaling questions? Could the same be said of an intern in -engineering? - -In other words: is the question not signaling because the one asking is from HR, -or because the one asking is an intern? If the latter, than he's just arguing -that interns have no place in interviewing, but if the former than he was -picking on HR. - -Extrapolating that, it is common to find people who don't value HR's work, and -only see them as inferiors doing unpleasant work, and who aren't capable enough -(or _smart_ enough) to learn programming. - -This is equivalent to people who work primarily on backend, and see others -working on frontend struggling and say: "isn't it just building views and -showing them on the browser? How could it possibly be that hard? I bet I could -do it better, with 20% of code". As you already know, the answer to it is -"well, why don't you go do it, then?". - -This sense of superiority ignores the fact that HR have actual professionals -doing actual hard work, not unlike programmers. If HR is inferior and so easy, -why not automate everything away and get rid of a whole department? - -I don't attribute this world view to Slava, this is only an extrapolation of a -snippet of the article. - -=== Draconian mistreating of candidates - -:bad-apple: https://www.paulgraham.com/apple.html -:be-good: https://www.paulgraham.com/good.html - -If I found out that people employed theatrics in my interview so that I could -feel I've "earned the privilege to work at your company", I would quit. - -If your moral compass is so broken that you are comfortable mistreating me while -I'm a candidate, I immediately assume you will also mistreat me as an employee, -and that the company is not a good place to work, as {bad-apple}[evil begets -stupidity]: - -____ -But the other reason programmers are fussy, I think, is that evil begets -stupidity. An organization that wins by exercising power starts to lose the -ability to win by doing better work. And it's not fun for a smart person to -work in a place where the best ideas aren't the ones that win. I think the -reason Google embraced "Don't be evil" so eagerly was not so much to impress the -outside world as to inoculate themselves against arrogance. -____ - -Paul Graham goes beyond "don't be evil" with a better motto: -"{be-good}[be good]". - -Abusing the asymmetric nature of an interview to increase the chance that the -candidate will accept the offer is, well, abusive. I doubt a solid team can -actually be built on such poor foundations, surrounded by such evil measures. - -And if you really want to give engineers "the measure of whoever they're going -to be working with", there are plenty of reasonable ways of doing it that don't -include performing fake interviews. - -=== Personality tests - -Personality tests around the world need to be a) translated, b) adapted and c) -validated. Even though a given test may be applicable and useful in a country, -this doesn't imply it will work for other countries. - -Not only tests usually come with translation guidelines, but also its -applicability needs to be validated again after the translation and adaptation -is done to see if the test still measures what it is supposed to. - -That is also true within the same language. If a test is shown to work in -England, it may not work in New Zealand, in spite of both speaking english. The -cultural context difference is influent to the point of invalidating a test and -making it be no longer valid. - -Irregardless of the validity of the proposed "big five" personality test, saying -"just use attributes x, y and z this test and you'll be fine" is a rough -simplification, much like saying "just use Raft for distributed systems, after -all it has been proven to work" shows he throws all of that background away. - -So much as applying personality tests themselves is not a trivial task, and -psychologists do need special training to become able to effectively apply one. - -=== More cargo culting - -:cult: https://calteches.library.caltech.edu/51/2/CargoCult.htm -:cult-archived: https://web.archive.org/web/20201003090303/https://calteches.library.caltech.edu/51/2/CargoCult.htm - -He calls the ill-defined "industry standard" to be cargo-culting, but his -proposal isn't sound enough to not become one. - -Even if the ideas were good, they aren't solid enough, or based on solid enough -things to make them stand out by themselves. Why is it that talent, judgment -and personality are required to determine the fitness of a good candidate? Why -not 2, 5, or 20 things? Why those specific 3? Why is talent defined like that? -Is it just because he found talent to be like that? - -Isn't that definitionally also -{cult}[cargo-culting]footnote:cargo-cult[ - {cult-archived}[Archived version]. -]? Isn't he just repeating whatever he found to work form him, without -understanding why? - -What Feynman proposes is actually the opposite: - -____ -In summary, the idea is to try to give *all* of the information to help others -to judge the value of your contribution; not just the information that leads to -judgment in one particular direction or another. -____ - -What Slava did was just another form of cargo culting, but this was one that he -believed to work. - -== What to do - -I will not give you a list of things that "worked for me, thus they are -correct". I won't either critique the current "industry standard", nor what -I've learned from interviewing engineers. - -Instead, I'd like to invite you to learn from history, and from what other -professionals have to teach us. - -Programming isn't an odd profession, where everything about it is different from -anything else. It is just another episode in the "technology" series, which has -seasons since before recorded history. It may be an episode where things move a -bit faster, but it is fundamentally the same. - -So here is the key idea: what people did _before_ software engineering? - -What hiring is like for engineers in other areas? Don't civil, electrical and -other types of engineering exist for much, much longer than software engineering -does? What have those centuries of accumulated experience thought the world -about technical hiring? - -What studies were performed on the different success rate of interviewing -strategies? What have they done right and what have they done wrong? - -What is the purpose of HR? Why do they even exist? Do we need them, and if so, -what for? What is the value they bring, since everybody insist on building an -HR department in their companies? Is the existence of HR another form of cargo -culting? - -What is industrial and organizational psychology? What is that field of study? -What do they specialize in? What have they learned since the discipline -appeared? What have they done right and wrong over history? Is is the current -academic consensus on that area? What is a hot debate topic in academia on that -area? What is the current bleeding edge of research? What can they teach us -about hiring? What can they teach us about technical hiring? - -== Conclusion - -If all I've said makes me a "no hire" in the proposed framework, I'm really -glad. - -This says less about my programming skills, and more about the employer's world -view, and I hope not to be fooled into applying for a company that adopts this -one. - -Claiming to be selecting "extraordinary engineers" isn't an excuse to reinvent -the wheel, poorly. |