One major difference between the open-source zealots on some other sites, and the open-source advocates here seems to be one of employability. In other views of open-source software, all software should be free - and often that means that programmers should not be paid for programming, but for everything around programming (services). That's a fine view, but as a person being paid to develop software, it's one that my family's mouths find hard to swallow (pun not fully intended).
Here, we like our software free, but we like our efforts to be paid, too. The bottom line is getting the job done, and we have a multi-purpose software tool which we like using to get that job done. Some people may get a bit religious about whether that tool is "perl", "Perl", or "PERL", but a rose by any other name would still have just as many oddities.
It's not that the perl community seems to be averse to open source, or to commercial source. As long as we get to finish our jobs, look like superstars (sitting on the shoulders of giants), get paid, and go home to spend time doing what we really want, we're happy. Too often, that still seems to be programming in perl, but hey, off the clock, it's whatever you like.
So, in the spirit of this employability, I offer:
Key things to keep in mind when working for others.
One of my many duties is to bring junior members of the team up to speed. Junior here can involve temporary employees (contractors), intern students (whether 4 month, 8 month, or 16 month terms), new graduates, other new hires, or even simply members of the team who have not been on the team as long as I have. So I get asked for a lot of advice. Some of the advice is specific to our company, and thus is probably of very little interest to a wider audience. However, much of it is likely just as applicable to PerlMonks who are in those junior positions wondering what they need to do to get ahead.
Performance. Your boss wants to look like his/her team is ahead of the curve. You want to look like you're ahead of the curve, too. Even if you are the hardest person in the company to talk to, if you consistantly get what needs to be done faster, cheaper, and more reliably than anyone else, you'll be invaluable.
My personal method of accomplishing this means that I only do things twice: the first time to learn it, the second time to teach the computer to do it for me, and after that, I should never need to do it again.
This also ties in closely to using the right tool for the job - in my work, that's usually perl, but sometimes it's shell scripting.
Note that this actually has very little to do with the performance of your code, unless your job explicitly is "to improve the performance of the code." And note that jobs are rarely going to say "to write ultra-fast code", but "to improve the performance of existing code." In other words - "It works, now speed it up." So focus on your actual job, getting actual requirements accomplished, before you worry about things outside of the scope of your job. That is the core of the performance your boss wants. The goal here is to get everything your boss wants so that you have time to get what you want. Many bosses will be happy to see you expand your role, as long as it isn't at the expense of the role you started out with.
Theoretically, in a positive company, high performance equals regular (and larger than average) raises. It's all about the money.
The next biggest thing is communication. This is primarily dealing in the language of the community you're in. At PerlMonks, that means English. At work, that may mean English still, or it may mean another language. You need to express your ideas in a way that others can interpret to mean what you are trying to convey. Simply - say it properly, so that I get what you mean. That said, if you say something improperly but the person you're talking to understands you anyway, communication still has been acheived. If, however, you make the listener work to figure out what you mean, they're not going to stick around any more than they have to to get their work done - possibly even less.
Grammar is important. Spelling, too - so much communication is done via email nowadays that you can't get around it. Relying on a spellcheck may work, but it is slow. It's much better to be able to get spelling right without the spellcheck (see "performance" above). I'm not trying to advocate purism in language - just communication. The odd spelling mistake (or typo) or grammatical error is not an impediment to communication. A complete lack of punctuation, proper capitalisation, and l33t sp33k - these are show-stoppers for communication.
In my experience coding, debugging is more important than coding. Anyone with a mail-in degree can write code. Getting it to work right, and understanding why it works right, are the difficult parts. This plays into the performance requirement above - you need to be able to get working, reliable code out quickly. And if you're stuck for a day or two trying to figure out why one ten-line sub isn't working, your performance as a whole is going to suffer.
If you have a star debugger on your team, ask him/her for tips. Don't think that they will treat you badly and thus be scared to open up your weakness in debugging to them. They'll be happy to teach this skill, as long as you're a willing and honest student. Why? Because it will help their performance in that they won't need to help you debug every other problem you encounter. It's still about the money - for you and for them. They aren't doing it for your money - they're doing it for their money. But that's ok. (Also in this, you need to be able to communicate with this person where your problems lie so they can help you.)
These are some of the more obvious work-related issues I've seen with new hires where I work. Anyone have some other key points to add?