views:

412

answers:

4

Inspired by this: http://stackoverflow.com/questions/868301/how-can-i-teach-a-know-it-all-beginner-programmer

  • Constantly changing between tools/IDEs/libraries when it's tough.

Well, not constantly but I've been to several legacy projects and I've tried to change the libraries to more open ones because I saw that the old one were pretty suckish.

  • Blind certainty that really bad designs are really very good.

Meh, not so much about me. I'm sure that all designs suck but the deadlines force us to choose.

  • Copying and pasting from the Internet, without understanding the code, and "marking" it as a project.

Well, I write all the code like that: copying and pasting, changing to my needs, refactoring to my structure and reusing. I really hate writing new code, especially for some library I haven't been quite intimate with.

Am I doomed?

+9  A: 

Two suggestions from a old friend that have never led me astray.

  • Be willing to take, and consider suggestions from others.
  • Never let your self-confidence get to the point where you presume that your solution to a problem is always best resolution.
Gnatz
A: 

I completely agree with your bad design point. In my view bad design is actually an after thought. I have seen many times the design evolves. You will notice that its a bad design even though you thought it was good earlier. Since you have spent some time on the design you have a better idea in mind. A bad design is good given a time constraint and good design is bad if time not taken care of.

Although the end goal is good design but there are parameters associated which affect the decision.

Bhushan
+5  A: 

A couple rules I try to live by...

Don't be afraid to admit when your wrong. The faster you detect/admit your own the more valuable team member you are. The more receptive to criticism you are the more you will gain from it. Try to love being proven wrong (as dumb as that sounds) and see it as a chance to learn something you would have never learned on your own since you thought you did it right the first time.

Don't be afraid to say "I don't know". Admitting/realizing you don't know something is the fastest way to know more about it. If you feel like you fully understand some (or any) process you are shutting yourself down to reception of new ideas and information.

Copas
Ah yes, in my company the bosses have lengthy programming discussions nearly daily. Guess how often I heard the words "You are right." Never. But I heard "I don't know" at least 1 time, so that's a start right! I am there for 6 months now :)
Blub
+2  A: 

I think the biggest thing you have to do is have a healthy fear of writing code that can fail. Once you realize that you can write something that will go down in flames, then you will gain a certain humility pretty quickly. Also you need to focus on getting result oriented with your company's goals aka making a profit. Switching libraries and IDEs might be cool and fun as a person that loves to write code, but if you can't relate it to a business' goals to make a profit then you are doomed to be simply a disconnected hotshot that has no influence on the development practices of your department/company.

Achilles