241–250 of 946 posts
When I first saw it, I thought it was a process step that was unnecessary.
Then I thought it was a way to program visually, but generated code only works in narrow domains.
I realize that UML is tool to define your system, and it lays bare your assumptions, which is one of the hardest problems in computing.
Quantum computers. I was so deceived by all the hype that it took me long to see it as SU(N) matrix product accelerator.
Zero knowledge proofs and Shamir transform to non-interactive protocol. The tunnel analogy did quite a harm to me, also the math was just unbearable (defining set of languages and etc). Only a year ago when I got an old paper on “Observational wallets” describing how to prove ‘log_g A = a’ and ‘log_g A = log_g B’ the whole ‘proving statement without revealing secret’ after long frustration and angst made sense to me. If I had encountered finding Vodo analogy first, It would have clicked much quicker to me.
It took me an embarrassing amount of time to fully grok what object oriented programming really means. It's one thing to have someone tell you what an object is, but it's another thing entirely to build a fully object oriented system. I remember what made it click: I was designing an animation system, which had a bunch of different interdependent moving parts. Once I started treating each part like an object and lett…
You could build a chatbot that supports Discord, Slack, and IRC dynamically at runtime, or a web app that can use multiple different database engines, or a social network with multiple types of posts that can all be rendered in a main feed, or a bunch of other things. In all of these cases you can also take advantage of this kind of dynamic dispatch to inject mock objects for testing, as well as theoretically have an easier time swapping out a layer if you want to change a dependency.
What really frustrates me is that almost none of the OOP instruction I've encountered ever showed these kinds of real, practical examples. They always over-emphasize harmful inheritance-based approaches and never really explain composition. In college we learned about OOP by building a little text-based RPG thing with different types of monsters implemented as subclasses of an abstract base class, which left me feeling like there wasn't much practical use for it outside of game development.
It wasn't until my first internship that I saw a real-world use of OOP, in the form of a giant Spring Boot monolith with tons of dependency injection. Eventually, after staring at that for a few months, OOP finally clicked for me, but I still find it annoying that nobody ever tried explaining this using practical, small-scale examples.
Earlier quoted context omitted.
This summer I read "On Writing Well" by William Zissner which was an eye opener for me. I'm far from an expert in writing clear texts, but I am definitely noticing more text which are just... big balls of blurb that don't actually say anything. All because of that book. It sounds dumb, but this year it clicked for me how big of a difference a poorly written text compares to a well written text. Hope your training pay…
This is the first book I recommend to anyone who wants to improve their writing. With Minto's Pyramid Principle as a follow-on. My top 3: 1/ Edit ruthlessly. Every single word is reduced to its simplest form and pulls its weight--it has a damn good reason for being there. 2/ Aspire to write at a third-grade reading level. Readers prefer simple writing even when reading deeply technical content. 3/ Start your most imp…
It's just so much experience to avoid those mistakes.
The axiom of choice, Tychonoff's theorem, and the open mapping theorem [0, 1, 2]. Each one took me, in my view, much too long to grasp. [0] https://en.wikipedia.org/wiki/Axiom_of_choice [1] https://en.wikipedia.org/wiki/Tychonoff%27s_theorem [2] https://en.wikipedia.org/wiki/Open_mapping_theorem_(function...
Voltage and amperage for me, years after a college electronics course and a childhood of soldering kits I finally started to get it. I was always tripped up with analogies about how it's like water in a pipe or something, which can be useful, but aren't quite right.
Can you share what helped it click? I’m in the same boat, trying to understand it through analogies.
That's the way to understand electricity without analogies. :)
Anyway, voltage is always measured between two points (one is typically called "ground" but that's not important here.) It's a difference. (A difference of what? No one knows. That's just the way it is.)
Current is always measured through a single point. It's a count of the charge flowing past a point per time unit. (What is charge? No one knows. "Charge" is just a name for the mysterious something that "voltage" is a difference of...)
When electricity moves it obeys a (very simple) Law called (Ohm's Law) e.g.:
E = V/R
E.g. is I have a 5 Volt power supply and I put a 100 Ohm resistor across it (remember that voltage is always between two points) then 5/100 Amperes of current will flow through it.
Also, If I take just the resistor and drive 0.05 Amps through it, it will develop a voltage of 5 volts, as measured from one end of the resistor to the other end.
Now if that doesn't help you, remember the advice of John Von Neumann to Felix Smith: "Young man, in mathematics you don't understand things. You just get used to them."
UML When I first saw it, I thought it was a process step that was unnecessary. Then I thought it was a way to program visually, but generated code only works in narrow domains. I realize that UML is tool to define your system, and it lays bare your assumptions, which is one of the hardest problems in computing.
Any abstraction can evolve into wasted time not making the thing.
Steely Dan
Taking the point of view of others, and learning to view a situation from a "perspective-less perspective." It's easy to think you have people skills because you listen to others and repeat their point of view back to them before telling them they're wrong. And unfortunately you can get quite far in the business world simply by being good at demolishing other people's positions. As a mental exercise, a few years ago…
mine is the opposite, you can't get anywhere in life with the perspectiveless perspective
Or, cynically, maybe it's effective to adopt the group-first mentality once you have the personal momentum from years of being self-centered.
Earlier quoted context omitted.
Yep, I think mocks are mostly a smell. The "functional core" of a module should be entirely or almost entirely unit testable with (possibly fake) dependencies passed in. The glue code ("imperative shell") should be tested at a higher level - "integration" or "end to end" or whatever you want to call it - which looks at the externally observable effects of running the code (database changes or API responses or whateve…
Amen. I have been frustrated at many jobs where developers were so proud of endlessly writing mocks and spending more time on their tests than on core functionality. Over time I have favored very basic unit tests and leaning in more on automated integration and regression tests. I know the theory of unit tests catching things earlier, I just don’t think it matters in practice.
Of course it's not necessarily a full replacement, but it's definitely better and more time efficient than bad tests.