What I learned in the past 3 months regarding development
Tags: css, career, webdev, react
Published: 2020-03-30 22:20:58

I must admit - the title is a tad bit too ambiguous.
But it needed to be, since I wanted to write various things on dev.to on multiple occasions but simply was too busy.
It's 5am after an almost 9 hour coding streak at work.
My first [open-source project](https://github.com/cosmostation/mintscan-binance-dex-frontend) is now close to being production-ready.
It's about time.


(Me from the future) This one is about CSS and developer mindsets

## Update on my take on CSS
Last year on December, I cooked up a [rather controversial post](https://dev.to/fly/i-front-end-and-hate-css-here-s-how-i-deal-with-it-3na7) which went rather viral(about 20x more views than all previous posts combined) on how I deal with CSS, because - well frankly enough - I was too bad at it to realize how much I sucked. I was pretty much a perfect example of the [Dunning-Kruger effect](https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect).
Yet after replying to one too many comments that I'm comfortable to admit, and trying out multiple methods thanks to the most helpful people(I tried scss, tailwind), I reached a couple of conclusions.

> Use SCSS

This one is mandatory. Just pros, no cons.

> Use a post-css compiler to make all your classes have different names according to filename and random strings at the end

Projects using CRA will probably need to eject to make this work(or use [this](https://github.com/timarney/react-app-rewired)) but it just makes your life so much more comfortable. A downside that I'm feeling these days is that it makes your build css substantially larger when coupled with scss and a not too optimal coding style.

> Use classnames

```javascript
import React from "react";  
import cn from "classnames/bind";  
import styles from "./template.scss";  
  
const cx = cn.bind(styles);  
  
export default function(props) {  
  return (  
  <div className={cx("template-wrapper")}>  
  test  
  <div>testtest</div>  
  </div>  
  );  
}
```
This snippet is literally how I start writing all my new components.(I use it as a live template)
I find it to be the perfect balance of DX and optimization.
But...

> There's no answer

It's really up to you. I tried tailwind, and honestly I believe it could be a better alternative to the way I CSS my project.
But what really made me shift from using styled components to a scss + classnames approach was the fact that it was the approach taken by the legacy project I was given the task of maintaining.(And obviously I weighed out the pros and cons and decided it to be the best choice in my current situation)
_There IS no answer_. If that project was written in tailwind, I'm pretty certain that's how I'd be CSSing right now.

If you are by any chance in the same shoes as I was 3 months ago - trying to find the optimal way to write css and as a result barely getting any work done - pick a method and just go with it, refactor when you really feel the need. A close deadline always helps.

## Developer mindsets
I had two jobs before my current one. Both previous jobs had problems of their own, and after 3 months(surprisingly the longest I've stayed at a single job), I am some-what truly content with my environment and would like to share some things that I heard, felt, agreed, learned from seniors or experience.

I'm an optimization freak(I think most of us are deep down inside). I love making load times shorter, and creating gimmicks that enhance UX.
One day I was feeling really proud about myself that I was able to create a new page rather quickly because I had compartmentalized my code effectively for reuse. I told that to a senior developer.
His answer was pretty much this in a nutshell.

> Anyone gets good/better/faster at development given time - it's about how well you understand WHAT is needed in a project that makes you a good developer.

Let that sink in. It's not about what you can make a difference by optimizations and code structure - that should be a given. It's about the visible differences apparent to the user/client. Every single decision on every bit of code should be made with this at its base.
Which sets the scene for the next one.

> Coding is decision making. Try to take into account and know as many variables as possible

In essence, this is obvious. Well, EVERYTHING is decision making to be blunt.
It's the gravity of making the _**right decisions**_ based on _**as much information as possible**_ that I realized was important.

One day I was lost in a train of thought, wondering what was the best method to optimize fetching data from the server. I felt that the implemented methods was putting too much strain to the backend so I was considering ways to cache already fetched data. My mind was strolling through even setting up a browser DB such as CouchDB. This wondering took more than 4 hours of my time searching through the best practices and looking for references of other projects that had faced a similar situation. After I finally made a decision, I asked my CTO on how much strain the server will be able to take. It turned out that the number of requests I was trying to reduce was almost meaningless and would save probably a few dollars a month with thousands of users.
What I was trying to fix was simply not cost-effective. I ditched the entire thought process and decided to carry on making more features in an instant. Lack of understanding on backend maintenance costs resulted in the loss of hours of productive thought processes / searching.

It's constant estimating and comparing in your mind, about what kind of approach will bring out optimal results with the time you commit. As a result, the next one comes along.

> Investing time in order to be in good terms with your co-workers/people you work closely with pays off exponentially

And I mean **_exponentially_**. But there is a tipping point where time investment becomes less and less effective. This point is

> when he/she/you can take constructive work-related criticism without hard feelings, and both parties feel comfortable in doing so.

If you can take constructive work-related criticism, awesome. But making sure that your co-worker can give you that criticism when they feel it is needed is a completely different matter.
This varies too much according to one's personality, so I won't go down this rabbit hole. But I find this to be one of the key factors in work efficiency, **_multitudes_** higher than being able to optimize code effectively.

Well, I'm completely knackered after typing this out.
It's 7am and I should really get some sleep.
I began writing this post as a dev log for what I learnt about React and front-end developement.
I think I committed way too much writing about developer mindsets.

Hope I didn't sound too cocky. Any form of feedback is always welcome.

Cheers.