Forem: Jason Leow ~ plugins.carrd.co

AI makes you get worse at coding?

Jason Leow ~ plugins.carrd.co — Sun, 06 Oct 2024 13:43:00 +0000

Lots of software folks—especially super experienced, senior ones—talking about how using AI will make you get worse at coding.

I dunno man.. if using AI made you worse at coding, maybe you’re just not using it right. I feel like I only better at coding using AI, compared to the same length of time spent coding without. And at the rate of how good it gets, I suspect it will be a multiplying factor in helping me accelerate at getting even better at coding, faster.

Some observations and solutions:

❌ Poor prompting, like giving vague instructions or desired outcomes. Basically skill issue.
✅ Hot take: Prompting is like a whole new programming language itself. The English part of it is deceptive - just because you speak English doesn't mean you're well versed in prompting. Even hotter take: Just because you know Assembly, C++, Javascript and PHP, doesn't mean you already know how to prompt.

❌ Expecting AI to be able to do everything from a single prompt
✅ One part of skill issue. But Most LLMs until now don't do well if you give them all the information they need to solve it, expecting them to give you the right answer in one go, on first try. Nope. You need progressive prompting, revealing more context as you go. Only the recent o1 model seems to have cracked that, but waaay too expensive now to use for coding.

❌ Stop reading code. Just accepting whatever the AI provides.
✅ If you don't watch what you eat, you become what you eat. Rubbish in, rubbish out. No quality control means poor code, as simple as that. Just because the provider is a robot doesn't mean you stop being a manager and arbiter of what code enters your repo. If you'll never do that with even senior programmers, why would you suddenly get lazy and just accept whatever the AI gives? Human folly, not robot issue.

❌ Spend more time debugging than coding.
✅ If debugging is taking too much time, you're probably prompting wrong, or doing what I said in the first 3 points here. And the right solution is seldom to ask the AI to debug your code, because you got off at the wrong base. Revert, and start over with a fresh prompt knowing what went wrong. And then prompt it together piece by piece instead.

❌ Never believed in AI for coding anyway, so just give it a cursory attempt, and then says it's "meh".
✅ You get as much as you put in. If you never believed in Stack Overflow, you'll think it's shit too when the first answer you get is "Answer is duplicate of xxx", or "Why ? Use my framework instead.". So many folks I see dissing on AI, when you probe further, they just hate it for ego reasons, and never gave it an honest try. Besides, it's such a lame take. Like, when programmers started searching for answers on Stack Overflow, I'm sure the older veterans would complain as they would complain now about AI, that Stack Overflow will make programmers worse at coding. Because they just "copy and paste code"! Yet, googling for answers and on Stack Overflow is now considered an industry norm.

So... in the end, AI is just a tool like Stack Overflow before, but with superpowered search, filtering and personalisation. Think about it. That's just it.

It's just a fking tool.

You can use it to be lazy, or you can use it to get better. Don't blame the tool, blame the skill, change the mindset, or drop the ego.

Ball's in your court.

How to use AI for coding the right way

Jason Leow ~ plugins.carrd.co — Sun, 08 Sep 2024 23:35:00 +0000

Devs: "Yeah Cursor/ChatGPT/AI is great and all, but you still need to know what you want, or know how to check for hallucinations. A complete beginner won't be able to code working apps with it."

Not really true anymore..

I've been coding in an unfamiliar language (Ruby) for a freelance gig, and PHP for personal projects, so I’m often unsure how correct looks like.

What I do to make sure it's correct:

– Overall approach: Using AI for coding is like having a super knowledgeable programming intern who's knows everything but not so good at applying said knowledge to the right context, and we just have to help nudge it along. Put another way, Claude/Cursor are like outsourced devs, and my work mostly is managing them, pointing them to the right direction. More creative direction than actual coding. I think 80% of my code written by AI now, but that doesn't mean I can fall asleep at the wheel. I got to stay alert to errors, follow conventions, check their work all the time.

– Before I start, I chat with Claude 3.5 Sonnet on Cursor on the broad steps to take, the overall architecture. Progressive prompting. I can reference the whole codebase with Cursor for context. Only use Sonnet. Not Opus. Not Haiku.

– I also add system prompts or "rules" for Cursor to give it a better context frame from which to answer. Adapted the prompt from the Cursor forum. It goes something like "You are an expert AI programming assistant in VSCode that primarily focuses on producing clear, readable Python code. You are thoughtful, give nuanced answers... "

– In Cursor setting, you can also upload documentation of the framework, language or gems/packages you're using, so that it can refer to it for best practices and conventions.

– AI can be not just coder but also code reviewer. Get it to review its own code, using prompts like "Any mistakes in this code?", "Does this follow best practices for Rails/PHP?" Sometimes I ask "Does it follow convention in this codebase?" and @ the entire codebase and @ the documentation of the language.

– Sometimes I use a different LLM to as a checker. I open a separate window, and get Llama 3.1 or GPT-4o to double check the code for bugs. It's like getting a second opinion from a doctor.

– Share error messages, highlight the code, cmd-L and link the right files to give it enough context. I can't emphasize this enough but with Cursor, using the @ to link the right files/components, or even a docs on the internet, is killer. It's tempting to @ the entire codebase every time but from personal experience/observation, giving too much context might hinder too, make it 'confused' and it starts hallucinating or giving weird suggestions. There seems to be a sweet spot in terms of amount of context given - more art than science.

– Or use cmd-K to edit the line directly. Otherwise I ask it to explain line by line how it works, and ask it questions, reason with it. I learn from the process. Knowledge and skill goes up. This is an important step, because people are right that AI can make you lazy, waste away your coding muscles, but I think it's 100% how you use it. I try not to use AI in a way that makes me lazy or atrophy, by asking questions, reasoning with it, learning something each time. Mental disuse would be simply copypasting without thinking/learning. It's a daily practice to stay disciplined about it. Kind of like eating your veges or going to the gym. Simple but ain't easy.

– Following these steps, I'm able to solves bugs 99% of time. The 1% is when there's some special configuration or a key part of the context is hidden or not part of codebase. That's when I tend to need help from the senior devs, or from code reviews or tests to pick up on. The usual way. The processes are there to mitigate any potential drawbacks of AI generated code.

Cursor + Claude Sonnet are like code superpowers.

First published on Lifelog.

A fun detour is also progress in coding

Jason Leow ~ plugins.carrd.co — Tue, 02 Nov 2021 12:39:03 +0000

Sometimes, when stuck debugging a bug, the best thing to do is to take a detour, away from the bug.

Once after working really hard for past 2-3 weeks learning and head-banging on a Rails API, I decided I needed to switch up and do something fun instead. Sometimes taking detours make all the difference, even though it sounds unproductive and not adding anything to the progress.

Progress is not lines of code written

But that’s the thing. What’s progress anyway? Measurable progress like lines of code written, revenue made, customers acquired – sure, that’s progress. But it’s also my job as an entrepreneur and a creative professional (I see myself as one) to stay inspired and motivated, in order to make this journey sustainable. And switching up the tasks like this is all about inspiration and motivation. In the end, if I don’t persevere in the future, whatever progress I make in numbers in the present will be for naught anyway, isn’t it?

Yeah, so this detour is actually still progress. I do see it as much more important work actually. Having fun and staying inspired is the real work, because downstream you get all sorts of goodies from it – better work quality, more productivity, fresh and innovative ideas, sustainability, and overall higher quality of life.

How you know a detour worked

I want to jump out of bed in the mornings, not out of trepidation but excitement. And indeed, after spending time in my coding playground this morning, playing with Vue.js repos in Codepen; browsing cool shit that people make; learning how to make them myself; following my curiosity and playfulness, my fun tank was all topped up. I can feel it right in my heart. It sings. And I sang my way to lunch, spirits glowing, chest forward and head up high.

What a difference a morning can make. Now that’s real progress.

Follow my daily writings on Lifelog, where I write about learning to code, goals, productivity, indie hacking and tech for good.

Lazy debugging gone long

Jason Leow ~ plugins.carrd.co — Mon, 01 Nov 2021 10:26:55 +0000

Codenewbies: Don't be lazy when it comes to debugging, especially if you knew better right from the onset

That’s what I learned from my first 4-day hitting-head-against-wall experience of trying to debug code.

Debugged for 4 days because I was lazy

I wanted to do a POST request to my Rails API using a Vue app. Both are super basic setups, just for learning purposes on how to develop an API and to use it. And out of laziness and not doing prior research, I created a single text input field to POST to my API, thinking that if I type a proper JSON in the text input it would work. And of course, it didn’t. Actually before that, I somehow knew that I needed to have a proper form to structure the JSON so that it gets POSTed properly, but I was lazy. And all because of a little bit of laziness, I spent days to debug what could have been solved in a few hours.

So the key lesson I need to hammer into my head: DON’T BE F**KING LAZY, especially if you knew better.

There are no shortcuts

There’s no shortcuts in coding. Yes, even using libraries and frameworks. All shortcuts come with trade-offs, and a price. You either pay it much later, or very soon. Thankfully I paid up in four days. Imagine if I had to hammer at this for weeks?! I would have given up coding altogether. But that also showed me just how much perseverance is needed when it comes to coding your own thing. More bugs like this will come for sure, and very likely even bigger ones taking more days or weeks.

Better to enjoy the challenge, than to want to wish it away at first encounter.

It’s strange, I do kind of enjoy digging down deeper into the rabbit hole to solve a problem. And even stranger - there’s a stubborn kind of streak in me that ‘likes’ to keep at it till I win. Man vs machine kind of game. It’s not always a delightful game, but a satisfying one nonetheless when I solve it.

If this was a relationship, it ain’t romance and fireworks in the honeymoon period. It’s fighting and loving, hitting and kissing, all at the same time. Not a typical relationship, but one full of life for sure!

Follow my daily writings on Lifelog, where I write about learning to code, goals, productivity, indie hacking and tech for good.

How I ended up making a JAMstack app on Rails & Vue

Jason Leow ~ plugins.carrd.co — Sun, 31 Oct 2021 06:30:16 +0000

Amongst tech stacks, pairing Rails as backend and Vue as frontend with a JAMstack approach has got to be one of the weirder combinations...

"I WON!" I felt like a lottery winner when I finally made an API-first app. One that works not just in local but in production, out in the real world. It’s a todo list app, with Ruby on Rails REST API as backend, and a Vue.js app as frontend to fetch data from the API.

But amongst tech stacks, this has got to be one of the weirder combinations. Pairing Vue with Node, yeah more normal. Or any of the more recent and modern frameworks to handle the backend server. Rails is usually thought of as a monolith, not quite for JAMstack. So how did I come to this combo?

From Rails to JAMstack to Vue

When I discovered JAMstack, I knew it in my gut (even though I’m a coding noob at that time) that I want to explore this tech stack for making web apps, and eventually my SaaS. But I didn’t know how to get there. I dabbled with Stackbit then and it was such a great way to slowly orientate myself to JAMstack, since you can literally spin up a JAMstack website in minutes using Stackbit. I made tiny customizations to the template, slowly begin to read a little JSX/React/Gatsby, how everything connected together.

But how do I make an API, and which frontend framework should I use to fetch data from it? I knew a bit of Ruby on Rails by then (from my learning to code journey the year before), and I always felt that creating a backend on Rails felt within my reach. It wasn’t as scary as using other frameworks. And I’d done it with Rails before already. So I decided to go for Rails as my backend framework of choice.

Then I (re-)started my journey of learning how to code, this time with Vue.js. AN hour of code everyday. Just start. I got inspired by what @dannypostmaa was doing with his product Headlime. He also didn’t know how to code eight months ago! When asked, he said he picked up Vue.js because it looks easiest to start. So I researched a bit, and discovered it suited my programming taste. It can be adopted progressively, and all that’s needed was to add a script to the html file, just like the good old jQuery days. That was familiar because all the HTML, CSS and JS were all used the same way I was used to in web development 101. It was not so scary unlike React, Next.js and Gatsby where everything was JS, even in a HTML file.

Learning Vue and the first taste of the joy of coding

Learning Vue had been such a joy. I could never have known that I would enjoy coding this fun, all because of a framework that was suited to me. But more importantly, I also found incremental ways to learn coding and to stay motivated, by browsing mini Vue projects on Codepen, and learning from them.

And now, after almost two months of feeling my way through coding on Vue and then Rails, I have a production-level kind of app (albeit a very basic one) using that Rails-Vue stack. It felt like I’d come so far from only knowing how to make informational websites using HTML, CSS and JS. Or to go even further back, from making sites using Wordpress.

And the best part?

That sense of excitement and possibility, from what was a tiny little spark, to what’s a blazing fire today.

Now that is precious beyond measure.

Follow my daily writings on Lifelog, where I write about learning to code, goals, productivity, indie hacking and tech for good.

Side projects I wouldn't build in 2021

Jason Leow ~ plugins.carrd.co — Sat, 30 Oct 2021 06:55:40 +0000

Not all side projects are created equal. Some are just over-done, to hell. Don't do it.

Learning coding by doing is one of the better ways to pick up coding. Code newbies are often advised to choose a side project and then use it as a vehicle to learn your programming language or framework of choice. Even experienced devs have side projects, as a way to tinker and learn new tech.

But not all side projects are created equal.

Some are just over-done, to hell. Here’s a list of things I wouldn’t build myself in 2021 and some suggestions on what's worth building instead, and why:

Todo apps

Generalized todo apps are the chairs in the design industry. Every designer wants their own spin on the chair, so does every developer. It’s saturated and boring. But perhaps todo apps can work in super niche work situations where tracking the tasks is important, like say a factory, or distributing meds at a hospital.

AI-powered copywriting app

Since GPT-3 opened up access, generalised copywriting apps powered by GPT-3 had been popping up every week. It's done to hell, and it's becoming a commodity. Instead of using the AI for general copywriting, how about for specific, niche use cases and industries? Like say short-form tweets for Twitter.

Remote job boards

The pandemic basically threw the world into remote work, and remote work job boards are flowering like wild weeds. Probably better off not making a general one, unless you belong in an industry or vocation where there’s a gap, like say digital is not common yet, open roles are still spread by word of mouth, and/or matching candidates to employers is hard.

Free icon pack

Frontend devs/designers, just don’t. Besides icons, also trending are free packs of illustrations and Figma/Sketch templates. Just. Don’t. Unless it’s part of a larger marketing strategy, free design packs are so commoditized they are almost worthless. Some exceptions could be (again) super niche use cases. Like say illustrations for healthcare/medical apps. But you probably really need to understand the industry to come up with something original and in demand.

What else wouldn’t you build in 2021? What would you build instead?

Follow my daily writings on Lifelog, where I write about learning to code, goals, productivity, indie hacking and tech for good.

Step 1, reboot the server

Jason Leow ~ plugins.carrd.co — Fri, 29 Oct 2021 07:15:04 +0000

Yes, switch on and off that computer. Same principle, different computer.

Some days, just rubberducking alone doesn't help.

Today I had to seek help for a bug again again, but this time writing out the question out loud (aka rubberducking) didn’t work. A friend helped me out in the end, and all it took was that dreaded question: “Did you reboot the server?”

You know how the first thing you should try when your computer/smartphone acts up is to switch it off and back on again? Yep. Same principle, different computer. A server is a computer too. It was hands-down a mistake that only a rookie can make. One of those laughable yet relieving moments. Thankfully, I didn’t spend the whole day on it!

My friend mentioned that he used to have a sticky note stuck on his screen, outlining the tips for debugging before he asked someone else for help. The very first point was “Reboot the server”. That got me thinking…if I had to write the same sticky note, what should it contain?

Reboot the server.
Rake/migrate db (for Rails users).
Check the code for syntax errors, missing semi-colons, commas or closing brackets.
Type out the code if you had copy-pasted over some bits of code.
Google {language/framework} {error message}.
Search Stack Overflow.
Stop all debugging after 30min, take a break.
Try a new approach after break, whatever it may be.
Rubber ducking: Write out what you’re trying to do, talk about the error you got, outline the things you tried, paste public code repo. And wait. Don’t send it out yet.
Continue debugging for 30min.
Send it out to friends.

That definitely can’t fit into a sticky note for sure! But as a first noob version, it’ll do. For now.

Follow my daily writings on Lifelog, where I write about learning to code, goals, productivity, indie hacking and tech for good.

Daily code, like daily bread

Jason Leow ~ plugins.carrd.co — Tue, 26 Oct 2021 23:52:03 +0000

Why I decided to code for 1h daily for 100 days under #100daysofcode

A year from now, you’ll wish you had started today ~ Tony Robbins

That line still resonates deeply today. Or stings badly, depending on what I’m thinking about.

I’m glad now for some of the things I started a year ago today. Things like being on keto, learning coding, having a child. Without these things, the quality and meaning of my life would have been much worse off.

But it’s one thing to be glad that you started, but another to have reached your goal. For coding, I’m glad to have started, but my journey is far from over. In fact, it’s just began, and I’m nowhere near the level of proficiency I need to be able to create the products I dream of. Basically, a competency-aspiration mismatch.

“Easy or not, time will pass anyway.”

If time will pass anyway, might as well just do it, so that one year later I won’t just be glad to have started, but elated to have accomplished my goal.

That's why I decided back in July 2020 that in order for me to get to the mastery I want, I need dedicated practice. To achieve mastery, I can’t drop in and drop out every few weeks or months. My grasp on coding often feels like I got it, then I don’t. Two steps forward, three steps back. I’m tired of this push and pull relationship. Hence, I dedicated an hour of code daily, in the mornings or at night. Rain or shine, busy or not. Sixty minutes of code every single day, or bust (my streak). For 100 days - #100daysofcode

Daily code, like daily bread.

And I'm grateful and glad I did, because I finally made coding stick, and I made my very first SaaS.

Follow my daily writings on Lifelog, where I write about learning to code, goals, productivity, indie hacking and tech for good.

Secret dev tools for every code newbie

Jason Leow ~ plugins.carrd.co — Mon, 25 Oct 2021 23:36:52 +0000

I’d been learning a lot of new programming tricks lately and picking up new tools too. Some of these tools got me really excited that I have to share them! These tools are not commonly recommended in online tutorials or articles and might not be well-known to code newbies:

Coding, hosting - Glitch

This really blew my mind. It sounded like just another Github alternative on paper, but when I arrived on the site, all the vibrant colors, cool whimsical illustrations……! It’s like Github but with unicorns and rainbows; like Willy Wonka’s chocolate factory but for coders! It’s got so much personality and confidence in their branding, that I’m super impressed. Such a fun and delightful experience just browsing through all the code repos. And it’s not just a prettier Github, but a better one too. Glitch allows you to code collaboratively in realtime, much like Google Docs. This makes Github feel like Windows 95 Microsoft Word (oh wait, Github was acquired by Microsoft lol). You also see your site or app deployed live in a preview window with a unique subdomain (or custom domain), much like Codepen and JSFiddle. There’s definitely something of a trend here, where community-generated content is built around a collaborative tool.

Command Line - Hyper

Using the terminal used to scare me a lot, but since having to learn Rails and Vue, I had to start using terminal quite a lot and am slowly coming round to it. But not the user experience of it though. The developer experience of using this dark mode interface with neon green characters isn’t the best, so I decided to try out Hyper. It’s an alternative to using your native terminal, and comes with themes to add color to the text, and plugins like search that allows you to search for a particular command you used in the past. Much better UX now.

Testing APIs - Insomnia

Postman is a popular tool for testing APIs, but it feels bloated. I chanced on Insomnia from a tutorial and loved the simple and well-designed interface for it. Sometimes simple with less features is better for beginners, because it’s not so overwhelming. Coding a Ruby on Rails API is completely new ground for me. It was scary initially, but after following a few tutorials, I feel more confident, and being able to now set up the GET/POST/PUT/DELETE requests and test the API easily had really boosted my morale.

Database - TablePlus

This was a real life-saver. I hated trying to access my database over the terminal. A database is best visualised as a table, but command line returns it in text! It just doesn’t go. TablePlus shows the data you have in a table format, allows you to query and search easily, and more.I’ve not even touched the depth of the features available. I’m just so relieved to be able to see my data now in a table format, in a way I can understand, and manipulate my data much more easily.

Design - Figma Community

This new Community tab in Figma is still in beta, but I can see that it’s going to be a huge hit amongst designers. Figma is a collaborative UI/UX design tool, kind of like Photoshop remixed with Google Docs, but ten times better. I always felt it had an edge over Sketch (which is another design tool popular with UX designers), but now with the Community feature it’ll really stand out, because the Community feature is like Dribble remixed with Github rolled into one - a bank of Figma templates made by notable tech companies (like Spotify) and great designers. Browsing through all the different templates made available for free, I almost feel like I don’t ever need to design anything original ever again, because all I need to do is to search, and then duplicate and customize to my own project. And it’s not just templates for designing UI for phones or desktop screens, but also lots of cool collaborative tools and templates to hold a remote brainstorming session together, resume templates, everything! It’s like a designer’s dream come through!

Follow my daily writings on Lifelog, where I write about learning to code, goals, productivity, indie hacking and tech for good.

I couldn't foresee myself coding before but I do now

Jason Leow ~ plugins.carrd.co — Mon, 25 Oct 2021 13:58:35 +0000

How it went from "I wish I can code..." to "Hell yeah I code!" - My journey of decoding coding

One of the things I couldn’t foresee myself doing before, but do so now: Coding.

“I wish I can code…”

For the longest time, I was one of those who said “I wish I can code” but never really meant it. Why? Because my actions reflected my priorities, and seldom did coding end up being acted upon. Even when I did, it had a start-stop manner to it – I’ll do a few tutorials, then quick. I’ll pick up again, then quit after a few weeks. After a few cycles of earnest false starts of this, I was beginning to feel that coding is just not my thing. Maybe I’m just not hard-wired that way, I justified to myself.

Let’s give this a shot, again

But somehow, I tried again in Jan 2019, and tried to push through on learning. It helped that the Government gave everyone $500 to take whatever course they wanted, as part of a national upgrading initiative. OK the money barrier is settled. So I signed up for a few beginner courses on Udemy and made a few projects from it. Got some fundamentals in HTML, CSS, JS, jQuery, Bootstrap, PHP, mySQL. Those initial lessons were really just following a video tutorial line by line, and not really understanding what I was doing. A bit of monkey see monkey do. But it grew on me, slowly. It’s like learning a new (spoken) language. Bit by bit, I connect doing this thing with getting this other thing. Cause and effect. I learned how to ask better questions. By the end of the course, it boosted my confidence to try harder in other things. I had crossed a threshold. The threshold, that moment when coding no longer felt scary. (I realised it was actually just higher pain tolerance of hitting the proverbial head against a wall when it comes to debugging)

In love with Ruby

Then next came my next milestone and challenge. I wanted to make a basic web app on Ruby on Rails. This time I logged the steps in my journey and a pattern emerges:

Get over initial learning slump. Muster inspiration and courage by reading articles about other prolific makers and developers whom I look up to, listening to podcasts etc.
You fear what you don’t know. Read up articles about Rails, how-tos, to-dos for noobs.
Build early foundation (barely). Take a Rails course online, build basic app/blog, “see how easy it is?!” I tried a few of MacKenzie Child’s 12 in 12 Rails course on Youtube.
Try tutorials for building specific features of the app I want to build. On top of the basic blog app I built, I took bits of MacKenzie’s other tutorials and pieced them together to get the other features and functionality in, e.g. user accounts, authentication.
Keep going. Build, google, build. Learned more tools, like command line, Git, Github and serverless tools like Heroku. Ask for help from friends. Thanks @craigpetterson for your help!
F**k it, just launch! And Your Life In Months was born.
Iterate based on feedback. It’s now at a place where I like as a Version 1.0. More to come in the next versions!

JAMming with nocode

After Rails, I took a hiatus because I really pushed it hard and got a bit of coding fatigue. At this time JAMstack appeared on my horizon, and I hopped onto it and had loads of fun making JAMstack sites! What followed was another whirlwind journey of learning (some) GatsbyJS, React, Markdown, and playing around with all the headless CMS in the market. Ended up with a productized service where I can make more JAMstack sites for other people - Sweet Jam Sites.

Finding a new Vue

Then I dropped out of coding for a year again. But I remembered, when I discovered JAMstack, and I knew it in my gut (even though I’m a coding noob at that time) that I want to explore this tech stack for making web apps, and eventually my SaaS. But I didn’t know how to get there. I dabbled with Stackbit then and it was such a great way to slowly orientate myself to JAMstack, since you can literally spin up a JAMstack website in minutes using Stackbit. I made tiny customizations to the template, slowly begin to read a little JSX/React/Gatsby, how everything connected together. But how do I make an API, and which frontend framework should I use to fetch data from it? I knew a bit of Ruby on Rails by then (from my learning to code journey the year before), and I always felt that creating a backend on Rails felt within my reach. It wasn’t as scary as using other frameworks. And I’d done it with Rails before already. So I decided to go for Rails as my backend framework of choice.

Then I (re-)started my journey of learning how to code, this time with Vue.js. AN hour of code everyday, for 100 days. I took on the #100daysofcode challenge. Just start. I got inspired by what @dannypostmaa was doing with his product Headlime, and he also didn’t know how to code eight months ago! When asked, he said he picked up Vue.js because it looks easiest to start. So I researched a bit, and discovered it suited my programming taste. It can be adopted progressively, and all that’s needed was to add a script to the html file, just like the good old jQuery days. That was familiar because all the HTML, CSS and JS were all used the same way I was used to in web development 101. It was not so scary unlike React, Next.js and Gatsby where everything was JS. Learning Vue had been such a joy. I could never have known that I would enjoy coding this fun, all because of a framework that was suited to me. But more importantly, I also found incremental ways to learn coding and to stay motivated, by browsing mini Vue projects on Codepen, and learning from them.

#100daysofcode to Lifelog

Fast forward to the end of the 100 days. I finish with around 20 mini-products. What's next? Since the daily writing platform where I write is closing down, I decided to step up and create a platform to replace it for a bunch of us homeless daily writers. I took what I learned from the JAMstack philosophy, and frontend development from Vue, and thrown in Strapi (an open source Node.js headless CMS) as a backend to form my very first SaaS - Lifelog. And the rest is history.

What’s next?

This is usually where grandiose statements about what I will and want to achieve next come in. But something I learned about sparking joy in my work made me want to approach my goals in another way. Just follow my curiosity and energy. Take whatever comes, drop whatever bores, and ride on whatever pulls me forward.

I’m not sure what will turn up on my decoding coding journey, but I now know, at least, that I don’t need to know and it’s better for it.

Follow my daily writings on Lifelog, where I write about learning to code, goals, productivity, indie hacking and tech for good.

Do you see coding as one fun step, or lots of tedious steps?

Jason Leow ~ plugins.carrd.co — Sun, 24 Oct 2021 06:37:02 +0000

How you see the act of coding shows what your true preferences and interests are

Here’s a great heuristic for discovering what your true preferences and interests are, where your passion and enthusiasm is anchored in, credits to @sivers on Twitter:

Imagining lots of tedious steps? Or one fun step? If we hate doing something, we think of it as hard. We picture it having many annoying steps. If we love doing something, it seems simple. We think of it as one fun step…[like for running] “Easy! You just put on your shoes and go!”

I love this. It’s so true, and so telling. What a great mindfulness and introspective practice! Indeed, anytime I notice that I am thinking ahead and dreading the many steps to get to the goal, it’s highly likely that I’m not all that enthusiastic about that goal. But during occasions when I’m super motivated and passionate to do something, I don’t think ahead so much, and just f**king do it, even if objectively the steps remain the same. I don’t make as many excuses, or mope and dawdle as much. It’s like the road bumps don’t matter. Challenges are taken on the chin, without sweat and pain.

But what if something makes you feel both? Like say with coding, I always find myself dreading all the “many tedious steps” ahead. But when it comes to the final product itself, the thought of being able to create something tangible and material that you can see or touch out, of thin air and abstract thoughts – that makes me want to get there in “one fun step”.

How strange!

Does that imply that I enjoy making, but not coding? So do I enjoy it, or not? Is it possible to enjoy one part of a process but hate another? If so, how do I resolve this conundrum?

Follow my daily writings on Lifelog, where I write about learning to code, goals, productivity, indie hacking and tech for good.

By-products as products

Jason Leow ~ plugins.carrd.co — Sat, 23 Oct 2021 08:05:43 +0000

What if the mini-projects that I made while learning to code can become products in themselves?

I got an idea. Since I’m learning to code, what if the mini-projects that I made along the way can become products in themselves?

Usually these class projects—a to-do app, a shopping cart, a blog, etc— are byproducts or throughputs which don’t do anything much after you completed the lesson. In and of themselves, yeah, they are not much, to be honest. Not good enough to be products in themselves. But with a bit of polish and finding the right use case, it just might.

Case in point: I was learning Vue, and I love how easy it is to use it. At it’s simplest, you just copy-paste a Vue script into your HTML page, and you can already start building out sleek user interface features. Vue can be used for prototyping in the browser, so there’s a lot of interactivity you can do with it. With data-binding, it’s also great at handling animations, interactive graphics.

I was browsing Vue on Codepen when I found a calculator made using Vue, and that got me thinking, what if I made some customizations and embedded this in my Carrd sites? Wouldn’t that extend the functionality of Carrd sites by multiple factors? I always liked making functional Carrd sites that work a bit more like mini web apps than the static landing pages that Carrd is usually used for.

So imagine not just calculators but animated graphics, charts, date picker calendar, timers. Imagine if I made these things for practice learning, but also sold them as little code snippets for Carrd site owners who don’t code, to add a little bit of extra functionality to their Carrd sites. Wouldn’t that be awesome?

Byproducts as micro-products in themselves. Throughputs becoming outputs. Just like how in nature, every byproduct from one organism is actually an input for another organism. Shed leaves become organic material for other bacteria and fungi to break down. Fallen logs are homes for countless insects. There is no waste in nature.

So why not for coding?!

Follow my daily writings on Lifelog, where I write about learning to code, goals, productivity, indie hacking and tech for good.