Archive
Running C#/.NET code from Cloud 9 IDE
I was experimenting with Cloud 9 IDE mainly for remote coding interviews.
I also wanted to see if I could add C# support. C# syntax highlighting was already supported in Cloud 9. Mono is also pre installed in the Cloud 9 Environment.
All I had to do was add a custom runner to use mcs command line compiler for mono.
I am a complete newbie when it comes to ubuntu / bash etc., so please bear with if there are any script issues with the runner.
You can configure a custom runner using this json:
{
"cmd" : [
"bash",
"--login",
"-c",
"mcs '*.cs' -out:'$project_path$project_name.exe' $args;mono '$project_path$project_name.exe' $args"
],
"info" : "Started $project_path$project_name",
"env" : {},
"selector" : "source.cs"
}
What distinguishes a good software engineer from a great one?
I found these from the answers to the quora question – http://www.quora.com/Software-Engineering/What-distinguishes-a-good-software-engineer-from-a-great-one
- Talent. Some people get software design. Most people don’t. The ones that do are naturals. They’ve been doing it since they were very young, they just understand problem solving, expressing solutions in quality code, debugging, large scale architecture design, etc. The best people I’ve met can produce incredible quantities of correct, well-designed code in a staggeringly short amount of time. Very, very few people can do that, and if they don’t have innate feel for it very early on, it’s extremely unlikely they’ll ever develop it.
- Discipline. These days it’s fashionable to talk about productivity, flow, etc., but great people spend 99% of their time doing useful work, and almost no time browsing the web or chatting on AIM. Everyone has ups and downs, but most people mistake lack of discipline for natural productivity fluctuations. There are millions of incredibly talented people that never see the light of day because they’re lazy.
- Experience. Intelligence and talent are not enough – the space of potential mistakes in software development is enormous, and even the smartest people cannot work it all out on their own. Experience builds intuition, and great people make significantly fewer mistakes because they’ve seen them made before.
- Business-awareness. You can also call it product-awareness. Most engineers (especially the really talented ones) tend to waste a huge percentage of their time making improvements to things that won’t make the slightest bit of difference in the grand scheme of things. Great engineers are aware of the fact the company exists for a purpose – they have a feel for what matters and what doesn’t to the customers. They prioritize their time accordingly, and they can work for months without any direction and still produce useful work because they always understand what’s the next most important thing to do for the company.
- Social-awareness. Really great people are capable of cooperating with, leading, mentoring, being led by, and being mentored by other people. They’re not jerks. They’re pleasant to be around, and they understand that proving someone wrong and convincing them that you’re right are two completely different things.
- Able to balance pragmatism and perfectionism – Great programmers have the ability to make both masterful/quick/dirty hacks and elegant/refined/robust solutions, and the wisdom to choose which is appropriate for a given problem. Some lesser programmers seem to lack the extreme attention to detail necessary for some problems. Others are stuck in perfectionist mode.
- Not averse to debugging and bugfixing – Mediocre programmers often fear and loathe debugging, even of their own code. Great programmers seem to dive right and drill down with Churchill-esque tenacity. They might not be happy if if it turns out that the bug is outside their code, but they will find it.
- Healthy skepticism – A good programmer will get a solution that appears to work and call it a day. A great programmer will tend to not trust their own code until they’ve tested it extensively. This also comes up a lot in data analysis and system administration. An average programmer might see a small innocuous-looking discrepancy and ignore it. If a great programmer sees something like that they will suspect it could be a hint of a greater problem, and investigate further. Great programmers tend to do more cross-checking and sanity checking, and in doing so discover subtle bugs.
Compiled from answers of Russel Simmons and Slava Akhmechet
How to Document Wisely
Life is too short to write crap nobody will read; if you write crap, nobody will read it. Therefore a little good documentation is best. Managers often don’t understand this, because even bad documentation gives them a false sense of security that they are not dependent on their programmers. If someone absolutely insists that you write truly useless documentation, say “yes” and quietly begin looking for a better job.
There’s nothing quite as effective as putting an accurate estimate of the amount of time it will take to produce good documentation into an estimate to slacken the demand for documentation. The truth is cold and hard: documentation, like testing, can take many times longer than developing code.
from How to be a Programmer: A short, comprehensive, and personal summary by Robert L Read – http://samizdat.mines.edu/howto/HowToBeAProgrammer.html#id2791115
Sendhil's Cyber Home 