I do find there is a great divide between coding for school, and coding for work (and coding for hobby, fwiw).
I don't code a lot - my degree is in IT, I do occasional database or scripting work to support my work, but I don't code as my primary job. It's just a tool that occasionally I get to dust off. I am pretty bad at it, especially by academic standards.
Academic world - elegance and efficiency count for a lot. Clean, well documented code that executes efficiently... even if it takes you hours upon hours to generate that code.
At the workplace - your getting paid by the hour for results. That doesn't mean that clean, elegant code isn't desired, but there's definitely a tradeoff between the cost to set your butt in a chair and polish code, versus pushing something quickly that just brute force works.
Even outside of code, for all our projects, we have three metrics we use to judge:
First, it has to work. I don't care how efficient it does it, or what it looks like, or anything else. If it can't fulfill the job requirements and specifications, then it fails. This is usually the hardest hurdle to overcome, especially if you are doing something that you can't just buy an off-the-shelf part to accomplish.
Second, it should do so efficiently as possible. Efficiency counts against multiple metrics here: cost, speed, energy, manpower, etc. If two widget makers both complete the same task, but widget A does it twice as fast, or with half the cost, widget A wins the bid.
And finally, it should look pretty. People like pretty things, and two widgets that are otherwise functionally equivalent, the prettier one gets the nod.
Comments
I don't code a lot - my degree is in IT, I do occasional database or scripting work to support my work, but I don't code as my primary job. It's just a tool that occasionally I get to dust off. I am pretty bad at it, especially by academic standards.
Academic world - elegance and efficiency count for a lot. Clean, well documented code that executes efficiently... even if it takes you hours upon hours to generate that code.
At the workplace - your getting paid by the hour for results. That doesn't mean that clean, elegant code isn't desired, but there's definitely a tradeoff between the cost to set your butt in a chair and polish code, versus pushing something quickly that just brute force works.
Even outside of code, for all our projects, we have three metrics we use to judge:
First, it has to work. I don't care how efficient it does it, or what it looks like, or anything else. If it can't fulfill the job requirements and specifications, then it fails. This is usually the hardest hurdle to overcome, especially if you are doing something that you can't just buy an off-the-shelf part to accomplish.
Second, it should do so efficiently as possible. Efficiency counts against multiple metrics here: cost, speed, energy, manpower, etc. If two widget makers both complete the same task, but widget A does it twice as fast, or with half the cost, widget A wins the bid.
And finally, it should look pretty. People like pretty things, and two widgets that are otherwise functionally equivalent, the prettier one gets the nod.