Ask HN: How do I get better at programming as a hobbyist? | Hacker News Reader

Ask HN: How do I get better at programming as a hobbyist?

15 pointskirso22 comments

Based on the "I love programming but I hate the programming industry" I wanted to ask the following:

I am a hobbyist and I like to build small and tiny projects.

My gripe is that I don't want to go into software engineering as a professional career (for the reasons outlined in the previous post), however that hinders the progress of learning quite a bit, especially doing it part-time in the free time.

I do have some expectations potentially to build something that people pay for (eventually but not in a rush). Right now its just about solving puzzles, jogging my brain and solving for problems I personally have. But I do want to increase the pace of learning.

Any tips, stories and resources are appreciated!

View on HN

You said you hate the industry, so I have to assume you want to build a business. Unfortunetely, people don't pay for programming skills. They pay for you to solve a problem or to entertain them. In essence, to get better at programming, you'll have to build products and solve the problems that come with them. Too many bugs? Learn testing. System crashes at night? Better monitoring, logging, etc. Features take too long? Better architecture. Algorithms and programming exercises are the easy part, productizing something, running something in production is the hard part. There is no book, course, or other material that can give you the understanding of what it means to build production-grade software. You can read countless stories on how you should write your code (clean code, TDD or whatever) and how you should operate your production system (DevOps, IaC, containers, and so on) but will this really apply to you? Doubtful. Start small, fix problems and fail a lot to learn what the true painpoints are and how to solve them. I met a lot of people who just tried to follow "current best practices" without any understanding as for the reason and the result almost always way a horrible moster of an architecture that fell over at the first sign of trouble.

Everyone with experience has their own style and preferences. For example, I like to write very defensive and modular code because I really hate chasing down bugs or getting up at night due to a production failure. Most people I meet don't like my code because writing code with that much test coverage and deliberate APIs takes time, so day-to-day I have to make compromises, but I will always push in that direction. Others push in other directions because of their own personal experiences. As long as there is communication, the end result is always worth it. However, if you were to follow only my advice, you'd likely become terribly locked in and think that programming is terribly boring. So don't listen to me, gather your own experiences and use learnings from other people to supplement your view of programming, but never let their view replace yours.

Sorry I should have been more clear, the title was based on a very popular post from a few days: https://news.ycombinator.com/item?id=40105121

I don't hate the industry, I am a PM and work with engineers daily but looking at what they work on, its not really something I personally desire professionally.

The stuff that you describe though, is really only possible on the job. Like I don't imagine doing kubernetes for my apps. But I get the philosophy behind what you are trying to say and thank you for that.

Just keep making things and research whatever you run into that you don't already know (tip: pick projects where you're going to have to research more things if you want to learn more). I don't think you're actually hindered by not being a professional SWE - I've learned more just from hacking around with personal projects than I ever have from writing code for my employers. There's definitely going to be some professional tooling and conventions that you'll miss out on, but those are only important for programming in professional settings, not for making things in general.

Contributing to open source projects is a good way to get exposure to new patterns too.

On the note of contributing to open source: please contribute to a project you personally use and care about.

Hey kirso,

I completely understand where you're coming from. Programming as a hobby doesn't mean you can't improve your skills or create something valuable. Here are a few suggestions that might help:

1. Project-Based Learning: Choose a problem you want to solve and build a project around it. This approach can help you learn in a hands-on way and see direct results.

2. Programming Challenges and Competitions: Websites like LeetCode, HackerRank, or CodeSignal offer a wealth of programming challenges that can help you improve your skills and keep your learning fun and engaging.

3. Online Courses and Tutorials: Websites like Coursera, edX, or freeCodeCamp offer numerous courses on different aspects of programming. You can learn at your own pace and choose topics that interest you.

4. Open Source Contributions: Contributing to open source projects can be a great way to learn from others and improve your skills. You can start by fixing bugs, adding small features, or improving documentation.

5. Networking: Join programming communities online or locally. This can provide you with a wealth of resources, advice, and potential collaboration opportunities.

Remember, the key is to enjoy the process. Happy coding!

Instead of making a bunch of tiny individual projects, start working on one project that can start tiny, but grow over time.

I can’t help but think about this interview [1] with James Thomson who wrote Pcalc for the Mac. He wrote a little calculator app to help him learn. A fairly basic project, but then kept going. Any time Apple releases something new he ports Pcalc over to learn that new things, be it the watch, or even Vision Pro. When he wanted to learn about 3D graphics, he made an about screen for Pcalc that ended up being its own app where the user could drive a car around and it was a little physics sandbox. It kind of reminded me of the Easter egg in Excel 97, where the user could fly around a 3D world and find a spot where all the devs names would scroll by.

I’m kind of like you, where I like tiny projects that can be elegant and avoid complication. But to get better, the projects need to grow, and I’ve learned the most from project I’ve had which grew over time to become more than originally scoped. Sometimes this requires full rewrites along the way. Starting again with the knowledge of where previous decisions limited you can be helpful when starting other projects in the future.

You might see some of this as bloat. Maybe it is, but that’s part of the learning as well. What features are truly useful vs bloat. How can you implement new features while keeping the core experience feeling lightweight and fast? How can you design the features so the app is still simple and approachable for a new user, yet grows with them to be capable for power users? How can it adapt to fit different use cases?

So that would be my advice. Watch the interview below, and then pick a project that can start simply… your MVP… and then integrate and expand it with new features over time. Each feature is its own mini-project inside the larger project. You could look at almost any piece of software that has been around for a while for inspiration. Pick something you’d actually use day-to-day, and maybe one some people you know would use too. When you use it you’ll naturally start to generate your own feature requests, and if other people will be using it, you’ll have to develop with end-users in mind, which means more error handling, bug hunting, user friendly UI, documentation, help, onboarding, etc… all the stuff that probably doesn’t happen with little projects.

[1] https://m.youtube.com/watch?v=-_ZbWVTQNk0

What a wonderful answer! thank you for that.

Lots of practice. Read books about programming. I don't see how not wanting to go into programming as a career prevents you doing the things professional programmers do to enter the profession.

I learned how to maintain my motorcycles with no intention of becoming a mechanic, but I still had to read the service manuals and practice and ask for help.

Mostly time and mental capacity with already demanding job to be honest. I enjoy programming so much that I'd love to do it full-time, just not in a corporate.

You learn by doing. When you don't know how to do something, you research. \

I use targeted search terms to find exactly what I need. Very much a just-in-time approach. I don't try to learn everything about a particular language, tool, library, etc. I focus on exactly what I need to get the next step working.

Of course, I often stumble across interesting materials that I read into deeply.

As a hobbyist you can potentially end up knowing far more than a SWE professional. For many jobs you already need to be an expert in a particular niche in order to get hired. That's why getting that first job can often be so difficult.

Thanks for the perspective!

Work on something that you need, at home, or at work.

Or just for fun.

When Sun went to floating offices, I grabbed the office reservations, and superimposed them on a map of the office.

I did that?

You may enjoy a rapid prototyping environment. Think hyperscript [1]

Quick and easy wins that actually do something useful/fun will propel your quest.

   Enhance HTML with concise DOM, event and async features. Make writing interactive HTML a joy.

[1] https://hyperscript.org/

Nice! I did a little todo app with elysia, turso and htmx/hyperscript - the experience is very friendly.

https://bun-elysia-tailwind-htmx-todo-app-falling-pond-2121....

Read other peoples code. Pick something open source that is decent and read it like you are critiquing it. You’ll see techniques you’ve not contemplated. You’ll see concepts you simply weren’t aware of.

My first mind blown code read was TeX when I had to compile it off a tape to get it to run on a Pyramid in the late eighties. I learned so much it felt incredible. I’m sure there are much better code based now. Perhaps the source code for Git.

It's going to sound snarky, but I don't mean it that way:

The answer to "What is best way to get better at $something?" is almost always "Do $something. Over and over."

If you ask yourself the question and "Do something over and over" does not suffice, then explain why you think it does not suffice and how you'd like to pivot.

In your case, it sounds like you lack direction. Figure out a small project with well-defined goals, and then do it and don't quit.

If you just want a series of programming puzzles, check out the Advent of Code[1]

[1] https://adventofcode.com/

For me, I approach programming as a way of building something. The same way an architect builds a building, or a carpenter builds a desk. You build something with purpose, because you find value in it.

When you figure out how to build something, you’re solving puzzles through figuring out the best language to approach that structure with, and learning how to build it with said language. As you build more parts, you naturally learn more.

Pick a real project that will help you in a meaningful way.

You could even start with a web based game you can share with friends. This will teach you web applications, databases, possible sign-in security.

You can write something at home or use the cloud [1]. I have had a lot of fun using Python on a Raspberry Pi [2].

  [1] https://replit.com/ (has a free tier)
  [2] https://www.raspberrypi.com/

Practice and measures.

Solve ambitious problems. The best thing about being a hobbyist is that you are not beholden to populist stupidity. Do what works best for you, minimizes future effort, and most directly solves your target problem. You will get better and faster over time.

I have been a hobbyist, made a website moneymaker, for the last 20 years.

Pick a framework/s with good documentation and code grom there. Get AI to help fix your code but not write it.

You do not learn well help surfing and getting a dozen answers to the same question.

Build stuff that runs in production and that you personally use. Make time to fix and improve your software, even when it works fine. Read the docs. Read other people's code. Review and rewrite your own code a lot.

Make stuff. Make a requirement for yourself that you will enter unknown territory.

Revisit your old code often, and improve it.

Reply on news.ycombinator.com