This page is meant for new or aspiring software developers! Below is a list of things I've learned over the years. I studied computer science at my local university and got my first job about a year and a half later. I now have about 5 years experience doing web development and I really enjoy the work I do. I code only during work hours (as you can probably tell from my Neocities site). Outside of work, I'll read the ocassional text book or web articles and walk through tutorials for frameworks or programming languages I'm unfamiliar with. By ocassional, I mean a couple of times a year.

Don't feel pressured to know everything.

There's too much to know. There's always a hot new framework, database or language. Microservices? Websites, mobile applications, embedded devices, machine learning, data science, devops? Find a tech stack you enjoy and learn it well. If you know one framework/language well, you can relatively easily pick up another one. Learn the fundamentals; data structures and algorithms, software architecture, design patterns.

Source Control


Semantic Versioning


Big O Notation

I suck at this but a basic understanding is extremely helpful in profiling code.

Layered Architecture

This goes by a lot of names but a variant of this architecture pattern is frequently seen in mid to large applications.

Batch Operations

Need to CUD thousands of rows in your application? Learn to do batch operations. Don't call the database for each individual'll be really slow. Need to display a lot of data? Implement paging.

Nature of data

Is your application read or write heavy? Do you anticipate frequent changes to your database schema? If so, does it make sense to use a schemaless database or stick to a relational database? If it's both read and write heavy, does it make sense to have a seperate reporting database to optimize for reads? (Data warehousing can be a whole thing with a dedicated team depending on the size and variety of data you work with.)

Every decision is a trade-off.

And every decision is a lesson. Sometimes the negatives don't become apparent until you start writing code or deploy your application. Adjust accordingly.

Learn how to write awesome tech specs.

Don't make them dry, use lists, tables, flow charts. Explain why you crossed other options off the table. Keep them short. Look into implementing RFCs or ADRs in your organization.

Every technology has its use cases.

You don't fucking need Cassandra database until you fucking do. Do some research before adding a new tool. Weigh the pros and cons, does your organization have the ability to learn and maintain a new tool? I once read a horror story about MongoDB from Bay Area devs...because MongoDB wasn't the right database for data that was highly relational.

To DRY or not to DRY

Just DRY. DRY is great...until you go overboard and your extreme and elegant abstraction introduces coupling. Now making a change for one of your components is a liability for the others and no one wants to touch the fucking thing.

External Dependencies

Consider writing a wrapper for it? Sounds like a waste until you want to switch out or modify the response of said library. (This is really a case by case basis.)

Automated Testing

I'm still learning but tests have saved my ass a couple of times.

Dictionary/HashTable vs Array/List

Dictionary/Hash O(1) lookup, Array/List O(n) lookup. I should have stopped smoking weed when taking data structures and algorithms. But depending on your use-case one data-structure may be preferable to another. Is your array/list sorted? Then you may be able to traverse faster.

Hardware/Operating Systems

These are areas I'm looking to increase my knowledge in but a basic understanding of how CPU/RAM/IO devices and operating systems work will help you write performant code.


I'm still learning all about caching. Do you need caching in a small application with a small amount of users? Probably not...keep it simple. You can implement caching at different levels. Do you call the database each time someone loads a page to display data that does not frequently change? Consider caching this value. (Your database has likely cached this value for you but we can save a trip to the database.) You can also cache HTTP responses by setting approriate HTTP headers.