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:
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.
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.
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.
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.
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!
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.
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.