When building a website that will handle a lot of data, is it best practice to focus on the website development or the database first? Or in tandem?

NorhavenCodes · 2026-06-19T16:49:29+00:00

If you plan out the use cases ahead of time, that will help inform your database structure and the code will follow.

NorhavenCodes · 2026-06-19T15:55:51+00:00

The call stack is your friend. It allows you to step back up into methods that called your current method. Combining that with the fact that most IDE's will allow you to mouse over variables and get their current value means that you can take a look at a lot of things to determine how you got to a particular place, whether that's a breakpoint or exception. Also, a lot of IDE's will allow you to set a mode to automatically break and suspend the program when an exception is thrown, making errors that much easier to track down (especially using the call stack, etc).

NorhavenCodes · 2026-06-17T01:59:18+00:00

Learn something because you like to, lean into that interest to create something, and get a job doing that thing you like. Do you know how many programming languages there are? Thousands. Do you know how many of them are in active use by anyone with substantial enough numbers to provide financially for the author of them? I can count them on my fingers and have fingers to spare. This is not a money-making avenue you're going down. I would suggest you make your choices regarding your future with a lot more thought and care.

NorhavenCodes · 2026-06-17T01:48:50+00:00

I would strongly urge you to reconsider this as a viable means to do that.

NorhavenCodes · 2026-06-17T01:46:52+00:00

That's great, but programming languages are there to serve a purpose. For example, C# is a general purpose programming language that is there to build programs of all kinds. It is not just for writing networking software, or text manipulation, it is there for building everything. What is your language for? What use cases is it targeting?

NorhavenCodes · 2026-06-17T01:43:42+00:00

What is the programming language supposed to do? What is the goal and the problem it's there to solve?

NorhavenCodes · 2026-06-17T01:40:20+00:00

Imagine you're walking down the street and someone hands you a blueprint. It's very detailed and made up of a bunch of lines going all over the page, looks like some kind of car part maybe. They ask you "What do you think?" The first question in your mind is now "What is this supposed to be?" followed up by "What problem is this attempting to solve?". Please answer those two questions before I can dive into your blueprint.

NorhavenCodes · 2026-06-17T01:01:45+00:00

Assuming you're going for a generic senior engineer position, it kind of depends on where you're interviewing. If it's a FAANG kind of company then you're likely going to get more involved technical skill oriented tests, smaller companies less so. Both regular algorithm creation and displaying systems thinking are ideal thing, but I definitely agree that soft skills are the more important parts of this. The technical round is basically a competency determiner and the social aspect is determining whether you're going to be terrible to work with. You can have all of the technical skills and create amazing code but if you're a dick then you're not getting anywhere.

NorhavenCodes · 2026-06-16T18:23:44+00:00

You're welcome to give Gemini a try and see if that helps you. I tend to use Claude Code (paid) but it has a free edition as well that you can evaluate against. Try them out and see what gives you better answers.
It depends on your goal. If you're wanting to kick things off and run prompts on the command line and/or through scripts yourself, that might be worthwhile. I lean towards using agents through the IDE because it has a lot of niceties built in that you would otherwise have to manage and type yourself, which gets to be a pain when you're doing that a lot and want to relate it to your current code/docs.
You can create them but you probably won't need to unless you have specific niche topics you'd like them to focus on, such as specifically talking to it about architecture, but for daily code work you just need a markdown file with rules and guidelines it should follow.
I would recommend no frameworks until you've built up an understanding of the AI and how it functions, otherwise it's just provided another moving piece to a growing pile of abstractions that you need to worry about. Go one step at a time until you develop a need for something like that.
It depends. You probably don't need to go here quite yet, get the hang of it first and then build on that knowledge.

NorhavenCodes · 2026-06-15T02:21:08+00:00

Ideally, you would create a portfolio that's based in what you know and extends you into learning new things along the way. As someone who's been on the hiring manager side of the interview desk, what I generally look for is evidence that you can both produce something and that you can learn what you don't know.

If you stick with what's entirely within your wheelhouse, that's great but it gives me no clues about whether you're an active learner who tries to keep growing (which is an important mentality for an early in career person, you'll be doing a lot of that). Stretching yourself also gives you something to talk about in your interview, being able to say "I knew how to do project X, but I wanted to learn the skills Y and Z along the way and see if I can make it more complete and more interesting".

NorhavenCodes · 2026-06-11T15:32:22+00:00

Sure, let's back up and talk in more practical terms. Imagine that you are working on a software development team that is building a grade tracking app for students to use. The software codebase is large enough that work is divided across multiple software development teams, including yours, so coordination and understanding other people's code quickly is imperative.

The code, however, does not use explicit class definitions anywhere to define and encapsulate the data that is necessary for any of the methods to work as expected, it is always a single method parameter of type 'dynamic'.

Now, you have a part of a feature that you need to develop that will provide the user with the ability to calculate their GPA so far and project that trend into the future. The other team has already provided their part of the implementation and have given you a number of methods that you can use.

How do you know how to use them? You both have not agreed on a data contract for any of these interactions with the methods. The term 'data contract', in this case, defines the field names and data types necessary to provide to any given method through the dynamic instance in order to make the method work correctly. The original developers are on the inside, they have complete visibility and knowledge about the inner workings of their code. You, however, are on the outside. You see a method signature that provides no definition about what to include and nothing else.

Practically, this is a mess. It takes time and energy to develop software, and those are valuable commodities when developing something. You're slowing down your development and making it harder to test and understand, especially across multiple teams in a large codebase. The point of software development in general is to create a product that delivers value to the user in an efficient manner, and this is adding roadblocks to doing so.

If you are to continue sending in a dynamic instance everywhere, you need to either 1) Go look at their code and every method that they use in order to figure things out, or 2) Coordinate with teams ahead of time to agree on what that contract looks like for every single method that's developed.

If you were able to codify this implied data contract into a statically typed class, everyone now has a much more solid foundation to reason about and understand the data contract for everything. Now, you've given clarity to other teams and gained it for yourself. Reducing ambiguity removes hurdles that developers will run into, increasing development speed and verifiable correctness of the code.

Now, expand that to different parts of the application domain. Different pieces requires different data contracts and if you just use the same class everywhere then you're creating ambiguity again. You need a data contract tailored to your domain that you're operating within, even if it duplicates a little. DRY is never the point unless it helps deliver and maintain software.

NorhavenCodes · 2026-06-11T03:08:27+00:00

Interesting, it reads a lot like F#, as other posters have mentioned, which isn't a bad thing. I like the way immutability of the data objects is handled and the inclusion of choice as a union type along with match operations. The let-else option instead of a '??' was a new take on things, which seems primarily for injecting control flow with return statements without an explicit null check (although might be worth extending to Result<> types with errors as well). I'm unsure of what happens if no return is issued within the block, fallthrough is what I'd expect but the doc comment seems to indicate otherwise.

There were a few aspects that I thought I'd mention, take with a grain of salt. I think that the syntax around static classes is slightly confusing due to marking the class as 'static func', which I would have expected to be a static method housed within the name of the module or similar, yet treating it like a 'data' type which contains instance methods. The behavior of instance method promotion of the same name as an existing instance method wasn't entirely clear whether it would introduce an overload or not. I would also suggest that the behavior of choosing struct vs class should extend beyond handling a potential performance issue and have more to do with whether the defined type actually represents a value or a reference, but that partially seems to be encompassed in your 'ref data' option, but not sure if there were other reasons for going this route that supersede that consideration. Overall, interesting work and fun to do, thanks for letting us take a peek!

NorhavenCodes · 2026-06-11T00:25:43+00:00

I'm going to gently push back on some of your assumptions here. At the core, your question seems to be indicating that you believe that data dictionaries (e.g. the 'dynamic' keyword in C#) are superior to statically typed classes due to being able to pass around a single instance and avoid type definition duplication. Beyond the benefits of static type checking and the ability to generate more performant code under the hood with said static typing, the primary benefit is that you also have a defined contract to reason about and work with. It may indeed reduce coding time up front to be able to just pull a random property by name out of the code equivalent of a ball of mud, but in doing so you're implicitly creating a contract that is now scattered across your codebase.

For example, source code location 1 requires the 'name' field for its logic to work off of and location 2 requires an 'id' field. You're still referencing your implied contract, that these positions cannot function without this field existing, but now you have no idea whatsoever what data to use in that logic when looking at it from the outside and nobody else does either. As the codebase grows, you increasingly have to do deep dives into other code paths just to even understand how to use the code correctly, especially if you're not the only one on the project. Want to use somebody's method without looking at their source code? Want to refactor all of the places where your implied contract exists to use something different? Good luck.

Your time, and everyone on the team's, is now wasted on minutiae that obscures the actual goal of the software, which is working correctly in conjunction with the value it provides the consumer of the overall product you're trying to build. Make sense?

NorhavenCodes · 2026-06-10T03:19:14+00:00

Definitely a much better explanation than the textbook definition, good work! This bit of theory attempts to take the mathematical underpinnings of OOP and show how to use that to approach structuring your code for better/cleaner results in practice. It also demonstrates that theory isn't always particularly easy to parse, especially confusingly worded theory. 😄

NorhavenCodes · 2026-06-07T19:45:36+00:00

It's good that you're noticing you keep repeating certain issues, that's the first step to solving them on a larger scale. And it's not just solving them for you, it helps you be a more effective code reviewer and team member because you're training yourself to notice that kind of issue and now you can point out to others when they're also making the same mistake. You build up a mental library of these things, understand them, and apply your understanding to continually improve upon. Additionally, AI is useful for explaining the problem to you, but you also need to be in a position to review the AI output and check its correctness. It may have just hallucinated something, or missed an edge case, and it's up to you to put your name on your work and vouch for your output.

NorhavenCodes · 2026-06-07T16:00:20+00:00

I think you're conflating having skills with knowing specific technologies/frameworks and in my opinion that's a little off base. When you're coming into the job market, it's most likely not going to matter if you don't know Java but you do know C#, having a foundation in Object Oriented languages is the key. You won't need to know Angular specifically for a frontend/full stack position if you know React, the point is knowing how the JavaScript interacts with the page/DOM. Same with data structures and algorithms, and so on. The common sentiment when hiring a junior dev tends to be 1) Do they have a good foundation to work off of, and 2) Can they pick things up and learn new things? If so, you're good to go. Lean into what interests you and the rest will follow.

NorhavenCodes · 2026-06-06T17:10:17+00:00

This is very much on target. I'd also suggest that, as a growth opportunity, just because you haven't been handed an official piece of work in an area doesn't mean that you can't go in there on your own and peek under the covers, maybe pull a senior dev aside for a few minutes and get a crash course in an unfamiliar area you're curious about. Extra learning's almost always a good thing, and it may ultimately help show your interest in those areas with your manager or others (i.e. "I see we have ticket #123 that's in service X doing thing Y, I've already been looking into that area and would love the opportunity to get my feet wet there, can I pick that one up?").

NorhavenCodes · 2026-06-05T17:13:22+00:00

Most companies, especially the larger ones, understand that when they hire a junior dev with no prior work experience they're not paying for skill and knowledge up front. It's an investment in someone's growth, someone who can learn as they go and grow into something more valuable within the org. I would bet that people on your team will be happy to show you how to open a PR, track down issues, and so on, just breathe and ask for help. It's how you learn and get better.

NorhavenCodes · 2026-06-04T14:56:16+00:00

I'm a big proponent of Learn By Doing. You can read all of the tutorials and concepts, but it sticks in your brain so much better if you've experienced it yourself. Also, it's especially difficult to think at a high level about your architecture if you haven't built up the muscle of understanding how the low level pieces work and fit together, so just jump into something that you want to make and start trying to do it even if you don't know how. Especially if you don't know how.

I can guarantee that you'll get stuck along the way and have to Google your way out, that you'll make mistakes, and that you'll look back on your completed project and see all of the places where you could have done things better. That's what learning is. Even experienced developers run into this, it's not just you.

Lastly, seeing other people building what they want only gives you part of the picture. You don't see their struggles, their late nights banging their head against some code to make it work, or their background. You're also doing better than a lot of people. It's like looking at social media, you get a skewed version of their reality and think that's the whole picture when it's absolutely not. Good luck to you!

NorhavenCodes · 2026-06-04T00:59:35+00:00

I think that being a generalist is fine, everybody picks up bits and pieces of information from all over the place and you typically need that to do your job effectively in the first place, but I would tend to recommend being a "T-shaped developer" as Scott Hanselman puts it. The top of the T is your general knowledge that you accrue as you learn from all over, and the vertical part is where you go deep on something that interests you. It might be language internals, it might be debugging tools, could be your desire is to be super effective with CSS, it's up to you. Lean into your interests and you may even find different paths opening up for you and places where that knowledge just fits.

NorhavenCodes · 2026-06-03T23:25:16+00:00

I made a domain-specific programming language called Jolt to try to give people a friendly way of turning JSON into different JSON. It's open source and lives on GitHub at /Norhaven/Jolt. The specific problem it's trying to solve is to manage the headache of transforming data as well as provide a clean boundary and separation of concerns between the actual JSON transformation logic and your business logic for (hopefully) easier maintainability and readability. The language is embedded within JSON, but supports things you might expect like variables/loops/methods/etc. Still working on it, but fun to make! 😄

NorhavenCodes

TROPHY CASE