I love her. Listening to her album sounds like you’ve opened a time capsule that’s been left undisturbed for years. It’s so unique and the lyrics are so lovely. Talkin’ Like You is my favorite.
“I don’t stand in the need of company / with everything I see talkin’ like you”
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 :)
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
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.
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 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 don't know that I would put it that way, though maybe you could choose to. I have no trouble focusing for long blocks of time on tasks I'm engaged in, or even on any of my work in a week where I'm feeling motivated, but the problem is there will be days where I feel like I spent the whole day working (doing code reviews, answering questions, doing things for other people, etc.) but didn't get any of my project work done. I think those days tend to happen around boundaries where I finish one of my tasks and have to pick up a new significant task that I don't feel pushed to get started with for one reason or another (maybe combined with external life factors). A lot of other software engineers I've talked to can relate to this, so I don't think it's just me. This system is more for me to smooth out my productivity so I can make sure that I'm always getting some of my own stuff done and not just doing "filler work". The "intentionally doing one thing at a time" thing also just makes me feel a lot better and makes it easier to blow through an entire day with almost no distractions. There have been two or three days that were Fridays I think where I decided to take a break from the system just for a day and it's really remarkable how much worse it feels :)
Yeah, I've used time tracking software before and it was pretty effective, but I think something about having the log on paper, separate from the rest of my work, makes it feel somehow more intentional psychologically. It's also a little bit lower pressure since the idea is for me to accomplish the amount of work I want to accomplish rather than to fill up a certain amount of time, so with the new system the success metric is a bit more pared down. But I agree that "one goal a day + time tracking" doing essentially the same thing I have written in the post.
Author here :) I'd echo this. It's really crucial that you limit your goal for the day to something that you have nearly 100 percent confidence about. So even if you think "I can do this whole thing today!", you should just pick off the first piece of it that's definitely attainable to use as your goal.
In addition, on the few occasions where I didn't manage to hit my goal by the end of the day (maybe three times in the last month), I'd take the time to figure out why that was and think of how I could have reframed the goal in a way that would have made it achievable. Usually when I missed a goal it was because it was either not specific enough or it was dependent on something else. For example, I might have had "Push XYZ patch", when it should have been "Make bugfixes to XYZ patch and push if able", since there's always the possibility that the latest fixes introduce an unexpected problem or that the reviewer won't get to the code review that day.
Author here :) Fortunately, I mostly don't idly browse the internet on my computer - that habit is attached to my phone, which I just leave in the other room :) But in general, yes, if I need a break, I check off what I'm currently doing, write down "break", and then take a break, and check that off when I'm done. But my experience is that it's probably best to keep your breaks physically separated from your workspace if possible so that when you sit down to work it feels like "work time".
This is fascinating! For the side dialogues, did you do run the generator several times until it came up with something that sounded relevant/reasonable, or were you able to really chat in that manner and what you have here is the first thing it generated?
Re: Future Work: I didn’t think about the particular predicates in detail, but the author could consider using the cut predicate (!) to prevent some unnecessary backtracking. Without more thought I can’t guarantee that actually could be effectively applied here, though
There’s one extra validation hop to check valid state transitions that I don’t love, but if I take that feature out then I think it’s pretty low overhead for how readable it is