“There are two wolves fighting in each man’s heart. One is love, the other is hate.”

“Which one wins?”

“The one you feed the most.”

I think the same about everything you do, design and coding included.

I love design and I like to code a lot.

I can never be apart from any of those, or I'll miss the other.

TL;DR: Equilibrium

Well there's an important thing to note, regardless of whether we are talking designing the interface in a graphical tool or picking a technology stack to build it with:

Done is better than best.

Don't get caught up in trying to figure out what the absolute best tool for the job is (e.g node vs. rails). If you're writing the code and you're designing the interface, either at the same time or at different stages, just ask yourself what you know like the back of your hand which will enable you to get it done.

That's not to say you shouldn't learn new stuff, of course. Just make sure you are solving the real issue first, which is deploying something by a certain date. Building in timeline constraints will help a lot when you're creating your own projects.

Otherwise, you end up doing what you're doing: thinking too much.

Don't fret about always being on the cutting edge or leveraging every optimization trick in the book. The world won't end if you didn't run your JPGs through three different compressors, or didn't perfectly use @extend versus @include in your Sass, or didn't find the most optimal build system to assemble files.

It's best to take it slow. There's an opportunity cost in learning a new process, so instead try to iterate on it. Take a process you feel comfortable with, identify a problem area, and consider ways you can bolt something on to your process to improve it.

And when it comes to choosing between different kinds of software, just learn one and stick with it. Learn Foundation or Bootstrap, learn Angular or Ember, learn Grunt or Gulp. The web prides itself on building systems that are flexible and can hook into anything (which I feel like is where much of the complexity comes from for new developers), so there's usually a way to connect any two systems to each other.

Just focus on getting things done.

I used to feel very "creative" when coming up with beautiful homepages and UIs in Photoshop. But then I realized that none of the things I was “creating” were actually seeing the light of day.

Or if they were, it was in a mangled, sub-par version. So I decided to code stuff myself and take charge of the whole product, from A to Z.

I feel a lot more “creative” now, because I'm not just creating visual designs, but actual products, and sometimes even whole businesses or communities.

So my advice would be to redefine what ”being creative” means to you :)

Me too! This came to a head recently. Like you I started out as a designer and slowly morphed into a developer. For awhile I was convinced that "design in the browser" was the way to go, but much like you described, you start to think about design more in code terms (very subtle so it takes awhile to notice it).

Lately I've been focusing more in design, spending time actually designing as opposed to just hacking up designs in CSS. I have noticed more attention to detail and being more open to experimentation/different implementations (with code this is limited because there is usually a "best practice" to adhere to).

Good to hear someone else is bumping into this, too :)

I've been a hybrid my whole career, but I had the realization about 2 years ago that I was happiest in the day to day grind with just design.

So I only applied at design only jobs. It took a while, but I found one and I'm MUCH happier.

I fee like code made it harder for me to design because I'm constantly thinking about the code and designing even if I know something is going to be a pain in the ass to code to be performant and maintainable.

So I totally feel you. So now I just roughly wireframe, design in Sketch... nothing is ever REALLY pixel perfect, I just need to know where stuff is and what it'll look like then its off to code land for me.

This is why I design my code, and I code my design. I think one could not live without the other and both work well that way.

I had to go through this too. But for me, the creative restraints faded away as I became more comfortable with code.

You don't HAVE to learn all the new things.

Learn to master your workflow, which might include thinking, sketching, etc. Find a code editor that suits you and an environment where you feel happy.

Decide upon the frameworks you feels are the best for the way you do things (there is always more than one way, never the "only" way) and stick to them.

Hope this helps.

I think it's up to you to manage that separation. As nice as it would be to embody that "unicorn" status, the reality is that there are only so many hours in a day. If you're splitting that between design/creativity and code/best practices/chasing the bleeding edge you're gonna end up burning yourself out. Is it empowering to be able to do it all? Absolutely. Is it sustainable? Not in my opinion.

Take a step back and evaluate what you prefer doing. Focus on that.

Sounds like a classic case of trying to do too much.

As others have said below, there's an opportunity cost to everything – and also a mental cost.

You need energy to be creative. Trying to do too much is a surefire way to kill your energy.

Decide what your strengths are and put your efforts behind those skills. Let the other stuff go. I know it's hard, but you'll feel so much better when you're not splitting your focus between 100 different things.

The most creative people I know are the ones who pick a few tools and learn them deeply. It's hard to be creative when you're switching tools all the time. Learning something deeply opens up mental space to be creative with your tools.

If you were gonna slap the Pareto principle on this issue I'd say spend 80% of your time using your core set of tools and 20% of your time experimenting.

It happened to me some years ago when I got too much into AS3. I think that putting too much time into knowing solutions makes your mind focus on feasibility and production. Knowing less gives you the naiveté that helps you think about "what if" without production worries. Then, once you got the solution you can get together with developers and they're gonna hate you but the idea is already there and that is a good thing. Wearing the production and design hats at the same time can definitely be a bad thing.

I've come from a similar background, being fully focused on design and staying within the realms of Photoshop. Then branching out to full front-end development.

Not tried out nearly as many languages and packages as you have, but maybe thats the issue?

I like to code smart, use best practices and essentially write tidy code. Only to a certain extent though, at some point I'll think "sod this, lets get something cool done".

Put the best practices to one side and use your development knowledge to build something creative. Making something awesome is better than making something perfect.

Im dealing with something similar right now. I was previously trying to prioritize one over the other but now I'm trying to find the balance that I am comfortable with :)

You don't have to have the best tools, you just need the tools to do the best job.

That's why I never cared about anything besides HTML/CSS/JS.

I don't think that learning anything, especially anything that requires a new way of thinking, can be bad for your creativity. For me, transitioning from a design role to an engineering role has opened up tons of doors and given me great ideas for things I could build and new directions I could take my career.

But when it comes to the other problem you've mentioned - feeling overwhelmed by trying to keep up with all the new technologies that come out - my advice is to not fall into the trap of learning everything that comes out. A lot of these frameworks/libraries are really good at solving a set of problems, but they introduce a new set of problems. A lot of times, you can accomplish the same things with a new technology or an old one, but you could have launched a product faster if you just stuck with the old one and didn't make yourself learn the new one. Strive for a balance - know what all the major technologies do, and what problems they solve, but don't start using them until you have those problems.