Much like football is not just about kicking the ball, programming is not just about writing code. Below I've summarized six things I've learned over the last ten years as a professional programmer that will help you become a better developer not just in terms of the code you write but all around.
1. Make. Yourself. Comfortable.
I can't stress this enough. Don't suffer in silence. Or, you know, loudly. Make it your number one priority to stay focused when programming.
Your job is hard. And it is demanding. And there's only so much willpower you can muster each day (and you can only really replenish it by sleeping). Don't allow yourself to be frustrated by things you can fix.
If your build process takes too long, make it a priority to fix that. Use Google! Ask on Stack Overflow. Use Travis or CircleCI to make it trivial to deploy your app. Deploy to Heroku. Make your life easier.
And last but not least - you spend a lot of time sitting. So get a good chair. No, wait, scratch that. Get a great chair! I can recommend Spinalis Hacker - this chair fixed my lower back problems. True story.
2. Learn to stay calm
Seriously. Just calm down. You're writing a web app. People are not going to die if you don't fix it within the next fifteen minutes. All your restless leg syndrome and quiet "fuck fuck fuck" muttering does is stress out your colleagues. Breathe deep.
There's more to life than coding. Make sure you get some perspective. Read books. Travel. Travel anywhere. Travel to a developing country and have a chat with someone who lives on $5 a day. Have a baby. Go skydiving. Anything.
Be passionate about what you do - you should be because, well, programming rocks! - but don't get all OCD about it. It's a marathon, not a sprint.
Or, as Goethe put it: die ganze Arbeit ist Ruhig sein (all the effort consists of staying calm).
3. Read Out of the Tar Pit
This paper is pure gold. Get it here: http://shaffner.us/cs/papers/tarpit.pdf . Then go brew yourself a big mug of tea, sit down and read. And re-read. And then think about how you program and how you deal with state.
4. Learn functional programming techniques
You don't need to drop everything and start using Clojure or Haskell. FP is not a silver bullet; nothing is, really. But what FP will do for you is it will teach you to reason about state and that explicit is usually better than implicit. And that there is beauty in pure functions. And that in most cases, immutable is better than mutable.
Let's face it - web development is kinda like shovelling dirt. You get a bunch of data and you move it around (plus you map it to a different representation that works better for your problem domain). Learn to use
reduce. Check out lodash, you will most likely want to use it. That said, don't be too cryptic - the goal is to use FP techniques to make your code clear and easier to follow. So don't overdo it. Especially with
reduce which is usually the trickiest to understand.
5. Learn to manage code debt
There's nothing wrong with code debt. Yeah, I said it. You see, code debt is pretty much like any other debt - you can use it to your advantage or you can ignore it till it crushes you. You accrue code debt when you need to take a shortcut and move faster than you normally would (for which there are often very much legit reasons). And then eventually you have to slow down and pay back what you've borrowed.
When code debt becomes problematic is when it's not managed. Either because you don't know about it (which is arguably the worst case) or because you were sitting on it for too long and now all you can do is pay the interest. And put in extra time to cut down the debt on top of that.
Every coding project has code debt. It's a fact of programming life. And there's nothing wrong with that. Just be aware of it and do your best to keep it in check.
Incidentally, this is one area where you can really tell apart senior and junior developers. The former are better at judging and managing code debt. It's one of the things that only comes with experience.
6. Use Typescript
That said, Typescript is not perfect; the types are only as good as you - or whoever wrote the definition file you're using - make them and it's just too easy to use the
any type (which is essentially telling the compiler to give up). And - at least till Typescript 2.0 - all types are implicitly nullable (yuck!). But anything that helps us write code with less errors counts.
If you have any thoughts, please do leave a comment. I hope you liked my tips and - enjoy coding, guys! It's a great craft.