skysight-inc/HackerNews huggingface dataset:
I kind of see where they're coming from with this one, although I don't think it's true. The definitions of trivial and correct can be moved to fit whatever they're trying to say.

Rephrasing it as something like it's incredibly difficult to write a large piece of software with no bugs makes more sense. And I think for most organisations it may as well be impossible.
autonomous driving is a great example here. It will never be "correct" because there will always be accidents. So the author is right about that. But it is very possible that those cars may be 10x safer than the average human driver some day.
Php has had some really poor errorhandling and lots of magic. The idea that good error handing is just ignoring it is so wrong, that every update to php is basically a list of “this error will now be presented to you”.

How many scripts continue to prohibit apostrophes in passwords because there used no way to reliably instruct devs on how to handle apostrophes in strings? People named O'Brien still can't enter their names in forms and expect to get it back despite magic quotes being gone years ago.

Nowadays, modern php is conservative but fine. But it was really a terrible choice in its early days, when every one of its selling points was a misfeature.
How are you storing and sharing these docs? Is it a common Sharepoint library or something similar? I've found the biggest problem is often getting people to look at the document resource / archive when they have a problem whose solution might already be documented.
Function names and parameter order matter. That is the difference between having to look something up in the documentation and not. Back in those days most text editors didn't have fancy autocompletion with parameter documentation, if you weren't sure about the order you might have to look it up in the documentation. Having a self-consistent API that was easy to remember was essential. Especially in a language with dynamic types!

When I switched from PHP to Python it was an amazing, liberating feeling for me that I will never forget.
Ask HN: What do you use for project generation?
What do you use (if you do use) for project generation?

Use case: have a project template with all the names/dependencies/best practices baked in. Run one command with project name, have everything set up.

It would be nice to have one system to generate whatever projects: Java, C#, you name it.

I'm aware of Yeoman, and will explore it. Any others?

Related question: one you have your template, how do you make sure it actually works and is properly set up?
"Messy Api" isn't just parameters. For instance "Fatal" errors and regular errors going to two different logs was very messy and would byte you if you didn't pay special attention to it.

Or multi-byte compliant methods that are a variants, and not the standard method, thus biting anyone who just thought utf-8 would be default.

"terrible default": the poster child for this is register globals, which it took ages to have off by defaults. That's just a single line to set it properly, but that was part of the boilerplate that could have been avoided way earlier.

Overall developing for PHP meant to defensively remember a ton a weird stuff, just like javascript was for a while. I am so glad we mostly got past that, even if I am not in PHP anymore.
> I don't see it as a bad thing as long as all sides are aware that changing requirements changes the deadline as well.

In my experience, this could not be further from the truth. There is simply no awareness that change remains expensive it's just that now the process allows it without any fanfare whereas before a change was a big deal.

Not saying that change requests are the way to go but certainly an understanding that change is not free would go a long way
Obviously. Except when there are four two-wheelers tailgating you and braking would cause them to collide with you, or at least slow down all the traffic behind you so that everyone is now honking at you.

It's probably hard to understand what I'm talking about if one has never experienced traffic like this themselves.
That is for function with no C counterparts. htmlspecialchars() exists in no common C library. The reason strlen() is called strlen() (not string_length() or length() or whatever) however is due to C.
Microsoft Partners with Google to Improve PWAs
Making the Red Hat Platform Bet Pay Off for Big Blue
This guy was also top in terms of the number of FAQ entries written to help people. In fact he wrote the FAQ system itself and also wrote a right-click plugin so if you rightclicked on a question in chat it would auto-search the FAQ.
Maybe libreoffice should work on it for .odt then, together with various VCS plugins (mainly git and maybe hg). It could be an interesting differentiator feature.

Sure, it's hard to diff and merge tree data structures, but it doesn't have to be perfect. Text diffing and merging is already imperfect anyway, yet it's very useful.
Microsoft Scrubs References to Surface Hub 2X, Official Launch Now in Doubt
Toyota and Panasonic Start Joint Venture Specializing in Automotive Batteries
Apologies, I haven't heard of anything and I haven't dared upgrade yet either. Good luck!
Sadly, impossible.
https://web.archive.org/web/20200202100803/https://www.washi...
I think the customers don't know how to use legal counsel and somehow don't want to learn. I agree it's bizarre.

I have used Gunderson Dettmer since they started (was before that one of VLG's first accounts) and have very low legal bills. But I know when to use them and when not to. And when a partner is needed (almost never) and when I can get as good or better from an associate.

Another weird thing is that many customers value the firm and not the partner (I don't really use the firm GD, I use specific people). I "used" Cooley for one specific firm but really I used one person and when he decamped for another firm my company moved with him. Likewise just because that company used Cooley for general corporate law didn't mean we even considered their patent team.
How far down the stack does it need to be correct? Can a 100% correct Python script be considered correct if there could still be bugs further down the stack? Also what's the context of the software? Much software has pretty safe failure modes, but if it's a medical system for example, knowing level of correctness right down to hardware level may be useful.

I think in that light, most modern software can be built to be robust and easily maintainable rather than correct. Like the difference between building a bridge, where you understand everything in the system, versus building a vehicle engine, where you have multiple dependencies but you still need it to not catastrophically fail should any of them stop being correct (eg: fuel pump fails, engine management detects lower fuel pressure and cuts ignition, saving the engine).
SARS Stung the Global Economy. The Coronavirus Is a Greater Menace
Interesting, thanks for posting! I like how people start trying out new license models while still trying to keep their products as open as possible.

Since this is a desktop application, not a Saas, and you opted for a subscription model: would you mind sharing your thinking behind this? Traditionally desktop apps like this were sold on a 'version' basis (i.e. you get this major version as well as any minor updates for a one-time fee).

I can understand how a subscription model is desirable, as it sorta provides a predictable income stream. But in your case, where you try to reduce the risk for customers by promising to release the code as GPL after a few years anyway, wouldn't the traditional model make more sense, where users would 'own' one version of your product (esp. since you don't provide an ongoing service like hosting, apart from updates)? As a customer, my costs would be more predictable with less risks, and you could always have a mixed model (like for example Jetbrains has with it's IDEs), where you could still charge 'per seat', and have a subscription-like model where people get cheaper mayor upgrades and maybe support if they pay annually.

As I said, I can understand choosing a pure subscription based model. But, personally, I'd be more inclined to spend money on something like this (or recommend your product as a consultant) if I could outright buy the latest version, or at least have the option (at a higher price, of course). I'm not sure at all that this is a common sentiment, so I might very well be in the minority here. But I'd still be interested why you choose that model...
They will fight each other at monster truck rallies. "Team Cyber" and "Team Hummer" shirts will sell out. Many corn dogs will be eaten.
I'm a software developer who maintains very strict separation between work hardware and personal hardware. I keep my work laptop at work and only take it home with me when I know I'll be working from home the next day. It's amazing to be able to commute with no bags or anything on the days I'm working in the office successively. If I was forced to WFH without notice due to Coronavirus and I didn't have my work laptop with me, I would not work at all. Someone would have to drive to my place with my work laptop or agree to pay for a new computer I'd buy for the purpose for those two weeks or so.
Google Map Fake Traffic Jam “Hack”
Lessons Learned about Generating Startup Ideas in my first 10 years as a founder
Like I said, I've lived on both sides of the world. It is probably hard to understand the cultural norms of living without rampant noise pollution if you haven't experienced it first hand.
As a westerner who's lived and worked many years in Poland, the factor that seems to explain a lot of this is that wages in Poland remain extremely low compared to most of western Europe.

The result of this is that people can't afford to just replace things as soon as they break. For instance I had a pair of nice, but not crazy expensive headphones that broke while living there.

It was very easy to find a shop that helped me repair them, but this involved a decent amount of manual work. It very unlikely this would have been more cost effective than just picking up a new pair on most other countries I've lived.

If we put higher taxes on plastics and other materials so that the cost of labour vs. the cost of physical goods were similarly changed I bet we'd see a lot of improved behaviours like this also in the more affluent parts of the world.
I never use semicolons in js except in for loops like
for(let i=0; i<100; i++)

In all other places it isn't necessary anymore.
But when do people need to do more than a handful of mental calculations? While you might be faster with a mental abacus than with a calculator, I doubt that you beat an Excel spreadsheet. If Excel is unavailable for some reason either the source data you would need is unavailable too, or your mental calculation speed is not fast enough to be useful, even with the mental abacus.
A process to do safe changes in a complex codebase
Do you also personally die a violent death when your character gets shot on-screen?

That's where he's getting at at the end of what you quoted. Non-realism is necessarily a part of any game environment, in this genre at least.
It was a quake engine bug, which followed into GoldSrc, the engine developed for Half-Life, and thus Counter-Strike.

Quake-like games embraced bunny-hopping because I guess they were already pretty "unrealistic" whilst Counter-Strikes entire schtick was about the "realism" that it brought to the scene.

And bunny-hopping wasn't removed until 1.4, where they added a movement penalty every time you jump. It was softened in 1.5 after a lot of discord from the player base.
Speedy Cutover Service – electromechanical to electronic phone exchange (1984)
Not really, communists didn't get that right. That was not something they intentionally planned or wanted, this was an accidentally positive byproduct of a "shortage economy".

The economy wasn't producing sufficient amount of consumer's goods, so it did not produce consumer wastes as well. And if it produced something, it was primitive, communists simply couldn't produce plastic bottles because they didn't have technology to do that, not because they cared so much about environment.

The economy was producing goods like tanks, mines, bombs, guns, etc. and was doing this in a very ineffectively way, which harmed environment a lot, just in a different way, no plastic bottles, but rivers polluted by industrial wastes, air polluted through coal-based electricity production without worrying about proper filtering, etc.

Same with urban planning. They had to do urban planning the way they did as people simply didn't have cars. BTW some districts like Warsaw's Ursynow does not have sufficient number of shops, schools etc. anyway - buildings are randomly scattered and quite distant from each other, but, again, it wasn't done to make that place nicer to live, to give people more space, but to make it impossible to build barricades between buildings. Commies knew how they were loved by people.

Right now in Warsaw there is no urban planning at all, but that's totally different story (with huge piles of money, incompetence and corruption in the background).
I hope you're joking. What's good in removing species from their natural habitat? This could create a massive imbalances in any ecosystem.
> Being aligned with teammates on what you're building is more important than building the right thing.

I would write this as:

Building the right thing wrong is more important than building the wrong thing right.

And I firmly believe that agreeing on _what_ you are builing is more important than _how_ you are building it. Mainly because it is easier to change the _how_ than it is to change the _what_.
I would prefer being chopped in half to be buried alive in a book cabinet. And I'm not even a book, I'm a person.
Maintenance is not a “problem” even if I am the maintainer or in my case, the “rearchiterer”. It’s what they are paying me to do. What a company needs at one phase of its existence is different than at another phase.

It would be just as wrong for me to come into a company at the beginning of its existence when they are just trying to go from 0 to MVP and worry about unit tests, branching strategy, and “process” as it would be to promote the pioneer to a team lead.
Would you recommend that book to a software engineer with an interest in Maths?
For many years my purchasing policy for test equipment was "no schematics, no sale". I still try to stick with that as far as possible, but it means I don't buy much new equipment.
Hunting ‘slowly dying off,’ and that has created a crisis for endangered species
Seems like people who want a Hummer that can do Ludicrous Mode would be a good market.
For the whatsapp encryption scheme because the IV is fixed per a media key is there any reason not just to set it all to zeros or a fixed value instead of using the KDF to derive it.
I clicked this expecting an overly opinionated list on how to do things the right way, but came away agreeing with nearly everything said.

> Writing non-trivial software that is correct (for any meaningful definition of correct) is beyond the current capabilities of the human species.

This is the one point I somewhat disagree with, and it leads to one of the things I believe about SE - it's all about perceived risk. Mission-critical systems work well because the risk is well-defined, and it's usually "people will die". In business, managers are happy to break rules when the perceived risk of it biting them in the ass is low. Small budget? Skip the tests, click around on deploy to see if it works, and ship it. Not enough time? Deliver a minimal product and build the rest later when we have the budget.

There are two examples I often use for this - Panera Bread and Pipdig. The former leaked millions of customer records, ignored the press for a few days, and got off with zero consequences. Pipdig did even worse, they did backdoors and DDoS code to attack competitors in their WP themes/plugins, and when called out they lied, hid the evidence, and then went back to selling themes to unsuspecting bloggers with zero consequences.

Both sides likely knew what they were doing was wrong, but the risk of getting caught was minimal, so why not break the rules? It probably saved them a ton of money in the long run.

> Being aligned with teammates on what you're building is more important than building the right thing.

I've no idea why so many of you are up in arms about this. It isn't about bowing to managers, or being a punching bag for others. It's about making concessions as a group to define what you need to build, and the best way of doing it.

> Peak productivity for most software engineers happens closer to 2 hours a day of work than 8 hours.

I'd stretch this to say that "on average". Some days I'll get 30 minutes of stuff done, some days I'll fly through work for a solid 8 hours.

> Thinking about things is a massively valuable and underutilized skill. Most people are trained to not apply this skill.

This is so true it hurts. I'm currently working on a project in an agile structure, and it's going like many agile projects I've worked on in the past. Agile is used as a buzzword for "fuck planning, just write user stories and be done with it", all while team mates bitch and moan about spending too long in "planning" meetings. The second we took the time to actually have these meetings and plan out our backlog, we made key decisions and discoveries about how things work, what edge cases we need to think about, what doesn't work from a user perspective, etc.

> How kind your teammates are has a larger impact on your effectiveness than the programming language you use.

Over the years, I've always believed that empathy is the best skill you can have in software, and that is often paired together with kindness. An empathetic team is often a kind team, and when empathy is a core part of a team it highlights areas where certain stakeholders don't share that trait.
A good alternative is https://www.lawtrades.com

Also you can call local offices and individual lawyers and build up a long-term relationship. I've done that for previous startups and they can easily handle most general work and introduce you to any specialists you need, while saving all the overhead of going with a firm or in-house counsel.
- "journey": check

- "humbled, honored": check

- complete shutdown < 30 days: check

- no context on what, why, and how it happened: check.

This is a sour post, sorry for that. Startups are hard, no question about that.

But as mentioned elsewhere, this type of posts just adds more damage and unclarity to a situation that is probably pretty dramatic for the founders, customer and employees.
Wrike (project management software) actually does this, but it is for only text descriptions which makes it easier. Wrike also color codes changes by user.
> I would read that as "it's more important that everyone has a common understanding of what you are building than it is to spend time worrying about whether you have the exactly perfect goal."

The fact is, that unless you have a functioning crystal ball, you don't actually know what the perfect goal is; you only have hazy guesses at best. At some point, extra time spent looking for the perfect goal is wasted, because one hazy guess is no better than the next. It's much better to get something that is well-structured and functioning out the door. If you've done your due diligence, it has as much chance of succeeding (or failing) as the next thing. And to get something well-structured and functional out the door, you need everyone to be working towards the same goal, even if they don't all necessarily agree that that's the perfect goal.

There's an argument that this is how ancient divination worked in practice. You don't know whether you should attack from the north, attack from the south, or hunker down and build defenses. You definitely can't do all three. It's much better to pick one and do it boldly than to dither around in indecision. Divination gets everyone fully behind one option; that option may not be the optimal one, but it's certainly better than "do nothing".

Which makes me wonder if maybe modern product management would be better with some oracle bones...
> Thing is, NASA (and Russian and Chinese and Indian and ...) space engineers have approached their challenges from the point of view of actual engineering, while modern "software engineering" is all about craftsmanship, and just a sprinkle of actual engineering to make ourselves feel good.

You are, of course, absolutely correct. Context is key here: you treat software engineering like "real" engineering when it's appropriate to do so (space flight, aircraft control systems, nuclear power plant monitoring and control, medical devices, and so forth).

However, I think for many organisations - and for much of the time - the engineering aspect is often heavily overplayed, and actually you're trading that off against two key aspects of software that can be used to build a real competitive advantage. Those being (i) speed of implementation, and (ii) malleability. Building software can get you to a solution very quickly. You can also iterate or modify that solution very quickly.

Clearly there are limits to this but for many companies, and most startups, getting something working quickly, and iterating on it quickly is far more important than any engineering merit. Same goes for larger companies introducing a new product: don't overegg the "engineering" because it will slow you down and time may be the only sustainable competitive advantage you have.

There's a time to be an engineer, and there's a time to be a cowboy hacker (and everything in between). The real trick is in knowing where on the spectrum to execute in the context of the customer base you're serving and the software you're building.
Why I Continue to Invest in Ruby
GM made a Chevy Silverado platform 'hummer H2' suv, that's what this article refers to, not the milspec Hummer made by AM General.

The GM 'consumer' Hummer was basically a pseudo milspec hummer and this new EV version will presumably be a similar marketing effort.
https://en.wikipedia.org/wiki/Hummer_H2
it was actually nice reading the article without the images
It's totally possible that I've been lucky in my career so far. Or just that my personality type lends well to this sort of thing.

There are exceptions to every rule, but I've negotiated with Russians, Chinese, Americans, British, French, Italians...and just about every other European country and probably a few others I'm forgetting. (Deal sizes have been 1m+, but there's definitely layers above that where I don't have experience.) In all my experience thus far, I can honestly say I've only ever had the displeasure of having to manufacture a 'loss' once. And that was dealing with an American, albeit he was working for a large Chinese company.

I'm always eager to hear about other folk's experiences, so if you can give some more insight into what cultures you've seen this with and how you've managed to handle it I'd love to listen!

edit - I just realized the tone of this might come off as a tad 'superior' and that's truly not my intent. If you have experiences that can potentially make me better at what I do, I'm genuinely eager to learn.
Unfortunately no details on the cause. The business model is valid and perfectly sustainable so it should be good news for LawTrades and the others.
It definitely should, but keeping your working set smaller can also make things faster (as seen by Chrome here). This depends very much on the workload and what's being done to the data in memory. My example was just that a raster image editing program probably doesn't require a huge memory footprint just to be able to edit images well (as a lot of the memory use typically is not the image you're seeing, but history and undo state, which is neither latency-critical, not frequently accessed).