What are the tips or techniques you wish someone had told you ages ago?

We all learn from experience, so what are the tips or techniques you wish you’d discovered earlier?

Comments

[Mario Sommer]

The one thing that transformed the way I write code now the most was when I started to use early returns. In my opinion it makes it so much more readable. That's definitely one thing I wish I discovered earlier.

const myFunc = () => {
  if(nope) return

  // ... actual stuff
}

[Nicky Hajal]

One little one for JS...

If you want to debug code like this:

const filtered = someArray.filter((elm) => elm.tags.includes('someTag'))

And it isn't working, so you want to add a log to see what's going on. But it's a pain because you think you need to build out the entire function body like this:

const filtered = someArray.filter((elm) => {
  console.log(elm.tags);
  return elm.tags.includes('someTag');
})

Which is also annoying because once it works, you need to remove all that extra syntax.

Instead, you can use a comma, like this:

const filtered = someArray.filter((elm) => console.log(elm.tags),elm.tags.includes('someTag'))

JS will evaluate both statements and send the value of the final one.

It's a little thing, but makes my life a little nicer on a daily basis :)

[Fábio André Damas]

I hate to be the smartass who mentions a book but the experience was genuine. I've been working professionally as a software developer for 6 years and recently I picked up "The Pragmatic Programmer" by Andrew Hunt and David Thomas.

I feel like this IS THE BOOK that I wish I had read when I was just starting out. It covers all the basic stuff that I had to learn by banging my head against the wall and more. It's pretty broad in terms of the topics it covers and it never gets too particular. The good news on that front is that it comes with a good bibliography that you can then follow up on.

If you're just starting out READ THIS BOOK. It will save you a lot of time, headaches and make you look amazing in comparison with your fellow juniors.

[Michiel Hendriks]

There are a lot of books out there people should read and absorb (some of) the material. From the top of my head the following books are a must read (take your time):

• The Pragmatic Programmer
• Code Complete 2
• Clean Code

They are universal, present a lot of opinions. It is up to you to pick the parts you want to work with.

School taught me to hate reading books by mandating the kind of books to read. I recall that I used to read quite a bit as a kid, but once school started to mandate reading books it put me off. It put me off to reading books in general. Quite a few years ago I started to read books again, mostly non-fiction. I try to read a few chapters after lunch on Saturday and Sunday. Reading non-fiction books quite often gets me motivated to work on various things.

[Fábio André Damas]

All of those are on my "reading list" so I think I've chosen wisely (I'm assuming you mean Clean Code by Robert C Martin and not Clear Code).

I have the same experience reading these general purpose coding books. It fills me with motivation to try new stuff and when you see how much better you can get everyday by just applying some new techniques you've read about, it really motivates you to keep going.

[Cy Chainey]

Change the text editor theme when you read someone else’s or your own old code.
It makes it stand out more and forces you to focus.

[Vincent Guarnaccia]

Also changing the theme on preferred text editor when run as root.

[Ted Hagos]

1. schedule a time for coding - a long time ago, I thought I could code whenever time allows (like found time or small downtimes), it doesn't work for me. What work is if I set aside time, and simply allow myself to think about the coding work and eventually doing it
2. buying a good set of over-ear headphones - filtering the outside noise helps a lot
3. looping "rain sounds" or whatever white noise - works even better on a noise-cancelling headphones
4. realizing that there isn't a "one editor to rule them all". I thought I could use Vim for all coding/editing/writing tasks; as it turns out I can, but not very well on all tasks. On editing config files and writing asciidoc, it went swimmingly, but when building a sizable Android or Java project, I'm better off with an IDE
5. that when you drink lots of caffeine in a day, you should drink more water - more caffeine means more pee; and when you lose water it does wonky things to your brain, that'll cramp your coding. Drink lots of water
6. running or walking (or any form of exercise) - not only does this shrink the belt size, as it turns out, it improves your brain too. You improve your brain, you improve your coding. brainrules.net/the-rules
7. Read books written by really good devs - I see that a couple of people here endorse "Pragmatic programmer ..". Agree 100%. I love that book

[Debashis Dip]

In no particular order.

• Read the documentation before jumping into copying someone elses code.
• Add comments to the code for the future version of yourself.
• Don't be afraid to take a peek at library/framework source code.
• Testing is awesome, you should do it more.
• Commit frequently.
• You don't need to make the code scalable for 10m users when the maximum user base is only 10k
• Do not install beta version of some OS in the main development machine
• Take a full backup of your machine once in a while
• It's ok to not write codes like a ninja dev, If it works well and does the job as required then let it be
• Readability > Shortcuts

[Sergiu Mureşan]

One thing that really improved everything on a project I worked on was promises. As a beginner I kept on piling up setTimeouts until the application wouldn't even load.

If I knew this beforehand it would've saved me a looooot of time.

[Philip Hallstrom]

Under promise, over deliver.

[Michael Larson]

How to really do Test Driven Developement
SOLID principles
Continuous testing
Make changes in small batches
How to make code readable and understandable

[Beeblebrox]

any tips, materials, extraordinary book on #1?

[Michael Larson]

Yeah Test Driven Development by Example, by Kent Beck

[Daniel Starner]

Think first, code later.