Personal skills
How to stay motivated
It is a wonderful and surprising fact that programmers are highly motivated by the desire to create artifacts that are beautiful, useful, or nifty. This desire is not unique to programmers nor universal but it is so strong and common among programmers that it separates them from others in other roles.
This has practical and important consequences. If programmers are asked to do something that is not beautiful, useful, or nifty, they will have low morale. There’s a lot of money to be made doing ugly, stupid, and boring stuff; but in the end, fun will make the most money for the company.
Obviously, there are entire industries organized around motivational techniques some of which apply here. The things that are specific to programming that I can identify are:
Use the best language for the job.
Look for opportunities to apply new techniques, languages, and technologies.
Try to either learn or teach something, however small, in each project.
Finally, if possible, measure the impact of your work in terms of something that will be personally motivating. For example, when fixing bugs, counting the number of bugs that I have fixed is not at all motivational to me, because it is independent of the number that may still exist, and is also affects the total value I’m adding to my company’s customers in only the smallest possible way. Relating each bug to a happy customer, however, is personally motivating to me.
How to be widely trusted
To be trusted you must be trustworthy. You must also be visible. If know one knows about you, no trust will be invested in you. With those close to you, such as your teammates, this should not be an issue. You establish trust by being responsive and informative to those outside your department or team. Occasionally someone will abuse this trust, and ask for unreasonable favors. Don’t be afraid of this, just explain
what you would have to give up doing to perform the favor.
Don’t pretend to know something that you don’t. With people that are not teammates, you may have to make a clear distinction between “not knowing right off the top of my head” and “not being able to figure it out, ever.”
How to tradeoff time vs. space
You can be a good programmer without going to college, but you can’t be a good intermediate programmer without knowing basic computational complexity theory. You don’t need to know “big O” notation, but I personally think you should be able to understand the difference between “constant-time”,”n log n” and “n squared”. You might be able to intuit how to tradeoff time against space without this knowledge, but in its absence you will not have a firm basis for communicating with your colleagues.
In designing or understanding an algorithm, the amount of time it takes to run is sometimes a function of the size of the input. When that is true, we can say an algorithm’s worst/expected/best-case running time is “n log n” if it is proportional to the size ($n$) times the logarithm of the size. The notation and way of speaking can be also be applied to the space taken up by a data structure.
To me, computational complexity theory is beautiful and as profound as physics-and a little bit goes a long way!
Time (processor cycles) and space (memory) can be traded off against each other. Engineering is about compromise, and this is a fine example. It is not always systematic.
(1 votes, average: 5.00 out of 5)