Townley

Is a gas tax really regressive? (asking not because I don't believe it, but because I've never seen this idea stated before). I can see how it's more likely to be regressive among car-owning lower income people (who devote a larger portion of their income to gas, and would therefore be disproportionately affected).

But lower-income people are also less likely to own a car. Even among those who do, they're more likely to moderate their gas usage, more likely to find ways to carpool, and more likely to find the fuel savings of a smaller car to be compelling.

As a Python dev getting into more Rust development, I'm surprised whenever I hear of this as a progression towards better tools, rather than a way of adding new tools into my belt.

Django/Flask are great tools for spinning up a CRUD application with authentication/authorization, API endpoints, and a template language if I don't want to build out a React or Vue SPA.

Rust is a great language that's opened me to new domains of programming, and also gives me the ability to write more performant, hardened API endpoints at the expense of productivity in hours (this gap will definitely shrink as I get better and as rust frameworks mature, but I'd be surprised if it went away entirely)

If a developer views a suite of tools they know very well as "something they used to use", they're more likely to make future architectural decisions based on incorrectly viewing framework-powered python as a relic of the past, rather than a viable (and often preferred, if hours of work are factored in) alternative.

Whenever my normally-silent macbook needs to fire on its fans (compilation, DB restores, or any mid-sized 3D render) I love the audible reminder of how unfathomably hard it's working, and (by extension) what cool stuff is going on behind the scenes.

Optimism is absolutely a double-edged sword. It can keep you motivated during difficult tasks, make you a better/more positive teammate, and encourage you to look for the better ways of doing things that optimists, by definition, believe to exist.

On the other hand, it's also the reason behind most of my missed deadlines ("Oh yeah I can do that in a week, no problem"), burnout ("I've got nights and weekends, I can take on this project"), and disappointing/unrealistic projections ("I don't want to slow myself down with research, I KNOW people are going to love this product").

In my previous role, I was paired up with a developer whose natural tendencies were to pessimistically look upon each new feature request like a minefield. Having someone to negate the negative aspects of my optimism was a godsend, and we had one of the most productive working relationships I've ever had. I would unfairly get a lot of the credit for my positive, can-do attitude, but I've never forgotten the benefits of having a healthy dose of skepticism on a team, nor the absolute havoc that an unchecked optimist (like myself) can cause.

It's fascinating how after periods of stability and chaos, the ant eventually forms "highways" of regular behavior. Aside from fluid motion/sand in an hour glass, I can't think of many analogies in everyday life for this order > chaos > order pattern.

Alongside being interesting mathematically, multi-colored Langton's Ant videos are hypnotic to watch. The patterns they make are beautiful, and I'm embarrassed by how much I find myself rooting for this "ant" to make it as far as it can. https://www.youtube.com/watch?v=gZS7WtRE4_Y

I think so. Among other reasons, those ads were deliberately included in the app by the people who created it (and now have explicit responsibility over the content of those ads).

Since parents trusted those creators enough to give the app to their children, that's something.

Acknowledging the risk of an echo chamber, maybe the ubiquity of these books means that they're tools of the trade. Knowing how to build a great software product/business is a useful skill set that these books teach well.

From there, the path to success comes from being well-rounded and exposed to new ideas/their accompanying opportunities. Read "The Power of Habit" because it's an incredible book, but then also read books specific to the domains to which you're applying those skills. Working for a healthcare company? Read "How Doctors Think". Jane Jacobs for urban planning, Foucalt for history...

It's wonderful that you (and likely half of the people on HN) have read many of these books, and I think having this list is useful for people outside the industry getting a mind for how tech thinks. At the same time, exploring the pantheon of great works in other fields is a virtue that, luckily is toted by many of the books mentioned above.

It could be useful in a scenario where you trust the service provider to provide a legitimate encryption implementation.

If I trust Eve to provide an E2E service, in the same way I trust Whatsapp (not a given by any means), then an open source implementation of those tools lowers barriers to entry. That's a mixed bag in that it potentially enables bad security models, but overall I think access to tools is a good thing

That's not my impression at all. To me, it deepens their accomplishment by acknowledging the headwinds faced by women in tech.

Your proposed headline would be a fine lead-in to an article solely about a research accomplishment, but this is also an article about two people making inroads towards better gender representation in STEM fields.

The intellectual successor to This Old House's take on the entertainment potential of skilled craftsmanship probably isn't drama-filled reality TV, but rather YouTube channels like that of Paul Sellers. My drama-detesting father-in-law and his grandchildren watch those videos all day long to appreciate the craftsmanship, learning opportunities, and creativity of final products.

I don't feel particularly concerned by the espoused narrative that skill is being replaced by drama on TV. We live in a world where people seeking drama-free, skilled craftsman content can access all they could want and more, and This Old House can be proud of their contribution to this through a 40 year legacy of television content (and, relatedly, an awesome YouTube channel)

I'm a senior developer, and my wife is a corporate recruiter (at another company). The frustration both parties experience with the hiring process is palpable, and leads to some of our most eye-opening dinner table conversations.

On the developer side, whiteboards feel like having to study for the SATs again, which is doubly frustrating at the senior level because you know better than before how little these questions correlate to qualification. Irrelevant, spam-esque LinkedIn messages from recruiters confirm how sloppy the whole process feels. And you spend the whole time thinking, there just HAS to be a better way.

On the recruiter side, they have to wade through a horrifyingly-unmanageable torrent of unqualified resumes with the help of bad tools. When a great candidate fails their test and can't move forward through the process, the recruiter is almost as frustrated with the process as the applicant (management, I'm told, remains unwavering in their commitment to "establishing a baseline"). Even worse are the candidates who are filtered out from the process by Applicant Tracking Systems because their resume lists "8+ years of experience with a wide variety of NoSQL databases" and not "MongoDB"

I think both parties recognize the inefficiencies in the process. Where we've landed is the following:

- Developers need to learn to play the game. Understand how much of a black hole "Easy Apply" buttons can be and not rely on them, optimize their resumes for the role (including anticipation of boolean searches based on the job posting), and make meaningful connections with their local tech communities so recruiters know where to find them.

- Recruiters need to advocate for flexibility and transparency in the process. Workflows involving "shoving as many people into the funnel as possible and use an ATS to sort through the noise" are untenable. Reconsider systems that treat whiteboards or tests as requirements and not just data points. Offer up relevant information earlier, with the hope that good applicants will use that info, and their honesty, to help you figure out if they're a good fit.

I hadn't: I jumped the gun thinking that you were sharing 10 minutes of anti-vaccination propaganda, and offering up ammunition for people who think "Well those guys over there say otherwise, so who knows?" My apologies for that.

My point was that planting the poison pill of "Are vaccines dangerous?" is itself dangerous, and despite the video's good intentions might still apply here.

As a popular video, it'll appear in sidebars more than it'll be watched. I worry that in that capacity, it'll maybe snare a bunch of no-vaccination believers in the honeypot, but will plant the safety question into the minds of many more.

My concern is tempered by the understanding that the Bill & Melinda Gates Foundation knows what it's doing here, but the choice to make an informative campaign clandestine strikes me as an odd one with potential negative side effects.

This is an unhelpful contribution to the narrative that vaccines are unsafe. Consumers who don't have time or medical training shouldn't feel uneasy about vaccination except in unlikely circumstances (in which case they're much better off getting advice from doctors and not YouTube), and seeing a video called "How High is the Risk?" adds to that uneasiness in ways that directly harm public health.

EDIT: See comment below. As the video intends, I mistook it to be anti-vaccination propaganda, when it's the opposite. I have minor concerns about non-forthright information campaigns, but apologize for jumping the gun.

My favorite idea here is how it's a developer's job to articulate the issues with a client's code base to the clients themselves. Some clients just want the problem to go away, but smart ones recognize the importance of a high-level understanding of the state of their code base.

If you work for a cheapskate who's just nickel and diming about billable hours, the "Why does this take so long" question is nothing more than the rhetorical whining of a bad client. But in a healthy client-developer relationship, the question is important. It's a less-articulated, unfamiliar version of the following, which any good developer would find amiable:

"I, as someone invested in the success of my company, am seeking insight into a part of that success that only you have. I trust that you're not playing Minesweeper on our dime, and yet our current process isn't delivering the returns we expect. As someone who knows better than I do, are my expectations unreasonable and in need of adjustment, or are there investments that can be made to get us there?

I didn't follow how this relates to docker. Does running the pydocenv command modify dependencies stored in the Dockerfile (or a file that pydocenv references within a "pip install -r ___" command inside the Dockerfile)?

It seems interesting, in that I respect any library (eg pyenv or pipenv) that tries to solve the issue with pip has compared to npm or cargo, where the installation of a library isn't coupled to the dependency tracking. I just can't see from the examples how this is preferable to changing a requirements.txt file and then rebuilding the docker image

What's been your feeling on generalizing the idea to other products?

There's certainly value in being The Vidalia Man, having connections within the industry, and owning the domain. At the same time, the lessons you've learned (not to mention the platform you've built) could apply to just about any other niche agricultural product, such as ramps in the northeast, or southern flour.

How do those two tensions play against each other when it comes to deciding where on the spectrum between "I sell onions and only onions" and "I will become the next Amazon" to fall?

Talk to your supervisors about how you aren't excited about your tasks at work. If there's nothing they can do about it, quit. Find something that excites you.

A family friend of mine used to play violin in a traveling rock band. He slept in the van and loved every minute of it. Later, when he had a family, he settled down and became a contracted fundraiser for non-profits. One day he came across a particular non-profit that he loved, identified with, and felt excited by. He took a 50% pay cut and settled into a permanent position with that company because "it felt like being back in the van again"

If you're the kind of intrinsically-motivated person who can trick their head into being excited about 12 hours of being immersed in a problem, then you'd be an incredible asset to any company that gets you excited.

If you have an idea of what company, industry, or problem that might be (good news: people usually do), pursue it like hell.

> Beyond that, keep in mind that while donations keep Linux Mint and other distributions afloat, the occasional message of appreciation can be encouraging, and at times personally invaluable.

Exactly. This issue isn't just something that "maintainers deal with"; it's also something that "users can help with".

The next time you install a library that makes your life easier, write someone an email. Star the project on GitHub. Open up a "TODO: Keep Being Awesome" ticket where others can show their gratitude.

Even if you don't have the skills or bandwidth to contribute to a project's development, you can contribute to its morale.

Mind helping me understand this a bit better?

The link mentions that to produce a HDCP-compatible device (eg one that has an HDMI port) it needs to be licensed, pay an annual fee, and make promises to frustrate DRM-mitigation efforts.

If I wanted to make my own monitor with a VGA input (or, more practically, pipe the signals coming from VGA into a program that does something with the feed) I would just have to find a suitable adapter and receive the serial data.

Does this mean that doing so with HDMI (either the real-world DIY monitor, or the in-software feed-ingestion program) would be:

A) Difficult/time-consuming to write due to a lack of open drivers B) Run afoul of IP laws pertaining to the HDMI standard and get me sued C) Prevented by the cryptographic handshake that happens between an approved display and the output drivers D) All of the above?

I'm unfortunately even more conflicted than that. I can't answer the question "If someone wants to take my crummy code and commercialize it, am I okay with that?"

If it's a kid in his basement with an amazing idea, absolutely. I'll watch them ring the closing bell at the NASDAQ from my couch and feel nothing but pride.

If it's Google or Amazon... maybe still yes, but less so? It'd depend on my subjective perception of the net benefits to societal innovation, which is 1) more wishy-washy-subjective than I'm comfortable with, and 2) seems like it would make for a really bad license: "MIT-Unless-I-Dont-Like-You"

I recently wrote a piece of software and wanted to make it open source. GitHub's helpful dropdown of license choices gave me more pause than I expected as I struggled to choose between MIT and GPL.

"I definitely want someone to be able to modify, fork, and publish better versions of this code. Do I also want them to be able to commercially license their derivatives?"

On one hand, this code was contributed to the public commons and it'd be sleazy for Amazon to come along, improve it, and license it. It seems unfair, and the spectre of giving free labor to innovation-killing, rich entities discourages me from contributing. A GPL license takes care of that concern, and provides a much-needed codification of fairness.

On the other hand, giving people an MIT license and saying "You can do whatever you want! Go nuts! Innovate!" is a boon to creativity. If some startup took my weekend project and made $1 billion off of it, good for them! That's the innovation that open-source is meant to encourage!

When the article mentioned that coders are confused, it hit the nail on the head. We're confused individually and collectively; emotionally and conceptually; theoretically and concretely.

We're looking for a simple answer to the question "Which option do I select from the GitHub license dropdown so I can get back to making value" when there's no simple answer to be found.

63

Here's a shorter link:

http://aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa...

I can, and do, appreciate opinions on languages themselves. But my decision to continue using Python over Clojure is much less about the language's syntax and more about the available libraries. How do Clojure web frameworks compare to Django/Flask? What would I use instead of Pandas for data analysis? Are there keras-like deep learning tools?

Switching languages based on a comparison of idiosyncrasies between the two seems like moving to a new city based solely on the weather: a valid consideration, but nowhere near sufficient.

I'm sympathetic to anyone who's had a challenging job search, and am glad that you found something.

Society is worse off for having barriers that prevent anyone who wants to code from being able to do so. That includes the inefficiencies of the job industry not placing you into a productive coding role faster. But it also includes the lower salaries, lack of support/representation, belittling, and near-universal campaign of horrible harassment that every woman I've talked to in the field has experienced.

Everyone in the field of software development struggles, and I don't want to take away from that. We should be making life easier for everyone. But doing so involves recognizing problems specifically and succinctly, and building solutions that fit those problems. One of society's many problems is that women in tech have to contend with a nightmarish swirl of negative distractions that I've never had to think about as a white man. In the face of such a problem, giving resources to the effected population makes total sense, and it's a good thing that more organizations/companies are doing so. Even more than that, it brings us closer to meritocratic equality.

15 second summary of 5 minute article:

- Keep your phone on silent at all times

- Disable vibrations when on silent

- Remove notifications from your home screen

A few weeks ago, one of my favorite artists came out with a new album. The day I tried it out, I played through it several times. My brain was invigorated, my blood was pumping, and I had an abnormally productive day of coding.

That day of productive coding produced tens of thousands of dollars of value for my company. That's value that, at least partially, wouldn't exist without the artist's new album.

My company will reap benefits in the form of added revenue. I'll reap benefits in the form of bonuses and promotions. But the artist, who produced this value as an externality, will only receive value if I decide to buy their CD out of gratitude.

The gap between artists producing value for society, and being rewarded for that value, is a shame, and we're worse off for it. I can't think of a solution, but I also can't shake the feeling that this disconnection of value is at the heart of the "making a living" issue.

Years ago, I took an Amtrak NY > Chicago > Seattle > SF > LA > Texas > New Orleans, stopping in each for a few days. I brought programming textbooks and some novels, and just read/thought all day long. At night I'd either eat in the dining car (expensive) or from a supply I'd picked up in the previous city. I'd get a sleeper car when it was cheap (eg Chicago > Seattle) and sleep in my seat during more expensive legs of the trip.

You meet people from every part of US culture (North Dakota oil field workers, Portland hippies, LA actors...) all unified by not being in a rush and a dislike of flying. On trips outside the NE corridor, the train attaches an observation car which becomes an incredible place to talk the night away with fellow passengers.

You have to be flexible, in sound physical shape, and have a month and $2k to part with (or you can just take on a few Wordpress theme contracts and call it even) but it's a truly wonderful experience for a certain person at a certain stage in their life.

It depends a lot on what you're hoping to do. There's a happy medium for a large app between "every component manages their own state/props and those of their children" and "every component is a stateless vessel for VueX data".

I think if you're at the point where "passing data around in props is a nightmare" that's the pain point that VueX is meant to resolve, and it should feed into the solution. But following the principle of "components should manage their state without VueX if it's easy/convenient for them to do so" is a good way to avoid the global state becoming too unwieldy.

I love Vue and use it wherever I can. I used to feel iffy about the angular-y syntax and how CSS JS and HTML all often live in the same file, but I've come to love the way that coupling embraces the component architecture: "This file has one (1) self-contained component that does this one thing". That plus the built-in routing, global state management, and scoped CSS/SCSS made me never want to go back to React.

The one thing that keeps React in my toolkit: React-Native development with Expo is truly an excellent experience. Getting everything going without having to fire up visual studio or Xcode is a dream. I tried using NativeScript with Vue and it just wasn't the seamless "3 NPM commands and you're done"