Guest post by “In order to be an effective programmer, you need to possess a combination of traits that allow your skill, experience, and knowledge to produce working code. There are some technically skilled developers who will never be effective because they lack the other traits needed. Here are seven traits that are necessary to become a great programmer.”
I’d never trust a person writing about XAML, WPF and MSDN forums.
You got modded up, but the article’s first point takes your attitude into account:
Whatever the merits of the technology, you’ll still do well to learn the basics of it before it’s needed.
You included MSDN in your list, but look at what the article actually says about MSDN:
Edited 2013-05-06 06:30 UTC
You should not take seriously the jokes we all do against MS technology
The thing is that they are rarely funny.
This is a funny microsoft joke: http://www.youtube.com/watch?v=UC4vz6IbdtY
Need a 5th season!
This year I heard.
Yesterday I read there will be one special episode (40 minute one).
But the best skills are still laziness, and a natural lack of trust in your tool (well they rarely lie, but they mostly tell you only half the truth).
Agree laziness is the number one trait. And to combat doing to much work, write tools/scripts to automate. Then write your code and use your tools to test your code.
While I do agree in having a reasonable doubt on the reliability of the tools, I totally disagree with laziness.
I really don’t see how laziness can lead to good programming techniques: keeping things concise, simple and efficient requires actually a great deal of dedication.
Maybe you refer on the quotes of Bill Gates saying that laziness was his best quality as a programmer… well, I’d take it as more as a friedly chitchat than as a serious advice.
What it means, is you hate repeating stuff over and over. You are “lazy” and therefore program something to do it for you. (IMHO this is the number one trait in a good programmer)
For example if i want to change 10 lines of text in a file, i wont open a text editor and use the keyboard to manually do the repetitive task. I will use a regular expression and sed in a one line script to do it for me.
That isn’t laziness that is being pro-active / constructive.
Edited 2013-05-06 12:11 UTC
Reducing your workload is a form of laziness.
ERRR NO.
Simply not doing work is lazy. Picking efficient ways to do work that you are actually doing is not lazy.
It’s just semantics. Geneticists call themselves lazy for the same reason. The idea is to work smarter rather than harder, and avoiding hard work is the essence of laziness.
There’s probably a dialect issue here as well, because I know “lazy” has historically had much worse connotations than it does today. (At least in my region and age group, in yours it may have retained those implications.)
And the person doing it manually for 10 lines will be done faster. The trick is to know when it is worth the time to automate and when it isn’t.
We are talking about being a programmer here. Not the fastest… if you think a bit about there are additional benefits to doing it programatically.
And to let you know, after being “lazy” all these years, i probably could write the script to modify these lines in similar time to doing it manually.
Try Larry Wall, Bill Gates isn’t all that quotable as a programmer in my opinion.
http://c2.com/cgi/wiki?LazinessImpatienceHubris
Sorry but I can’t take anything seriously said by the guy that created perl.
And I can’t take people seriously who fall back on lame Perl-bashing.
How is it lame? The language makes programs that aren’t maintainable.
Edited 2013-05-08 07:07 UTC
>How is it lame? The language makes programs that aren’t maintainable.
It’s lame. You made a sentence that makes no goddamn sense, so we should blame English?
Programmers are writing bad code, just some languages give them more rope to hang themselves.
I’ll admit that Perl has some idioms that can be more easily abused than the idioms of other languages, but it’s otherwise a perfectly fine programming language. You can write spaghetti in any language, even statically-typed OO languages (in those languages, we call that kind of spaghetti “enterprise frameworks”).
no 8 – Acceptance that you might be wrong
no 9 – Acceptance that you might get the solution wrong first time and can make a better hash of it second time around.
No 10 – Be willing to say ‘No’ to increasing demands.
The last one is really hard for a lot of people. In some societies saying no is akin to losing face and is generally not accepted very well. This is IMHO rather sad because it can relieve the stress on the programmer.
{I’ve been writing software since the days of Punched Cards and Paper Tape and am looking forward to the days when I can retire my paper tape repair kit once and for all}
Your suggested 8 & 9 are already there and is numbered #5.
Managing expectations is a little more than saying “no”. I normally tell management a rough estimate of time and what other tasks I have in my queue and I let them make the call.
Reminds me of the test I had to take to enter the top development team at my university.
Each student was given a computer with Internet connection and the JDK installed.
In two hours solve 36 problems about math, physics and Java programming: use ALL the tools you need to get the test done.
I found myself going through WolframAlpha, StackOverflow and obviously Google and many others, and then compile and run like crazy.
Best course I’ve ever taken.
Edited 2013-05-06 07:23 UTC
StackOverflow … no thanks … you usually get the boring standard answer to a programming problem that is the lowest common denominator….
Elistism much?
Stack overflow is quite a good way of solving a lot of common problems that you come up against everyday.
Also solving problems in the “boring” way is probably the better way to do it.
Michael Jackson said in his 1975 Principles of Program Design:
There is nothing wrong with the “lowest common denominator” when that is all that you need.
This coming from some one who put down Perl as a programming language… pot, kettle, black?
This artigle is good, except it’s too narrow on what it says it applies to. Those traits apply well to any good scientist or engineer.
I am disappointed but not remotely surprised the article failed to mention the most important trait of all:
0. Willingness and ability to learn, understand and think about your users’ problem domains firsthand.
I am no great technical programmer, but one thing I do make a point of doing is to sit down with users and learn about them and their jobs: what they do, what they know, how they think, and what their duties, liabilities, concerns and desires are. While I could never do their work anywhere near as well or fast as they could, I consider it my basic responsibility to know enough about their work that I could muddle by at least at intern level and communicate with them in their own language. “Stepping into their shoes and walking around in them,” as a wise, if fictional, commentator once put it.
Once I can think about users’ problems as if they were my own, I can apply my own analytical and coding skills to creating solutions that they couldn’t produce themselves. But just because that’s my own area of expertize doesn’t make theirs any less important or less deserving of attention or respect. If anything, it’s the opposite: they are the ones who actually make things and do things; my job is merely to facilitate that.
So it shocks me how many professional developers seem content to sit at their desks all day every day, churning out code with no personal understanding of how that code will integrate into users’ lives. I appreciate that management cultures obssessed with internal politicking and buck-passing tend to create isolationist silos that confound such communication and collaboration, but a lot of developers seem to embrace the arrangement. These professional “problem solvers” and “solution builders” would rather live their whole life in some self-imposed Skinner Box, never touching the world outside. Sitting with users (“lusers”) is often seen as a menial, dirty task and quite beneath them: the responsibility of BAs, QAs, managers; anyone but themselves.
These same programmers get upset and angry when end-users complain that their provided ‘solutions’ fail to address the problems they actually have. Yet they are as much the architects of their own failure as anyone. A coder who only knows how to code is about as much use as a manager who only knows how to manage. The former [rightly] aren’t shy about criticizing the failings of the latter when they are the ones on the receiving end, but perhaps they should perform the same analysis on themselves sometime.
Amen, I could not agree more. This is one area that really pays off.
The situations I’ve encountered most are either a vague, ambiguous description of what is needed, or a hacked-together requirements doc that is over-detailed in some areas but glosses over others.
If you sit down with the user to see what they are trying to do, you get a sense of their workflow, interruptions and frustrations. The details matter. (It is shocking how saving a mouse-click or two can turn “I hate it” into “I love it”.)
This is also where thinking about the future comes in. Eventually you develop a “Spidey Sense” about how the program/process might evolve in the future, where you can save almost total rewrites (or a horrible mess) down the road if you put a little extra design/work in at the start.
What depresses me beyond belief is that your comment and mine are the only ones on either OSAlert or TechRepublic that even acknowledge the existence of a world outside The Team, never mind advocate actually interacting directly with anyone in it.
There is something terribly wrong in a mainstream programmer culture that sees the program as Everything: The End In Itself. But the program itself is nothing; it is merely a means to an end. The only thing that gives a program any purpose or value whatsoever is the people who use it.
Nope, it’s just that management team tend to enforce isolationism of said sector. I’m a coder but I like to know how is used my code, how to improve it considering its usage, the limits of the specifications given to be coded. As an embedded coder I learned electronics to have a better symbiosis with the software I develop.
In one of my previous firm I worked for, I was in close partnership with the hotline to solve users’ issues with our applications. I was bullied to keep my dedicated place and shut up. The management team thoughts they knew more about users’ expectations and finally screwed everything over.
“Divide and conquer…”
Kochise
Being pragmatic is very important. Earlier in my career I wanted to do everything the “perfect way” or follow the “true path”.
Now I want to get the job done well and as simply as possible, sometimes it is living with a hack until the system get scrapped and replaced.
The most important thing is follow thr
1. Makes effective use of acronyms. For example, A.A.A.A. – All Acronyms Are Awful.
2. Generates high-quality design documentation, preferable after the product is delivered to the customer.
3. Maintains proper familiarity with the C.M.M.I model, and generates artifacts demonstrating processes in increasing compliance to desired C.M.M.I. level. Considers this a much higher priority than actually performing said processes.
4. Diligent in completing time-tracking data that mimics supervisors requested charges. Does not allow actual tasks performed to interfere with this process.
5. Adept at task switching. For example, switching from Facebook to Eclipse in less than 1 second.
6. Amicable to team members, especially the team leader / project manager. Always smiles and nods at management requests, without letting these requests harms the quality of the end product.
7. Includes helpful, detailed comments in code artifacts. For example, properly documents un-sanitized code from new, billable team members “provided” by management:
“/* Be sure to add header file, will_compile_and_run_when_hell_freezes_over.h */^aEUR.