HN user

ericathegreat

70 karma
Posts5
Comments36
View on HN

There's a huge difference between: - Don't use this, it's harmful to you, and - Don't use this, it won't make things actively better.

Study after study has shown that it is extremely, almost absurdly difficult to lose weight and keep it that way in the long term.

If "not actively causing long term weight loss" is the only criteria for advising against something, then we should be advising against a heck of a lot more things that are perfectly fine.

It's phrasing like this that causes people to go on crusades against random foods, rather than actually using moderation in all things.

In one case, the same person did the same thing to us twice in a row - interviewed, got an offer, then got "counter offered" from their existing company the next day. Pretty confident that they're just interviewing as a negotiating tactic.

But honestly, in general, if someone interviews around then decides to stay at their existing company for more money, they're probably not the folks I'd be likely to hire regardless. They're not looking for new learning opportunities, or new ways to grow, they're maximizing for some other value structure. And best of luck to them with that, I'm sure they'll find plenty of companies where those values are the expectation and norm.

You're "playing the game", but I build teams out of folks who aren't game players. :)

Small counter-opinion here; if I interview a candidate, offer them a role, and find out that they have been using our time only to get a better deal from their current employer, then I will most likely choose not to interview them again in the future.

If you have engaged with me in bad faith (pretending to want a job with us when you actually don't) then I would be very uncomfortable endorsing you to join one of my teams in the future.

By all means, interview around. And if you get a better offer and accept it, then I will cheerfully congratulate you and wish you the very best of luck! But if you're operating in an area where the pool of potential employers is small, make sure you don't burn too many relationships in the process.

This class of users is also some of the most easily scammed.

These folks, who need "less security", are the exact same who will tell a stranger their password over the phone simply because they said they worked for Google. Scammers can use data from an email account to write convincing fake communications that lead to folks losing their life savings.

Teaching folks that their data isn't important enough to turn on security, is teaching them to fall into scammer's traps.

I'm highly dubious of any research that equates "went to a top tier university" with "is highly intelligent" as its only metric. Especially one that also says "but outside America that's not true".

Could it be that people who come from backgrounds that value attending a top tier school as a status symbol also come from backgrounds that (can afford to?) pursue a biollionare-making career? And that in countries where the billionaire class do not value top tier schools so highly, fewer billionaires went to top tier schools.

Could very easily be classic correlation.

Something that you might want to consider, but which hasn't really shown up in the comments, is... Do you actually _want_ to do the finishing?

Are you taking on these projects because you want the end result to exist, or because you just really enjoy the initial phase of learning and discovering and mapping and planning? If you are getting joy/mental stimulation/a creative outlet from this, then perhaps it is serving its purpose already.

Sometimes, doing something you love, even if you leave it incomplete or do it poorly, is exactly what you need to refresh you. Maybe your hobby isn't building software. Maybe your hobby is just... Dreaming up new projects, and learning about new technology. And if this is your hobby, and not your job, maybe you don't actually need to finish projects at all. Leave the finishing to your day job.

There are still professional, high quality hand knitters in the world.

Of course, having people hand knit garments used to be the only way to get a knitted garment at all.

Then we invented industrial knitting machines, and those hand knitters found their roles had changed. Instead of knitting a whole garment, they would be closing up the toe on the socks, or doing finishing work on a sweater. Of course, companies didn't need anywhere near as many knitters under this system, so a huge proportion of them lost their jobs.

Then the knitting machines got better. They could close the toes on the socks themselves, could do most of the finishing work automatically. Some of the remaining knitters became industrial knitting support workers, but most of the actual knitting jobs dried up.

But there are still professional, commercial hand knitters, even today! They test hand knitting patterns for the hobby market. Make the samples up for photographing, and make sure that all the sizes come out right.

They number... Dozens? Maybe? And most of them treat it as a side gig, despite being the absolute pinnacle of hand knitting talent, since it pays terribly.

A job doesn't have to have been totally replaced to be effectively replaced. As we find ways to hand over larger and larger pieces of the work to an automated system, the number of real roles in that field diminishes, until it eventually becomes infeasible as a career choice.

This is what a lot these digital content creation jobs are heading. Gradual obsolescence.

It depends on the intent of the advice.

If the advice is intended to let you "win the game", or "get ahead of the competition", then yes. If everyone is doing the same thing, then using it isn't going to provide you with any particular advantage over anyone else. "Add these words to get to the top of Google results" is doomed to eventual failure.

If the advice is intended to help you improve your quality of life, or improve at something specifically for the joy of being better at it, then being well known will not dilute it. "If you're feeling sick, then you should drink more water and rest" is just as valid now as it was when it was a new and revolutionary insight.

A familiar dream, that kind of misses the actual challenge of programming is not the syntax. HTML really doesn't take long to learn - at least, not the kind that's being produced here. The hard part is unambiguously describing what you actually want. That's what code is, at a fundamental level - a way of describing exactly what you want in a way that cannot be misinterpreted.

Consider the instructions.txt given; 'This is an application called "My Bikes".'.

Okay, so what does "called" imply here? Is this what you want displayed in a title bar? Or is this the name that should be used for links to this application? Or is this text that should be displayed in large type at the top of the page? Or is this the name you're going to refer to it as in other "instruction.txt" files, when you want to link or reference this app? Or is this the label that should be used when someone adds their app to their phone home screen? Or something else entirely? I would argue that any of these would be valid interpretations of the phrase, but I'd bet that at least some of them would not be what the author originally intended (or even considered) when they wrote the phrase.

Consequently, you might find that you need to say something more like 'This is an application. The browser title bar should be "My Bikes". The displayed heading should be "My Bikes" in large, sans-serif font. When other pages link to this page, they should use the link text 'EricaTheGreat's Bikes'..." etc, etc.

And you can bet that pretty soon, users of this language will start complaining that "I have to type so much to get even the most basic things going. Could I just simplify it down to something like 'title bar: "My Bikes", heading text: "My Bikes", heading size: large, heading font: sans-serif"... "

Well look at that! In making this statement unambiguous, we've just created a very verbose programming language!

It remains as ever a delightful dream, but unfortunately one that doesn't actually solve the real problem - that natural language uses a lot of words to say things that are ambiguous and ill suited to producing the desired outcome.

Why would someone pay in advance for something that they will get for free at the same time as everything else? Fundamental limitation of capitalism is that one of its goals is to acquire the maximum amount of value for yourself, while losing the minimum amount. Even the most successful Patreon users rely on "Patreon exclusive content" for their supporters to be able to make some kind of livable money.

That's a tricky precedent to set though, isn't it? If you do sufficiently good work elsewhere in your organization, you can break the law without penalty? That's like McDonalds claiming that they should be allowed to mistreat their workers because they also run a children's charity.

Doing a right thing doesn't grant you immunity when you do a wrong thing. And there was no question that what they did was illegal. Many thousands of people told them that the moment they announced they were planning to do it, they didn't even need legal counsel to point that out. They did it anyway.

This. Absolutely.

If something fails six months after release, who ends up paying the penalty?

Are your developers on-call for production issues? Will they be woken up at 3 in the morning, expected to solve customer issues caused by one of those corner cases? Or if it's someone else on call, will your developers experience the wrath of the person who _was_?

If a production issue occurs, does the person who produced that code get pulled off whatever new they are now working on, because "they're the best person to fix that issue"? Even if they've "moved on and up" and their new work is more interesting or prestigious than the project that has the issue?

Is their failure publicized across the whole business?

If data is corrupted because of a corner case, do your developers have to go through tedious processes to repair that data (with angry customers causing frustrated managers to breathe down their necks)?

Do they have to defend and justify to all of their peers why their code broke production because of a "corner case" that they were fully aware of and chose not to handle?

And even more importantly, if they build the 80% first, what guarantee do they have that you will let them write the last 20%, and not just move on to the next thing? Consider - if they build the corner cases first, they've guaranteed that they'll get all the scoped work done (because you won't ship without the other 80%), but if they front load that highly visible 80%, they will almost certainly get pulled off the project before they get to handle those corner cases.

All of these things are very strong motivators for teams to do exactly what you're asking them not to do. As a (presumably) product focused person, your reward happens as soon as your product is in customers' hands. You are rewarded for a product that is released quickly. But developers are frequently penalized for that.

When you ask your development team to focus on releasing incomplete software, you're asking them to treat _your_ success as more important than _theirs_.

That doesn't mean that what they're doing is necessarily right. You need to set up an environment where your teams' success is aligned to the thing you most want to have happen. Change the rewards and penalties in your company, and behavior will change itself.

Or, failing that, negotiate a compromise position between your desire to get something to market, and their desire not to continue paying the price for that speed for the rest of their tenure at the company.

Would definitely recommend the mini-series documentary "Howard Goodall's Big Bangs".

Episode 3 in particular, which was about equal temperament, is especially good. It explains things like scales and chords in a very satisfying way for both experienced musicians and those who have not had a formal education. He even ties it back to the actual physics of sound and harmonics.

It's only got half a dozen episodes, so it's worth a go.

Nothing stopping you from doing just that!

Pick a game development technology that you like the look of (a language or framework or engine), do their basic tutorial, then drop by their forums. Almost all of them will have a "looking for collaborators" section where people with ideas but insufficient skill, or with skill but insufficient ideas, can shop around for partners to make something cool.

If you're not picky regarding tech, there's also TIGSource, which has a platform non-specific collaborators wanted forum: https://forums.tigsource.com/index.php?board=8.0

Or, if you're looking for something a bit more time boxed, a lot of game jams (game development hackathons) will help you find a team to work with on a no-commitment once off project to get a feel for whether this is something you enjoy. See if there are any running near you, and drop on by. Global Game Jam is a great one for this, but it's not until early next year, which may be too long a wait for you.

Grab a makey-makey, some aluminium foil, some cardboard boxes and a laptop running Stepmania. It takes about 15 minutes for kids to hands-on make their own DDR machine. (Dance dance revolution). I've done this multiple times with upper primary and lower secondary, and it's always gone down really well.

Perennial Crops 7 years ago

Interesting thing about annuals, is that they needn't be anywhere near as problematic as they have become.

Consider - any plant which died after three months without reproducing is pretty improbably as far as evolution is concerned. And yet, there are millions of naturally occurring annuals.

That is because naturally occurring annuals are "perpetual annuals" - annuals which reproduce within that three month period, but effectively lie dormant in seed form until the next time the climate is beneficial.

In nature, these are plants which have evolved to thrive in a specific climactic condition. They optimize _hard_ for those conditions, to grow fast, to make babies (seeds), then self seed either in-situ or far and wide. Then they die off to improve the available nutrition in the soil (ready for the seeds to sprout next year) rather than burn up a whole lot of energy just keeping themselves alive through the rest of the year. It's highly efficient. A single corn plant can produce potentially dozens of new corn plants in a subsequent year - one plant per kernel. These are the "perpetual annuals" - technically annuals, but self managing so that they continue to produce every year.

Perpetual annuals are highly resilient. Their short reproductive life cycle makes them very quick to adapt to local conditions. The same physical space can be productive for much longer periods of time, with spring plants dying down to make way for summer plants, then for autumn plants, then a winter where the land lies fallow, building up rich sediment to feed the next year's crops. They also make polycultures very practical: smart sequential plantings can mean that, say, a nitrogen hogging plant like a broccoli can be sequentially planted after a nitrogen _fixing_ plant like a pea, so that plants aren't always sucking up the same type of nutrient and effectively wasting the rest.

Unfortunately though, many modern annuals are not actually _perpetual_ annuals. And it is precisely our genetic modification that has made them into problems. We have selectively bred these plants to the point where they produce seeds which are infertile, because that makes it possible for the breeders/suppliers to keep selling seed year after year (rather than selling seed once, knowing that farmers can then propagate themselves in perpetuity). In particularly extreme cases, we've bred plants that _literally have no reproductive organs at all_ - seedless watermelons and seedless grapes, for example. With these plants, the "annual" life cycle is genuinely plant, grow, die. End of the line. Start again from scratch.

Planting hybrid perennials is definitely better in terms of human labour, in that you will get multiple harvests from the same plant. They're also good for the environment, because they provide stability to soil. However, in the grand scheme of things, the best option is a blend of _both_ perennials _and_ perpetual annuals. Ideally while allowing the plants to reproduce naturally, rather than trying to optimize genetics for short term commercial traits.

And that's a genuinely great thing.

Sure, by the end Flash was a pain in everyone's backside. But Flash was critical in the transformation from a text-only internet to one where we could watch videos, or play games, or chat to other people in real time. So much of our modern web standards were born from an attempt to make it possible to do the things that Flash taught us should be possible.

If Flutter can be half as transformative as Flash was, then bring it on!

Relying on native components means that differences in platforms get propagated up into application developer land. Consider: Two "native" components have slightly different behaviours. Therefore, the framework also implicitly has two slightly different behaviours. Therefore, the developer using the framework has to cater for two slightly different behaviours. This is where the real pain of cross platform development happens, and the reason it has such a bad rep.

By bypassing the target environment's native controls, they're paying more heavily in render code, but they're getting rid of all of that propagation of pain to higher up the development stack. As a developer, that's a cost I'm willing to pay.

(* For reference, I have used Flutter, Xamarin, React Native and Java at various points in time, and Flutter has very rapidly become my preference. It has a consistency that I appreciate. But of course, ymmv.)

Agree. Consider the situation of data entry professionals, those people who transcribe audio recordings or enter data into databases.

If you have one person entering data into a computer, then the odds of them introducing an error and failing to spot it are fairly high.

If you have twice as many people entering twice as much data data, then the odds of an error getting introduced are roughly doubled.

However, if you have those two people entering the same data, then their mistakes cancel each other out. If person A and person B both entered the same thing, it's extremely unlikely that it's incorrect. If they differ though, the a problem has been identified, and can now be fixed.

The odds of both of those people entering the same piece of data incorrectly is tiny. Likewise, accidentally introducing a bug into both the production code and the test is pretty unlikely.

That said though, if those two theoretical data entry people above are given the wrong data to enter, then they the system cannot protect them. They will both correctly enter incorrect data. "Garbage in, garbage out".

Likewise, if the requirements of a piece of software are poorly understood, then it is quite likely that both the test and the production code will implement the same "bug". Writing tests won't fix a failure to understand the problem you're trying to solve. And they're not supposed to.

I like the look of this. A couple of questions I can't see answers to on the landing page... - Is it possible to change the schema after creation? Or is this a "get it right first time" deal? - Is validation strictly not-null/range-check? Or can you add more complex validation rules?

I think this depends very much on what you consider the intention of a justice system to be. If it is to strive towards balance between individuals, then you are correct. If a person causes suffering, then they should experience suffering themselves. Balance attained.

However, if the intention of a justice system is to reduce the total amount of injustice done in the world, then punishment is surprisingly ineffective.

Being a criminal does not _preclude_ a person from also being a victim. People who inflict violence have very, very often experienced a great deal of violence against themselves. In these cases, punishment is going to do far more harm than good in society. Harsh punishment, especially incarceration, makes pre-existing issues much worse. It creates recidivism, and increases the total amount of injustice over the long term. Compassion, support, empathy, education, and carefully guided opportunity to improve would, in many of these cases, improve that person's circumstance to a point where they no longer have cause to harm others. The original victims may not have received the recompense that they deserve, but the likelihood of more people experiencing pain at the criminal's hand in the future is reduced.

So it's not quite as simple as all one way or all the other. I think that is why the raw concept of 'retribution' is a less desirable idea these days than it has been in the past. It makes the demands of individual balance at the expense of community balance.

Don't get me wrong, I think that ignoring individual balance outright in favour of community balance is equally flawed. The trick is providing lots of options, so that someone like a judge can make the call as to where that balancing point should be and be confident that it is played out.

I don't think women are more or less capable than men when it comes to coding. There's no particular aspect of the process which could make it strongly gendered. However, I regularly observe a selection bias, which sometimes makes it seem like women _average_ high.

Women who are mediocre at coding have no particular motivation to go into the profession. A lot of the messaging about the career is how hostile it is to women. If you didn't have a burning passion and a strong aptitude for coding, why would you opt yourself into that? You'd have to have a serious skill and/or passion for the field to want to even start.

For men, though, that hurdle doesn't exist to the same degree. Passionate, skilled developers still follow their professional dreams, but there are also numerous men-folk who ended up in programming simply because it paid well, or because it was a nice indoorsy type job. Without that first cultural hurdle pushing them away from the career, they slouched their way through university and got a mediocre job as a mediocre developer.

There aren't as many professional, mediocre female developers, because only because only those who are really serious and passionate bother to push their way into industry. As we approach 50/50 balance, I'm confident we'll see a much more balanced mediocrity as well. :)