akdas

One thing that I've seen implemented to prevent that is to have the pay bands for level N and N+1 overlap. So in the time that you're doing "next level" work, you're expecting to be at the top of your current pay band, and then the promotion doesn't automatically give you a big pay raise, but it unlocks a pay band that you can go up in.

This works if performing at the top of your current level equates to performing at the bottom of the next level. That said, there's a problem where sometimes a "promotion" is really a new role, meaning to perform at the next level, you have to kind of not perform well at the current level.

Shameless plug, but I wrote some blog posts because I had a lot of the same questions. In my case, I wanted to learn the WebGL APIs, so I wrote two posts:

* https://avikdas.com/2020/07/08/barebones-webgl-in-75-lines-o...

* https://avikdas.com/2020/07/21/barebones-3d-rendering-with-w...

I still go back to them myself to refresh my memory. It's funny that I called this a lot of boilerplate, but Vulkan is known to have even more.

This won't answer all your questions, but maybe it'll answer some of them.

I was thinking the same thing. Usually, you'd want to write the new code to a page that you mark as read and write, then switch that page to read and execute. This becomes tricky if the code that's doing the modifying is in the same page as the code being modified.

To expand on this: the "unit" here represents the number of possible values that can be returned.

The confusion is probably because "empty" can mean two things:

- What's inside the returned value. That may be why the parent suggested empty for the unit type. But that's now what "unit" means in the common parlance.

- How many possible values can be returned. Never returning means the function has zero possible return values.

The Birth and Death of Javascript. One of my favorites! https://www.destroyallsoftware.com/talks/the-birth-and-death...

I recommend reading the previous 3 parts too, plus I'm looking forward to the next parts. I love that it goes into details and very clearly explains the problems and solutions, at least if you're familiar with C and know some things about compiler implementations.

A while ago, I created an interactive explanation of the different parts of a minimal ELF file: https://scratchpad.avikdas.com/elf-explanation/elf-explanati...

I wrote this page for my own compiler that I'm working on, but I think it would be a good complement to this article. Note that the page is not that great on mobile, the extra real estate on desktop really helps.

I started on two resources on different topics. One day, I want you invest a good amount of time into building them out.

https://cstheory.avikdas.com/

https://nesdev.avikdas.com/

Thank you! My passion is teaching, and I created interactive visualizations for a CS theory class I taught: https://cstheory.avikdas.com/

If you're interested in collaborating for your classes, reach out to avik at avikdas dot com

Thank you! That means a lot to me

Thanks for the feedback. I replied in a sibling comment about how I made it.

For the bug, feel free to email me at avik at avikdas dot com if you'd like. The behavior I verified just now (for me) is that if you click one byte to highlight it, then clicking any other byte in the same group will remove the highlighting.

I wrote it all by hand :)

Lately, I've been using Svelte for interactive visualizations (see my post on using a tool called Astro with Svelte: https://avikdas.com/2023/12/30/interactive-demos-using-astro... ). But this one is all hand-written JS!

Writing an ELF file by hand is something I did recently: https://github.com/avik-das/garlic/blob/master/recursive/elf...

To explain the format to myself and others, I also created an interactive visualization for the bytes in the file. It helps me to click on a byte, see an explanation for it and see related bytes elsewhere in the file highlighted. https://scratchpad.avikdas.com/elf-explanation/elf-explanati...

All things considered, the GBA is a pretty powerful machine. Running an ARM processor is helpful too, as high-level language compilers that output high-quality ARM code are common. It's for this reason the GBA is one of my favorite machines, since it hits that sweet spot between simplicity and power.

It's the Gameboy and the NES, running a Z80-style and a 6502-style processor respectively, that typically need more hand-holding from manually written assembly code. It's not just the processor but the lack of hardware features (such as lacking multiple background layers, the relatively low number of sprites that can be on screen at a time, etc.) that result in squeezing out extra performance to overcome these limitations in creative ways. Compare that to the minesweeper game just rendering all the board cells as sprites!

I absolutely love the "What's In A GIF" series. It's what inspired me to write my own GIF decoder while learning Erlang at the same time: https://github.com/avik-das/giferly

The first time around, I struggled a lot with decoding errors. Many years later, after being a more experienced developer, I wrote the LZW decompression with unit tests. Doing so forced me to think about each edge case, and fix issues without breaking existing functionality. Very quickly, I was able to open pretty much any GIF file I threw at it!

https://avikdas.com

A few of my posts on dynamic programming got a fair bit of traction here on HN.

I haven't posted in a while, but after a busy few years, I have some posts lined up. I want to reflect on some teaching I did (one big reason I didn't have time to blog), as well as document me getting a new home server set up (this time with containers, finally).

I haven't written in a while, but the first year I started blogging, I set a goal to write at least one article each month for a year. I reflected on it after the 12 months. The highlights:

- I got to the front page of HN a few times. Definitely a vanity thing, but it was fun!

- My posts on dynamic programming, which got a lot of traction, resulted in someone I knew reaching out to ask me to speak at a conference they organize. The conference didn't result in much professionally, but I love public speaking. It was just a great experience.

- I mentioned off-hand that I got to talk about DP, and that got me connected with someone who was able to create a video course on the topic. I learned a ton thanks to their guidance on things like how to organize smaller chunks of information that build up to a bigger course.

- Another post about mental health got me a chance to be interviewed on a podcast. I'm a huge podcast listener, so I was ecstatic about actually being on one!

With the confidence from the 12-month experiment, I then decided to write weekly about hiring in the tech industry, a topic I'm passionate about. I kept that up every week for over a year! What came out of that is I had a bunch of thoughts floating around in my head, and now I have them documented. Now if I want to bring up something about hiring, I probably already have an article I can just link instead of explaining it from scratch. The same actually applies to some topics on my personal blog.

EDITED: Regarding that last point, I've been setting up a Raspberry Pi after a few years. Having some notes documented has been invaluable for myself.

This clearly solves the halting problem (we assumed the existence of halt as the first step of our proof by contradiction).

Implementing the halting problem using addition does not assume the existence of halt. It assumes the existence of addition, and you use that to show that halt must also exist. And that's not possible to do.

To implement halts using addition, you need to:

- Take the input to halts, namely the source code to a program.

- Convert that into an input to addition, namely two numbers.

- Call into addition, which adds the numbers.

- Use the result of that addition to infer whether the original program halts or not.

Adding to this, if you imagine the audience is _you_, then you might feel motivated to write the article you _wished_ you had before embarking on your project. That audience falls under your second one ("another retro renderer enthusiast who has similar projects"), but maybe is even more targeted.

One advantage of this is being able to look back on previous projects in the future, as a form of documentation. That helps me pick up on a project I haven't worked on in a bit. True, you don't need to publish the documentation publicly, but since I wrote it, putting it up publicly is almost no effort now that I have a blog.

This is a great example of intent vs. impact. Regardless of the intent, the impact was negative. Recognizing how their actions impact the candidate is a huge part of interviewing, and the interviewer should have seen the candidate get nervous and adjusted.

That said, given that candidates are generally nervous to some extent anyway, and semi-colons shouldn't matter in a whiteboard interview, that joke seemed like in poor taste to me. That underscores why we need better training and mentorship for interviewers.

What's so interesting about this experience it hits so many of the points I've been complaining about in my writing about hiring in the tech industry[0]:

- Giving trick questions that have an "insight" moment, instead of one that has multiple answers, even partial answers to build off of.

- Not letting the candidate pick the language they're comfortable with. The candidate may even know the language they're asked to code in, but if they haven't been working with it recently, an interview is not the right time to pick it up again.

- Making the candidate nervous, both by not being helpful and by watching over them with unnecessary scrutiny.

- Looking for flaws instead of strengths.

People, myself included, are always talking about these problems, but companies have so much inertia, they are not evolving fast enough to solve these problems. No wonder tech companies are filled with people who, while capable, often fit a particular mold, and why we end up in situations where products don't reflect the needs of the market (because the people working on those products aren't representative of the market).

[0] https://hiringfor.tech/archive.html

I'm defining feminism, as defined in literature such as _Feminism is for Everybody_. It's a pretty objective definition, as these are the grounding principles of the movement.

feminism as a movement isn't really for equality, they say they are but they aren't really or else those wouldn't get accepted in the movement

You keep bringing this up, but you haven't provided proof. Whereas people blaming women (instead of cultural sexism as a whole that's practiced by both men and women, and therefore the target of feminism) for their problems has plenty of proof in the comments here.

To be fair, there are people who call themselves feminists while being toxic, such as Trans-Exclusionary Radical Feminists. Mainstream feminism decries these groups, as evidenced by the backlash against J.K. Rowling. This kind of exclusionary behavior is _not_ acceptable.

And finally, if you believe in equality, then let's champion it. Even if you believe that women are making it hard for you, positively commend those who are behaving in an equitable way, and the same for men who are behavior in an equitable way. _We_ get to decide how the world should be. Let's make it happen!

There are a lot of strawman arguments here. I've never heard feminists say any of these things because they are antithetical to the concept of equality for all. I'm a feminist, and asking for men's spaces is something I do. Feminists want spaces for men. Feminists want people to bring up male issues. Feminists don't want men to be stoic.

If they really wanted men to cry more then they should encourage women to handle that burden rather than totally drop the ball and shame men who dare to cry.

There's some truth to this, but it's also omitting something that's extremely important (and therefore changes the entire tone of this argument): we should also encourage men to handle that burden rather than totally drop the ball and shame men who dare to cry. It's not men vs. women. It's men and women together. That's what feminism is.

In a world without gender roles, men (and women and non-binary folks) would be valued just for being human. That is, everyone has value, even if they don't provide "value" (which is subjective and changing anyway) to others.

Yes! This was a central point in my previous article "Why men's health depends on feminism" (https://avikdas.com/2020/11/01/why-mens-health-depends-on-fe...). You might imagine the type of misogynistic responses that one got, so I wanted to directly connect observations to recommendations this time around.

I wasn't sure what kind of response this article would get, so I didn't want to send traffic to MensLib without some further information. I posted the article there already, and I do think that's a great forum. Even then, based on my previous experience, I see some woman-bashing on MensLib sometimes, so I think we need to do even better.

Other than that one, I don't know of other such positive men's spaces.

Nope. Feminism is about valuing people as people, regardless of what gender roles tell us about how to judge them. What you're talking about is a gender role, which is explicitly what feminism is against.

I wrote this article because the experience of these transgender men add to my own personal experiences, sometimes affirming my experiences, sometimes providing a new perspective. I have written other articles before from my own perspective.

This is exactly why I expanded on the original article! I have been advocating for all the same interventions, but to hear it from those who have experienced both worlds is a great affirmation of my one-sided experience.

I don't think the quote in my article suggests you need to want those spaces. But I do. Cotten does. And it's hard for us to find those spaces.