Things I Learnt The Hard Way - Take Responsibility For The Use Of Your Code
This is hard. Very very hard. It's the difference between "freedom" and "responsibility".
This is hard. Very very hard. It's the difference between "freedom" and "responsibility".
I've seen a lot of systems that would never run on a isolated computer, like the developer tool, 'cause the system requires running on a specialized environment. Those things are wrong.
Sometimes, you'll have to say no: No, I can't do it; no, it can't be made in this time; no, I don't feel capable of doing this; no, I don't feel comfortable writing this.
Learn when you can't code anymore.
If you know a lot about one single language, it may make it easier to get a job, but in the long run, language usage dies or loses its charms and you'll need to find something else. Knowing a bit about a lot of other languages helps in the long run, not to mention that may help you think of better solutions.
If it took you more than one hour for you to figure out what went wrong, it is a good idea to put it on list, 'cause these things have the tendency to appear again.
You know what's one of the worst function names ever? sleep()
.
Sleep for how long? It is seconds or milliseconds?
Think how the data you're collecting from your users will be used -- this is more prevalent on these days, where "privacy" is a premium.
One thing a team may decide to fix the continuous flux of code style comments in a code review is to use a code formatting tool to auto-format the code. That's ok, but they should never rely on it.
When doing code reviews, do not focus on style; focus on design things that look a bit weird.