2,163 karma · joined June 1, 2023
While we are at it, also spend another year learning technology and design patterns to prep for a design interview.
Listen, nobody gets a job at Google because they studied for coding interview. Coding is a precondition of getting the job, but it is far from enough to secure it.
You only turn on actual power when it is firmly connected and you turn it off immediately when there is any signal that it might be disconnecting.
Remember, for most starting developers (which is almost all developers), a GitHub account is an essential part of their job search, just like having a LinkedIn account.
And then at a lot of companies you get a separate GitHub account because companies do not really want to deal with your personal account, they want to manage it to enforce 2fa, to be able to disable it when you leave (as if it mattered), and so on.
Well... if they are able to craft a call to a syscall from some random piece of memory you are already f-d and this little hurdle is at most going to be an annoyance.
I also have a little bit of a fetish. I really enjoy it when other people do their work correctly and do those small things that show their prowess. And I like to to think somebody someday sees what I did and will enjoy it the same.
That's why, when I sail, I always have all my lines neatly tied and organised. And use proper knots for their applications. And look at other yachts when docked to see if their owners know what they are doing or not.
The car's position is not discontinuous, the velocity isn't either (in both cases it has to slow through intermediate velocities).
It is the decelaration that in one case grows suddenly and in the other changes smoothly.
On an egg, there is no place where curvature changes suddenly, and yet on a four point egg there are points where it does exactly that.
> If you want to refute the theory you need to attack the main argument
I did not mean to address any arguments for or against simulation. And definitely did not want to refute the theory.
Where did you get that idea?
I am just saying to be careful about assuming too much about the world that is running the simulation in case we live in one.
* The physics of the world that is running the simulation can be completely different from ours. Just like we can put together a bit of software that runs a computer simulation with pretty much any rules we want.
* Even if the world that is running the simulation has a similar concept of time as ours, it is not guaranteed that the rate of simulation is constant. So if our world gets more complicated the simulation rate might be slowing down and we would be none the wiser. Just like a computer physics simulation does not have to progress at a constant rate (in can render things faster when there is less entities and then slow down later when there are more entities -- to produce a movie that runs at a constant speed).
* We have no idea yet what are underlying rules that govern our world, let alone be able to infer anything about the simulation based on it. Claiming that quantum physics is because of limitations or bugs in the simulation is at the very least super premature.
I am careful not to say that we are or are not simulated and that's because I simply believe there is insufficient data. I think there are some convincing arguments for the simulation in the way how the rules seem constructed to prevent us from understanding what is really happening. But there might just be a good explanation for this just like there is a good explanation for general relativity that comes directly from understanding some mathematical facts.
It is called accountability and if nobody is accountable for anything then there is no actual motivation to get businesses and financial institutions to do anything about it.
What is counterproductive is blaming and persecuting wrong things.
The goal is to get companies to be accountable for being committed to taking this process seriously, providing honest information whenever it is needed and then to honestly implement the recommendations once the process is concluded.
We know that technical bugs happen regardless of good intentions. So we should err on the side of being lenient.
Where we should not be lenient about is simple negligence where all of the information was available and the decision was made regardless. For example, if the manufacturer knew that bolts were lying around and decided to save on the costs by being willingly blind to the fact.
And where real persecution should strictly follow is hiding information and evidence that is obviously needed to improve safety.
The reason it could not be done with cars is the drivers. Drivers simply cannot be held to the same standard as commercial pilots or staff.
Remove the driver from the equation and it might just be possible to replicate the process.
That assumes regulation that will require "operators" to provide truthful reporting of accidents.
> It would be something like a fusion of Clojure and Common Lisp, (...)
Mine would be, too. Unfortunately, that's not possible. Clojure is one of those few languages actually designed by somebody who knows what they are doing. Clojure's limitations come from the limitations of the platform it is running on and certain design criteria (interoperability) that were necessary for its success.
As I am an avid runner and I train daily, I pay close attention to all sleep, heart rate, stress, and running performance numbers.
Unfortunately, it will frequently say I had good night of sleep when I definitely feel groggy or the opposite.
As to misclassifying idle time before and after sleep, I recognise that simple lifestyle adjustment could fix it (just don't browse on your phone before sleep!) But that of course won't fix it if you try to lie still but can't fall asleep.
It is simple, you break up whatever improvement work you want to get done into small enough pieces so that these pieces can be included to use up any capacity margin during your development cycle.
You always want to have some spare capacity to fill with improvement work. This way you can manage unplanned work by temporarily reducing your improvement work rather than overrunning your project.
The important part is that any improvement needs to be broken up into small enough pieces that each can be shipped separately. You don't want half done, unshipped work to be a continuing feature of your development process putting an overhead on everything you do.
As to refactoring, best refactoring is usually done in small increments. I look at the codebase, I see something I do not like, I pick one thing I can fix here and now. Lather, rinse, repeat.
Some of the worst mistakes I have seen that really put the existence of a project in question was bright developers getting their managers to agree on a huge step change and that change never getting done. This usually is some sort of rewrite even if devs try to hide the rewrite. Usually they say "let's create a brand new service where we will keep everything clean and then we will slowly migrate the functionality from the old to the new". And it rarely works.
Because of these experiences, I have pretty much banned rewrites at all projects I work with. I now understand that a rewrite carries with it a huge amount of various risks and that people are biased to overestimate the costs of the ugly stuff they see in the old application and underestimate the risks of things they are not aware of when deciding to do the rewrite.
So: 17 judges decided some measures need to be implemented of which one of the judges objected to some of the measures.
Also it is not a ruling on whether this is or isn't genocide. In simple words, this is a rule "in case" this is later found to be genocide, to prevent any further damage that could happen before court submits its final ruling.
* soil,
* climate,
* harvesting process (for example, you get different results if have somebody harvest by hand the ones that are ripe vs when you send a machine to harvest an entire side of a hill),
* fermentation/preparation process,
* roasting process,
And that is before even you choose what you do with your beans. Any grinding, brewing method will produce potentially very different flavour profile because coffee brewing is notoriously sensitive to minute changes in grind sizes, grind size consistency, temperature, pressure, duration, level of flow of water through the grinds, etc.
And then the question of how much you dilute the brew or what you add to it.
You can get very different results from two different processes:
a) make espresso into the cup, pour milk, add ice
b) put ice into the cup, make espresso over the ice, pour milk onto it
which is exact same ingredients, just a different order.
You can get the coffee to taste very, very differently based on what you put in your mouth before you drink the coffee. Try drinking a sip of coffee, then put a piece of cake in your mouth, eat the piece, then make another sip of coffee. You will find the coffee now tastes completely different.
The dimensionality of the space of all parameters is enormous.
I always remind myself there exist people much smarter, much more motivated and with much more time on their hand who think about these things and figure stuff out.
To deal with the problem (of security) seriously, the only possible sane policy is to not provide ANY unnecessary information under any circumstances. And that might not be enough, because the information that is legitimately needed to get the things we want might already be way too much.
I have a personal domain with a catch all configured. So back then I would just give a name like adobe.com@<personal-domain>.
When they leaked my password I contacted their support and they flatly told me that's not them who lost the password, even though evidently the mail itself was tailored specifically for Adobe.
It is likely the support was told to follow a script when a concerned client contacts them and there is no way they are going to tell you anything else regardless of the specifics of your case or how absurd their arguments are.
When I learn something is very cheap or free, my first though is definitely not "what an occasion!", my first thought is to look for the fine print and start from the position of distrust.
"You will not get what you haven't paid for."
Paying for things does not guarantee good service or product, but buying things for cheap or getting them for free (from commercial entities) pretty much ensures you get crap and/or strings attached.
I can understand people who have no money trying to get by paying as little as possible for things. And I do not criticise.
Occam's Razor is just a useful mind tool that helps us navigate the world based on the observation that oftentimes the simplest explanation tends to be what is actually happening.
BTW lots of other logical mistakes.
With Windows, if it doesn't work, there is a chance there simply is nothing you can do about it. There is no source code. The support people are completely useless. If you can't fiddle with it until it somehow works or find a person on the Internet that fiddled with it until it worked and they were gracious to share the solution, your only option tends to be to reinstall the entire thing and hope for the best.
I know Linux works more reliably for some people and less reliably for some others. It probably has much to do what you do with it. What kind of hardware you are running it on, do you just install it and use it as it is or you are the kind of person like me who likes to change everything to his liking.
I also tend to not like to reinstall my machines. For about 15 years my daily driver was a single Debian unstable installation which was continuously updated until I faced too much problems and had to completely replace it. I would have fixed it all but I just did not have the time and I needed it working.
"Google Maps began as a C++ desktop program developed by brothers Lars and Jens Rasmussen at Where 2 Technologies. In October 2004, the company was acquired by Google, which converted it into a web application."
"In 2004 Google bought Keyhole Inc., which was partially funded by the Central Intelligence Agency's venture capital arm, In-Q-Tel. Keyhole had developed an online mapping service that Google rebranded in 2005 as Google Earth."
"Gmail was a project started by Google developer Paul Buchheit, who had already explored the idea of web-based email in the 1990s, before the launch of Hotmail, while working on a personal email software project as a college student. Buchheit began his work on Gmail in August 2001."
Condescending on a response was because a guy didn't even bother to read my comment and was putting stuff in my mouth that I didn't say. And also because uses condescending language (like "hilariously absurd") when clearly wrong.
Do I think people should be nice to each other? Yeah, I do. But I also believe my self-imposed obligation to being nice to you is conditioned on you following minimum rules. I am not expecting much, really. Like don't say I wrote something which I did not. Or put a minimum effort when writing an article if you expect kind response. If you don't do it, I reserve my right to respond about it the way how I feel.
I believe requiring everybody to be nice to everybody else in every possible situation is not a good way to have an advanced civilisation. I think there was a Black Mirror episode to that effect.
Nowhere I called them "hunter-gatherers". That's something YOU wrote. You took words "hunter" and "gathered" and created in your mind "hunter-gatherer" which is completely different because it has a specific meaning.
People are still hunting and still gathering to this day. This does not make them hunter-gatherers. Hunter-gatherers describe a civilisation that is primarily concerned with hunting because they do not farm anything. These people were clearly farming, but farming does not exclude hunting or gathering.
The pottery, bones, compost and manure do not indicate advanced knowledge of farming. This just describes a dumping ground of a pre-industrial civilisation. That's pretty much all of the garbage they had. And they had to throw it somewhere and that somewhere was around them where the fields were.
I am not saying they didn't have any knowledge, but saying they had advanced knowledge is just jumping to conclusions.
I don't know how to tell this without being condescending, but do you guys even understand how farming works?
The fertile soil is a result of a long process of bringing organic material and ash and depositing it on the field. Exactly the opposite of what we are doing today
When they lived in the rainforest, they would gather whatever leftovers from eating, possibly their feces, decaying matter, and deposit it all on the field. They would keep hunting, they would keep gathering, and all that hunted and gathered material would end up on the field. Maybe they would compost it separately and then drop it on the field, maybe they would drop it on the field and the field would be in effect the composting area. Over hundreds or thousands of years this would create those amazingly fertile fields.
It is very easy to see how this developed. They probably have noticed that if they keep throwing their leftovers or feces in a particular area, everything starts growing better there. The same if you throw out ash. Which they had lots of beacuse they were burning a lot of wood every day, living in the rainforest and not facing energy price hikes. If you have a village and you hunt and gather every day, if you constantly keep burning wood fire and spread it all around your village for thousands of years -- guess what -- whether you planned it or not you will create those fields because I bet nobody would be trucking the garbage far from the village.
The problem is we do not live in the rainforest and we do not have so much organic matter to cover our fields. And the leftovers from what we eat we dump mostly into landfills. Our feces are also escaping the system and are not providing matter back to our fields.
First of all, the yellow light bulb might not be enough to reach with the heat to the red and green lights. And since it is only turned on for a brief moment, might not be providing enough heat. And will still be wasting heat when it is not needed.
Even heating it up when it is cold is a waste of time. I can only guess at the number of nines, but 99.9% of the time you can get away without heating even when it is very cold, because the conditions are not right for the snow to accumulate (read -- it is not snowing, the temperature is not close to zero degrees celcius and the wind is not blowing in the right direction).
The only time the heat is really needed is when the lights are obscured with snow.
So here is a better design: have a photo cell inside the light to detect if the light is reflected back to the photo cell. The cell is isolated from the rest of the inside but has a clear access to a small portion of the glass in front.
When snow starts accumulating on the glass, the traffic light will start getting scattered in all directions including getting reflected back inside the traffic light and into the photo cell.
You can easily discern between light from the outside from light from the traffic light by seeing if it follows the pattern. Ie. constant light from outside regardless of the light turning on or off means it could be something like a sunset shining into the light and we need not worry about it.
What we are looking for is a clear difference in light shone into the cell when the traffic light is turned off vs when it is turned on. If I can do that there is probably other, smarter people who can figure out even better solutions.