I tried taking inventory of the 'decisions' I thought were no big deal

Until now, I thought my job was to write code.

Build screens.
Build APIs.
Build databases.
Finally, deploy to GCP.

Since I am an engineer, that is pretty standard.

I have also focused my technical resume on what I used and what I implemented.

I can use Next.js.
I can use React too.
I can work with Go and Laravel.
I can handle everything from frontend to backend and infrastructure.

I have always presented myself that way.

However, lately, I have started to feel like that is not quite right.

I enjoy the time spent thinking about design, but when it comes to the stage where the policy is set and I have to endlessly continue similar implementations, I get bored quite noticeably.

What to build.
Where to separate things.
Will this structure cause problems later?
What should we not build this time?

Thinking about these things is interesting.

But when it comes to just stacking up a decided form, my mood suddenly becomes heavy.

I used to think this was because I lacked perseverance, but recently I have a slightly different perspective.

It is not a problem of perseverance, but perhaps the work I find interesting and the work I was selling were just misaligned.

I have sold myself as someone who writes code.

But what was actually providing value was,

“Wouldn't it be better to separate this here?”
“This structure seems like it will lead to a dead end later.”
“Are you sure it's okay to combine those into one?”

I suspect it was the time I spent thinking about things like that.

So this time, I decided to dig up the past decisions I thought were no big deal.

This article also serves as a portfolio of the design decisions I have made so far.

However, this article is not aimed only at engineers.

I would be happy if even those who think they don't have much of a track record can pick something up from this.

It is hard to count things that are normal to you as achievements.

Things I thought were no big deal turned out to be quite important from someone else's perspective.

Recently, that has happened a few times.

I don't bother recording things that I can do naturally.

Even for things I decided on after much hesitation,

I just end up thinking,

'If you think about it normally, this is what you would do.'

Moreover, when you are involved in a project as an implementer, design decisions get buried within the implementation work.

What remains in the end is,

'I built the screen', 'I implemented the API', 'I revised the functionality'

and results like these.

Why did I choose that form? What did I separate? What did I avoid? What did I decide not to build?

These things hardly remain. Even if I write them in my technical resume, it is at most one sentence.

If a proposal is not adopted, it remains even less. This is because there is no finished product, making it difficult to write as an achievement.

Eventually, even within myself,

'Well, it's the same as doing nothing'

is how it gets treated.

But experience does not remain just as your job title suggests.

I think you cannot see your own value unless you dig up not just what you were in charge of, but also what you saw, what you thought, and what you decided.

'It's easier to bundle everything together' will come back to haunt you later

Previously, I worked on a business system replacement project that handled complex processes related to payments and billing.

In the old system, various processes were tightly coupled.

Changing one part would affect another.

As similar processes increased, it became unclear where to make fixes.

At first glance, this is just a common story of,

'Old systems are tough, aren't they?'

that kind of talk.

However, what bothered me wasn't just that the code was old.

Which processes are truly common? Where should we start separating them as different tasks? Has making them common actually made them harder to change?

These were the things that concerned me.

So, instead of increasing inheritance relationships to make things common, I changed the structure to one that combines components based on their roles.

Technically speaking, it's a story about choosing composition over inheritance.

But in short,

'I stopped throwing everything into the same box'

is what it means.

Bundling things into one might look easy at first.

You can reuse the same mechanism. The code is reduced. Everything looks neat and uniform.

However, when you bundle things that change separately, you run into trouble later when you want to change just one of them.

This is not limited to systems.

Pack consultation, production, support, and Q&A all into a single product.
Speak to both beginners and experienced users at the same time in a single article.
Make one person responsible for everything from decision-making and tasks to management and customer support.

Just because you put everything together doesn't mean it's organized; in fact, mixing things up can sometimes make it impossible to tell what the problem is.

Separate what should be separated.

This is also a form of sound design.

It is not always best to save every piece of data you might want to use in the future.

In a SaaS I developed personally, I handled customer information, activity logs, notes, tasks, and more.

All of this information could be consolidated into one place as 'customer-related information'.

Put notes, tasks, and history all inside the customer page.

If you are just building something small, this is faster.

However, I was thinking that I might want to use it for analysis and diagnostics in the future.

So, I treated customers, activities, notes, and tasks as separate roles.

Whose information is it?
When did the activity occur?
Is it a record written by a person?
Is it a summary created by AI?
Is it a task that needs to be done?

If you leave these things ambiguous, you will have trouble when you want to analyze them later.

However, just because you might use it in the future doesn't mean you should save everything.

Data collected with the thought that it 'might be useful someday' is rarely used.

It only tires out the person entering the data.
It only increases the number of items to manage.

Thinking about the future and preemptively building everything are two different things.

How much should be kept?
What should not be kept?

These things also need to be decided.

Design might be more about what you discard than what you add.

It's easy to leave things to AI. But there are places where you shouldn't.

In another personal development project, I created a divination-based calculation service using AI.

This service requires calculation processing with second-level precision.

AI is good at creating text. It can also interpret and explain things.

However, it's honestly scary to leave calculations that need to return the same answer every time to AI.

"The answer is slightly different between yesterday and today."

That would be a problem.

So, I implemented the core part of the calculation in Go and separated it from AI and external services.

I leave the interpretation and explanation parts to AI.
I guarantee the calculation parts that require reproducibility.

It's fast if you leave everything to AI.
It's safe if you build everything yourself.

It's not that simple.

You need to separate the parts where changes don't matter from the parts where changes would be problematic.

The more convenient AI becomes, the more important it is to decide what not to leave to it, rather than what to leave to it.

Not using AI is not the same as being cautious.

Using it without defining the scope of what is safe to delegate is much more careless.

Standardizing on one technology looks neat

When I built a data collection tool for market analysis, I didn't unify the backend into a single technology.

This is because the required characteristics were different for the part that processes large amounts of data and the part that operates a browser to collect information.

I use Go for the parts that need to be processed at high speed.

I use NestJS and Playwright for the parts where browser operation and peripheral libraries are easy to use.

Standardizing on a single technology looks cleaner and only requires one development environment.

It is also easier to explain, as you can say, 'This entire system is built in this one language.'

However, if you prioritize unification too much, you end up forcing a single technology to handle tasks it isn't good at.

It's like hiring one all-rounder who can do everything.

It is certainly easy to manage.

But if that person collapses, everything stops.

Technology selection is not about choosing your favorite language.

It is about looking at the nature of the processing, frequency of changes, operational methods, and available libraries to decide which tool to entrust with the task.

If you try to solve everything with one tool, you start forcing the work to fit the tool rather than fitting the tool to the work.

This is quite counterproductive.

A screen that doesn't confuse users in the field is better than a pretty one

In a public infrastructure management system, I was involved in screen design in an environment without a designer.

It is a business system used daily by people in the field.

For consumer-facing web services, the novelty of the look and the first impression are important.

But for business screens, it is more important that users do not get confused during daily input and verification.

What is the order of input? What do they want to compare in the list? Under what conditions can they proceed to the next step? Where should they go back to if they make a mistake?

A screen is not just a box for displaying information.

It is a path for the user to make decisions and proceed to the next action.

No matter how pretty it is, if the user wonders 'What do I press next?' every time, it is a failure as a business screen.

Usability is not created just by making buttons round or coordinating colors.

Who, when, looking at what, and deciding what.

If you don't think this far, you'll end up with a maze that only looks impressive.

There were times when I made a proposal but it was simply rejected

Writing this much might make it look like I've been free to design whatever I wanted.

That is not the case.

There have been times when I sensed a problem, proposed an improvement, and it was simply rejected.

There were also times when I wasn't understood.

Because it wasn't adopted, there were times I couldn't verify until the end whether that judgment was correct.

At the time, I thought,

Was my way of explaining bad?
Should I have provided more evidence?
Is my ability to propose weak?

I thought about these things.

I think that was part of it, too.

However, I was brought in as an implementer, not in a position to decide design policy.

An implementer's improvement proposal is, after all, just one opinion.

If the person in charge says the same thing, it becomes policy.

Even if the content is the same, the weight changes depending on who says it.

It's a blunt truth, but it happens often in organizations.

However,

I have no intention of ending it with,

'I was right, but I wasn't understood'.

This is because a technically good proposal and a proposal that can be adopted within an organization are not the same thing.

What will happen to the delivery deadline?
How far will the scope of changes extend?
Can the team understand and operate it?
Is it necessary to change it right here and now?

It is necessary to consider these conditions as well.

If a total change is impossible, change only one part.

Instead of creating the ideal structure all at once, shrink it to a size that can be adopted even under current constraints.

I believe that designers need not only the ability to think of good ideas, but also the ability to make them a size that others can accept.

This is an area where I want to gain more experience in the future.

A designer is not someone who knows the correct answer from the start

The term 'designer' sounds like someone who sees the whole picture and provides the correct answer from the beginning.

But in reality,

Organize what the problem is.
Find what should be separated.
Compare several options.
Decide what to prioritize and what to discard.
Break it down into a form that can be executed within the constraints.

It is a repetition of this.

I think design is closer to the work of creating criteria for judgment than the work of guessing the correct answer.

Why was it made in this form?
What did I want to protect?
What would change the design if it changed?

If you have those criteria, you can make corrections even if the situation changes along the way.

If you start building without criteria, ad-hoc responses will increase every time a problem occurs.

And in the end,

'I'm too scared to touch it anymore'

is what gets completed.

Even though it should have been small at first, no one can explain the whole thing.

This is a scene that is quite familiar in system development.

This wasn't just about system development

The story so far is not limited to system development.

The same thing happens with note articles, product creation, and service design.

Packing too many claims into one article.
Trying to solve everyone's problems with one product.
Continuing to add features that seem convenient.
Increasing the number of things to do without deciding what to stop.

When this happens, you aren't moving forward even though you are working hard.

In fact, the more you move, the more complicated things become.

It's not necessarily that you lack materials.
It's not necessarily that you lack ability.

Because the categorization and priorities are not decided, the more work you add, the more things get tangled up.

I like finding these tangled places.

What is the real bottleneck?
What should be done now, and what should be put off?

Where should we divide things to make the next decision easier?

Looking back, whether it was system development, giving advice to people, or thinking about notes and products, the things I was looking at haven't changed much.

Writing code and giving advice look like completely different jobs.

But within me,

“Separating things that are mixed”
“Making things in a state where they can be decided”

I think they are quite close in that respect.

From now on, I will sell myself as a designer, not an implementer

Up until now, I have put to the forefront the fact that I can implement across the frontend, backend, database, and GCP.

As a result, I was seen as someone who could implement a wide range of things.

I will continue to do this if necessary, but if I place this at the center of my value, I will naturally attract projects that expect a high volume of implementation.

And I start to get bored during the long implementation phase after the design is finished.

This doesn't benefit anyone.

From now on, I will choose work centered on requirements organization, basic design, application design, replacement design, and improvement of existing structures.

I will also get involved in implementation as needed.

However, I will treat implementation as a means to verify the validity of the design or to give shape to difficult parts.

Rather than designing and then endlessly continuing the same type of implementation, I want to move into a role where I organize the next set of problems and decide on the next direction.

Writing this article has made that direction much clearer.

There was value worth selling in the decisions I thought were no big deal

I have no track record.
I have no experience to show others.

Even if you think that, you might just not be counting your decisions as achievements.

Not just what you completed,

What did you feel uncomfortable with?
What did you separate?
What did you choose not to do?
What did you stop doing?
Who did you help avoid confusion?

If you look back that far, you may find value that you had overlooked yourself.

Until now, I have only looked at the amount of code I have written as my track record.

But what was important to me was not what I made, but why I made it in that form.

Buried within the decisions I thought were no big deal was the value I should be selling from now on.

There may be decisions within yourself that are too ordinary for you to count as achievements.

Not just what you made, but what you felt uncomfortable with, what you separated, and what you chose not to do.

If you dig that deep, you may see value that you can use for future outreach and work.

At WindShift, we provide business design support to help you transform the experience you have built up as an employee or freelancer into your own business.

How do you connect your experience to whose problems, and how do you link that to products, messaging, and customer acquisition? I have summarized that way of thinking in a pinned post.

Additionally, for corporations and small business owners, we support business organization, requirements definition, AI utilization, and the improvement of existing operations.

We handle everything from the stage of organizing what should be built and how much should be built, including requirements organization for web applications, basic design, replacement design, and improvement of existing structures.

If you are considering business improvement or design support, please visit the WindShift website.