My $0.02: "You are complicating this" is an accusation of the recipient. In my opinion, offering the alternative you see as simpler can make the dialogue more productive, e.g., have you considered y? It's simpler because abc... and also achieves the same objective. How did you arrive at this solution? This also saves your own face if/when it turns out things are indeed more complicated than you originally thought.
Unfortunately, I found that Hide My Email complicates unsubscribing. I tried unsubscribing from Jumba Juice many times unsuccessfully, only to realize that the email that I entered was my actual email, and I should enter the email that was shared to Jumba Juice instead.
The conversation starter needs to be chosen carefully though. If it's a question about a project, it may be easily construed as dissatisfaction on the progress of the project, when the manager is neutrally curious.
Introduction to Calculus and Analysis, by Richard Courant and Fritz John. This book clearly explained many of the motivating examples of the concepts in Calculus, which was important to me as a beginning student. Too many times I read math textbooks that simply present a list of definitions, theorems, corollaries, and whatnot, failing to guide readers from one point to another. I agree that for advanced level of math, there're probably no good motivations or 'storyline' that weave these constructs together (they're purely symbolic); however, for a layman level, I feel it's crucial to at least make the readers understand why and how these concepts come to be, so that they can grasp at least a little bit of the 'logic' of math.
Similarly, Analysis I by Terence Tao has a 'Why do analysis' that has made me actually enjoy analysis.
This book broke down a hard and mysterious topic (operating systems) for a new CS student like me into everyday analogies, which almost eradicated my fear of the subject matter. It had the appropriate amount of technical details to be usefully informative for a college class while also inspiring a more in-depth read of other material that are much more boring. The book is the reason why I love operating system so much, and I continued to take more CS classes as a math major.
Sorry I just noticed your question when I'm browsing through my comments.
I haven't used note-taking apps extensively, I use Google Docs to write things done (not exactly 'note-taking') most of the time. What I've noticed is that I frequently need to link to other docs when I'm only mentioning a high-level overview in my current doc. Some examples: * When I'm writing a design doc, I need to reference docs that record the severity and symptoms of the problems that I'm solving with my design, docs in the past that tried solving the same problems, etc. * When I'm writing an overview for other readers or just for personal organization, it goes without saying that I'll make references to existing docs.
Digest/Reminder: I think it'll be a killer feature of any card/snippet-based note-taking app! Too often, brief notes are jot down and left to rot. Some notes are intended for that - I wrote it down just to get it out of my immediate working memory, not that I intend to do it in the near future. But for some notes, I do actually want to be reminded to organize (i.e., create a personal and internal structure over) them, esp. for reading notes. WeChat isn't frequently used outside of Asia(?), but a thoughtful and automated digest sent through email or phone notification could achieve something similar.
I remember I read in HN somewhere that, people _want_ to feel useful in code reviews and one way is to leave comments. So one strategy is to send stuff out early with some small imperfections so that people who want to feel useful can pick on them. IMO, following this spirit, and in this case, an efficient but not necessarily personally beneficial strategy would be send out a PR early (so that you're not investing in too much time and not too emotionally invested in defending your solution later), then get them to suggest solutions, and implement in their way. This takes away pretty much all of the pleasure of creation in coding and deprives one of the sense of accomplishment, but it's far less frustrating and mentally straining than having to argue and defend which solution to adopt, to me, when working with that kind of people.
I'm of the opinion that happiness shouldn't be a goal of my life, for different reasons.
Perhaps I don't fully understand the word "happiness", but I've always considered it to be a rather transient state of mind: it's always on the order of hours for me, which means I don't feel happy for most of my waking hours (although one can certainly argue that one only needs e.g., 2 hours of a day of happiness, to be "happy"). Combined with the hedonistic treadmill, happiness is more like golden nuggets that one stumble upon on a path to somewhere rather than the path or destination itself.
The problem with this view though, I've found, is that it's difficult to find goals and meanings elsewhere. The vast, vast majority of people are after happiness, which makes much of the social construct centered around obtaining it and conditions me for that goal as well. It's very difficult to find alternative an alternative goal (I do believe it's easier to live life if there's a goal, not that there should be one).
My experience with the book and its patterns has been that there's an issue and some developers recognize that it could be best resolved with x, y, or z pattern. Then the developers go to extreme length to make sure the implementation adhere to the the 'principles' or 'spirits' of those patterns, so much so that it creates unnecessary complexity (e.g., unneeded layers of abstraction) and friction in other components (to accommodate the 'purity' of that implementation). What's worse, it's very difficult to challenge such implementation in code reviews, since it's originated by GOF, which automatically makes it legitimate. The worst part, though, is that you have to maintain the implementation, any deviation from those patterns is seen as corner-cutting.
Seriously, I feel you should write a blog post about this types of reporting strategies that describe the work that are both accurate and palatable to management (and perhaps most importantly avoid despise from other developers).
