this post was submitted on 21 Feb 2024
289 points (91.6% liked)
Work Reform
9994 readers
130 users here now
A place to discuss positive changes that can make work more equitable, and to vent about current practices. We are NOT against work; we just want the fruits of our labor to be recognized better.
Our Philosophies:
- All workers must be paid a living wage for their labor.
- Income inequality is the main cause of lower living standards.
- Workers must join together and fight back for what is rightfully theirs.
- We must not be divided and conquered. Workers gain the most when they focus on unifying issues.
Our Goals
- Higher wages for underpaid workers.
- Better worker representation, including but not limited to unions.
- Better and fewer working hours.
- Stimulating a massive wave of worker organizing in the United States and beyond.
- Organizing and supporting political causes and campaigns that put workers first.
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
LinkedIn is fine, my past 2 contracts both were off LinkedIn
Yes, include keywords but spread them out, absolutely. Also include them in your cover letter.
Don't use headhunters, but you can use recruiters.
Pick a specific tech stack to specialize in, one that is popular abd high demand. 100% yes you should have a portfolio using that tech you can link to on your resume or applications. Focus on applying to the smaller but refined pool of jobs that explicitly need the exact tech stack you have in your portfolio.
Example: I specialized in .NET tech stack. C#, azure, EF Core, NUnit, Sql Server, etc etc. The full windows stack.
It's a super popular stack, and there's tonnes of demand. I don't waste my time applying for python or c++ or lua or go or rust jobs. I stick to my stack.
I have many projects on my github using that stack, including install instructions, releases, docker containers, etc etc.
As a result I can talk about the tech used in these stacks extensively, I know them like the back of my hand. I have strong opinions on patterns with them, I can teach others about them, etc.
What's the strongest opinion you have on the stack you know (or one of its elements)? Not necessarily "interview-safe" opinions
I despise the current paradigm of mock'ing everything, abstracting everything, and unit testing 100% cide coverage for no logical reason.
Instead I only unit test the following:
Any code I truly want to unit test, because it does something that is iffy on if it works or not, I break out into atomic logic that can very easily unit test.
Code coverage is a business requirement and we already have 100% coverage from integration tests, then I'll start worrying about unit testing the shit out of stuff.
In other words if you waste time on mindless unit tests to assert that 1+1=2 when you dont have 100% coverage on your integration tests yet, you are wasting time.
In terms of atomic code, consider this example:
This would be very normal as a pattern to see, but I hate it because to test it, now I need to mock a stubbed in IStudentRepository.
Consider this instead:
Now this is what I consider atomic logic. The rule of thumb is, if the class has no dependencies or all it's dependencies are atomic, it too is atomic.
Generally it becomes clear all the atomic logic can just be declared as static classes pain-free, and there's no need to abstract it. It's trivial to unit test, and you don't have to mock anything.
Any remaining non-atomic code should end up as anything you simply must integration test against (3rd party api calls, database queries, that sort of stuff)
You'll also often find many of your atomic functions naturally and smoothly slot into becoming just extension functions.
This approach goes very much against the grain of every dotnet team I've worked with, but once I started demoing how it works and they saw how my unit tests became much less convoluted while still hitting ~90% code coverage, some folks started to get on board with the paradigm.