04 Dec 2024 #career
It all starts with the job description.
No job description? Red flag.
“We’re looking for a passionate coding ninja to join our family. We work in an agile and fast-paced environment. We’re looking for a coder with 5 years of experience who can work on our public web page, mobile app, backend, frontend, DevOps, security, compliance, sales, marketing, documentation…Compensation based on experience and interview results.”
I’m making that up, but I wouldn’t be surprised if there’s a “real” job description like that one out there.
Passionate, coding ninja/superhero/master, family, fast-paced, high pressure…Nothing screams danger more than those words in a job description. Run, Forrest, run!
After reading between the lines of the job description, look at the company website.
“We’re a family.” That was the opening line on the careers page of a company someone tried to refer me to. I stopped reading. I didn’t need to look at anything else. It was a hell no. That was a blinking danger sign with sirens.
Ironically, every company claims to offer excellent conditions, and every applicants seems to be the perfect candidate for the job.
03 Dec 2024 #misc
It’s more important to ask who this isn’t for than who this is for.
Who isn’t this course for? Who isn’t this coaching program for? Who isn’t this blog post for?
I created a Udemy course on unit testing, one of my favorite subjects. I answered who this course is for on the landing page.
One student said some parts were too advanced. He had just started with the subject and my course covers more advanced material. It wasn’t for him.
So I asked for feedback. What were those challenging parts? There’s room for improvement there. Extra lessons and better lesson descriptions.
And I quickly updated the landing page to show who this course isn’t for. That will attract fewer students but the right ones. The ones my course is really for.
Whatever you’re doing, answer who this isn’t for.
02 Dec 2024 #writing
Publishing your first LinkedIn posts is scary.
I know that feeling. Your hands shake. Your heart is beating. You keep retyping your password. You’re publishing something on the Internet for the first time ever.
You’re in fight or flight mode, ready to run away from lions behind a bush.
What if I say something wrong? What if my boss reads what I write? What if that comes up in future interviews? What if someone makes fun of me? It’s normal to have these worries.
I felt the same way when I wrote for the first time on LinkedIn, even after writing on my blog for years.
If the fear of being exposed online prevents you from hitting “Post” or “Schedule” on LinkedIn (or anywhere else online), follow these strategies:
1. Publish a lot
The first time you do anything is scary.
The only way to overcome it is with repetition. Write a lot and publish a lot. Create a writing schedule you can sustain and then challenge yourself to double it.
Back in January 2024, I decided to revive my LinkedIn account by writing 100 short-form posts. I started with one post a week, then two, then three, and settled with one post per day, every day. Fear of writing? Gone!
If you write every day, you will hit 100 posts in about three months. The fear of writing and being exposed will disappear.
2. Schedule your posts
Otherwise, after hours of crafting a perfect post, you will find yourself with the cursor on the “Post” button hesitant to click it. And you will delay it for tomorrow. And often, tomorrow means never.
Schedule your posts, forget about them, and come back the next day.
3. Turn off email notifications
LinkedIn (and any other social media company) will try to keep you on their platform.
They will trick you with all kinds of emails. Someone posted. Someone commented. “Someone on LinkedIn viewed your profile.” Really, LinkedIn?
Turn off all email notifications and continue with your day. Otherwise, you’ll be refreshing and refreshing your browser tab and checking your email, wondering why nobody has liked or commented on your first masterpieces.
4. Understand Sturgeon’s law
90% of everything is crap. That’s Sturgeon’s law.
That’s not to discourage you. It’s to lower your expectations when writing for the first time. 90% of everything is crap. Your first posts will be in that 90%. Your first posts will be far from perfect.
Keep writing and keep improving.
I wrote my first blog post back in 2018. And “post” is a strong word. It was a word vomit. I dumped a bunch of words into a document and published it online. I still have that first post unedited to remind me how I started.
Same story with my first LinkedIn post. I made all LinkedIn sins possible in a single post. Only added an external link. Zero formatting for mobile devices. Lots of hashtags.
If after writing for months, you don’t cringe when reading your first posts, you haven’t improved much.
5. Remember the 30/30/30 rule
No matter what you do:
- 30% of people will love it.
- Another 30% will hate it.
- And another 30% won’t even care.
I learned that reading “Choose Yourself” by James Altucher.
Write for your 30% and forget about the other 60%.
6. Think of writing like buying lottery tickets
Would you expect to win the lottery the first time you buy a ticket? Nope!
Writing is the same. Every time you hit “Post,” you’re buying a lottery ticket. If you don’t win today, you buy another ticket tomorrow. If your post didn’t get the likes you wanted, there’s a chance it will next day.
Keep publishing.
7. Make it about business, career, or work
Every social network has its own vibe.
LinkedIn isn’t the exception. If LinkedIn were a person, he would be a 30-year-old office worker wearing a suit and minding his language because his boss or future boss is watching.
Everything you write on LinkedIn make it about work, business, and careers.
If you’re not sure what to write about, share:
- Lessons from your last job
- Lessons from your best boss
- The best book you have read
- The best course you have taken
- Lessons you wish you knew before starting your job
Share anything you wish you knew two years ago about your work or career.
You don’t have to share personal details or post selfies. Don’t publish what you wouldn’t publish in a local newspaper or niche magazine.
8. Be a journalist
What should I write about if I’m not an expert? Don’t let that thought stop you.
Don’t try to be an expert. Who’s an expert anyway? Share what you have learned and what you’re learning. Show your work.
Don’t create, document. Imagine you’re a journalist with a part-time job doing whatever you’re doing now.
9. Find a writing buddy
Writing your first posts can feel lonely. Probably, only your coworkers will like them when they log in to LinkedIn once every full moon or when they’re looking for a new job.
Find someone in the same journey as you and work together.
Parting Thought
Your first posts are the most challenging. Going from zero to one is the hardest part. Don’t be afraid of hitting “Post” or “Schedule.” The more you hit it, the less scary it becomes.
No matter what you write about or where you write, an online presence is the new CV and portfolio. And LinkedIn is a good place to start. Safe and professional. The boss is watching, remember?
Take a deep breath and write your first post. Commit to your next 20, 30, or even 100 posts and see what opportunities they bring.
01 Dec 2024 #career
It’s not the best coder. It’s not the one who cranks out more pull requests or lines of code.
The one who gets promoted higher and faster is the one with the best soft skills. The best communicator. The one who’s best at explaining complex subjects to non-tech people. The best at dealing with people.
The best coders are left alone to continue cranking out code in a corner. “Ok, kid. When will you have your PR ready?”
And when the best coders, with poor soft skills, are put in charge of teams, projects tend to go sideways. They fail to communicate expectations, provide context, and coordinate people. They continue thinking in terms of lines of code and pull requests, not in team dynamics.
Start improving your soft skills by reading “How to Make Friends and Influence People.”
If you could take away just one lesson from that book: never tell anyone he’s wrong.
30 Nov 2024 #csharp
Trying to test private methods causes a lot of confusion.
That’s a common question we all have made when finding unit testing for the first time. These days, I found that very same question on Reddit:
Can someone explain to me why unit testing our private methods is bad?
Because we don’t want to break encapsulation.
If you have a private method, how are you going to call it from a test class or method? It’s private. You can only access it from inside the same class. That’s the whole point of access modifiers: restricting access to the fields and properties that hold the internal state of a class.
And please don’t make your private methods public and static to call them directly inside unit tests. They’re private for a reason, right? We don’t want the rest of your code to use them directly.
Exposing internals is the most common mistake when writing tests. I’ve seen it and fixed it before.
Let’s take the HasAdmin() method from the question as an example,
private bool HasAdmin(List<string> relations, bool hasPermission)
{
// Beep, beep, boop...
}
Unless HasAdmin() has 0 references—if that’s the case, you should remove it—another method from the same class is calling it. And you can trace the chain of method calls back to a public method.
HasAdmin(), or any other private method down in the chain of method calls, is changing something that you can observe from public methods. Probably it’s affecting a return value or changing an internal state you can inspect with getters. That’s what you should test instead.
To test HasAdmin(), create a User object with the right relations and permissions, call the public methods you have, and check what should change when your user is an admin or not. Maybe you return additional data only admins can access or finish an action without throwing a UnauthorizedAccessException.
You test private methods indirectly while testing the observable behavior exposed through public methods.
Et voilà!
To read more about unit testing, check how to write your first unit test in C# with MSTest and four common mistakes when writing your first unit tests.