28 Dec 2024 #misc
The first moments show how you’re going to be treated for the rest of the time.
It applies when you go to a restaurant, call a customer service line, or go to a bank. And the same is true when joining a new team as a developer.
The first day I joined my last full-time job was awful.
I was speaking a foreign language for work for the first time. I was working from home for the first time too. My company laptop didn’t arrive that day. I was told to install the software project with long and outdated instructions. I was completely lost.
I got a call from my boss’s boss that day, promising I’d “be in trouble” if I didn’t install that project before the end of the day.
The funny thing is, I didn’t have to work with that project at all in the 5 years I was there.
Instead of making your new team members feel lost, set clear goals for the first day, week, and month.
For the first day, a new team member should:
- Install the right tools: email, VPN, chat clients, etc
- Introduce themselves in Slack or company chat
- Get to know their team lead
For the first week:
- Have 1-1s with all team members
- Have the working environment ready
- Complete a dummy task to understand the project workflow
For the first month:
- Complete a medium-sized task, with almost no guidance
Make it really easy for new team members to install your project and its dependencies. They should be ready to work by running a single script or pressing a button.
Make it really easy for new team members to follow existing rules and conventions. Don’t rely on outdated documents. Show sample code or work that follows those conventions.
Get your developers “up and running” as quickly as possible. Show them how you’re treating them for the rest of the time.
27 Dec 2024 #writing
Writing a book is a sign of prestige and a synonym of expertise.
A book brings interviews, talks, consulting gigs, and more opportunities. Sales don’t bring the most money, but the doors it opens do. That’s what I’ve heard.
If you think of publishers, pitching, and rejection when you think of publishing a book, there’s the self-publishing route. Amazon, Gumroad, or your own site are good options.
Writing a book can seem daunting.
But in an interview for Self Publishing TV on YouTube, James Altucher shared a simpler way to write a non-fiction book:
- Find a topic you’re interested in.
- Look up 10 scientific papers about it.
- Explain each paper in simple words and share a story.
Et voilà! You have a book: “10 Scientifically Proven Ways to …”
The thing is, scientific papers aren’t written for normal people. They’re impossible to read. Full of technical jargon and long paragraphs. Arrggg! I tried it when I wanted to understand phones reducing our cognitive capacities. I said, why they write like this?
Even if you don’t write a book, this is a great idea for a newsletter, series of posts, or email course.
26 Dec 2024 #misc
This year, and for the first time since University, I took a writing class for the Internet.
It was a webinar, to be precise. Tim Denning and Todd Brison ran it.
The main lesson? Write daily. Daily?! Yes, daily.
That was shocking. I was used to writing on my blog when I felt I had something to say. Usually, once a month. Later, when I gained some traction, twice a month. I only wrote daily when I challenged myself to write ~20 posts before Christmas in 2022.
To write daily, you don’t have to produce 1,000-word posts each time. A good headline and one main point are enough to hit “Publish.” Even a tweet, a quote, or 200 words are a good place to start too.
When you write daily:
- You make people notice you and remember you by consistently showing up in their feeds.
- You get closer to your future customers, bosses, and partners. Remember, people don’t buy from or do business with random people on the streets, but from people they know.
- You build a library of content that showcases your expertise. People will see you as an expert, or at least someone who knows about the subject you’re writing about.
Write your first piece to get ahead of those who never start, and keep writing daily to get ahead of those who quit along the way. Your future self will thank you for it.
25 Dec 2024 #misc
We, as coders, take pride in preaching and following best practices.
Don’t write SQL, use an ORM. Don’t write conditionals, use design patterns. Don’t throw exceptions, use Results…Don’t do that, do this.
Those “don’t do that, do this” hide all the context in which they make sense. That’s the part we skip and don’t tell when we preach best practices.
Today, I had a call with a consulting company that needed help. They were migrating a small shop’s application from the early 2000s to a newer stack. It wasn’t written and maintained by professional software engineers. Zero best practices. Lots of copy-pasting.
Migrating that application and bringing its owners up to speed are two different challenges. They have to maintain the application once the migration is done. Using the latest and greatest best practices wasn’t an option.
Often, instead of going all in on best practices, the best path to follow is “let’s do the simplest thing that can work, without doing any more harm.”
We shouldn’t call them “best practices,” but rather “pieces of advice that worked for me under certain circumstances and might work for you too.” And we shouldn’t blindly follow them. Not all code is created equal and worth the same.
24 Dec 2024 #writing
Don’t write to seem smart or to sound like a famous writer.
That will only make you use technical jargon, complicated words, and long boring paragraphs that scare people away.
Instead, write for only one person.
Every time you sit to write, imagine you’re writing for a friend, coworker, or your past self. It will give you the right tone, context, and level of detail. You won’t use words or jargon you wouldn’t use in a real conversation. Instead, you will use your true voice.
I wrote most of my coding tutorials for a friend or two. They almost never asked me to write them. I never showed them the finished piece. I simply imagined myself explaining something to them to make my writing easier.
If writing for someone sounds hard, record yourself explaining something and transcribe it.
What’s the point of sounding smart if your writing get so complicated that people don’t read what you write?
“Write with the same voice you talk in. You’ve spent your whole life learning how to communicate with that voice. Why change it when you communicate with text?” — James Altucher