“The Design of Everyday Things” by Don Norman is excellent; he originally called it “The Psychology of Everyday Things,” but it kept getting misshelved. “Don’t Make Me Think” by Steve Krug is also very good. Neither of these is a specialist’s tome.
“Mental Models” by Indi Young is good, one level deeper, mostly about humans. “About Face” by Alan Cooper is very thorough on the practitioner side, more of a college textbook, with lots of examples and pedagogy.
Also look at Nielsen Norman Group (https://www.nngroup.com). The 'Norman' is the Don Norman who wrote the book, and NNG have a bunch of research that you can look at.
The Roland TR-808 drum machine doesn't have a kickdrum.
Instead it has a BassDrum. It's not as warm as the TR-909 nor as infectious as the LinnDrum, and it can't be tuned and it has no MIDI or swing option. But when tweaked just right it can bellow out a teeth-rattling low register note that make da cars go BOOOOOOOM.
It was a happy feature of a device that Roland obviously conducted zero market research for, in that the first run of these units actually had a longer decay time which meant it was even more bass-heavy. Subsequent releases "fixed" the decay issue because Roland didn't think to ask anybody why they would need that much bass in their drum kicks.
Little did Roland realize that to residents of South Florida there is no such thing as too much bass. When producers wanted more out of the machine, they took to opening it up and fiddling around with the factory default settings (Richie Hawtin did this once and the result was Spastik [1]). Those who were more electronically inclined took a soldering gun to the circuit board to tune the kick circuit and increase the decay time to the point of self-oscillation (it's not hard to do that -- the instructions are right here [2]).
Can you expand on that? I haven't the strength of body to endure climbing any more (though I do have a local indoors climbing wall). Why climbing? What does the rest of your WFH day look like?
Climbing - because it's fun. And I need it to be fun to motivate me... There is a tonne of skill and technique behind it that has a lot of depth. I meet quite a lot of coders who are attracted to it for that puzzle solving aspect.
I'm 45 - so no spring chicken. I started climbing when I was 40 - off a very low fitness base. I don't go all out every day (which is ill advised anyway) - just fairly easy bouldering routes just to get the body moving. Mebbe one or two sessions I'll try to go hard (but only with a very long warm up). Mostly it's just about the routine as opposed to achievement and crushing goals.
Unless you are very old or suffering from injury or disability - there is no reason you can't start climbing now. Just take it slow. It will be difficult on your forearms at first for a few months. Regularity is key. Living near your gym is super important for me. Mine is a 3 minute walk away. I bought an apartment very close to my gym - and it was one of the biggest reasons for my choice.
Rest of the day WFH - coding... till 5 - 5.30. Often down to the shops during lunch. I'll try and go for a walk before dinner if I can...Cook dinner... TV and chill before bed.
Nothing exciting - but a routine that is working pretty well for me.
I'm not the OP you're replying to, but if I may interject my own two cents:
Climbing doesn't have to be a massive route on a 50ft wall. I don't enjoy bouldering, but it's great because it's a full body movement that trains both strength and flexibility. One thing I really love about climbing is the focus- you can't think about Slack notifications while dangling on a wall, the clarity of thought and just being in the present moment is second only to skydiving in my experience. Meditation works as well, but I enjoy the physical aspect.
Even just a few V0 / beginner problems get the blood flowing :)
And to be even more pedantic, the function works because it is applied on an event listener... When null[1] is evaluated (in the right side of the || of the conditional), it produces a TypeError... which in effect (due to no catch and evaluation continuing in a parent/event-driven scope) is essentially equivalent to an empty return in this specific context.
True generally, but irrelevant here: the function in question is RegExp.prototype.match. By definition, it never returns undefined, but only an array or null. The only way `match == undefined` could be true would be if smething had overridden RegExp.prototype.match, which would be… surprising and worthy of explicit note.
Also match[1] will never be undefined: it’ll either throw an exception, or be a string. No, this is just a bug, a poorly written guard that fails to guard what it was supposed to, and I suppose an exception is just silently swallowed and treated equivalently to the intended early return. But the clause should be changed to just `if (!match) return;` or similar.
Quick heads up you may want to update that to be === rather than ==, because of course JS is wonderful and null does == undefined (not a nerd snipe, I was just confused by your comment and went and looked at the code, and realized it was likely a typo :) )
Yeah, unfortunate typo, thanks for the correction. I spend most of my time writing Rust, and when I’m writing JavaScript I type !== and === naturally, but I think writing this comment I just didn’t quite switch into JavaScript mode.
I have to disagree with you on this point (and your third point)
I've seen so many examples where developers DID improve Code quality (CQ) from of the numerous automated/personal quality checks available. (Though what follows is from a Frontend dev perspective)
- CI is CQ
- Code Review is CQ
- IDE w/ Linters is a form of CQ
- `tsserver` is an real-time type CQ
- Immutability is a passive CQ
Idk, maybe Frontend-space is a world away from what you're working with every day, but CQ in my domain has both technological and cultural tools available before code ever reaches the end-user.
> So for non-technical leadership, it is hard to know if "extra time" spent on code quality actually improves anything or is a waste of time and money.
This is really interesting to me as a problem statement: how can devs unfold/make known the value of CQ as a critical function in this math? (I don't have an answer, but I think about it a lot). What are we not sharing – or, worse, what methods/language/etc. are we using that don't fully translate between teams?
I feel it's the job of the org to be able to identify this kind of bottleneck. What position within an org is responsible for explicating the properties of this kind of issue? (Again, I don't know)
> But how do you know these things actually improves code maintainability? How do you quantify it's effect?
Trends. Trends in Client retention, trends in fewer user-submitted bugs. Trends in error rates garnered from logs. Trends in employee retention. Simply stated, Statistics. Imagine: you code a Minimum viable product (MVP) and get to market! Then you're inundated with user-submitted and computer monitor-submitted issues (i.e. AWS alarms) – you have a "shit show" of a product. So, how do you improve this MVP to reduce the Trends of failures? The solution is expressed in the ways I outlined above (but with vigor): CI, Tests, utilizing language linters such as TypeScript's tsserv, etc. (and so much more).
> Code reviews and linting is just applying some opinions to code. How do you prove these opinion are valid?
It's not an "opinions on code", it's a culture which is predetermined by the org (assuming the culture is healthy enough to understand its necessity and/or recognize its deficiency of the same). EVERY org needs to "scale". Orgs asked themselves: how do we effectively "scale" and what is "scale" org-wise? The tenets vary, but the history has painted a portrait of domains: SRE, DevOps, Data Analysts, Frontend, Backend, Product, Systems, Networking, SDET, etc. Each is not encumbered by the need for tests/CI/pre-deploy shtuff (arguable), but is released from "toil" because they recognized scale went beyond "opinions on code."
Validity of code is tests and there are many, many, expressions of tests: End-to-end, Integration, Regression, Smoke tests, Unit, etc.
> How do you prove empirically that immutability is not just a fad like so many others?
I look back on the time before I was cognizant of the concept of Immutability and every larger FE app I wrote feels now indistinguishable from disorder and turmoil. I hope the YC community can expand on the necessity of immutability from a maths perspective (as I cannot), but it's eminently scalable (read: understandable and practicable from an FE dev perspective).
(It's late and I gotta cut off here, hopefully someone can expand and/or redact everything I've said).
> I look back on the time before I was cognizant of the concept of Immutability and every larger FE app I wrote feels now indistinguishable from disorder and turmoil.
Good for you, but this is not very objective. People were saying the same things about OO inheritance and and a bunch of other stuff which the industry have later become more skeptical towards. I'm not saying you are wrong about immutability, just that you cant show any solid empirical evidence that immutability improves long-term maintainability.
On the topic of immutability you can actually trace it back to a point (and languages even) where every variable is a global one. That almost always leads to hard to debug errors and generally poor quality of the final product until you catch all the bugs. The natural "fix" is to have variables that a scoped and cannot be used outside of that scope - I hope I do not have to make the case for why that strictly improves long term maintainability.
Immutability is taking it a step further and provide a mechanism where scope does not matter. If you have an immutable object you can always expect the values to be what they are and not changed by some other path of code. You can freely pass around the immutable objects because they cannot be changed.
In other words, it's a mechanism that you can use to ensure that no matter what is changed, it's not the value of you immutable objects. I'd argue that it lowers the surface of things to consider and with any decent tooling also prevents you from trying.
So you try to convince me that immutability is great. But I did not say I don't believe in the benefits of immutability, I said there is no empirical evidence that it leads to better long term productivity.
I'm not in a position where I can give you any empirical evidence because I do not collect it. My teams do see a decrease in bugs that reach production when they start to embrace immutability. But, the catch is that most of those teams are on a general journey of known good practices such as integration tests, static analysis, linting, and to some degree unit tests and reducing cyclomatic complexity. So I cannot in good faith give you any numbers because I do not run controlled experiments for that alone.
Looking back on my replies a few days later I think I missed every mark I tried to hit. The arc of the "narrative" was about the nascent devops bleed into the frontend space which our team appreciates from now - but failed to make any real sense of it. I'm not a good writer.
> People were saying the same things about OO inheritance and and a bunch of other stuff which the industry have later become more skeptical towards.
In my experience this is the usual adoption curve of new practices (not necessarily best practices). They come as a shiny new solution for an annoying problem, it gets absorbed by early adopters that then become evangelists. More people start using these patterns/practices and start encountering the issues and obstacles with it, some get disheartened, frustrated and become outspoken against it.
These practices then evolve with time, becoming more nuanced, having "best applications" and "non-use cases" to better judge its applicability. And then becomes mainstream and a expected practice for modern software development/engineering.
I've seen this with multiple trends: OOP-isation of everything, UML (birth and death, kinda superseded by C4 diagrams these days), NoSQL, microservices/SOA, Kubernetes, Dockerisation, and so on and on.
FP and immutability are getting into the maturing phase of this, I remember a few years ago when it started making inwards on FE development, it was adopted, kinda overused and now I see it trending towards more cautious adoption.
I believe it's all a matter of understanding, all new shiny things will always have early adopters that can cope with the pain points. These are addressed when getting more mainstream and with that comes the knowledge of what actually these pain points are in the real world after years of adoption.
I don't see this pattern changing anytime soon, I've seen it repeat too many times the past 15 years.
Totally agree. I will add that the hype is typically ignited because a technique have shown real benefits in a particular domain. The problem comes when the technique is treated as a panacea and is applied uncritically outside of this domain. This eventually cause a backlash, which may even hurt adoption in the original domain where the technique was successful.
If the average developer has to be able to maintain (and therefore understand) the code, it stands to reason that the more eyes on it the better it converges on this state.
Thank you for sharing; your insight is human and approachable.
I'd like to ask, though: looking back, what were (or have become) the best resources to you - read: books, articles, conference videos, etc. - which have unequivocally helped you in the years since?
My answer may go in a different direction than you might expect. But The most important gift I’ve ever given myself is being brave and facing my fears/demons. Taking a break from the flow of life, stepping outside of expectation, and turning inward. Of going to therapy for the first time, learning to meditate, and working through the childhood conditioning that was causing me to choose a life of “imprint” rather than “blueprint”. The imprint allowed me material abundance for which I am grateful. But the blueprint has given me my life’s purpose, my true calling, which is no less scary than the choice I made in 2006, but more valuable than anything on paper.
I’m always happy to connect more deeply and provide guidance if this resonates with you - PM me.
https://www.cs.cmu.edu/~dst/LispBook/book.pdf