Ask HN: What projects did you build to get better as a programmer?

In ancient times, one had to do something interesting or perceived as difficult to build credibility. This involved taking something from blank paper to working program. Yeah, the work was usually overly large and inefficient but people who came out of such “approved” projects were considered (new) members of the community. This was totally separate from coursework and grades, of course, as creation was far more important.

This was usually a super Star Trek game, or an implementation of Life (which led to a fair number of language wars), or a 4x4x4 tictactoe or chess program. One hacker won his spurs making the best checkers program going. More complex projects were binary file editors, system utilities (magtapes pretending to be DECtapes!) or OS mods. Some were lucky to get to an hacking Mecca - these are the ancient heros. Acceptance could not be purchased, only earned and poseurs were ridiculed.

I assume things are similar now, with GitHub replacing card drawers and net based communities replacing f2f. “Because I could” was an amazing goad, particularly when you didn’t know the limitations. Cracking, while useful, wasn’t anywhere near as worthy or honourable. Hackers make neat things. It’s the making not the knowledge itself, and whether the thing is used is a secondary but satisfactory gain.

Decades on, I’ve written miles and miles of code, but very little of it was neat. Useful, commercially successful, yeah, but only a few things here and there made me sit back and smile - these things would have passed muster back then. I hope others get to experience such feelings a few times in life.

This is a nice response, what were those bits of code that made you smile?

Two come to mind quickly: Spending a night or two trying to tune 2D chemical matching code to gain 10-20% and ending up with a factor of 3x. Bought the group lunch for that one. The other was creating an application that hung together well and was easy to use. Took several iterations of the GUI to have something that did more than cause confusion... They say the best GUI's aren't memorable because they're not in the way. This was too complex for that, but it was considered obvious.

Very cool, these are nice moments to be able to remember. Thanks for sharing

I found the trick was to get a job in software development. That solved the problem of trying to find things to do, other people do that hard work and bring me requirements.

They even pay me for it too!

I don't know what you're after, but if your aim is to go into software development as a profession then read on. Otherwise skip the rest.

Honestly, if you have the fundamentals down you can probably find an entry level job and learn the rest on the job. No tutorials will prepare you for real experience in software development.

Programming is only about 20% of software development in my experience. It's a critical 20% that you can't do without, but the rest is hard to prepare for and best just to get real experience of.

There's no point spending forever learning to be the best in the world at that 20% without discovering if you even enjoy the other 80%. There are even far too many who hate that 80% and often will not be scared to share this disdain freely.

The trick is to ignore them, fully engage with the whole job and you'll quickly out pace them in career development, and you'll likely enjoy your job a whole lot more too.

> There are even far too many who hate that 80% and often will not be scared to share this disdain freely. The trick is to ignore them, fully engage with the whole job and you'll quickly out pace them in career development...

Taking cheap shots at your coworkers is the true way to get outpaced in career development. If OP is looking for career advice, this kind of attitude is not good advice. Humility is the right path.

The 20% is not accurate, at least in the U.S. in my personal experience. Requirements-gathering, software design and implementation is maybe around 60% of your job at most companies in the U.S. At the end of the day, you get paid to connect the business domain to the technical details of software that will solve the problem; the other 40% of the time you are not doing technical things, you are responsible to communicate, attend meetings, give updates, ask questions, and manage projects.

At least, after you've gained some experience. Being a good programmer is how you get the job in the first place. You have to build up the rest of the package, which is very doable if you are humble and join the right company.

I think you misunderstood my comment, at no point did I suggest taking "cheap shots" at anyone, and indeed my advice was to focus on "the rest of the package" as you suggest.

One recommendation I don't hear often is build something that will stick with you. Keeping with the apprenticeship/tooling idea, I would build something that you will use over time.

You will be forced to keep backwards compatibility in mind, you will see what makes a process have friction, you will see odd bugs from a random edge case you will have to fix or discover. Treat yourself as the customer and build a tool you can use to help yourself out.

It is almost recursive in building tools to help yourself learn, and using those tools to learn.

I agree. I accidentally ended up using the very basic todolist in my starter kit https://github.com/mcapodici/firestarter for all my todos! And noticed the ui and ux issues as a result.

Yeah it is funny what you will discover when you are forced to use something you can change.

You also sadly realize how much software gets shipped that if the person who wrote it used it, would hate it. You have incredible leverage with software. What would you change about the UI/UX?

I wrote games. Originally in BASIC, for the the common 8 bit machines (PET, TRS-80, Atari). But also (hand assembled) machine language.

My early ML adventures were terrible. My early Space Invaders clone was awful. For SI, I couldn’t figure out how to tell one alien from another. So I stuck a different character in the middle of each one. Just dreadful stuff.

Moving on to college, I moved from a lowly 8 bit to a multi user mainframe. And from BASIC to FORTRAN. This certainly alters one’s perspective on what a computer means.

Nevertheless my friend and I tried our several attempts to write a rogue clone. We wrote that at least 4 separate times, across different mainframes and time share systems. Arguably our most successful was in our second Pascal rewrite (our first stab in Pascal was also dreadful). But we kept running out of resources.

Write to your passion. Because when you write to your passion, you focus on making it work. And when you find you can’t make it work, now you can focus on making it better.

None of those projects over all those years were ever finished by any stretch of the definition. We were far to busy making stuff up and breaking things.

I once build a machine learning library from scratch in rust. No external libraries allowed. It could do linear regression, lasso, and ridge. It also contained some statistical inference features, like p-values, AIC, feature selection. Basically chapter 3 of Hastie [1]. It's more difficult than you might think, as you have to figure out how to do efficient matrix manipulations, deal with floating point overflows, multi-threading, unit testing, bench marking, etc.

[1] - https://hastie.su.domains/Papers/ESLII.pdf

My journey as a software developer began in the 80's at MIT by writing 3D graphics code on a Symbolics Lisp Machine. Some fond memories:

https://kaveh808.medium.com/late-night-lisp-machine-hacking-...

One big difference between then and now was that back then you wrote mainly from scratch and were in charge of most parts of your software, whereas today it is mainly about gluing various toolkits and frameworks together.

Yeah, and you aren't even in charge of your own for-loops.

Could build a vue js SPA frontend that dynamically renders a table of things (fake pet food sales?) based on a call to AWS dynamodb.

Could use AWS Lambda to implement a server side auth layer.

Would get some decent AWS exposure (deploying vuejs with S3 and cloudfront, possible serverless lambda experience plus API Gateway), some nosql experience, would learn the request response lifecycle and how frontends actually work. Could do some terraform to deploy the AWS stuff.

Years ago my experience was that I knew AWS and devops stuff. I wanted to do something more substantial with golang, and I wanted to make a frontend for an API I had made (but had never done so before).

Starting with a simple idea (a dynamically rendered table) was simplistic enough that it was doable but still complicated enough that I needed to spend a couple hours for a few days after work to get it working. I had a great feeling once it was working and I really ended up learning quite a bit as a result.

Thanks a lot for this. Your response is appreciated by someone and I want you to know it <3

This is an excellent topic and I was hoping to find a set of great ideas here (really love the http server example). I was thinking of the concept of Katas in martial arts. What would be the Katas for programming I wonder.

Some thoughts:

1) Build your own database. Not a SQL db. Just something that takes records on a cli and enables retrieval. Persist the data. Support better queries/

2) Maze solver.

3) Snake game

4) Helper/Solver for something like Wordle.

5) Chat server (but I like the HTTP server idea. Annoying thing is newer HTTP versions have gotten complicated).

I think there are twenty to fifty of these little things we have all done in our career, and either forgotten them or it felt too natural to register. Wish someone compiles a list of such projects some day. It would bring back joy in some of the coder-at-heart folks lives.

The projects that made me a better programmer when I was new to the field were all games written for my own amusement.

If I had to single out a single project that I think advanced my understanding the most, it would have to be building a computer from scratch and writing the OS and a C compiler for it.

I believe you're in the middle of two points, on one end, you don't want to write something trivial. On the other, you don't want to write something too new or cutting edge, as you're solo. Finding great projects to work on somewhere in the middle can be difficult.

I'd suggest that while you're finding your feet programming during this time, focus on software engineering, design patterns, and other SWE principles (SOLID for example).

As far as project ideas go, it really has to be something that aligns with your interest. I see you're aware of the suggestion "to build what (you) like." Your inexperience in this domain does not preclude you from building software adjacent to your personal hobbies.

I'll use myself and my own interests for example. I am a fan of the highest level of the US' legal system, the supreme court. I regularly listen to oral arguments presented before the court, along with keeping up with the SCOTUS via blogs and such. I can check to see if there is any public data available for me to play with, which there is. From there it's all about seeing what's available for me to use and coming up with a project idea using this resource.

I use this example to try and express that "what I like" does not have to pertain the software development discipline itself.

What I actually started with was video game modding for games I liked to play, along with Discord compiler, a project that allows folks to compile code on Discord. Both followed my interests pretty closely, both required lots of extracurricular learning.

"during this time, focus on software engineering, design patterns, and other SWE principles (SOLID for example)."

Do the opposite of this, please....for the love of all that is holy.

The people who care about that stuff are complete douche bags. I used to be one of them.

Build things for regular people.

One thing that I'd suggest is no matter what you build, deploy it for real - don't stop after running it locally. Buy a cheap domain for all of your projects, and give each project a subdomain. Put a version of what you build into "production", so you can get a sense for what it takes to release software and update it.

Also, reflect on everything you build and think about what brought you joy. Specific trends ebb and fade, but understanding what you're passionate about will allow you to always apply yourself to learning new skills (while also having fun). Enjoy!

I have some basic ideas that I have implemented in multiple languages. I think of them as "Rosetta Stone" projects:

- Bowling score - More of an exercise than a project.

- Sudoku solver - Also an exercise, but could be more with a UI.

- "Setting Sun" tile puzzle with UI. Saw one of these at a Cracker Barrel restaurant (https://www.siammandalay.com/products/setting-sun)

- Wordle with UI - I've only done one in Rust/WASM, but might do one in Dart/Flutter.

My answer to this is different to others, so I'm not sure how useful it will be, but here goes:

When I approach a new creative coding project, it is invariably because I want to learn how to use a specific technology that I have heard of.

So, for example, I wanted to build a "real time" stack using RabbitMQ and websockets with Tornado. I also wanted to build a front-end with Backbone. These were all kind of new and cool at the time. So what kind of app would use this tech? How about an app where you can submit a "currently playing" where you are, e.g. in a nightclub or at a concert, and have people within a certain radius get live updates as they are pushed? This was a really fun project and it also gave me an excuse to dive a bit more into PostGIS and nginx than I had in the past.

Years later, I wanted to have a go with some of the cool machine vision tools I had been hearing about. I also wanted to have a go at building a front-end with Web Components. So I built an app that would let you build a specification with a nice UI and send it to a worker that would create a video using six ML models working together. This was a really fun project and also gave me an excuse to have a go building a lightweight Python JSON API backend I would later reuse quite a few times.

In both cases, the driving force was a perceived need that had arisen from my day job. Specifically, I was aware that there was tech out there that was rumoured to be able to solve problems I had or thought I would soon have, and I wanted to get a handle on what the "unknown unknowns" and "gotchas" were involved.

This was also what got me working with VueJS for the first time, a technology that does extraordinarily well at what it says it does, better even than I expected. (I think I built a vanity site for my music work at the time?). Vue became my go-to at my day job for the purposes, so much so that I found myself instigating a rewrite of an existing AngularJS front-end soon before I left the company. I feel very confident their AngularJS code has all been burnt since then.

I'm a Web developer so I don't know if this approach translates to other fields of Software Engineering. Web is one of those things where new tools are cropping up and being hyped all the time, and staying abreast of developments in the tech is kind of part of the job.

> What projects can I start with?

It's like asking people on the internet what you should eat for dinner or who you should marry. Unless you don't learn programming just for the sake of it (assuming that's true based on the question you are asking), you either haven't learned enough yet to broaden your horizons to get ideas, or don't have enough geeky hobbies to put your new skills in motion. Have fun finding out what it is.

I think https://csprimer.com/ is exactly what you're looking for.

The best way to learn is to build something for someone else. When someone else sets the requirements you have to engage in real problem solving and research the best tech to solve the problem. This keeps you from following just the easiest path as well as exposes you too new ideas.

You can do this at work, for a local non profit, for your friend's weird startup idea, ...

That's one way to learn time schedules, efficiency, but not necessarily the rest of a programmer skillset

I had the most prolific time of my life, when out of work for 6 months, and I did completely random projects, a 2048 solver (it was trendy at that time), a connect-four adversary and many others ideas https://caub.github.io/misc/, just imagination, learning the algorithms, also some leetcode for future interviews, still then this moment helped a lot building myself

I have a suggestion. Instead of trying to figure out what to build, why don't you start reading the source code of what others have built?

For example, interested in blockchain and know some Golang? Why not start reading the Ethereum main repo source code and documentation? This is just an example to make a point, but you get the idea.

Good luck :)

The 2 projects that I learned the most from:

1. A crazy verilog based class at Berkeley (CS150 back in the day). Proably in the lab for at least 4hrs a day for a semester writing code with a 20min compilation time

2. Spectacularly failed attempt at building a shared calendar app at a big co for internal use. I was a junior programmer and got assigned huge portions of it with the instruction to make “work like outlook”. Learned a ton. Company got basically nothing of value in the end other than a much improved engineer

Theme for both was hugely ambitious project and an absolute ass-ton of reps

I built automated tests and frameworks. You can get pretty far in a career in test automation while still learning and getting better because people perceive the code as important but the whole company doesn't (usually) fall apart if you mess something up in your code.

More important, in my experience, is to find someone tough but super knowledgeable to review your code. Try to anticipate what kind of notes you'll get if open you a PR with your code as it is, and then fix that stuff before you open the PR. Write a checklist of stuff that keeps getting picked on by better coders than yourself, print out the list, and tape it to your office wall.

I personally find writing apps for myself to be a fun and practical way to learn. That way you might get introduced to a few libraries you've never used before - and get new codebases to dive into and learn from. I have friends who started programming with writing tools to mod games and IRC/Discord bots.

I've benefited a lot from the apps I've written to improve my day-to-day life.

Just to give you an example: I wrote a tool to sync my uni timetable from the proprietary system they're using to my Google Calendar - that way I have all my events in one place and I'm also notified of classes early enough so I can get to campus in time.

> When do I start learning more about other things like systems, algorithms, databases, etc?

At work.

I found building my own CMS covered every required aspect of web development

Build an automated trading system. It doesn’t have to make you a fortune. But it should be automated, connect to other services, and risk your own money. This captures a lot of programming - consuming market data, making decisions, checking against risk levels and your stateful position, reconciling local and remote state, state machines, etc. But most importantly it puts your money at risk, so you better get it right. That’s the most important thing to learn in programming.

I wrote game engine after game engine with various languages and designs. Somehow I’m still motivated today to rewrite navigation in my 15th engine for the 3rd time.

Early in my career I built this language aware diff tool that some people used. I learned how to write language parsers and beautifiers for various kinds of languages.

Writing a full CRUD todo app on both web and iOS helped me understand things a lot better. The most important thing is to keep it simple, and by going across platforms you can see the importance of good data representation design.

The idea is to start off by making bad decisions, and slowly refactoring your way to good abstraction, this helps you intuit the reason for abstractions.

Redis? https://build-your-own.org/

https://github.com/kanaka/mal

If you're learning a scripting language, building a web scraper is a great way to learn some fundamentals of a language by using the basic data structures, getting the data flow correct and solving regex, parsing and printing issues.

Protip: use an IDE and a debugger to turbocharge your lesson!

Better in what way? Building things, or learning to tip-toe around your pedantic, histrionic colleagues?

I found things that people told me were too difficult for a singular person to tackle and tackled those.

Anytime i learn a new language, I write and http server.

I rebuilt MySpace... and it got quite popular

Build a compiler.

gfd