![](/static/253f0d9b/assets/icons/icon-96x96.png)
![](https://fry.gs/pictrs/image/c6832070-8625-4688-b9e5-5d519541e092.png)
“Never install, carry or handle”. OK but what are they for then?
“Never install, carry or handle”. OK but what are they for then?
That’s the usual open source way. The config probably came later so they just added the option without changing the default because that would break backward compatibility.
And there would be too much boring work to build a migration.
I guess that wouldn’t help the deaf people though. (:
Bank holidays would be really awkward. You start wort at 23 and the next day is off so you would just have to work that one hour.
Office workers could probably move hours around. It would get complicated for shift workers though. Paying overtime for work on holidays?
Exactly! All applications can be shit, not just web sites.
People screw up CLI’s all the time (looking at you Google Cloud). They (used to) insist on using my installed python which automatically upgrades and breaks the CLI. Good job python. Good job Gcloud.
Yes you should. I think most comments here are about products that have millions of users where it’s actually worthwhile spending all that extra time and money to perfect things.
For most development, it isn’t worthwhile and the best approach is to wing it, then return later to iterate, if need be.
The same goes for most craftsmanship, carpentry in particular. A great carpenter knows that no-one will see the details inside the walls or what’s up on the attic. Only spend the extra time where it actually matters.
It triggers me immensely when people say “I could have made a better job than that” about construction work. Sure maybe with twice the budget and thrice the time.
102 times if you count the one before the code.
This is more toxic then funny.
Noobs don’t know to avoid snaps… But that setup wpuld be good to recommend if a noob really needs to use arch, btw.
Just get Krita already!
That’s not how randomness works. You would want to randomize once, saving the number of steps remaining until the bullet is the next shot, decrementing the number of steps for each try.
That’s what they meant by Dark pattern.
That leads to focusing on the nitty gritty details first, building a library of thing you think you might need and you forget to think about the whole solution.
If you come up with another solution half way through, you will probably throw away half of the code you already built.
I see TDD as going depth first whereas I prefer to go breadth first. Try out a solution and skip the details (by mocking or assuming things). Once you have settled on the right solution you can fill in the details.
Right,too much coverage is also a bad thing. It leads to having to work on the silly tests every time you change som implementation detail.
Good tests let the insides of the unit change without breaking, as long as the behave the same to the outside world.
As little as possible,I think
They don’t want to pay architect salary to do decorating work and I fully agree. Problem is that stuff like this are often overlooked until someone makes a fuss about it, costing PR. The other 90 % of the overlooked stuff is never found though so it’s still a good decision to skip stuff like this.
I have done 14k edits over six years. I too like it for being therapeutic. I’d rather do micro-edita on osm than play another level of candy crush. Same kind of reward but you are also helping out creating something larger!
Honestly though, I don’t think osm will ever catch up to the commercial alternatives. Mostly because their harsh stance against automatic edits (and lack of version control). Also the lack of standardization is a problem. It’s very hard to create client applications because the data is structured way different in different regions.
It’s actually the company’s problem. They usually opt to add more debt though, rather that wade through the old stuff.
In the end, all software sucks and should be replaced as soon as possible. Code quality is a lie we tell ourselves so that we can sometimes be proud of our work. It’s usually the code we are most proud of that is the worst. Design patterns everywhere making the vode overly convoluted and “future proof”. The only future proofing that happens is that no-one will understand it, so they won’t change it. Trying to design for the future usually makes it harder in the future.