Taking longer to load than usual. Thanks for your patience.
Couldn't load the data. Please reload the page.
Taking longer to load than usual. Thanks for your patience.
Couldn't load the data. Please reload the page.
It’s been ten months since I switched from a five-year career as a designer to engineering. Transitioning from a designer to an engineer is probably an unusual path, so I thought I’d share my experiences and challenges for others considering a similar career change. I worked as a 3D generalist in my previous role, so my job was a bit different from a typical graphic designer. Still, since my main work involved creating visuals, I’ll refer to myself as a designer here.
Engineer: “Stick to the design document! Don’t make unauthorized changes!”
Designer: “Create interesting visuals! Think of how to make it better yourself!”
This may sound a bit exaggerated, but it’s not far from the truth. Designers, who tend to focus on visual aspects, and engineers, who focus on functionality, prioritize different things and get criticized for different reasons. In my time as a designer, I didn’t have to worry about the ten-plus scenarios in which data might not be received properly from the server. The best part of being a designer was the ability to inject personal perspective. Adding ideas I thought were good was enjoyable.
The arrival of image-generation AI was the turning point that pushed me to consider engineering. With technology advancing so that anyone can easily create visually appealing designs, I thought, “If that’s where things are headed, why not learn both design and engineering?” That’s when I started looking for engineering roles.
The first major hurdle I faced was eliminating any ambiguity in understanding. In my designer role, ambiguous instructions were an opportunity for creative thinking. However, in engineering, making changes that aren’t specified in the design document is treated as creating a bug. Any ambiguity needs to be clarified with managers or clients, and if a design adjustment is needed, the document must be updated before moving forward.
Sometimes, though, clients themselves aren’t sure what they want, and you still need to make progress. In those cases, you interpret the design document and previous discussions, ensuring you can explain your decisions if questioned later. Without prior experience in team development, I initially made changes based on my subjective judgments from my designer days, which led to a lot of bugs.
This approach might not apply to all workplaces, but avoiding ambiguity is essential for engineers. To draw a parallel, if you’re building a car, and there’s no specific instruction for the roof, an assembly worker can’t just decide to attach a propeller! Even if it could fly, people would wonder, “What on earth is this?”
In design, as long as the final visual outcome was good, the neatness of the code or file structure wasn’t a big issue. Even if work files were a bit scattered towards the deadline, it was fine as long as my supervisor and clients were happy with the visuals.
But that’s not how it works in engineering. Unlike delivering an image or video that can be finished once, applications need to be maintained over time. If things aren’t organized, it burdens the team managing the app and collaborating developers. The key is to deliver a well-structured, efficient application that maintains the intended design without unnecessary complexity.
Engineers usually adhere strictly to the design document, so detailed attention to visuals isn’t always mandatory. Having a designer’s eye allows me to fine-tune the appearance of an application. However, whether this is accepted depends on my manager and clients.
I didn’t realize this before, but engineers engage in a lot of communication. Of course, communication was necessary as a designer, but with engineering, there’s a need to meticulously align understanding. To minimize misunderstandings, you must use terminology consistently, avoid rephrasing based on personal knowledge, and thoroughly read and understand documents. Compared to my designer days, the level of attention to detail is significant, and it’s good training.
In my previous design job, our producer probably handled a lot of alignment with the clients without me realizing. As an engineer, I now interact with clients who are knowledgeable in code, and that adds a new layer to our discussions.
I noticed even as a designer that skilled engineers have an almost instinctual grasp of technical problems. Even when it’s not their app, they can make educated guesses on internal behavior and potential workarounds. This intuition is invaluable for anyone working with computers.
As long as I aim to be a generalist skilled in both design and engineering, I won’t be able to compete with specialists. So, I’ve let go of the idea of becoming a specialist. Instead, I focus on understanding the bigger picture, honing that as my strength. Still, I want to maintain a personal area of expertise.
If you’re someone who loves making things and working hands-on, transitioning to engineering could be a good idea. Engineering involves creating systems, and having a unique perspective from design or another background broadens your career possibilities and makes things interesting. People with diverse perspectives bring fresh ideas that others might not think of, making this a great asset for your career.
It’s helpful to know the basics of at least one programming language. Once you understand one language, others are relatively easier to learn. In my case, I had prior experience building websites and VR applications within my company, so I understood the basics of programming before becoming an engineer.
I had used Git as a designer for our company website, but it was only with one or two other people. In a team of dozens, it’s a different story. Updating everyone’s code with your changes (commits, branch merges) can be daunting at first. Without a solid understanding of what each file does, including autogenerated ones, unnecessary changes might affect the code everyone uses. If those changes lead to bugs, it disrupts work for others, which can be stressful. Gaining experience with team development, even with friends, can be beneficial.
I’m still learning this myself, but creating code that is resilient, easy to read, and less prone to bugs is a valuable skill, especially as apps grow in complexity. You might find it helpful to read about SOLID principles.
This may apply to any job, but if you’re a conscientious person, you may find yourself burdened with extra responsibilities. Having ways to protect your mental health is crucial. In my designer days, I wanted credit for my work, but as an engineer, claiming credit sometimes leads to added responsibility. It can be wise to keep quiet about your contributions when it’s unnecessary!

With AI simplifying various tasks, there will surely be more people able to handle a broader range of responsibilities. Anticipating that future, I made my switch to engineering.
Whether or not this resonates, I hope my experience provides a little inspiration for anyone considering a similar path.
Feel free to drop me a message if you're interested in working together and bringing our ideas to life.