views:

746

answers:

19

Related questions: http://stackoverflow.com/search?q=great+developer


Let's say you've been learning a new tool/language for a few months (read the book, got the t-shirt, that sort of thing) and you've got to a level of "proficient" - you can build stuff, but slowly and with constant reference.

How do you go about moving above that level to someone who can be considered an "expert". Time and experience are the obvious winners, but are there any other ways?

Code reviews? Pairing? Reading source code?

+3  A: 

push the language. My normal approach to a new tool is "to find the edge of what can be done by running full speed and head long into what can't be done." Just try things. Spend part of your time pounding octagonal pegs into heptagonal holes. Abuse the systems. (Clearly this should not be done with production code.)

Exploring all the nooks and crannies of of how a language works will give you a feel for how it's supposed to work and show you things most people don't known


an example of something I have found this way:

Class a, b, c;
a * b = c;

that could be valid code if Class has an overloaded addition operator that overloads the assignment operator for Class. However it doesn't parse as you would expect:

class a { ... }
Class b, c;
a * b = c; // same line ends up being a declaration not an expression
BCS
+6  A: 

Always keep trying new things. Think of things you can't do... then do them.

BlackWasp
+1  A: 

When your peers consider you as a good reference. As in any other profession ( music, painting, marketing, you name it ) it takes a lot hardwork but most of all passion. But if you like what you do, eventually you'll find your self resolving more and more difficult task.

You might change your job and join a group with more qualifications, you'll learn from them and repeat the process.

Adding other activities not directly related to code to your skills also helps, for instance learning other "natural" languages, learn to play some instrument, chess, whatever you like, has also shown to improve the way you see and interact with your daily job.

But as I said, you know you're doing well when other recognize you as "great" developer.

:)

OscarRyz
+2  A: 

I think experience is the key factor in becoming good at something. Whilst just spending years of your life on something won't make you good, with all the right factors in place time is the only dynamic factor that'll give you the ability to claim your expertise in something.

If you're proficient in something keep pushing yourself and trying to expand your horizons. Learn new things and apply it to your previous knowledge. You never know when you'll learn something worthwhile unless you're learning all of the time.

EnderMB
+5  A: 

I think the main thing you can do is just keep using the language or tool in question... practice makes perfect.

Reading and exploring features you haven't tried yet expand your knowledge and let you discover new ways at solving the problems the tool can help solve.

I most poignantly felt this while learning Haskell. There was a moment while I was working on problems on projecteuler.net where I realized there was a whole different way I could tackle problems. Namely, I discovered I could use guards and parameter matching to totally eliminate if/else constructs in my code, which cleaned up the code a LOT, and I started to see ways of tightening my Haskell code that I just had never even considered before.

I took away from this experience the idea that if you just try the other features that you don't quite understand, they will eventually click for you, and you will see problems in a whole new way, and become that much closer to being an "expert".

However, I don't really believe there is such a thing as an "expert". Merely people that are better in certain niche areas than others, or may have explored certain things more... but even the so-called "experts" have gaps in their knowledge too, you just won't be able to recognize them until you have explored the tool or problem space as much as them or more.

Mike Stone
+1  A: 

Never assume you know everything about the language.

Continue reading other people's code.

Remain inquisitive, rather than authoritive.

moobaa
A: 

I think being willing to accept that there is always another way of doing something is a good start. The next part is finding out what that is. It's important to learn the right way of doing things, not just the way that seems to work. For example, I was new to .NET and I reviewed some C# code for working with a list. The code included some P/Invoke in order to select a list item. I knew inside that there must be a C# way of doing this and that the person writing the code just hadn't tried hard enough. It's important to recognise that a solution isn't quite right.

In the end, experience is the only way to improve, but how you gain that experience can vary from code reviews (like the example given) to trying new technology to see how it fits with what you do to just reading the latest blogs to participating in a site like this one (I've already learned some new things just in the last day since I joined).

Overall, I think you need to have the passion to learn. Without that, there is no drive to elevate yourself beyond being a "just enough" developer.

Jeff Yates
+2  A: 

These are all good things to do :

  • Try to implement things.
  • Don't rest on the knowledge you have acquired.
  • Learn new languages, write tutorials, help others.
  • Hang around some coding channels on IRC, learn to recognize WTF-code from non-WTF-code, and try to manage that your code doesn't hang on the WTF-code side.
  • Help an open source project.
  • Produce some code to modify an open-source project to add a feature you need and submit it.
neohaven
+1  A: 

Force yourself to use it constantly. Even though I feel Perl to be more "natural" than python, I used python exclusively for all the assignments for an entire semester. This will drag you through most of the dark and scary corners.

florin
+3  A: 

The way to be great is to never think you are good... at least I hope that is the case :)

Aidan
For that it helps to have an ego problem; an ego that doesn't work is a good way to avoid sitting on your laurels.
BCS
A: 

Meet your fears, think it's something from Karate actually, ie don't be negative about something until you tried it.

epatel
+15  A: 

There is one and only one way to elevate yourself from "good" to "great": more practice.

That is the single most effective thing that you can do to become an expert.

Build more stuff. A lot more stuff. Build as much as you can as often as you can.

The more you build, the faster you'll become an expert.

A company that I used to work for hired a developer that had no experience with the implementation language that we were using. However, he had experience with a similar language, was smart, and extraordinarily motivated. This guy fully committed himself to becoming an expert. He spent as much time as he could, every day, mornings, during lunches, and evenings, to the greatest extent that he was able, building random things in our implementation language. He ate, breathed, and slept it.

It didn't take long at all before members of the team were coming to him with questions...

Fhoxh
>>He spent as much time as he could, every day, mornings, during lunches, and evenings, to the greatest extent that he was able, building random things in our implementation language. He ate, breathed, and slept it.>>This does not sound like optimal use of one's time. (Heresy! I know, I know.)
Patrick McKenzie
I wouldn't say that blindly building stuff is the way to go. Yes, you should build alot of stuff, but you also need to spend time reflecting on what you have done and what you could have done better.
David The Man
Reflection and Introspection should always be part of your definition of "build" anyway.
EBGreen
This makes sense and is supported (e.g. Gladwell's Outliers book: http://en.wikipedia.org/wiki/Outliers_(book)).
Kit
+1  A: 

Aside from the previous (great) suggestions, one thing to consider is to document your own learnings (as unit tests, little sketches, interactive debugger/prompt sessions etc) and keep them stored somewhere - possibly under version control.

A few months after I've been down this path with Ruby, a friend asked for these snippets, and found them invaluable. Sometimes it's hard to push the language when you don't really know what to look for, so ask some friends who have been through the same learning steps and see if they have some notes!

Carlos Villela
+1  A: 

Any time you need to do anything on the computer, figure out how to do it programmatically. Practice makes perfect and builds memory. You'll find yourself remembering some of the simple things and finding ways to do new things you couldn't have imagined when you started.

Timothy Carter
+2  A: 

One of the most useful exercises I have done in a large project is to step through the whole thing in the debugger; line by line, looking at intermediate values, setting breakpoints on callback routines and threads.

One of the best effects of this exercise is to give you greater insight in what's going on inside your project. In many projects this is the only way to learn about the system internals.

Dour High Arch
+3  A: 

Work in a job where you are surrounded by other great programmers. You will learn directly from them and your natural drive to be competitive will grow your skills quickly.

Before you know it you'll find you have an edge over most other programmers in the industry.

Andrew
A: 

Practice makes perfect, but it won't bring you from good to "Great" as a programmer.

No sir. If you want to be "Great", you will have to hone your judgment and sense for purpose. Good programmers can code circles around each other with clever algorithms. But great programmers know the difference between clever algorithms and elegant solutions that address both the specific problem AND the 'big picture'.

Good programmers get the job done. Great programmers make the job obsolete.

Good programmers are content with being the smartest people on their teams or among their peers. Great programmers strive to surround themselves with smarter people than themselves.

Good programmers accomplish feats by coding all night long. Great programmers accomplish feats by mastering the art of approximation.

Good programmers are served hand and foot by IT personnel. Great programmers swap out their own power supplies.

Good programmers know their programming technology backwards and forwards. Great programmers know multiple programming technologies backwards and forwards.

Good programmers write clear, concise, and informative code. Great programmers also write clear, concise, and informative English.

Matias Nino
+1  A: 

Learn as much as you can from other programmers you respect. Find a mentor if you can, but don't doubt what you can learn from programmers of what you might consider "lesser skill", either. Whether it be through work, open source projects, blogs (or even Stack Overflow), almost everyone has something useful they can teach you.

Also, when learning from others, don't just learn how to do a certain thing, but ask them why it's done that way. That allows you to focus more on the big picture and helps you to know when you should break certain rules to accomplish your overall goal.

Jonathan Schuster
A: 

Practice is very important, but make sure you continue to read and learn. Hacking away with no external input is like learning golf without any lessons - you'll develop bad habits and reinforce them over and over until they're hard to break. Remember, there's always someone smarter than you.

Another useful exercise is starting a blog. The act of explaining something to someone else forces you to really organize your knowledge, and provides a much deeper understanding than keeping it all bottled up inside.

cam8001