Just ****ing write some code.

How to be productive immediately AND in the long run.

Opinions and what's worked for me. YMMV.

Write tests first

Testable code is good code.

If you don't do it now, you probably never will.

Code quality is king

Writing code is easy. Reading it later is hard.

Write clean code today.

Bad code shows through in product quality.

Quality code is faster to add features to.

The best code is no code

Your code can't have bugs if you don't have any code.

Sometimes you need code

Not all projects can have no code.

Minimise code when it is needed.

(dry)

Tools are good

Good.

Small, focused, clean API.

Bad.

Stuff native to JS.

Trivial functionality you use once.

( Anything that namespaces with _ :3 )

Lock-in API ( frameworky )

Vet your deps

Shit goes wrong. Plan for it.

Smaller / fewer deps are easier to debug.

Look for deps with fewer sub-deps

Look for deps with TESTS.

Have confidence, be critical. Don't assume someone knows better than you.

Picking dependencies

READ THE SOURCE

_{( At least skim it, understand how it works )}

If you can't be bothered reading the source because it is too long, DON'T USE THE LIB.

Good libs are small.

Sometimes you need to use bad tools

EG: Sequelize. Horrible.

Wrap with something less disgusting. ( roll your own? )

Don't assume existing wheels are good enough.

Make wheels that fit your software if need be.

Make wheels for fun, increase your skills.

Throwback slide. Small is good.

The internet is bad. Ship less code.

If you need to split your bundle, you have too much code.

Frameworks are HUGE

Know how to do what you dont have time to do.

When looking for or using a tool, try and have a pretty good idea of how to implement it.

Nothing is magic, everything is easier than it seems.

You probably could write react.

If you have no idea how a tool works, try and avoid.

Open the debugger.

Code's buggered? use the debugger.

Do it immediately.

Don't play with settings to an API or randomly change shit.

node --inspect myNodeFile.js exists.

Don't transpile.

Please, if you take only one thing from this, let it be this point.

Transpilation makes EVERYTHING worse.

No one can read your code

You can't debug your OWN code.

You never really know how anything works for sure.

It takes ages to build, anything over 1s is abhorent.

*Throwback* - YOU READ CODE MORE THAN YOU WRITE IT. Saving 0.5s to use some wanky feature will cost you and your team minutes/hours of mental parse time in the future.

Always be refactorin'.

Past you is an idiot, past you couldn't code for shit. Don't trust past you, you're better than them.

Find productivity bottlenecks and fix them.

MODULARISE.

Write tiny functions.

Decouple as much as possible.

Write wrappers for libraries with bespoke APIs.

Avoid singletons.

Your computer is so fast.

_{If you are writing a physics engine or an fft lib, skip this slide.}

So fast, you have no idea.

Don't write 'fast' code, you're not writing a physics engine.

Use inbuilt functions like .map() and .reduce() over custom for-loops

Your computer isn't that fast.

_{If you are not writing a physics engine or an fft lib, skip this slide.}

Find hot loops and go to town on your code.

Use comments in place of good code.

Really go nuts, best practice is a douche anyway.

Fast is ugly.

Teams matter

The quality of the software is a reflection of the average ability of the team.

Spend time on your juniors.

If you don't have the time, just write really shitty software forever idc.

Start from scratch a lot

Don't copy-paste past projects.

Don't use code generators.

_{( past you is an idiot remember )}

"Gee this all sounds like a lot of effort"

It is.

But it's worth it.