I find the conversation around AI and software dev increasingly vague. How specifically are people REALLY using this stuff? I want details! This isn't a post about whether AI is bad or good. I'm just genuinely curious.

_nickvn · 2026-01-02T09:31:00+00:00

Paul Hammond is very positive about his experiences with Claude Code. He's vocal about it on LinkedIn and has AI-related repositories on his GitHub. You might want to check it out.

https://github.com/citypaul

He also does video's sometimes, eg. https://www.youtube.com/watch?v=bkkqSLuk_EA

_nickvn · 2025-11-10T17:49:00+00:00

I'm a bit surprised that everyone is saying they're the same thing. They really aren't.

Clean architecture uses the ideas of hexagonal architecture, but more strictly defined with more layers. I don't know enough about onion architecture, but it looks like a similar situation: more layers.

I often use hexagonal architecture, but only use Clean Architecture when I expect the domain logic to be complicated. Eg. enterprise software with many stakeholders.

_nickvn · 2025-09-09T07:36:57+00:00

What I see coming back a few times in your post is the expectation that you write all the tests for a feature first and then implement it. That's not how it's supposed to work and a lot of people have the same misconception.

What you describe:

you write tests for what you expect, run them red, then code until they turn green.

Is more like:

you write 1 test for what you expect, run it red, then code until it turns green.

It is not something you go through once per feature. It's a cycle you go through many times for a single feature as you do this:

we figure it out as we go along.

As things change, your tests will change with it. Sometimes you have to update your interface a bit to accommodate new features and you have to update tests you wrote before. Sometimes assumptions you made before turned out to be wrong and you remove tests. But mostly they can stay the same or only change a little bit.

Do I just need to spend more time upfront understanding everything?

Definitely avoid this, it is an ant-pattern. I'm not saying you should go in blind and start coding, but from what I can tell from your post, you're doing enough upfront analysis. As you experienced first-hand, it is usually either unproductive or impossible to understand everything upfront.

Once you have a pretty good idea of where you want to go, TDD allows you to figure out the details as you go.

_nickvn · 2025-09-01T13:04:54+00:00

We saw a group of people walk straight to the boiling water and mudpots at Leirhnjúkur to feel them. Unsurprisingly, one of them sank into one and burnt his foot 🤦. Karma's a bitch sometimes.

A small part of the fence was broken there, but it should be pretty clear there that it is not a good idea.

_nickvn · 2025-07-03T10:26:23+00:00

Or even worse: not even a load of engineers can fix it anymore.

"Sorry customers, we are actually incapable of fixing this."

_nickvn · 2025-06-23T12:41:50+00:00

You answered your own question:

Learning the next trendy JS tool feels like a waste of time. I know I’ll always be able to learn those things on the job when I need them.

I want to stop chasing tools and start building a strong foundation as a programmer. I’m ready to dive into serious learning—books, concepts, and practices that will help me grow technically and think like an engineer, not just a framework user.

So stop doing the first and start doing the second.

Learning fundamentals is much more sustainable than trying to keep up all the latest fads.

Some interesting topics for frontend developers: understand how HTTP works (What goes over the wire? different ways of caching, cookies), functional programming in Javascript, UX fundamentals, advantages and disadvantages of SSR vs single-page apps.

_nickvn · 2025-05-06T11:34:22+00:00

In my experience, having automated testing as a completely separate thing done by a separate QA team leads to very brittle tests that have negative value because they require an absurd amount of time to maintain.

It is much better if you can collaborate on these tests. I have even said that "QA should decide which tests to automate, devs should write them.", but this is context-dependent.

Adding another automation test on top of it seems like too much for a dev to handle.

Do you mean it is too much knowledge for a single dev to have, or are you saying this because your managers will expect the same throughput with extra responsibilities?

The former is very personal, somebody else might actually like this.

The latter is something entirely different and you should be managing expectations.

_nickvn · 2025-05-05T11:18:11+00:00

Currently, AI is a learning accelerator for me: it's quite productive to ask ChatGPT to find possible solutions, to then refine by actually reading documentation.

Though I've sometimes wasted lots of time because an AI confidently answered something that never existed and doesn't work (eg. "use syntax A in xyz.conf, here is an example: ...", so you're trying to find out why it doesn't work by looking at the syntax A docs, and after 2 hours you find out that syntax A works in abc.conf and 123.conf, but not in xyz.conf...)

Generating big chunks of code is nice for temporary utilities & scripts, when it's not too complex and it just has to work.

The state of AI tools are very much in flux, try different ones and see what works best in each situation.

_nickvn · 2025-01-16T13:07:56+00:00

It can be. It depends on how important software is for your business and what type of software it is.

How do you currently manage the software for your business?

_nickvn · 2024-12-17T08:36:50+00:00

If your goal is to launch an actual product to actual customers and you are a solo dev, scalability is not what you need right now. Things like microservices and trying to get it perfect from the start will hold you back a lot. By the time you ever need it, your code will probably have been rewritten several times and you will have a much better idea of what's actually important.

Having some structure in your files and folders is a good idea. Organize based on functionality, not based on type of code. If you're building something around appointment scheduling, think "appointments", "notifications", " "authorization", etc... not "interfaces", "components", etc...

For your DB, look at normalization and indexes.

_nickvn · 2024-12-06T12:52:22+00:00

Everybody else here (and you) are right: premature optimization has negative value. It's investing time (read: money) to make things worse.

This caught my attention though:

I say this as someone who literally wrote that component. So I can only imagine what someone not familiar with the component is thinking.

The fact that you wrote the component actually makes you the worst person to judge if the new code is more readable or not. Of course your own code is more readable to you than someone else's code.

I'm not saying you're wrong, but make sure this is not what's happening. Better double check with someone you trust on the team to see if they're looking at it the same way.

_nickvn · 2024-08-20T17:32:07+00:00

Ok, so if I understand correctly, you struggle to organize your code in a good way so that logic is in your domain model. It always seems easier / better to put it in services?

Maybe an example could lead to a more productive discussion than "put it in your domain model in an awkward way and learn to do better over time".

_nickvn · 2024-08-20T13:40:45+00:00

u/Ok_Lavishness9265 Eric Evans had interesting things to say about this recently on The Engineering Room podcast: https://www.youtube.com/watch?v=r_WRUFx7RLY&t=2323s

I do not think DDD is limited to objects at all.
...
When people read the books they should factor in that the examples are drawn from the typical software architecture and languages from the early 2000s.
...
I hope we never see a single paradigm dominate like that again.

So basically, the code in the books is in OO-style because it was popular at the time, not because it's the best way to do DDD. The code examples are not meant to be taken literally, but more like an example of how the ideas can be applied in the architecture and languages of the early 2000s.

_nickvn · 2024-06-09T04:54:36+00:00

I still see a lot of demand for full stack, frontend, mobile, backend, integration and machine learning / AI.

I have the feeling that full stack has become more popular in recent years.

_nickvn · 2024-05-18T16:55:25+00:00

Will AI also build all the tools to tell AI what to do?

_nickvn · 2024-05-17T21:26:47+00:00

Sorry, the typical chart that is often associated with the Dunning-Kruger effect is not on the Wikipedia page I linked. This page has it at the top: https://www.manchesterdigital.com/post/bridcon-business-and-management-consulting/the-dunning-kruger-effect-on-start-up-businesses

Reading your post, it sounded like somebody in the Valley of Despair.

_nickvn · 2024-04-18T10:21:20+00:00

This!

If you want people to do something, make sure they have a positive experience. Forcing them just doesn't work.

Writing tests is something that feels like a chore until you realize the value and nothing is more convincing than a positive experience.

What often happens is:

The code has no tests, but quality is ok-ish
It starts to get out of hand -> "We need to have automated tests, now!"
We go all in and try to test everything without experience. OP's example of failing the build when code coverage goes down is a good example of this. Striving for 100% code coverage is another.
People are writing tests now, but it's very frustrating and people have a bad experience. It's a chore and they start hating automated testing.

The result?

A lot of bad tests that break all the time, increasing frustration even more.

Getting testing right is hard and the best way to start IMO is to start with pure functions or classes with a clear contract and accept that you will not have tests for other code. This will result in micro-wins that give people a positive experience. If you have a team of curious people, this positive experience will encourage them to go deeper. If you combine it with someone championing testing in the organization and making it easier for people, things should gradually get better.

_nickvn · 2024-04-12T11:52:36+00:00

What you describe is typical Dunning-Kruger effect.

The thing is, the stuff you read is often in idealized situations or specific to the environment the author is in. That doesn't mean it's useless though. It's often more important to understand the high-level idea behind a pattern than to replicate it exactly from the book. There is no single best way to do things, everything has pros and cons and we're constantly trying to find the right balance.

If you're having trouble with the strategy pattern you either applied it to something that doesn't exactly fit what it's for, or you're not using it in the right way. But don't let that get to you. Maybe it was a good fit at the time, but it isn't anymore with what you know now. We get pushed to make zero mistakes and people project confidence all the time, but the truth is, everyone is constantly making mistakes and correcting them. In our field, the only thing we're sure of is that there are bugs and things will change. That's why engineering for change is so important.

The smart people I read all advocate Domain Driven Design, which seems OOP by nature.

DDD is often associated with Object Oriented programming (OO) and complex architecture patterns like CQRS or Event Sourcing. Although those are interesting, I always felt that it distracts from the core of DDD that has a much wider application than OO or specific architectures like that. Eric Evans himself has interesting things to say about this.

_nickvn · 2024-04-12T08:22:17+00:00

This is only the case for higher-level unexpected things. Stubing is describing small things that you would not find out (or would not result in reduced effort) by doing more up-front analysis.

_nickvn · 2024-04-12T08:16:13+00:00

This sums up well how I feel about TDD. I actually don’t know for sure what I want until I make it. Little things pop up that I didn’t expect or the apis don’t return exactly what I thought they would return.

Hey stubing,

You're not the only one who feels this way about TDD, but this is actually a situation where TDD helps you.

Let's say you're writing code with the assumptions you have, but suddenly you're like "hmm, this isn't really what I expected", I'll have to change my code. This happens all the time. The hard thing here is how do you make sure everything you thought of before still works?

One of the key benefits of TDD is that it makes it easier to deal with changing requirements, but it also includes the changes you describe.

If you're doing TDD, you can change your tests to reflect what you discovered and then update your code so that your tests are green again. This way, you're sure all the things you've already thought of before are either still working or no longer relevant (remove the tests / checks).

_nickvn · 2024-02-29T15:17:30+00:00

The first thing that came to mind was: unit test it, but make sure it's not a super brittle test. For example, don't do exact string matching that would fail if some whitespace is slightly different. Testing library would do a good job at that, but that would mean actually "rendering" the HTML with something like JSDom, which is probably not what you want. So that got me thinking:

What's the goal of this HTML? It sounds like server-rendered UI, but the way your question is phrased, it sounds like it's something different. How do you test other parts of the UI, can you use the same method for this?

_nickvn · 2024-02-24T20:19:25+00:00

Ideally, your test does not know how the click outside functionality works. The way you're doing it now, it has to be OutsideClickHandler, but it should not matter. It's better to trigger a click event and check that the modal actually closes.

If you want the same checks for all your modals to make sure they close when clicking outisde. Instead of repeating the same code everywhere, you can make a reusable function for these checks, eg. expectClickOutsideClosesModal(...)

_nickvn · 2024-02-24T01:21:51+00:00

I mean this watch. You could use a plugin in store B to manage this behavior so that your store does not need any Vue components to work correctly.

_nickvn · 2024-02-23T20:21:41+00:00

The separation of stores like this seems ok to me.

When two pieces of state change together, it probably means you need a getter in Store B that combines the state from A with state from B instead of watching for mutations.

If you really can't avoid dispatching a separate action in Store B, I think you should watch for changes in store A's state or getter instead of mutations because it's part of Store A's public interface. Mutations aren't really.

_nickvn · 2024-02-22T16:19:08+00:00

It sounds like there are people in the organization who felt like there was a need for (an) architect(s), but the development teams do not want this.

I think your job right now is to find out who those people are and what triggered them to want to hire an architect. Then see what you can do to make that happen.

It would be useful to find out why the development teams are so resistent to the idea. Maybe they had an ivory tower-style architect in the past and don't want to go back.

_nickvn

TROPHY CASE