In my work, I move between software development and design.
From the outside, these fields can look very different : one seems technical, the other creative. In practice, they share the same foundation: understanding a problem, working within constraints, and producing something that solves it.

Coding and visual design are just the visible parts of the process. They are outputs. The real value is the thinking and decision-making that lead to those outputs.

Development Beyond Code

Writing code is the execution phase. Before that comes a series of steps that define what the code should do, why it matters, and how it will be maintained over time.

A developer’s role involves:

• Analysing the context of the problem

• Translating needs into clear, testable requirements

• Selecting the right technical approach for the constraints

• Ensuring the solution remains reliable, secure, and maintainable

The programming language or framework is a tool. It can speed up development, improve performance, or offer better integration, but it does not define the value of the work.

For Example

A client asks for a dashboard that shows real-time sales. If I focused only on writing code, I might immediately start building a React interface, connecting it to the database, and streaming updates.

But before touching the keyboard, I dig into the request:

• What decisions will this dashboard support?

• How often does “real-time” actually need to update?

• Who will use it : managers, sales reps, or external partners?

• What devices will they view it on?

From these answers, it turns out:

• Updates every minute are enough to support their decisions

• The users are on tablets during travel

• Data security is a bigger concern than sub-second latency

With that context, I choose a simpler architecture with periodic updates, lightweight components for mobile performance, and a secure API gateway. This meets the goal, costs less to run, and is easier to maintain.

The difference is clear: the value came from defining the right problem and making design choices, not from the number of lines of code written.

Design Beyond Aesthetics

In design, the equivalent misconception is that the role is about producing something visually appealing. Aesthetics matter, but they are the result of other decisions, not the starting point.

Design work involves:

• Understanding user needs and behaviours

• Identifying the functional and contextual constraints

• Establishing a clear hierarchy of information

• Balancing usability, brand, and emotional impact

A beautiful interface that fails to solve the user’s problem is no more successful than a clean block of code that doesn’t address the actual need.

For Example

A startup asks for a “modern, beautiful” landing page to present their new SaaS. If I only focus on visuals, I might design a sleek, gradient-heavy interface with bold typography, smooth animations, and complex background effects. It would look impressive in a portfolio.

Before opening any design tool, I ask:

• Who will visit this page first : potential customers, investors, or press?

• What do they need to understand within the first 5 seconds?

• On which devices and connections will they see it?

• What single action should they take before leaving?

It turns out:

• Most visitors are small business owners discovering the product for the first time

• They care about price, core features, and credibility, not flashy visuals

• Many will load the page on mobile over average connections

• The primary goal is to get them to start a free trial

The final design is clean, fast-loading, with a clear value statement above the fold, simple feature breakdown, and a prominent “Start Free Trial” button. It still looks good, but its structure and priorities come from the problem, not the desire to make something “cool.”

Shared Ground: Problem-Solving Under Constraints

In both development and design, the work begins by understanding the problem clearly. From there, it’s about exploring options, weighing the pros and cons, and arriving at a solution that makes sense in context.

Constraints are constant:

• Time and budget

• Technical limits

• User expectations and behaviour

• Long-term maintenance and scalability

The job is to make decisions that respect these constraints without losing sight of the main objective.

Adapting to Changing Tools

In development, technology stacks change regularly. Interfaces once built with jQuery and PHP are now made with frameworks like Next.js and Bun, often typed with TypeScript. Deployments run through hosting platforms linked to the repository, building and releasing automatically.

Data and server logic that once required dedicated infrastructure are now handled by managed services. PostgreSQL can be provisioned on Supabase, NoSQL on Firestore. BaaS platforms cover authentication, file storage, and APIs, while headless CMS like Strapi or Sanity deliver content via API.

In design, static layouts from Photoshop have been replaced by collaborative tools like Figma, keeping layouts, components, and styles in a single source. Shared design systems align with development components, with tokens for colours, spacing, and typography. UX work is built into the process from the start: research, accessibility checks, and user testing guide the design, supported by wireframes, prototypes, and feedback loops.

The Role of Artificial Intelligence

AI can now generate code, assets, and design variations in seconds. This shortens the time needed for repetitive or mechanical work, but it does not replace the core responsibilities:

• Defining the requirements

• Checking the quality of results

• Integrating outputs into a coherent system

AI works by reproducing patterns it has learned. If we stop using our own judgement and our understanding of human needs, we end up in a loop where the output keeps circling around existing ideas. Over time, this narrows the range of possibilities and makes it harder to bring new perspectives. This question will be explored in a future article.

Conclusion

Whether in development or design, the essence of the work is the same: understand the problem, respect the constraints, and deliver a functional, coherent solution.

The code, the visuals, and the tools are means to an end. They will continue to change. The ability to analyse, decide, and solve problems will not.