You could run the suite on the updated browser on the latest passed build, then automatically batch approve since you know it has to be green. Now you can run all the newest test suites in this updated browser against this approved build.
Can you not slowly rotate over time in your current company? Or just interview at other companies and ask, saying you want to start in product management and see if they have any tracks or internal processes to help people move departments. I know that they do it in a lot of companies, even the one I am in which is around 75 people. There are tracks to move between departments if you're interested.
Thanks for replying! Yes, that's a way. I nearly managed to pull it off a few years ago, but ended up being more relevant on the non-dev stuff, and that led me to the wrong track (as in, not the one I wanted, but the one paying me more). I got better and better as a PM and now it's hard to convince anyone that they should let me go to a less strategic role. In the sense that developers are often executing the roadmap, not defining it (at least where I am), and paying me for (slow) execution only is kind of a waste of my domain knowledged and experience. But you're right, trying internally may be the best/safest way.
It's a lovely article and great technology. I am just not so on board with testing the implementation details of such a component. Visual testing always feels off when done with these kinds of testing frameworks (jest, and vitest). As in do you really want to test that a class name is applied to assert that the component rendered with a certain style or visual look? If I change the CSS of the class name to a totally different background colour, then this test
will still pass yet the component is broken because it has the wrong style.
Although then I have to answer the question, what is the best way to test for visual changes? Then it would have to be visual snapshots where you save the current state of the test as a screenshot and then assert it matches the previous run.
> As in do you really want to test that a class name is applied to assert that the component rendered with a certain style or visual look?
I think the author doesn't do a good job in explaining what questions such tests are helping to answer. By checking the class name of an element in a component, you are not testing the visual appearance of the component, but its behavior. As in, given a certain set of inputs, the component is expected to produce a certain output. In the author's example, the difference in component's behavior when it receives different `type` props ("success"/"error"/"info") is that it produces a DOM element with different class names. It doesn't tell you anything about whether the component looks right on the screen, but it does confirm that the component is responding to the `type` prop correctly.
I guess another way to put it: how much value does this test provide? Maybe an extreme opinion but I am totally okay with removing tests of little value. Tests require maintenance and attention, so is the test itself a net negative on the codebase? Just because you have a test for a component, it doesn't necessarily mean that the test is valuable. Testing for the sake of testing isn't a great idea.
That being said, I understand what the test is doing also thanks to your explanation! My point is if you refactor the internal behaviour, the implementation details, then a good test would not need to be changed either. As in I want to keep the same look and design of the component, now with say different styles or maybe I dropped in a component from our UI library.. now there are no classnames but visually it's the same. So if I change the internal behaviour, the end result should be the same and the test shouldn't need to change.
I think there's a balance. When you've been writing for a while, sometimes you write just to get an idea out of your head. When it becomes a habit, sometimes you write just because. Creative process is all about fear indeed. Hope you find a community or a writer in your area that can inspire you, as it's very hard to start all by yourself! You also do sometimes need an "other" to write for, so I mean you end up being in a place where you aren't writing for yourself, even if that "other" doesn't exist. Puts less burden on yourself.
I appreciate the sentiment, as you're right about one of too many of these are easy traps to fall into. I would also say that life isn't so binary, it's not one or the other, it's a huge mix of everything. Also I am not sure doing without thinking exists, the "doer" in your case has to think about what he is doing otherwise he wouldn't be able to do anything no?
For me I found this made me check them more, as I would be thinking "well maybe someone has sent me a message since I last checked" and it might be true. It's a tricky one! I found uninstalling the apps and logging out on the web after each session helps a bit, as then there is some friction in having to check what's going on since I have to log in every time.
Can you recommend a workflow for obsidian? Or some pointers for resources. I am struggling to "get" how to take notes with it and I am feeling a lot of friction
Browsing through Linking Your Thinking's YouTube channel[1] might be a good first-start. Despite appearances here, I am not a notes fetishist, so I find his videos rather approachable especially his "Start Here" video[2].
Jamie Rubin's blog series[4] is pretty good, too.
I personally just create atomic (single-topic) notes, with tags in the YAML front-matter, and store them in a folder structure along the lines of the Johnny Decimal System[3]. I store checklists, procedures, howtos, concept summaries, cheatsheets, and a daily log stored in a YYYY-MM.markdown file.
I don't have any comment on the blog post in the article, because this system works really well for me. Obsidian is extensible at hell, but I'm not spending all day looking for new tweaks, I'm just writing notes. Also, since notes are just files stored in directories, I have all sorts of shell/Python-scripted automations and shell aliases to quickly do stuff.
> I personally just create atomic (single-topic) notes, with tags in the YAML front-matter, and store them in a folder structure along the lines of the Johnny Decimal System[3]. I store checklists, procedures, howtos, concept summaries, cheatsheets, and a daily log stored in a YYYY-MM.markdown file.
You must be a very organised person, any sort of Zettelkasten or knowledge-based linking system for me is too complex, I'd rather just take a simple note, maybe with the date in the filename, to each their own I guess.
I’m not organized at all, but this system takes me very little effort.
As a quick example, I used to do daily notes, one markdown note per day but that was too much mental overhead, so I switched to one markdown note per month with an <HR> tag between each day.
But, what works for me won’t work for everyone else.
Zettelkasten seems like inhuman, nightmarish garbage to me.
If simple notes are working for you, then stick with that!
With Obsidian you really don't have to have any system, other than linking shared concepts between notes. Optionally, limiting each note file to a single atomic idea is also helpful. Obsidian takes care of the rest, organizing, displaying, linking.
I don’t overcomplicate it. Just create a new note and write. Often times I’ll create something for each day and just jot whatever down throughout the day. A lot of developers keep a random text file open all the time anyway for that type of thing, so just think of it that way.
I’ll add a ## header if needed to separate a topic here and there too.
If I remember an earlier note that was similar I’ll [[ to create an internal link.
Copying and pasting PDFs, images or other reference material is easy since by Obsidian can just copy those files into a local attachments folder.
If there’s a good reference video on YouTube or something, you can just embed it.
If my sidebar of notes gets longer than the screen I’ll take a few minutes and sort them into folders.
Honestly, there’s no fancy or organized workflow here. I just keep it open and write as it makes sense, then clean up every now and then when needed. Whatever is most comfortable for you is the right way. It’s your notes.
I started up a job a few months ago and threw myself into Obsidian, and it has definitely been paying off. Here's how I work, ymmv of course:
- I create a "Work" folder. Inside it are folders for Weekly Notes, Tasks and Information.
- At the beginning of each week I make a new Weekly Notes page. I have a subheading for each day, and a subheading in each day for a todo list. After the todo list, I put down a heading for each of my meetings/activities that I want to take notes for and fill them in accordingly.
- When I begin work on a non-trivial ticket or project, I make it a note in my Tasks folder named with it's Jira tag. That makes it easy to link to from my weekly notes, and gives me a loose idea of when I was working on which tickets through backlinking. I then use these notes to plan out the problems, store personal research and organize code snippets.
- The Information folder serves as a kind of "Misc." folder. I have sections for travel, guidelines, best practices, and I even store some PDFs relating to my job in there.
A few other general tips for Obsidian:
- Create a group in your graph view for "Work" and it will highlight all of the notes in your work folder with a specified color. Pretty handy.
- Make heavy use of linking, both internal and external. Tags are also nice, but don't be afraid to break out your notes when things get too heavy; that's what it's made for.
- Liberal use of the keyboard shortcuts is a gamechanger. Ctrl+O to open notes, Ctrl+P to open the command palette (which I mostly use to split panes), and hold Alt+Arrows to quick-switch to adjacent panes.
- Plugins are nice, but it's easy to get carried away. Mind Map, Tasks, and Admonition are the only ones I keep enabled.
Hope you get as much out of it as I do. It sounds like a lot, but it feels like second-nature to me now. Feel free to adapt this to your own needs or skip it all together, this is just my personal workflow and what made me fall in love with Obsidian.
I understand the friction you're feeling. There are several ways to do the same thing in Obsidian, which can make it confusing to know whether you're doing it the right way. The way I managed to grok it was by reading this excellent post about this user's Logseq workflow [0]. Logseq is an open source copy of Obsidian. The advice applies to Obsidian as Logseq works the same way.
Second this. I even have a bookmarklet in the browser that adds text selection or a page automatically to Obsidian. And yet, when it comes to saving something I feel is important, the maximum I can do is just create another note and put the text/link and forget. I feel like I need to find proper place for this note in the folder hierarchy or think how to categorize it ("should it go to the Economics->Behavioral or Sociology?"), and quickly becomes a burden. In the end I feel like heavily underusing it, but perhaps I just don't get the right workflow..
The best workflow is to consciously underthink it. If you find yourself spending more than 10 seconds thinking of where to put something then you're doing it wrong. Force yourself to go with the first place you were thinking. You'll most likely find it later using search tools.
Sometimes you don't even need to take notes. Just the act of pasting in a link or a snippet from an article you read is enough to reference it in the future.
If you insist on making things clean, then you can use some sort of version control and review all the notes that you've taken once a week and organize them better. The most important thing is to take the note.
Right, agree with <10 sec rule. But, again, the main promise of second brain tools is to keep your "second memory" layer organized. Apple Notes are good enough for copypasting links and excerpts you want to make searchable later, right? So I assumed that Obsidian's markdown/hyperlink system should bring some benefits into organization.
For me, the value is somewhere in between. Priority number one is getting the data into the second brain. Afterwards try to do a little organizing but don't fuss around too much with it because I can always make improvements later (especially if/when I access it for a second time). That's kind of how the real brain works.
i would focus on just taking notes on related topics, without much structure for a bit. try to link them together if they are on related ideas a bit. once you have a network of notes that feels a little less manageable (~100), i create a "map of content" where i link to all notes related to that concept, and in it i essentially tell a higher level story about how those notes relate to each other.
What do you mean by this?