tomlagier

Obligatory: Not every company is in "that category" (hyperscale startups trying to churn out their MVP).

Some places where clean code really matters:

- The personal project where, if you can't figure out how you did something, you'll quickly get bored and quit.

- The open source project that needs to onboard hundreds or thousands of developers across language barriers in order to successfully solve problems.

- The medium-to-large startup or enterprise that needs to maintain velocity on a product line.

- The small startup that never quite hit hyper growth and needs to retain developers.

- ... many more

If you're trying to get rich quick, or quickly iterate through many different, dissimilar ideas, then writing sloppy code is fine. I'd argue that that's _not_ most codebases (though perhaps it is in the entrepreneur community).

What is? I see quotes used this way in written communication fairly commonly.

Oof. The number of 4b's I've had to deal with in my career...

What are some techniques to use when you see this happening? I frequently try to get stakeholders to simplify and really identify the core problem / proposed solution, but I run into a lot of "all or nothing" or "design for every possible use case" folks in startups.

> Many people believe it to be the future global reserve currency. Whether you agree with that or not, there's a non-zero probability of that becoming true.

Mayyyybe. I don't think that's why most people are buying it, though. I think it's your last point.

> Also if you look at it historically, it has been the best performing asset in 10 years out of it's 12 year existence which kind of reinforces people's beliefs.

Yeah, this is what gets me. BTC is valuable because BTC is valuable. I don't understand why that loop doesn't unroll, and it breaks my brain a bit. I can't think of anything else that has value _only_ because it has made other people wealthy, and that has so consistently appreciated off of that fact.

The idea that an asset needs _no_ intrinsic value in order to be valuable, or that the intrinsic value may have been defined a long time ago and is now irrelevant to its current value just doesn't compute to me.

Isn't that true of any asset? Why is BTC better than, say, a bunch of emeralds?

Here's mine: it doesn't seem socially useful if everyone holds a small amount of bitcoin and does nothing with it, particularly if all of those holdings are centralized on a small number of exchanges. I have no idea whether that is the true use for most BTC, but (mod exchanges vs private wallets) it's been the case for every single person I've talked to that owns some.

I just don't get it - we're all holding pieces of this stuff because it keeps going up in value because we're all holding pieces of it? And that's somehow worth the enormous computing cost to maintain the network?

Yeah, I'm sure that BTC is great if you're a Syrian refugee or a billionaire evading capital controls but it feels like the majority of the stuff is just... sitting there...

I'm actually really thankful that exchanges are in the picture because ledger-only transactions aren't nearly as wasteful as on-chain transactions, but still don't understand why people want it. A cryptocurrency seems useful to me, inflationary crypto-assets seem like their only use is to reward early adopters?

The value proposition of BTC seems more-or-less like "there is a limited supply and more people will want some in the future because it has made some people rich".

Honest question - does there need to be a value-based case for trading something? Does the SEC have a mandate for stopping purely speculative trades?

The real bummer about this write-off is that it's binary based on the usage of the space - if you use it for _any_ non-business activities, you are unable to write it off. Compare to assets, where you write off the portion that you use for business. It makes it a fairly difficult writeoff to achieve for renters and people in small homes - who might be working out of their living room, kitchen, or bedroom most of the time.

Just a pet peeve of mine - it seems like it's well intentioned, but for many people who really could use it (people in small spaces starting their own business), it's not applicable. On the other hand, it can cut a nice chunk off of a big house's mortgage.

I say this as someone who has never been able to take advantage of the writeoff despite working from a small home for years.

This is a very good summary of the state of the front end.

I think a trap that many software engineers fall into is interpreting "loose coupling" as "build things as far down the binding hierarchy as possible".

You see this under various guises in the web world - "event-driven", "microservices", "dependency injection", "module pattern". It's a very easy thing to see the appeal of, and seems to check a lot of "good architecture" boxes. There are a lot of upsides too - scaling, encapsulation, testability, modular updates.

Unfortunately, it also incurs a very high and non-obvious cost - that it's much more difficult to properly trace events through the system. Reasoning through any of these decoupled patterns frequently takes specialized constructs - additional debugging views, logging, or special instances with known state.

It is for this reason that I argue that lower-hierarchy bindings should be viewed with skepticism - if you _cannot_ manage to solve a problem with tight coupling, then resort to a looser coupling. Introduce a loose coupling when there is measurable downside to maintaining a tighter coupling. Even then, choose the next step down the heirarchy (i.e. a new file, class, or module rather than a new service or pubsub system).

Here, as everywhere, it is a tradeoff about how understandable versus flexible you build a system. I think it is very easy to lean towards flexibility to the detriment of progress.

Twitter: https://help.twitter.com/en/using-twitter/picture-descriptio...

Facebook: https://www.facebook.com/help/214124458607871

Instagram: https://help.instagram.com/503708446705527

It's becoming a lot more common!

This is a bit of confirmation bias, I think - successful newsletters have enough reputation that the reputation loss from low open rate or higher spam flag rate is offset.

Newer newsletters don't have that reputation, so they are more heavily penalized for low open rate or higher spam flag rate. Thus, they need to react more quickly to users invisible actions or risk damaging their reputation. I don't think this is a growth hack, I think this is a necessary action as a new entrant in a very unforgiving space - see some stories upthread from legitimate newsletters.

While your actions are invisible to the sender, they are _not_ invisible to your email provider, and ultimately they are the ones who make reputation decisions that can destroy a newsletter.

Eh, beg to differ. There is certainly domain knowledge to be had, but the underlying principles behind any particular layer of the stack tend to be more similar than different across languages and frameworks. Everyone needs a database, authN & authZ, network requests, state management, pretty forms, error handling, optimized images, etc etc.

Knowing how these layers work as concepts is a lot more important than deep expertise with a particular implementation.

From the perspective of a new hire, you'll spend easily as much time learning their idioms, mutations of the platforms, unique glue code and business logic as you will learning the platform.

> Bitcoin isn't digital cash

This made me laugh. It's true, but the name literally means "digital cash".

Doesn't that seem like a tautology? I think the metric needs to be "bugs per feature" rather than "bugs per release" - it seems obvious that more changes will be buggier than fewer changes.

My last 3 consulting gigs have all had the same general issue - they went with the "quick to start up", scalable solutions and immediately smacked into a brick wall of complexity. These are 1 to 3 person eng teams that started with serverless functions, NoSQL databases, and event-based architecture and not even 6 months down the line had to hire an expensive consultant to shake out their architecture and point them at something less scalable but more practical to build on at their size.

If they didn't have VC, they'd likely die on the spot, drowned before they even had a shot at real product-market fit under the weight of their own accidental complexity.

Now, is there a set of common patterns that works well enough for startups to iterate quickly with, that _also_ scales? Probably. Can you be successful with NoSQL et al out of the gate? Almost definitely. Does it make it _much harder_? I have three anecdotal data points that point to "yes".

From my work over the last year, I'd suggest "choose boring technology" over "worry about scaling early" 10 out of 10 times. You need something that scales _conceptually_ before it can scale in the cloud, if you don't know what your core business value is or how your product actually works it's really damn hard to build a cloud-native app that anyone can actually iterate on. You're fighting incidental complexity every step of the way.

Maybe in 5 or 10 years, when the average developer has a wealth of experience in scaling technologies, when serverless functions have fewer dramatic downsides, when we start seeing out-of-the-box event driven full stack frameworks, when the bleeding sharp edges are sanded off NoSQL and we've figured out a good story around schemas and validation, then it starts to look more attractive for young companies. Until then, though? Stick with the boring stuff.

EDIT: Though, re-reading this, I suppose I should acknowledge my own survivorship bias - the companies that figured out their scalable, cloud-based tech stack early have no need for my consulting services...

> Would you trust your health information to a doctor with previous history of kickbacks, malpractice, lax HIPAA compliance?

It's entirely possible that you do.

An enlightening This American Life episode dives in to who gets to keep their medical license and how they may continue practicing after grievous ethical violations: https://www.thisamericanlife.org/719/trust-me-im-a-doctor

Was this effect achievable with Flash?

Isn't this a problem with all voting? Even if you do it in a secluded booth, you could just take a picture with a discrete camera.

Location: San Luis Obispo

Remote: Yes

Willing to relocate: No

Technologies: React, Node, Rust, Java, Postgres. Focus on full-stack web applications.

Résumé/CV: https://www.linkedin.com/in/tomlagier/ and https://lagiers.studio/

Email: lagierta at gmail dot com

Article took quite a while to get to the point - TL;DR is a series of bulldozers, backhoes, and large rotary snowplows.

I think it just depends on the number of subreddits. If 7,000 is 1% of subs, then it seems like a good investment. If it's 30%, then yeah, that's.. not great.

My wife and I did this. We quit our jobs to travel for a year, got 6 weeks in before it was clear COVID wasn't going anywhere and we needed to return.

We came back and decided that since we had a nice travel fund and no jobs we should use that buffer to explore career choices and places to live that we hadn't previously.

She is now attempting to become a full-time food photographer, I'm still in software but working as a freelance contractor with a lot more free time and better commute.

So far we've broken roughly even on the experience, with a significant boost in quality of life.

http://tomandmary.travel/

Rural California is just as conservative as rural anywhere else. Vermont is the only state I can think of, maybe parts of Maine.

Totally agree. I spent a lot longer (months!) on a very challenging real-world side-project, hoping that would be the ticket to a job.

At the end of the day, it was the ~40-60 hours I put into Cracking the Code Interview that got me the FAANG job, the side project was barely a blip.

Uhh.. have you ever been on Twitter? That's like half the activity there, people dog piling on others based on circumstantial, if any, evidence of perceived slights or wrongdoing.

Sure, people _shouldn't_, but they overwhelmingly _do_, which has real, tragic consequences. People with platforms must take care or they cause tangible harm to others.

This is likely a source of gender disparity in technology. Men tend to be more confident in math and engineering situations, even when they know as much or less than their female peers (the much-reported "gender confidence gap")[1][2][3]. We are disadvantaging equally capable women by using an interview format they are less likely to do well on.

[1] https://onlinelibrary.wiley.com/doi/full/10.1111/j.1949-8594...

[2] https://eric.ed.gov/?id=ED542116

[3] https://www.theatlantic.com/magazine/archive/2014/05/the-con...

I see GraphQL as a primarily organizational tool. If, for whatever reason, it is too difficult or costly to get frontend teams and backend teams aligned on the precise functionality of a REST API, GraphQL provides a spec that is almost certainly able to satisfy frontend requirements at the expense of nontrivial backend complexity.

This could arise if the backend team is producing an API for public consumption or consumption by many frontend teams with differing requirements.

I consider this a fairly narrow niche - the typical case of a backend serving a small number of frontends with tight collaboration between backend and frontend teams is, to my eyes, almost always handled more efficiently by standard REST.

One strategy that I'm really enjoying at a current gig: have the person writing the front-end write the end-to-end tests (or at least the specs) for the person writing the back-end. Just having a fresh set of eyes on the tests has flushed out a lot of edge cases, and tests make a perfect place to iron out small behavioral details. It really solves the "same mind writing the code and tests" issue.

Of course, this isn't always feasible (and is a little unfair to the frontend person in terms of workload).

> So what types are converted to what, automatically? And is it only for == or there are other traps?

This is the question that you asked and that I answered.

If you're looking for the language specification, it's here (first result for "Javascript specification"): https://www.ecma-international.org/ecma-262/11.0/index.html#...