I did the first 27 chapters of this tutorial just because I was interested in learning more and it was thoroughly enjoyable: https://mariokartwii.com/armv8/
I actually quite like coding in assembly now (though I haven’t done much more than the tutorial, just made an array library that I could call from C). I think it’s so fun because at that level there’s very little magic left - you’re really saying exactly what should happen. What you see is mostly what you get. It also helped me understand linking a lot better and other things that I understood at a high level but still felt fuzzy on some details.
Am now interested to check out this ffmpeg tutorial bc it’s x86 and not ARM :)
This looks to be very cool will check it out. Wild to see it on a Mario Kart Wii Site, but I guess modders/hackers are one of the groups of people who still need to work with assembly frequently.
The Revel app (which is rolling out rideshare in NYC where all drivers are actual employees) has a rating system that’s explicitly labeled something like “Bad - Okay - Good - Great - Amazing”, where the default selected option is “Good”. I think it’s really nice because then it’s clear that most of your rides should be in the “Good” zone and the higher ratings are really for special cases. On the other hand the ratings are really for Revel - as a rider you can’t see your driver’s rating.
First of all, many people take criticism personally. It’s a very natural thing to do. So there’s nothing wrong with you! And it’s not a flaw. It’s a naturally occurring phenomenon, so if it occurs, there’s really nothing you need to do about it - it will pass on its own, and it’s not an indication that there’s any problem with you whatsoever.
That said, it of course can feel unpleasant! And if it interferes with how you function in the workplace, perhaps it’s not useful to you. So for instance, if it causes to lash out at your coworkers for their feedback, then it would be important for your relationship with them to not do that. But based on your description it already sounds like you aren’t doing that, so it sounds like mostly an issue that’s internal to you, right?
If that’s the case, and really the main concern is for your emotional and mental well being, then there are kind of two different dimensions on which to address this.
First, as I said before, if you receive criticism and take it personally (whatever that might mean for you - sadness, anger, various thoughts arising), the way you’re feeling at that moment is exactly how you’re feeling at that moment and it is a completely natural phenomenon. You can’t undo how you’re feeling, or go back and react differently. So if you can see your feelings as naturally occurring and not indicative of some fundamental flaw, over time, even if these “taking it personally” reactions occur, they won’t bother you quite so much. This is the dimension I might refer to as “how you relate to the content of your experience”. IMO this is the more important dimension because it’s really in our control and is universal to all aspects of our experience!
Second, there might be ways to consider and address what’s causing you to react the way you’re reacting, but that’s a bit harder without being able to ask some more questions about what you specifically mean by “taking it personally”. Is it anger? Sadness? Guilt? Is it fear that people will think you’re bad at your job? Do you feel bad yourself for having made a “mistake”? Investigating what specific assumptions are going into this (maybe with the help of a therapist or some other trusted party) might help uncover what’s leading you to feel bad when receiving criticism, and then perhaps address that directly. This is the dimension I might refer to as “addressing the content of experience”.
Without talking to you more I can’t help much with this second dimension, but I can say a few generic things to take a stab at it:
One thing I might point out is that you used the word mistake several times - so it sounds like you think there was a right way and a wrong way for you to have done the task, and you did it the wrong way, and that’s a Bad Thing, and these comments are pointing that out, and maybe you’re afraid that means YOU are bad (or that others think that). In reality, while yes, the first code you put up might have had a bug, that is not some kind of absolute failure on your part. The whole reason code review exists in the first place is people will always be writing bugs and bad comments! It’s a learning experience. Substantive patches are rarely approved the first time without comments. (You did even said they were “honest mistakes”, so it seems like you know it’s natural for them to occur - so maybe my comments here are off base with what you’re dealing with.)
On the other hand if you feel like other people don’t know it was an honest mistake, and you’re worried about how they perceive you, the thing that helped me with that concern was realizing that I’m exactly as good at my job as I am, and no matter how much I try to control the way I’m perceived, over time people will recognize if I’m bad at my job or will recognize I’m good at my job, and that’s just how it is.* So all I can do is try to do a good job and learn from my experience, and other’s perceptions of me will play out accordingly.
Again I don’t know if these last two parts help or address your particular concern without talking to you more but am including it just in case.
Also just in case, I want to say it’s possible that the team you’re on is not following best practices for code reviews and that their criticism is coming off as overly harsh for that reason. So it might also be worth looking online for some code review guidelines to see if people are acting accordingly or if they’re saying things like “Lol I can’t believe you forgot a semicolon here, jeez, what are you, a noob?” (Being silly on purpose here but there are more subtle versions of this that can make people feel not so great.) Even if that’s true all of the above still applies I think, but it might be good to know or address if people are commenting in inconsiderate or mean spirited ways.
Anyway best of luck!
* ignoring cases here of people who are somehow extremely manipulative to hide their incompetence, which I’ve fortunately never witnessed, and I assume most people don’t want to be like that anyway so I’m not addressing that
In the book Getting Things Done the author explains that your brain is basically a really bad reminder system. So if it thinks there’s something you needs to do, it will basically keep reminding you of that thing at all times until you do it. So for each of these things, there’s what the author calls an “open loop”, and the brain keeps telling you about it until the loop is closed.
The way out, the author says, is to have a trusted system for storing information outside your brain. In that trusted system, you can write down what needs to be done for each open loop, and that basically closes the loop for your brain and it will stop reminding you of that thing all the time.
I still haven’t gone fully into doing it but my director at work swore by it, and the few times I tried it it was almost like magic. Even if you just pull out a todo app or notebook and for each of the things currently looping in your head, write down only the next step you need to take regarding that open loop (and maybe what the desired outcome is - I can’t remember if that’s in the book or not). For me the first time I tried it it was magical - it turned out there were only 4 or 5 things total looping on my mind at the time and after doing this exercise my mind was basically blank - the reminder system stopped telling me there was something I needed to do for these loops.
I think for it to be sustainable you probably have to really make sure you follow up on the things you write down so that your brain actually trusts you’ll do the things you wrote down, but at least for me it worked really well as a short term hack on a few occasions. I really need to finish reading the book!
I _had_ a trusted system way back in high school: my daily planbooks. However, when I tried getting back into the habit, I routinely find the problem of brain dumping all the open loops, then setting the book aside and forgetting to look at it for two weeks.
Part of the problem, I believe, is the nature of deadlines I handle as an adult compared to as a student. As a student, the majority of my assignments were due within a week (if not due tomorrow), so it was easy to track that everything was finished. As an adult, everything is either due by EoD (and therefore has no need of being entered in the system) or due six weeks out (I never did develop the work ethic to beat procrastination, even as an A student).
>I routinely find the problem of brain dumping all the open loops
set a time limit, i create cards on a kanban board, write a subject and dump my task list for either a minute or until i notice myself shifting thoughts.
>setting the book aside and forgetting to look at it for two weeks
then you realize, dump a card reminding you to look at it again in less than 2 weeks. keep a metric on how often you look and reward yourself when you improve your metric. the real magic comes when you're sitting around not doing anything and you look at that todo list... and then work on it
I have found your git activity tracker is a good at-a-glance method of determining your procrastination levels
Another part of Getting Things Done is to have a weekly review. Look at all the open projects in your trusted system and make sure you know the next thing you need to do for them. Look at your calendar and figure out what else you need to do. Think through the areas of your life and figure out what projects are in your head but not in your system.
There is a bit more to Getting Things Done than just to do lists.
> I routinely find the problem of brain dumping all the open loops, then setting the book aside and forgetting to look at it for two weeks.
Even as a student I had this problem. My solution was to write on sticky notes and put them on the wall directly next to my desk. I could no longer forget about them, and could easily remove each one as I completed it.
> you can write down what needs to be done for each open loop, and that basically closes the loop for your brain and it will stop reminding you of that thing all the time
This plus just do the thing and it's like a super power. I realized I was letting simple things that take little time roll around in my head all day because of procrastination. So now, if I can do something right then - I do it.
This is part of the system actually - if something takes less than two minutes then just do it. But I think that’s sort of in a separate phase from the initial writing down of something… Like you can write something down briefly when you think of it to put it in your “inbox” but then you have a set time later to process your “inbox” and put everything in the right place, etc. and at that point if something takes less than two minutes then you just do it. Otherwise in contexts like work I think you could easily swamp yourself trying to do quick tasks like responding to messages and take a long time to get to anything important.
That said, I haven’t finished the book and truthfully part of the drawback of it is that it’s a bit of a complex system with a lot of moving parts, which has slowed down my desire to really finish it. But it still seems like if you could get past the parts that seem complicated and make it work for you it’d be great.
The 'pomodoro technique' starts dead simple but builds to quite a complex system. Might be worth a look.
I've used the first dead simple bit myself to get things I don't like doing much done. I've suggested just that first part (four or five bullet points) to older teenager students for exam revision with some success.
I start my work day off with an Eisenhower matrix at the top of a new page in my business diary.
Leave the diary open and present on the desk. Ensure you're crossing out things as you work through them. Review previous days as often as you think is necessary.
Between that and having all my meetings in my osx calendar, I generally don't have open loops.
I've been experimenting with using ChatGPT-4 for this. I tell it to take on a personal assistant persona and it helps me intelligently prioritise & track tasks, plus break them down into smaller steps. You can also have fun with it taking on different styles like your "personal assistant bro" or "Data from Star Trek".
It is pretty helpful, but after a while I've seen problems with it getting lost in the back an forth: it forgets tasks, or forgets that they are done. There are definitely issues with large context spaces. After a certain point, I can repeatedly tell it something is done or to remove an item from the list, and it'll apologise but keep the item as "Todo". This is probably one reason why they haven't released the 32k space yet.
If someone finds the book helpful, it is helpful. No need to call it a meme if it does not cite studies. It is strictly a personal decision to read the book and use the system.
I think two important requirements for good unit tests are that
1) If you look at a particular test, you can easily tell exactly what it's testing and what the expected behavior is, and
2) You are able to easily look at the tests in aggregate and determine whether they're covering all the behavior that you want to test.
To that end, I think a better guideline than "only have one assertion per test" would be "only test one behavior per test". So if you're writing a test for appending an element to a vector, it's probably fine to assert that the size increased by one AND assert that the last element in the vector is now the element that you inserted.
The thing I see people do that's more problematic is to basically pile up assertions in a single test, so that the inputs and outputs for the behavior become unclear, and you have to keep track of the intermediate state of the object being tested in your head (assuming they're testing an object). For instance, they might use the same vector, which starts out empty, test that it's empty; then add an element, then test that its size is one; then remove the element, test that the size is 0 again; then resize it, etc. I think that's the kind of testing that the "one assertion per test" rule was designed to target.
With a vector it's easy enough to track what's going on, but it's much harder to see what the discrete behaviors being tested are. With a more complex object, tracking the internal state as the tests go along can be way more difficult. It's a lot better IMO to have a bunch of different tests with clear names for what they're testing that properly set up the state in a way that's explicit. It's then easier to satisfy the above two requirements I listed.
I want to be able to look at a test and know exactly what I don't mind if a little bit of code is repeated - you can make functions if you need to help with the test set up and tear down.
A few years ago my friend stayed with me for two weeks and he was doing “no alcohol August” just to see how he felt, and I joined him. I realized that I felt way better most of the time. I wasn’t drinking much before that, but even one IPA with dinner would make me feel super foggy the next day and sometimes anxious.
Otherwise I’m similar to you - I love the taste of beer and cocktails.
So I basically said after that I’d only have a drink if I really, really wanted one. At first, maybe this was once a week. Slowly, as I got better at saying no and listening to my body and realizing I could go without and still have a good time, I started having it less and less. A few years later, I have maybe one drink every three to six months and usually will drink it so slowly that it barely has an effect. If it starts to feel like a downer, I stop drinking it - doesn’t matter that I spent the money on it.
For what it’s worth I’ve found the “only when I really want it” strategy helpful for stopping other habits too - that’s how I slowly became vegetarian, for example.
I think a huge part of this too is that it gets around “hating yourself when you fail”, because there isn’t really failure with this way of thinking. It’s typical to have all or nothing thinking around this kind of thing - “oh, I had one drink, now I’m off the wagon”, or “I had one pastry, might as well give up on my diet”. But there is no wagon! That’s something you make up. There’s just the choice you have in front if you. If you have alcohol one night, it doesn’t mean you failed, or got off the wagon - it just means you had alcohol one night. That has nothing to do with whether you’ll have alcohol again the next night.
On a more practical alcohol specific note, I loved finding out that craft nonalcoholic beers like ones from Athletic Brewing Company, Untitled Arts, and Rescue Club are actually quite good and can hit the spot of having a beer for me! If I’m at a bar, I’ll sometimes order a seltzer with a splash of bitters if I want something that looks and tastes a little like a cocktail to avoid questions but I don’t really care about getting asked questions anymore.
And then again a big aspect is the social piece - hopefully you have supportive friends who don’t care that you don’t drink. It does take some getting used to in social situations to just explain “Yeah, drinking just made me feel shitty so I slowly stopped and now I rarely drink.” Over time I’ve learned to have a lot of fun sober though - even to dance comfortably. But I’ve also learned that what my dad used to tell me back in high school is actually kind of true - that if something is only fun because you’re drinking, it’s probably not worth doing!
Best of luck with your adventures! Let me know if you have any questions.
I’ve always thought https://enso.org/ looked cool. It’s a functional language that has both a text representation and a visual representation as a graph that you can edit directly. I still haven’t played with it much though
I sort of felt similarly when first using Zig until it crashed with a helpful error at runtime when I was trying to cast -1 to an unsigned integer :) The debugging time that saved more than outweighed the amount of time it took to do the explicit cast.
I actually quite like coding in assembly now (though I haven’t done much more than the tutorial, just made an array library that I could call from C). I think it’s so fun because at that level there’s very little magic left - you’re really saying exactly what should happen. What you see is mostly what you get. It also helped me understand linking a lot better and other things that I understood at a high level but still felt fuzzy on some details.
Am now interested to check out this ffmpeg tutorial bc it’s x86 and not ARM :)