SeanKilleen

In case it's helpful / relevant for folks, wanted to share a few things I do:

* 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...

Folks are going to have strong opinions here about things, so I'll try to stick to my personal experience. I adopted 1Password at my current organization. Overall, I've been very satisfied with it. Here are the major points I've noticed:

* 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.

I got a surprising amount of positive feedback on a job description I wrote recently, both internally and from candidates. So, I figured I’d write up my process here in case it can help anyone.

Jira is a perfect example of how culture influences tools. I've seen and been a part of environments where I agreed with this sentiment, and also where I felt the opposite. The difference between those places: whether a culture empowers its teams to think on their own and succeed.

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...

I created the BlogInABox[1] devcontainer to help people get started with Jekyll + GitHub pages. It's a repo that you can fork that has a site ready to go, and a devcontainer that has nice utilities like spellcheck & markdown linting/fixing. This way, you can use it locally in a devcontainer or with github codespaces and a simplified process.

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!

Thanks for posting! Original author here if anyone has questions/comments.

Was told by a few folks that this was an effective condensed look at a lot of good practices and how to explain them, and at least one person proposed a change at their org based on it. Typically don't share things like this here, but figured somebody else might benefit from it, so I'm taking the plunge. Feedback welcome here or in the comments (which use a GitHub account). Be gentle. :-D

Lots of folks will have opinions on this; adding mine just to give you an additional data point. Specifically not looking at other comments so that I can give you my direct take; I'm sure others may disagree and that's fine. :) I'm a hiring manager at a small company that recently hired two .NET developers.

* 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!

We're developing in .NET and publishing Linux containers deployed to Kubernetes. It's been an absolute joy!

"Dadabase" was right there.

Our company's app is written in .NET 7 (soon to upgrade to .NET 8) and deployed via Linux containers into Kubernetes.

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.

https://SeanKilleen.com

This book (Bird by Bird) is one of my favorites; recognized it immediately from the submission title. I've long said to folks that much of her advice in Bird by Bird is applicable to software, agility, and entrepreneurship.

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.

After over TWENTY years leading the NUnit project, Charlie is stepping back.

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.

In case anyone is looking to get familiar with how to work through some problems using TDD in C# with NUnit or xUnit, thought I'd post here.

The post is not meant to be dogmatic or overly opinionated; just a starting point for those who are interested.

Happy to field questions here, on Twitter at @sjkilleen, or via email at seankilleen@gmail.com.

Personal stance: I've heard direct feedback from others that it makes them feel more welcome and normalizes an idea that is important to them, so I tend to include them in various places.

Previous employer: A group dedicated to inclusion & belonging recommended to HR, who clarified that including pronouns was certainly welcome but not required. Several people changed it.

Current employer: I just decided to include them in my signature as part of the "name" line. I did agree with another comment's hesitation because it's a sort of expression of a company's brand, but I know enough about my current employer and their stance on D&I that I'm not worried I'll upset anyone.

The .NET Foundation is holding elections for is Board of Directors from 3/21-3/28.

While only .NET Foundation members can vote in this election, anyone who has a question for the candidates about the .NET Foundation, its mission, or their proposed plans to submit a question at: https://election.dotnetfoundation.org/questions.

Candidate statements can be found at: https://election.dotnetfoundation.org/candidates

I hope folks will join the .NET Foundation in widening its membership / leadership and looking for new ideas to build a more vibrant community the .NET ecosystem.

(Disclosure: I am one of the candidates running in this election)

FYI I created a quick tool for this at http://xluh.co/repo.

It's basic now but I'll be building it up in light of this.

If you want a free OSS URL shortener for your own domain name, I built a simple one at http://xluh.co/repo. Will be expanding on it in the future.

If you want a free OSS URL shortener for your own domain name, I built a simple one at http://xluh.co/repo. Will be expanding on it in the future.

If pieces of a codebase need to be changed, I break it into a few general steps (varies depending on specifics):

1) Look at the code and examine what it would take to make it testable.

2) make tiny, safe refactorings to prepare the code to be tested -- only if you are absolutely certain these changes can cause no side-effects (usually I'll rely on tools to help me do this, just to increase the confidence level). If you can safely extract related code into appropriately small & related files / objects, that can be a great start.

3) Put the existing code under tests. Write tests around that code -- preferably unit tests that exercise the legacy code, as written, to verify its behavior.

4) refactor the code that the tests are using to represent a cleaner codebase -- maybe you extract some objects / functions.

4) Write new tests to demonstrate the desired changed behavior. Write them as if you're writing them for a brand new codebase.

5) Make the code pass those tests. Some old tests may fail -- if they represent the old requirement, you can delete them. If they don't represent the old requirement, you know you have a bug.

Repeat this process for each piece of the application that needs to be changed. NOTE: In a legacy app, you sometimes have to make peace with the fact that some of the app in production will remain legacy, untested code. If it doesn't need to change, then you don't necessarily need to sink a huge amount of time trying to refactor / put all the code under test. Get in the habit of doing it whenever you need to make a change (and factoring in that time into any estimates, etc.) -- over time, the cost of a change will hopefully go down as you pay off that technical debt.

If you're trying to figure out what the cost of change will be, sometimes you can use static analysis to look at a codebase and show potential issues for a given section. Using such tools can sometimes help you understand how heavy of a lift it will be to modernize the code.

As has been suggested, "Working effectively with legacy code" is a guide book here. You'll likely also want to seek out language-specific material about refactoring, unit/integration testing patterns & tooling, etc.

Good luck!

This was my first thought as well. I hope someone can confirm he's safe. Whether it was true or not, it's not worth anyone's well-being.

Yeah, that really grabbed my attention. Of all the people who've used it so far, I haven't seen any report that they'll be favorably affected.

This web site calculates partial stars behind the scenes. So the equivalent visits uses the sum (including partial stars) in the calculation.

Author here -- this seemed to spark some interesting discussion and momentum on Twitter, so I thought the wider community might appreciate it or it might at least start a decent conversation. I'll do my best to follow along here, but feel free to comment on the article as well.

I've been using Trello for various aspects of my life for some time. Anything that has a flow, concept of "on deck", or a repeated list of items tends to make a good home for it.

Example: My learning (labels represent sources of learning, I have an on deck list and I stick to whatever I'm on currently -- or at least try to). I pick the most relevant thing to do next.

Another example: Vacation packing. I have lists of "Master List", "To Pack", "Staged", and "Packed". Whenever I take a trip, I move the applicable items from the master list to the "to pack" list. Haven't forgotten something on a trip in a long time. Bonus: organize labels by type of thing, and now I know exactly what I'm putting in which bag.

Trello is also great for organizing goals. 5 goals per year / month / week / day, in a way that bubbles up, is very appealing to me, though I haven't tackled this one yet.

Also, any software project I do usually has a board. Lists: Formation / Future / Waiting&Hold / Backlog / In Progress / In Dev / In Test / Ready for Prod / In Prod. Labels for issues, features, questions, ideas, high priority, and low priority items.

These recommendations are great, but I'll add one I haven't seen here yet: "Notes to a Software Team Leader" by Roy Osherove. I think it's a great read on how to empower your teams to succeed on their own. And it's written from the perspective that is likely to be shared (at least in part) by your dev leads, so it'll likely have helpful insight in that way as well.

Thirded. The narrative form threw me off at first, but I think it really lays out a lot of the concepts in a digestible way.

Hi all,

I created this site along with my brother. We're supporting our friend who is currently attempting to raise $100,000 for cancer research as part of the Leukemia/Lymphoma Society's Man/Woman of the Year contest.

The contest is drawing to a close soon, so I figured, why not see if HN can take down the site with traffic and donate to a good cause while we're at it?

Brief technical background: It's a simple .NET MVC5 site hosted on Azure with some (hopefully enough) caching in place. Not making use of Azure's CDN service yet but hoping that caching a good deal of the response saves on some costs.

We trust you'll send traffic in good faith (please let me be right about that; the site isn't free to run.)

If for some reason the site truly is crushed, we'd still surely appreciate a donation -- the official URL is: http://www.mwoy.org/pages/nyc/nyc15/DonateNow?fundraiserPage...

I wrote up this article after a nice conversation. I'd be interested to hear if it's helpful, and any other thoughts you'd care to add to it.

Also, pull requests accepted :) https://github.com/SeanKilleen/seankilleen.github.io/blob/ma...