Ovidiu Stoica

The GTD method, or the "Getting Things Done" method, is a productivity system designed to help individuals and organizations increase their effectiveness and efficiency.

It was initially used by busy executives in large companies but in the modern day, it suits perfectly the demands of indie hackers juggling family, a day job, and a side-hustle

Here are 6 benefits of using GTD for Indie Hackers:

1. Improved focus and concentration on the task at hand- GTD keeps focus on one task at a time which is what the brain can do best.

2. Reduced stress and anxiety - We all have things we know we should do but we are not. GTD provides a definite look at all the tasks you have and the next actions for them.

3. Better time management - GTD emphasizes the importance of regular review of one's current tasks and filtering them based on context (where am I? What can I do? How much energy do I have?) so you tackle the right task.

4. Better creativity and problem-solving - GTD uses the brain for what it does best, solving the current problem at hand. By forcing the question "What is the next action on this?", You already do more than 50% of the work

5. Progress tracking through multiple projects - GTD emphasizes keeping an active list of projects and at least one next action for each of them

6. Mind like water - Essentially GTD is a method of downloading your brain into a trusted system so your mind is not cluttered by the multitude of tasks you're not doing. By freeing your mind, you let it focus on what's in front of it

I'm reading Eat that From

Summary: Do the hardest thing in your agenda, the first thing in the morning.

I'm 3 chapters in and already published a video, which took me 2 weeks to edit

I've been a web developer for 7 years and explored all frameworks post @reactjs

1/Introduction & Team

2/Philosophy

3/Nested Routes

4/Data Mutation

5/(Un)expected Errors

6/Styling

7/Performance

8/Deployment

9/Remix stacks

10/Community

11/Future & Funding

TL;DR @remix_run

If you enjoyed this thread, jump back to the top and retweet for others to see it

1. Follow me -> @ovstoica for more deep dives and tips from web development

Many creators see their biggest success with posts about their results.

If you can use this technique correctly, you can attract more people to your course/SaaS/consulting. Sharing wins may feel weird, but it will become easier after we understand how others perceive it.

Now, let's dive in.

#1: People feel you are finally validated

Results mean you went through the struggle, iterated on your creations, and now someone finally bought.

I saw a creator share "2 people bought my course," and he got 10 more customers from that post—including me.

#2: Other creators love celebrating the wins of peers

When somebody is on the same path as you and wins, it shows you are doing something right.

I love when other creators win, and I retweet many of their results.

#3: It's easier to buy something others have bought

People HATE making wrong decisions with their money.

When somebody has already bought and seems satisfied, buying becomes very easy.

#4: People are drawn to big win events

This is why startup funding rounds are 100x times more publicity than bootstrapping.

A startup founder who just closed a big seed round will get invited to give talks, interviews, and what is his "secret" while bootstrappers will code away in silence until they share some profits.

#5: Process makes people aware; results make them interested

Sharing your process is very important, but people take you more seriously when you back it with results.

I have a YouTuber friend who's been at it for 3 years, and a video averages 400 views. People ask him, "When are you gonna be done with that?". If he averaged 10k views per video, they'd ask, "When is the next video coming out?"

Please share your results, no matter how small they are!

I wish you well on your journey, and comment below with your last results.

I'm translating some Clojure code to Javascript for my job for transparency for the UI team and I realized why I prefer Clojure for Javascript. Here's the problem:

Select only unique objects from a list

Javascript:

const myDistinctArray = [
  ...new Set(myObjArray.map(JSON.stringify)),
].map(JSON.parse);

or

// This one presumes unique "id" === unique object 
let uniqueObjArray = [
  ...new Map(
    objArray.map((item) => [item["id"], item])
  ).values(),
];

Clojure

(distinct my-object-list) // that's it

Why does the Clojure one work?

Clojure promotes immutability by default, and this includes maps. So maps are compared directly by value and not by reference or identity.

Conclusion

The beautiful thing about Clojure is how expressive the language is and how much you can say with very few lines of code.

Last year, 190B$ were spent on burnout healthcare costs. Here's how to be the exception for this statistic:

#1 Don't volunteer for every task to get recognition - It never pays off the way you expect and you'll be disappointed.

#2 Go for walks everyday - Get outside, get some sun 🌞

#3 Avoid overtime more than 1 day / week - If you have to overtime, do it once / week. Otherwise, at 17:00 close your laptop. 🕓

#4 Set clear work expectations with your boss - Tell them your work schedule and what you won't do.

#5 Mandatory: Exercise - Non-negotiable. Exercise or get the chair hump. You choose.🏋️‍♂️

#6 Have side-projects - Work on programming stuff outside of work. Helps to get your mind off the stress at work.

#7 Have a non-tech hobby - Churchill painted to relax from politics. What makes you think you can do better? 🎨

#8 Take breaks often - 5 minute breaks: Stretch, call a friend, play with your dog. Often, this will make you more productive than before. ⌛️

#9 Ask for help from colleagues - Being blocked on a task and not asking -> Working overtime to solve it -> burnout

#10 Admit to your team when you're bored with a project - You can switch projects but many times admitting it to others will solve the issues

#11 Request domain training to revitalise your passion - Training in modern practices or attending a conference can revitalise you

#12 Solid sleep schedule - Programmers tend to sleep 5-6 hours. You'll grow old faster. Sleep 8 hours. No tech one hour before bed.😴

#13 At the daily standup say "Yesterday I had a bad day and didn't do much". - Feeling behind -> Working overtime -> Burnout

#14 Social life - You need offline friends. 🙋‍♂️

#15 Talk to your boss about your future in the company - If you think there's no future for you in the company, you'll be disinterested. Discuss a promotion path and steps to achieve it. 📈

You get a maximum of 4 hours of peak focus per day.

Let that sink in. You cannot use all that time for your day job. As a developer, you need to learn to be more productive, so you spend less time at your job. Here are four tips to do that:

#1 Keep actionable tasks near you:

What's the next action on this task?

Non-descriptive, general tasks will make you procrastinate because you don't know where to start. With a general task, ask, "What's the next action on this?" usually it will be:

• Research X

• Ask somebody

• Implement Y

#2 Breakdown big tasks: 

Avoid general tasks like “Build dashboard.”

Your brain doesn't know how to "build a dashboard," but most likely it knows how to research a design system for the new dashboard or create a Next Js repo for the dashboard.

Break down big general tasks into small and actionable pieces.

#3 Communicate with the team: 

The tech world is very dynamic. What was critical yesterday doesn't matter today.

Always check in with your colleagues and manager/PM to ensure you are working on areas with real impact. Two hours spent on critical issues are more valuable than two days spent on nice-to-haves.

#4 Delegate whenever possible: 

Teaching a younger dev to do your job is a win-win.

By doing this you create better people for your company, and you create more time for yourself. Never be the dev that goes to his programming cave and comes out with the final product. Communicate and delegate.

Finally, you'll get better if you keep working on side-projects.

I announced verbally a month in advance but forgot to give written notice.

I was going to Bucharest from Rome at the airport when I called my manager with the news. He took it well and asked about the new position. In the end, he said, "Send me an email with the details."

Here's my biggest mistake: I forgot to do that. In the commotion of coming from vacation and reacomodating, I forgot. After two more weeks, I start to say that I need to close any loose ends before leaving. Here's when I hear my colleagues saying, "Wait, are you leaving?"

Never defer giving bad news just because it is uncomfortable.

Your reputation precedes you, and the people who carry it are those you worked with.

If you leave a job badly, it will most likely come back to bite you in the back.

My higher manager told me he just found out in the mids of all the confusion. That this will set him back for 2 months searching for a replacement, and that he wished at least I would've given him some notice and not only announce my direct manager. My relationship with him, even though it was good before, suffered.

Based on this, here's how to avoid what happened to me:

#1. Give your notice way before you are required to do that.

This helps your team by giving them enough time to replace you.

#2. Don't rely on your immediate superior that he will relay the news.

I thought he would inform all relevant parties, but that was not the case.

Inform whoever needs to be informed in person. Ask what you can do to ease the transition before you go, but don't compromise on your deadlines (I've received hints of doing that).

#3. Have a face-to-face with your colleagues.

Have meetings with the people you care about.

You will meet them throughout town, at conferences, or on social media, and it is a pity to tarnish a great relationship just because it will be awkward. A group call with your best friends from the job is also great to have some closure.

This has been weird to talk about. I hope you learned from my mistakes. Remember always to give written notice, even if you don't receive reminders about it!

Can you improve the experience for your SaaS Clients using Server Side Rendering?

React is a framework for building performant Client-Side Applications; however, there are situations where it is not enough. Your Javascript containing React components is delivered to the browser, where it is executed, and all the UI is rendered.

This approach has some issues, which resulted in the creation of Server Side Rendering for React.

What is SSR?

Server-Side Rendering (SSR) is the process of fetching all necessary data and rendering your React Components on the server, and delivering the resulting HTML directly to the client browser.

Why use SSR?

• SEO - Google page crawlers can execute synchronous javascript, meaning if you need to fetch data to render your content, it will not be seen and indexed by crawlers.

• Bundle Size - When building a full client-side app, you need to deliver all your Javascript code to the browser. This code needs to be executed in the browser for the final user to interact with your application.

• Time-To-Interaction (TTI) - How much time passed between users opening your application until they could interact with the content. The shorter this time, the better. SSR helps with reducing your application's TTI.

If you have dynamic pages that show data that can be indexed by Google and bring customers to your app, SSR is an excellent choice for this case.

Why NOT use SSR?

When there are many requests to your server to render for many clients, this can cause an overload and decrease the response time.

Client-Side apps: All clients do the rendering for themselves

SSR apps: The server does the rendering for all clients

If your application is a dashboard for a client to access his data, a SPA (Single Page Application) should be more than enough.