Anyfactor

I have been to a handful of discussions, where the things I have built or plan to build that is mostly fueled by passion where next in line on the chopping block. It sounds pretty straightforward, but facts over emotion. Always. Even if there is valid reason to terminate a project, you need to present fact. Not emotion, no rhetoric about the future. Just fact. And match those facts to counterarguments, known limits. You may not always come out as a winner, but you will have something to cling on to.

At the end of the meeting, if you are persuaded by the counter-fact there is no financial promise to your project that means either:

- You are not passionate about the project to build project to be financially viable

- You don’t realize that your getting paid to make your employer money. This is not a hobby project.

Just do the standard smile emoji face 🙂 with very small and repeated ups and down nods. Don't say or agree to something unless you understand what they are talking about exactly.

If they are insisting or hinting you to join on the laugh, do this 🙂 while doing a couple of small sideways shakes of your head and with eye contact with them, and tell them you don't understand what they are talking about or you don't get the joke.

If they explain the joke and you REALLY find it funny, do this face 😊

If they say the joke was something about their culture or you wouldn't get it, say, okay while doing this 😐 then do this 🙂 and try to leave this conversation as soon as possible.

---

I think in the age of guerilla marketing and filtered opinions, typos are the litmass test of pure and genuine opinion.

If you genuinely cared about what you are trying to say, your words will flow like a stream. Your rambled words will carry what you truly want to say. It makes you more human.

I am not against revising your comment, but I have seen that, the more I revise, the more I doubt myself. Do I really have to say this? What good will it do it me? What good will it do the other person? What am I trying to prove here?

Typo checking has made me more filtered and stopped me from creating somewhat of whatever you will call a genuine connection over the internet can be.

At least internet discussion or, for anything that is personally rambling grammar checking should have its limits. You should have an acceptable time of revisions with reasonable amount of grammar mistakes.

The MVP idea is covered by many people who are far smarter than me. Who are professional builders and developer. Who have jobs in software engineering. 

However, in the indie hacking space, as a self-taught software developer, I think the formalization of the MVP process comes with a little bit of bureaucracy. What you need is proof of concept even before committing to an MVP project. What you need is to show yourself it works. 

The POC (Proof of Concept) stack is probably not for you, as it is about throwing stuff on the wall until something sticks. For the POC stack, you don’t need a product, you need scripts that does things you intended to do, making it work as an MVP is a part you compromise on.

---

Example:

The client wanted to create a pricing tracker for some kind of industry. The intention is that he wants to aggregate the pricing information from several vendors, aggregate in one place, provide analytics, do some alalertsand sell a subscription.

A mature software engineer, will draft an architecture, build a proper API and website, do some wireframing etc. 

That is not me. I believe in the POC stack. Do the absolute minimum to prove a concept for a product with enough room to build and scale a product. And if possible do it cheap.

1. Get a VPS. Create the foundational programming there with a bunch of scripts that are connected to each other. Each script does one thing exactly. And you can hookup more scripts to each other without causing any friction.

2. Figure out the API part. TEMPLATES. TEMPLATES. TEMPLATES. Get a firebase template that supports auth and stripe. Use a CSS framework. Connect the VPS to Firebase to saturate it with data. And you have your product.

---

https://nim-lang.org/install.html

https://narimiran.github.io/nim-basics/

Install choosenim:

curl https://nim-lang.org/choosenim/init.sh -sSf | sh

Put nimble on path; check post install output of choosenim

Create basic nim script:

echo 'echo "hello world"' > hello.nim

Run script:

nim c -r hello.nim

You will see an executable as well. Run executable

I have a history for having bad commit history, bad commit messages and overall bad git etiquette.

After working years as a freelance programmer, I now work full time at a mature company as a DevRel with tons of public repository. No more wild west style programming for me. Moreover, I don't work as a programmer anymore so, I try my best to avoid disrupting the workflow of my engineering teammates.

So, this is my "clean" git workflow.

The workflow

Start with an Idea

Create a ticket to do something

Discuss the ticket with team mates. Ask around what to do.

Get an idea of what to do.

Come to final decision of what to do!

Clone to private repo

First clone the public repo on my local machine

Create a private remote repo

Delete .git file in my local machine repo

Git init on the local repo

Push content to the private remote repo

Invite teammates as colloborator on the private repo

Start working on stuff

Get started with work

Make commits

Push to remote

Showcase progress to teammates

Avoid doing rebase, make changes with commits exclusively

Get feedback

Get final review

Once team mates are satisifed, have it be reviewed and have it be greensignaled.

Download the private repo as zip file as a backup

Rename the local directory [1]

Delete the remote private repo

Create a fork of the public repo

Clone the fork

Delete the content of the clone except for the .git file

Transfer the contents from renamed private local repo [1]

Make one single commit with a summary of changes as bullet points

Push the repo

Create a PR

Invite the teammates one more time as reviewers

Squash commit and merge

Then delete my fork.

Why?

This is unsustainable

I know.

Commit Squash?

Have you tried commit squashing with a remote repository?

Rebase?

Have you tried rebasing with a remote repository?

Git bare repository?

Doesn't work all the contents get downloaded anyway.

You are supposed to keep a "version history" with git

I have a version history on my private repo when I started working. But I don't need to push that history to a public facing repo! I have a ticket. What more do you need as "version history"!

What about merge conflicts?

At the very last step, I do a fork of the most recent version of the repo. That is how I avoid merge conflicts.

Colloboration

I invite people who need to colloborate on my local private repo. They can make changes there.

Monorepos

I don't work with monorepos. But I have seen how messy they can get. So this strategy should work with monorepos, no matter how pedantic you think it is. You could get some extra mileage with branches.

There must be a better way

I have no idea how to draw but I want to use comics in articles to ELI5 topics at hand. I would like to make articles and documentation a fun experience to read or browse or skim through, and IMO comics, memes, drawings and diagrams are the way to go.

https://openpeeps.com/ || Hand drawn illustration library

https://blush.design/ || Customizing drawings

https://www.opendoodles.com/ || Open Source Illustrations

https://feathericons.com/ || Icons

https://www.screely.com/ || Turns screenshots to browser mockups

https://generated.photos/ || AI Generated Random Faces

https://doodleipsum.com/ || Generate Random Doodles

Writing technical foundation

Diagrams Diagrams Diagrams.... & memes

Technical Documents should be fun! Not technical!

People can simply read the documentation but a technical article should assume the reader knows nothing.

Try to make things fun and super easy to understand

Simple and short

Quantity + Quality; Not just quality.

Super short articles that gets to the point quick

Bullet points!

If we are doing multiple things nothing wrong having multiple articles. Don’t cram things into one place.

Each document should be self contained. We shouldn’t attempting serializing everything.

Tools

Excalidraw: Comic Sans + Whiteboard + Simple Diagrams https://excalidraw.com/

Draw.io - Complex diagrams https://app.diagrams.net/

Canva - Simple graphics and animation

ShareX - Screenshotting tool

Carbon.now.sh - Code Snippet Images

XKCD inspired Graphs - https://matplotlib.org/stable/gallery/showcase/xkcd.html#sphx-glr-gallery-showcase-xkcd-py

Inspiration

https://www.reddit.com/r/explainlikeimfive/

https://github.com/BolajiAyodeji/awesome-technical-writing/blob/master/README.md

https://dilbert.com/

https://xkcd.com/

I have worked for a social media startup (as a community manager) and attempted building one myself. The first rule of social media is that your friends are already there. So making groups of people interested in a desolate land is incredibly incredibly hard.

When we attempted to grow, we were getting a dozen, maybe half a dozen sign up every day. They will stick for a day or two, post some test content. But eventually they will leave the place. Our strategy was to interact with every user regularly but we just couldn’t -

- make them stay - invite their friends to join

The traditional path of social media startups is brutally hard, in my opinion there is no successful social media that is “better”, there is only social media platforms that were “lucky”.

I mainly work with (aka know) Flask.

I was part of a few Django projects and I saw people investing more in configuring the framework right than to focus on the actual functionalities of the application.

Even though they were building MVP, the initial investment in foundation building with the hopes of scalability for proof of concept project just feels wrong to me.

So when should you choose Flask over Django -

You need quick development turnover

You are building an internal (use) API

You building a proof of concept product

You are not worried about scalability

Why Power Query?

Power Query enables easy -

Pivoting

Merges

Filtering

Grouping

Splitting

Replacing

An advantage of Power Query is that it enables previews, that is not usually available with other ETL tools.

Alternatives to Power Query

Knime

Alteryx

Great tool but big bump in pricing from desktop to servers; same goes for the automation add-on

ADF or Azure Synapse

Has good PQ integration

Also check out “Azure Data Factory”; but you need to have the data in Azure PAAS.

Other Tools

Pentaho

Apache hop

Matillion ETL

Sisense

dbt

Domo

Quicktable

Zoho Dataprep

TLDR:

Make customer interaction as google-able as you can.

Always incorporate gifs with documentation and guidelines

Create video and step by step tutorials unconditionally

Convert every customer interaction to an FAQ segment or a microblog

Avoid writing books as documentation blogs. Adopt w3school like writing habits.

Post your FAQs to stackoverflow. Two dummy accounts. One to post the questions, one to answer the question

Add every meta information and phrasing variations possible to commonly asked questions

Support/success staff should also be a part of the dev team so they can understand the product philosophy and not just be a liaison of the dev.

🔗 Ask HN: How did you find your current job? | Hacker News (ycombinator.com)

⭐ LinkedIn, Craiglist, HN Who is hiring.

HN - Who's Hiring

LinkedIn - Open For Work Flag

https://www.gm4jh.com/ - Guerilla Marketing for Job Hunters || Cold Email your favorite companies

Writing an Open Source project

AngelList

Hackathon

Recruiter, particularly LinkedIn reaching out to you. But beware of those, who want you to sign up and they will reach out to you later.

Real Life Network with people or in LinkedIn. Tell them you are looking for a job.

Local Job Boards - Craiglist, Indeed, Monster, LinkedIn, NodeFlair, hired,

https://remotive.com/ - Remote Jobs Aggregrator

Slack groups that have a "Jobs" Channel

Find interesting companies > see who in your network works for them > send them a message

Start with a internship or a summer job

Cold apply to websites

Build a project you can sell to your future employer

Convert your contract/freelance role to a full time role

Referral from former colleague

Writing blog posts