Linked by MOS6510 on Sun 5th May 2013 22:43 UTC
General Development "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."
Order by: Score:
Comment by strim
by strim on Mon 6th May 2013 00:00 UTC
strim
Member since:
2008-07-01

I'd never trust a person writing about XAML, WPF and MSDN forums.

Reply Score: 6

RE: Comment by strim
by kwan_e on Mon 6th May 2013 06:28 UTC in reply to "Comment by strim"
kwan_e Member since:
2007-02-18

You got modded up, but the article's first point takes your attitude into account:

have an open mind to sources of knowledge that others may shut out.


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:

Researching for answers means more than typing several keywords into a search engine or posting a question at Stack Overflow or the MSDN forums.


Edited 2013-05-06 06:30 UTC

Reply Score: 10

RE[2]: Comment by strim
by ebasconp on Mon 6th May 2013 13:55 UTC in reply to "RE: Comment by strim"
ebasconp Member since:
2006-05-09

You should not take seriously the jokes we all do against MS technology ;)

Reply Score: 3

RE[3]: Comment by strim
by lucas_maximus on Mon 6th May 2013 14:17 UTC in reply to "RE[2]: Comment by strim"
lucas_maximus Member since:
2009-08-18

The thing is that they are rarely funny.

This is a funny microsoft joke: http://www.youtube.com/watch?v=UC4vz6IbdtY

Reply Score: 4

RE[4]: Comment by strim
by Jondice on Mon 6th May 2013 23:19 UTC in reply to "RE[3]: Comment by strim"
Jondice Member since:
2006-09-20

Need a 5th season!

Reply Score: 3

RE[5]: Comment by strim
by lucas_maximus on Tue 7th May 2013 07:12 UTC in reply to "RE[4]: Comment by strim"
lucas_maximus Member since:
2009-08-18

This year I heard.

Reply Score: 2

RE[6]: Comment by strim
by MOS6510 on Wed 8th May 2013 06:32 UTC in reply to "RE[5]: Comment by strim"
MOS6510 Member since:
2011-05-12

Yesterday I read there will be one special episode (40 minute one).

Reply Score: 2

Almost not accurate
by dvhh on Mon 6th May 2013 03:13 UTC
dvhh
Member since:
2006-03-20

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).

Reply Score: 10

RE: Almost not accurate
by timalot on Mon 6th May 2013 06:02 UTC in reply to "Almost not accurate"
timalot Member since:
2006-07-17

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.

Reply Score: 4

RE: Almost not accurate
by pedlo on Mon 6th May 2013 08:48 UTC in reply to "Almost not accurate"
pedlo Member since:
2011-04-30

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.

Reply Score: 3

RE[2]: Almost not accurate
by timalot on Mon 6th May 2013 10:14 UTC in reply to "RE: Almost not accurate"
timalot Member since:
2006-07-17

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.

Reply Score: 3

RE[3]: Almost not accurate
by lucas_maximus on Mon 6th May 2013 12:10 UTC in reply to "RE[2]: Almost not accurate"
lucas_maximus Member since:
2009-08-18

That isn't laziness that is being pro-active / constructive.

Edited 2013-05-06 12:11 UTC

Reply Score: 2

RE[4]: Almost not accurate
by JAlexoid on Tue 7th May 2013 12:16 UTC in reply to "RE[3]: Almost not accurate"
JAlexoid Member since:
2009-05-19

Reducing your workload is a form of laziness.

Reply Score: 2

RE[5]: Almost not accurate
by lucas_maximus on Tue 7th May 2013 17:34 UTC in reply to "RE[4]: Almost not accurate"
lucas_maximus Member since:
2009-08-18

ERRR NO.

Reply Score: 3

RE[5]: Almost not accurate
by siride on Wed 8th May 2013 02:23 UTC in reply to "RE[4]: Almost not accurate"
siride Member since:
2006-01-02

Simply not doing work is lazy. Picking efficient ways to do work that you are actually doing is not lazy.

Reply Score: 3

RE[4]: Almost not accurate
by izomiac on Thu 9th May 2013 05:38 UTC in reply to "RE[3]: Almost not accurate"
izomiac Member since:
2006-07-26

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.)

Reply Score: 1

RE[3]: Almost not accurate
by leos on Mon 6th May 2013 16:17 UTC in reply to "RE[2]: Almost not accurate"
leos Member since:
2005-09-21

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.


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.

Reply Score: 6

RE[4]: Almost not accurate
by timalot on Mon 6th May 2013 21:24 UTC in reply to "RE[3]: Almost not accurate"
timalot Member since:
2006-07-17

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.

Reply Score: 1

RE[2]: Almost not accurate
by johntdaly on Mon 6th May 2013 16:26 UTC in reply to "RE: Almost not accurate"
johntdaly Member since:
2012-07-27

Try Larry Wall, Bill Gates isn't all that quotable as a programmer in my opinion.

http://c2.com/cgi/wiki?LazinessImpatienceHubris

Reply Score: 4

RE[3]: Almost not accurate
by lucas_maximus on Tue 7th May 2013 17:37 UTC in reply to "RE[2]: Almost not accurate"
lucas_maximus Member since:
2009-08-18

Sorry but I can't take anything seriously said by the guy that created perl.

Reply Score: 3

RE[4]: Almost not accurate
by siride on Wed 8th May 2013 02:23 UTC in reply to "RE[3]: Almost not accurate"
siride Member since:
2006-01-02

And I can't take people seriously who fall back on lame Perl-bashing.

Reply Score: 2

RE[5]: Almost not accurate
by lucas_maximus on Wed 8th May 2013 07:07 UTC in reply to "RE[4]: Almost not accurate"
lucas_maximus Member since:
2009-08-18

How is it lame? The language makes programs that aren't maintainable.

Edited 2013-05-08 07:07 UTC

Reply Score: 3

RE[6]: Almost not accurate
by sobkas on Wed 8th May 2013 19:29 UTC in reply to "RE[5]: Almost not accurate"
sobkas Member since:
2005-12-13

>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.

Reply Score: 1

RE[6]: Almost not accurate
by siride on Thu 9th May 2013 00:08 UTC in reply to "RE[5]: Almost not accurate"
siride Member since:
2006-01-02

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").

Reply Score: 2

No's 8, 9 & 10 (of many)
by shotsman on Mon 6th May 2013 07:05 UTC
shotsman
Member since:
2005-07-22

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}

Reply Score: 5

RE: No's 8, 9 & 10 (of many)
by phoudoin on Mon 6th May 2013 07:53 UTC in reply to "No's 8, 9 & 10 (of many)"
phoudoin Member since:
2006-06-09

Your suggested 8 & 9 are already there and is numbered #5.

Reply Score: 5

RE: No's 8, 9 & 10 (of many)
by lucas_maximus on Mon 6th May 2013 12:12 UTC in reply to "No's 8, 9 & 10 (of many)"
lucas_maximus Member since:
2009-08-18

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.

Reply Score: 2

Comment by pedlo
by pedlo on Mon 6th May 2013 07:22 UTC
pedlo
Member since:
2011-04-30

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

Reply Score: 2

RE: Comment by pedlo
by timalot on Mon 6th May 2013 10:17 UTC in reply to "Comment by pedlo"
timalot Member since:
2006-07-17

StackOverflow ... no thanks ... you usually get the boring standard answer to a programming problem that is the lowest common denominator....

Reply Score: 2

RE[2]: Comment by pedlo
by lucas_maximus on Mon 6th May 2013 12:19 UTC in reply to "RE: Comment by pedlo"
lucas_maximus Member since:
2009-08-18

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:

Programmers… often take refuge in an understandable, but disastrous, inclination towards complexity and ingenuity in their work. Forbidden to design anything larger than a program, they respond by making that program intricate enough to challenge their professional skill.


There is nothing wrong with the "lowest common denominator" when that is all that you need.

Reply Score: 4

RE[3]: Comment by pedlo
by timalot on Thu 9th May 2013 03:39 UTC in reply to "RE[2]: Comment by pedlo"
timalot Member since:
2006-07-17

This coming from some one who put down Perl as a programming language... pot, kettle, black?

Reply Score: 1

Not "programmer." Scientist.
by theosib on Mon 6th May 2013 11:54 UTC
theosib
Member since:
2006-03-02

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.

Reply Score: 5

Trait Zero
by hhas on Mon 6th May 2013 12:14 UTC
hhas
Member since:
2006-11-28

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.

Reply Score: 5

RE: Trait Zero
by Pro-Competition on Mon 6th May 2013 14:48 UTC in reply to "Trait Zero"
Pro-Competition Member since:
2007-08-20

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.

Reply Score: 5

RE[2]: Trait Zero
by hhas on Tue 7th May 2013 11:47 UTC in reply to "RE: Trait Zero"
hhas Member since:
2006-11-28

Amen, I could not agree more. This is one area that really pays off.


What depresses me beyond belief is that your comment and mine are the only ones on either OSNews 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.

Reply Score: 4

RE[3]: Trait Zero
by Kochise on Fri 10th May 2013 07:53 UTC in reply to "RE[2]: Trait Zero"
Kochise Member since:
2006-03-03

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

Reply Score: 2

Pragmatism
by lucas_maximus on Mon 6th May 2013 13:41 UTC
lucas_maximus
Member since:
2009-08-18

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.

Reply Score: 4

Comment by looncraz
by looncraz on Mon 6th May 2013 15:03 UTC
looncraz
Member since:
2005-07-24

The most important thing is follow thr

Reply Score: 5

Revised List
by fretinator on Mon 6th May 2013 15:19 UTC
fretinator
Member since:
2005-07-06

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 */”.

Reply Score: 8