|
in german language "Toll Ein Anderes Machts"
Press F1 for help or google it.
Greetings from Germany
|
|
|
|
|
I can't believe this one came in last. I've seen so many people who were great at the other qualities but couldn't work together with anyone. They were much less effective than the could have been. Give me a good team player and the team can help with the rest. Of course they need competence in the other skills, enough to get hired as a developer/programmer in the first place.
|
|
|
|
|
INTEGRITY - 6 (at least)
All the choices & additional suggestions are important, but this is above critical
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Agreed, although in a 40 year career I've only encountered one person who lacked it. About four years ago I inherited the code for a critical component in one of our products.
The original author was an asshat to deal with. If he didn't like you, or thought the group you worked in was incompetent (my case), he would you over. Several times when I dealt with him he lied, misdirected, or otherwise refused to answer your question. He maintained a mythos surrounding his product that the code was complex and its performance required only certain people (namely himself) work on it. Activity on his product died down and the company needed folks on another project to which he was eventually assigned. He spent several months making no contributions at all. When confronted about it, he retired with zero notice. After a succession of other folks were handed his stuff (none of whom made any changes), it landed in my lap.
I've spent four years now responsible for this stuff. During that time I've diagnosed a number of issues, and made one actual significant change, replacing support for some hardware that had obsolesced. During that time I made an observation about his code: The code was deliberately written so that only one person could maintain it: the original author. Names were minimal in length, based on undocumented acronyms, and tended to obfuscate their actual use. There were global types and variables with single, lower-case character names. Source file names did not reflect their content. Header files were not used for shared, common definitions, but were arbitrarily present for other purposes.
A few months ago someone had the bright idea of making a fundamental change to this product, adding a major new feature. I spent a week writing a 'review' of the code, based largely on the over 4,000 compiler errors and warnings when the code was compiled using standard settings on the compiler. The 10 page document listed any number of areas that said "if this feature is exercised, the product will crash". Fortunately the bright idea folks found something new and shiny and went away.
Software Zen: delete this;
|
|
|
|
|
In a career of about 35 years, I've run across a few toxic people, but this takes the prize!
I must admit to preferring to work on a project by myself, but I always write both specifications and code as clearly as possible. This is both a matter of pride in good work, and because at least one other developer (often myself, six months down the line...) will need to read my code. I have never refused to perform a code or a specifications review upon request. In fact, I will often request that the one other extremely experienced member of our team do a review with me of critical code.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
I've found there's an informal code of conduct in our industry: Screw over sales, marketing, competitors, even primaries when you're a subcontractor, but never, ever screw over your coworkers. This guy did that with malice aforethought.
Software Zen: delete this;
|
|
|
|
|
Or does that come under "A solid grasp of programming theory and computer science"?
|
|
|
|
|
Working on a team has nothing to do with programming.
|
|
|
|
|
If working on non-solo projects, working with a team has everything to do with programming. In these situations code does not often exist in its own universe, and the ability to cooperate with others is important.
|
|
|
|
|
True, if the software you develop is for your use, and yours alone.
If you develop software for anyone else, your employer or outside customers, then you must have basic skills to interact with others in a professional manner. "Working on a team" simply refers to your ability to function in that environment.
I've interviewed a number of seemingly brilliant developers and recommended against hiring them because they obviously couldn't function in a group.
Software Zen: delete this;
|
|
|
|
|
...provides a solid grasp of programming theory and computer science and teaches you that the path to state-of-the-art IS the ability to name variables/functions/classes/etc clearly and unambiguously (accurately I would say). Anything else is doomed to fail sooner or later.
|
|
|
|
|
Some items that should've been included, in no particular order:
1) People skills - how to actually communicate in English with non-engineers
2) How to actually debug a problem - I've been pretty surprised how many engineers I've met who were completely unable to debug an issue
3) Learning how to find resources to solve a problem - aka Google, StackOverflow, etc.
4) Writing documentation - yes I know this is a 4-letter word in some parts but this is an important skill.
"Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd all be running around in darkened rooms, munching magic pills and listening to repetitive electronic music."
-- Marcus Brigstocke, British Comedian
|
|
|
|
|
Yes, this is pretty close to what I would have added, but also
5) Good progress toward thorough understanding of the language and keeping up with the updates for it.
|
|
|
|
|
Junior programmers that hack away at code because they want to prove they "know their stuff."
|
|
|
|
|
Just saying....
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
|
|
|
|
|
Noooooooooooooo!
|
|
|
|
|
For far too many knowing those three key combinations represents the extent of their skills. Just saying...
Software Zen: delete this;
|
|
|
|
|
just saying...
(Or other important tools)
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
|
Quote: Ability to read the minds of clients and managers
|
|
|
|
|
In my experience, the users only work for the client. The client usually has little idea what the users really need and how they will use and abuse the system. They think they know and are the ones paying the bills, but then once the system is delivered, they complain that their creation is hard for the users to work with.
__________________
Lord, grant me the serenity to accept that there are some things I just can’t keep up with, the determination to keep up with the things I must keep up with, and the wisdom to find a good RSS feed from someone who keeps up with what I’d like to, but just don’t have the damn bandwidth to handle right now.
© 2009, Rex Hammock
|
|
|
|
|
Yeah, no matter how sure you are that your ui makes sense, nobody can %^&$ stuff up like a normal using your creation!
|
|
|
|
|
Spot on! It's always a challenging cycle. If you build a foolproof system, they'll build a better fool.
|
|
|
|
|
My wife is anything but stupid, but I always try out UIs on her. She has an amazing ability to find the one wrong combination of keystrokes that I haven't anticipated and/or protected against.
|
|
|
|
|
I forget who originally said this, but only a highly intelligent person can behave really stupidly.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|