4 Answers
A random list off the top of my head:
Always assume that your code has bugs in it somewhere. (This is just good general soft. eng. practice.) This means: Be good at testing; aim for total test coverage, get your code under continuous integration as early as you can. Unit tests aren't enough; you want functional tests, fuzz tests, performance tests, stress tests. Get as much test automation as possible, then add whatever human-powered QA you can get.
Security: Understand that many modern attacks have far less to do with a user owning your system than they do with users owning each others' accounts. Even though you're backend, you still have to know and worry about some of the stranger frontend attacks. For example, if you don't know about Cross-Site Request Forgery attacks on web forms, you'll never think to block them with tokens. Also, validation beats sanitisation, but only if everyone on your team is doing it the right way.
Remember when architecting your system that many of your users will not be English-speaking heteronormative Westerners. I'm not just talking about languages, character sets and locales (but if you can accomodate those properly, you're already off to a great start). I'm talking about things like marriage ( http://qntm.org/gay ), gender ( http://www.sarahmei.com/b
The performance of a single request is far more important than you might think. You don't measure that as an average number, you measure it as a curve. Knocking 100ms off the site's front page is usually far more valuable than knocking 1s off a page deeper in.
Instrument and monitor as much as possible about your systems and apps. Then make sure that this ton of data is filtered through to humans in a way that is actually useful, that gets looked at, and raises as few false alarms as possible. Then work out how much user-identifiable data you can throw away ( https://www.eff.org/wp/os
The more aware you are of the full application stack, the better an engineer you'll be. This means everything from the user's brain down to the byte, packet and disk head level. It doesn't mean you have to know all this at expert level, just be aware of it. It does mean constantly learning about what's possible at the front end, and what the OS, database and caches are doing. (Related: Caches are great until they seriously screw you. Know how many caches you need, how many may be outside your control, how to deal with them and why you have them in the first place.) Knowledge of the full stack means the stuff outside of writing code - such as architecture and debugging - has far more options than surprises. Sometimes you can spend six months on making your backend architecture faster, or ten minutes on the frontend UI, with the same effective result.
There is no such thing as "self-documenting code"; at least, nothing more than five lines long. Anyone who claims otherwise is a liability. If you want to win favour from your colleagues, turn out the kind of documentation you'd want from them. Make sure that they're singing your praises after the system goes bang while you're on a plane. Or, as a wise person once said: Code and document as if your system will be inherited by an axe-wielding psychopath who knows where you live.
Debugging tools are there for a reason. So is Google. Get good with both and they will save you hours of staring at the same few lines of code or config. It's not about how much you know, it's about how much you know that you don't know, so that you can spot when you need it and go read up rather than drive straight into a hole. But when it comes to debugging overall, there really is no substitute for experience. Whenever someone on your team is wrestling a difficult problem, learn from it.
Never stay wedded to one set of technologies, nor jump onto the new new thing without having a good understanding of its weaknesses, immaturities and how it's going to handle a Slashdotting or a disk crash.
Never stop learning, or believing that your skills and practices can improve.
Always assume that your code has bugs in it somewhere. (This is just good general soft. eng. practice.) This means: Be good at testing; aim for total test coverage, get your code under continuous integration as early as you can. Unit tests aren't enough; you want functional tests, fuzz tests, performance tests, stress tests. Get as much test automation as possible, then add whatever human-powered QA you can get.
Security: Understand that many modern attacks have far less to do with a user owning your system than they do with users owning each others' accounts. Even though you're backend, you still have to know and worry about some of the stranger frontend attacks. For example, if you don't know about Cross-Site Request Forgery attacks on web forms, you'll never think to block them with tokens. Also, validation beats sanitisation, but only if everyone on your team is doing it the right way.
Remember when architecting your system that many of your users will not be English-speaking heteronormative Westerners. I'm not just talking about languages, character sets and locales (but if you can accomodate those properly, you're already off to a great start). I'm talking about things like marriage ( http://qntm.org/gay ), gender ( http://www.sarahmei.com/b
The performance of a single request is far more important than you might think. You don't measure that as an average number, you measure it as a curve. Knocking 100ms off the site's front page is usually far more valuable than knocking 1s off a page deeper in.
Instrument and monitor as much as possible about your systems and apps. Then make sure that this ton of data is filtered through to humans in a way that is actually useful, that gets looked at, and raises as few false alarms as possible. Then work out how much user-identifiable data you can throw away ( https://www.eff.org/wp/os
The more aware you are of the full application stack, the better an engineer you'll be. This means everything from the user's brain down to the byte, packet and disk head level. It doesn't mean you have to know all this at expert level, just be aware of it. It does mean constantly learning about what's possible at the front end, and what the OS, database and caches are doing. (Related: Caches are great until they seriously screw you. Know how many caches you need, how many may be outside your control, how to deal with them and why you have them in the first place.) Knowledge of the full stack means the stuff outside of writing code - such as architecture and debugging - has far more options than surprises. Sometimes you can spend six months on making your backend architecture faster, or ten minutes on the frontend UI, with the same effective result.
There is no such thing as "self-documenting code"; at least, nothing more than five lines long. Anyone who claims otherwise is a liability. If you want to win favour from your colleagues, turn out the kind of documentation you'd want from them. Make sure that they're singing your praises after the system goes bang while you're on a plane. Or, as a wise person once said: Code and document as if your system will be inherited by an axe-wielding psychopath who knows where you live.
Debugging tools are there for a reason. So is Google. Get good with both and they will save you hours of staring at the same few lines of code or config. It's not about how much you know, it's about how much you know that you don't know, so that you can spot when you need it and go read up rather than drive straight into a hole. But when it comes to debugging overall, there really is no substitute for experience. Whenever someone on your team is wrestling a difficult problem, learn from it.
Never stay wedded to one set of technologies, nor jump onto the new new thing without having a good understanding of its weaknesses, immaturities and how it's going to handle a Slashdotting or a disk crash.
Never stop learning, or believing that your skills and practices can improve.
Wow, that's a tough question. I've been focused on back-end server processes for most of my adult life, and I still worry that I secretly suck (and that people are just too polite to say anything).
School is certainly not the answer. By the time you reach adulthood all the stuff they taught you in school is basically obsolete. The approach and technique that you learn in school is good, you might be able to carry that for most of your life. But you can pick up coding techniques from a book. You don't need to freeze through a Massachusetts winter just to learn memory management.
It's the love and the passion for back-end engineering that will make you good. If you carry that around with you, and expose yourself to other engineers with similar passion, your goodness with ferment like a fine wine. You will eventually have a beautiful bouquet and a strong tannin (which is "an astringent, bitter plant polyphenolic compound" by the way).
School is certainly not the answer. By the time you reach adulthood all the stuff they taught you in school is basically obsolete. The approach and technique that you learn in school is good, you might be able to carry that for most of your life. But you can pick up coding techniques from a book. You don't need to freeze through a Massachusetts winter just to learn memory management.
It's the love and the passion for back-end engineering that will make you good. If you carry that around with you, and expose yourself to other engineers with similar passion, your goodness with ferment like a fine wine. You will eventually have a beautiful bouquet and a strong tannin (which is "an astringent, bitter plant polyphenolic compound" by the way).
Being a backend engineer means thinking one step ahead of the frontend and product folks, anticipating their every move and thought. You should be living, sleeping, and breathing frontend and product until you're so good that you can figure out what they need next and give it to them before they ask.
You need to have good knowledge of the database brandscape, sure, and learn your bash or it'll teach you some painful lessons.
In response to this question, a lot of people will try to sell you trash like "understand scalability". Ignore them. Turn your back and get those pseudo-intellectuals out of your life for good. "Scalability" is a modern term for what we used to call "doing your job" back in the day. Any backend engineer worth his (or HER) salt can deal with scalability when the rubber meets the road.
You need to have good knowledge of the database brandscape, sure, and learn your bash or it'll teach you some painful lessons.
In response to this question, a lot of people will try to sell you trash like "understand scalability". Ignore them. Turn your back and get those pseudo-intellectuals out of your life for good. "Scalability" is a modern term for what we used to call "doing your job" back in the day. Any backend engineer worth his (or HER) salt can deal with scalability when the rubber meets the road.
