* OPML is a format that bundles feeds together to share with others.

* I publish an automated list of the feeds I'm subscribed to on my blog. [1]

* I pay for Feedly ($50/year and I don't regret it) which has API access, and I use an Azure function to produce it. I have a blog post if you're interested in setting something like that up for yourself. [2]

[1]: https://seankilleen.com/reading-list/

[2]: https://seankilleen.com/2019/01/tutorial-reading-list-feedly...

* Great authenticator support. We have some accounts that our team members have to share, and we want MFA on those accounts. I can add an MFA field to 1Password entry and the people who have access to that entry can use it. Doesn't help when those entries require phone/e-mail based MFA; I'm working on a little Twilio / outlook group setup to take care of that. * Easy to navigate group membership. Passwords are stored in vaults and individuals or groups can be given access to those vaults. The model for it fits in my head and I like that. * Easy share ability. There are a few credentials that I occasionally need to share outside of a vault. I can create a link and grant access to specific individuals for a given amount of time. * The browser extension and integration have been really smooth in my opinion. * I find tagging and taxonomies of tags to be helpful, and 1Password supports those well. * We've gotten some great mileage out of 1Password connect. Some of our infrastructure secrets now reside directly in 1Password, and 1PW connect pushes them into our k8s environment as secrets where our apps can refer to them. Makes secret management across environments that much easier. * SCIM support (which I haven't yet implemented) and SSO support to bring more convenience for end-users. * Easy ability to recover if an employee forgets their master PW (have done this a handful of times). * A nice perk: our 1PW business comes with a free 1PW personal subscription for people, completely separate. If the employee leaves they have can convert their personal vault to a paid subscription or export it.

To answer your questions specifically based on my current context:

> What are the recommended ways to store and give access to passwords?

1Password vaults. One vault per style of responsibility. 1+ groups have access to a vault. People get put into 1+ groups.

> How can a new hire be given access to all required passwords day 1?

In our case, day 1 they accept the 1PW invite in their inbox, and then we assign them to groups. Done.

> And when such new hire gets promoted, how can we give access to the additional passwords they will need?

Keep those "tiers" of passwords in separate vaults. Update the groups when someone's role changes.

> And if someone leaves the company, how can we change only the sensible passwords they had access to and preferably notify everyone with access to it that it was changed?

See what groups that person is in and what vaults they had access to. Review "high priority" items which you've tagged in such a way as to surface them. Send an e-mail to the members of the vault telling them you're rotating passwords. Rotate the passwords. Anyone who's a vault member can see the password history too, I believe, so if something goes wrong the old password will still be available.

Comments URL: https://news.ycombinator.com/item?id=39846269

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=39605828

Points: 1

# Comments: 1

Comments URL: https://news.ycombinator.com/item?id=39593769

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=39400209

Points: 1

# Comments: 0

In the places where I've hated Jira, it's been locked into overly complicated workflows that didn't match what I needed; into the inability to create new views that provided insight into the work; into many tedious required fields even though we didn't use that data in our work stream at all. I've been locked into "one-size-fits-all" workflow approach.

Turns out: that's pretty much all configurable! Jira doesn't mandate the use of a one-size-fits all approach. Shitty company culture mandates that.

In my current position, I have admin rights to Jira and also a mandate to keep teams empowered and processes simple. Guess what -- Jira is pretty awesome here (I use it to develop, too.) In roughly a day or so, I created an entire automated hiring process via a Jira board [1] that got us phenomenal feedback from candidates. I actively ask teams what parts of the process are annoying, and then automate them or fix them, because I am empowered to care about developer experience.

Once you're a part of a generative culture that truly cares about empowerment and enablement, you start to see how much of your disdain for tooling was actually a disdain for a culture that prevented even very useful tools from having a positive impact.

[1] https://seankilleen.com/2024/01/how-i-created-an-automated-a...

It comes with a companion site [2] that shows how to get scheduled posts, comments, etc. working nicely.

[1] https://github.com/SeanKilleen/blog-in-a-box-container/ [2] https://bloginaboxdemo.com/

Hope this is helpful!

Comments URL: https://news.ycombinator.com/item?id=39266783

Points: 3

# Comments: 1

* You're not alone. There are a lot of people looking for work right now, and less work to go around, it seems. I recently had 60+ applications for 2 developer roles without using a recruiter or anything but word of mouth through communities I participate in. From a pure numbers standpoint, this means applicants have to work harder to stand out, which sucks for applicants and also because it leads to people gaming the system.

* So much of the hiring process has been enshittified. Tools doing keyword scans have replaced a lot of human judgment, and resumes have started to adapt to keep up. I abhor the practice, but: you may want to have a separate resume for places that may use these products, so that you get past auto-screening.

* Your resume is nicely laid out. However, I fear it will likely get you auto-rejected as lots of screening tools can't parse it for roles. You may want to have a version that avoids the multi-column layout. Again, this will be a guess as to whether companies are using that kind of software or not.

* I highly recommend adding your role or the equivalent role to the subtitle, e.g. "Senior Developer (Contract)" or ".NET Developer (Contract)" . It gives a quick overview of what type of work you've been doing, which is helpful when I'm scanning 60 resumes. I would go so far as to suggest You make the role a part of the heading and keep the employer & date below. E.g. "Senior .NET Developer" up top and "Technically Creative (contract) | Oct 2021 - Dev 2023" below.

* Suggest adding start/end dates including Month & Year (e.g. "Oct 2021 - Dec 2022"). It gives a sense of timing.

* There's another tough choice you face: whether to share unemployment status. It's a double-edged sword for candidates. For me, people who state their situation get respect for the authenticity, and those who try to hide it make me suspicious. But I also respect that people are biased against unemployed people even though they shouldn't be, so I would suggest making that a per-application decision.

* I already get a decent sense of this, but you may want to tweak your bullet points to reflect accomplishments/impact some more. Shows that you understand business value (which I believe you do).

* Technology under each bullet point makes me as a reviewer do extra work. Some kind of summary of technology you're proficient in will be a good addition. Should you have to? Probably not. Would I still read this CV? Of course. Will lots of folks glaze over and move on when they have to do extra work while reviewing hundreds of applicants? Yes.

* I like that you include your GitHub. I definitely look at those and it never counts against an applicant (for me. Again, double-edged sword).

* I think the one-page resume is working against you here. With your experience since '05 I think moving to 2 pages and expanding on some of the suggestions above will work in your favor.

* The title at the top of your resume, "Software Developer", could probably do with a tweak. It's one of the first things I see. "Senior Software Developer", "[Stack of Job You're Targeting] Developer", etc. may go a long way. I recently gave someone an interview because they had "Systems Integration Developer" in their title and I was looking for integration work. It would be an effective technique IMO.

* Find your local & global communities on Twitter, Mastodon, Slack, LinkedIn, Discord, etc. -- many often times have jobs channels where things will pop up. Coming from a community comes across as a sort of implicit reference in terms of places you may participate. And there's usually little downside as you learn things, participate in discussions, and build relationships there that are nice either way.

I wish you the best of luck finding your next opportunity!

It is a delightful ecosystem to work with. Productivity is huge, great tooling and IDE support even in non-MS ways. I joined this company 3 months ago and what I've been able to get done on this platform is honestly exciting. And I haven't had to sacrifice modern development principles.

Others that come to mind from the book: her writing on "one-inch picture frames" and on "radio station KFKT", which I found to be very helpful around imposter syndrome.

It's a very entertaining (and easy!) read packed with a lot of advice that I've found more useful over time than I imagined. Recommend picking it up if you're looking to meander a little in your reading. It's a good journey.

Has NUnit helped you, your career, or your organization? We'd love to hear about it at https://github.com/nunit/nunit/discussions/4283.

> To attempt to quantify Charlie’s contributions to NUnit is a daunting task. He was the lead of NUnit across at least 207 releases in 37 different repositories, authoring 4,898 commits across them. He participated in 2,990 issues, 1,305 PRs, and impacted 6,992,983 lines of code. And those are only the ones we can easily find; our numbers are sourced from after NUnit moved the project to GitHub in 2011, which means there are at least 9 additional years of work not quantified above.

I think of Charlie as one of the ".NET OSS OGs". I'd love to see him celebrated.

Comments URL: https://news.ycombinator.com/item?id=34564104

Points: 1

# Comments: 1