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.
Nicky's been a maker since his grandma bought him his first *real* toolbox when he was 4. His aunt taught him JavaScript when he was 12 and almost 20 years later, he still can't stop programming.
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:
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.
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.
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.
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
buying a good set of over-ear headphones - filtering the outside noise helps a lot
looping "rain sounds" or whatever white noise - works even better on a noise-cancelling headphones
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
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
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
Read books written by really good devs - I see that a couple of people here endorse "Pragmatic programmer ..". Agree 100%. I love that book
Thank you for stopping by! I am a full-stack developer that combines the power of entrepreneurship and programming to make the lives of programmers easier.
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.
How to really do Test Driven Developement
SOLID principles
Continuous testing
Make changes in small batches
How to make code readable and understandable
Hello! My name is Thomas and I'm a nerd. I like tech and gadgets and speculative fiction, and playing around with programming. It's not my day job, but I'm working on making it a side gig :)
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.One little one for JS...
If you want to debug code like this:
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:
Which is also annoying because once it works, you need to remove all that extra syntax.
Instead, you can use a comma, like this:
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 :)
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.
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):
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.
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.
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.
Also changing the theme on preferred text editor when run as root.
In no particular order.
One thing that really improved everything on a project I worked on was promises. As a beginner I kept on piling up
setTimeout
s until the application wouldn't even load.If I knew this beforehand it would've saved me a looooot of time.
Under promise, over deliver.
How to really do Test Driven Developement
SOLID principles
Continuous testing
Make changes in small batches
How to make code readable and understandable
any tips, materials, extraordinary book on #1?
Yeah Test Driven Development by Example, by Kent Beck
Think first, code later.
If you want to learn some new thing about programming, you need to build things with it.
You can have free and updated knowledge in internet, you need to search well.
SQL is beautiful.
I think this post by @pbeekums qualifies:
Abstraction For The Sake Of Abstraction
Beekey Cheung
In the same vein I really recommend Semantic Compression by Casey Muratori.
It really shows you how to effectively refactor code to be better, and is a perfect illustration why it's better to make it work then make it good.
It really does, it's like trying to write perfect code