Practices to follow for becoming professional

Question

What practices should a novice follow in order to move forward and reach his/her destination of becoming a professional programmer in any platform/language(specifically in c#.net)

Answer 1

He should write code in his spare time, not only during work hours. Practice, practice and practice, that's how people become professional developers.

Answer 2

Be willing and eager to learn. Let everyone be your guru.

Answer 3

Make sure you enjoy it.

Enjoy learning about the new technologies. Don't be afraid of change because things will constantly change. If you don't enjoy learning then this is the wrong profession.

Other advice:

• Follow tutorials. Type the code in and make sure you understand it. Modify it and see if your modification works as expected.
• Write some code yourself without using a tutorial.
• Read other people's code and try to identify the good and bad parts.
• Find the documentation for the language / library. Read it when you need to understand something new. Ask on Stack Overflow if you still don't understand it.
• Get other people to read your code and give feedback.
• Write some more code.
• Read the web logs of other professional programmers.

Answer 4

One of the best recommendations I may think of is to read many blogs from the designers of the platforms you are using.

For example for ASP.NET you should definitely read Scott Gu's blog: http://weblogs.asp.net/scottgu/

Answer 5

Try and get into good habits early - for instance:

• get used to using source control (take your pick)
• testing methodologies
• code refactorings

Ideally try and get some experience of working in a team environment - try picking an open source project that interests you and giving some of your time. You'll gain a lot of relevant experience this way.

Answer 6

I would recommend subscribing to MSDN Magazine - http://msdn.microsoft.com/en-us/magazine/default.aspx and various blogs, which can tell you how it's done profesionally and what kind of problems need solving, f.e the IE blog - http://blogs.msdn.com/b/ie/. Generally, the blogs you can find on MSDN are a great and reliable resource. I also recommend some literature on the development process and so on. But most importantly, be willing to experiment and enjoy it ;-) Good luck.

Answer 7

First, you never arrive at the "destination". There is always more stuff to learn.

Second, "being a professional" is at most 50% about technology. The rest is about being able to cooperate with colleagues, customers, knowing how to take a criticism and how to criticize, learning how to accurately (within 50% margin) estimate the time to completion given a problem, and also learning to say "i don't know [but I know how to find out] | [and I have no idea where to start looking]". The last point is basically about learning to be honest with yourself, colleagues and your boss(es).

You have to do programming as it were a craft -- do the job because you want to do it well and be proud of what you've done, not just doing the minimum that will satisfy your boss and get you a paycheck. (But don't overdo it on "doing the job well" - knowing when something is good enough is also an art. Perfection is the worst enemy of good enough, as an aquaintance of mine used to say.)

There's a book on the topic that I can recommend - Code Craft by Pete Goodliffe.

Answer 8

1. Always think about the design first. You would be surprised how much time you could save yourself if you simply spent an hour or two with a piece of paper and a pencil before you start writing any code. Obviously you can not foresee all the possible requirements and issues that you'll have to tackle when you start writing code, but nevertheless, a proper design document could save you weeks if not months of work by eliminating all that time you will need to write and rewrite the code. Other benefits of a properly designed code are re-usability and easier bug fixing.
   A clear and logical design also makes it easier for someone else to read and understand your code, which is a big thing if you're planning to work in a group with other programmers. No one likes to spend hours looking through the code just in order to understand it. This is where your design document would be very appreciated. So I suggest you take a VERY good look at the material that focuses on software design and architecture. There's plenty of really good books out there. And the design solutions and code patterns that they offer are pure gold.
   
   
2. Take a good look at the platform you're working with. Study it's abilities and limitations. Don't be afraid of the complexities that you might need to tackle. Most programmers know the simple most-used features of the platform, but only real experts know whats hiding in the dark corners of the technology. In case of the .NET, things like reflection and security could be on your list. These are much more advanced topics that majority of the programmers barely touch.
   
   
3. Creativity and experimentation. Use your other side of the brain from time to time. Sometimes it creates things no one ever thought trying out before. Search through sites like codeproject and codeplex for inspiration. See what other people have tried out before and what dirty little "not-so-obvious-yet-pure-genius" techniques they've came up with.

Answer 9

Hello Ankur, The thing is dude,you have to be very keen for the type of code you write.In today's world even a School boy can get into Programming.But what differentiate a Pro and a Novice is,you should understand the requirement and then dive into the code what you are writing.And if you get into it,don't be afraid in between.Coz a PRO have a solution to everything,try to become that.Everything what it needs is, TRY TRY and TRY YOUR BEST to come out of each problem.I Follow the Motto my GURU taught me...If You are in the Boxing Ring,Dont be afraid of the Punches you will be getting...Just bother about your GOAL.

Answer 10

My humble take:

Make sure that you're a sheep, not a goat

I'm referring to Separating Programming Sheep from Non-Programming Goats blog post by Jeff Atwood. To summarize, some people have, for lack of a better word, a knack for programming, which seems to be some kind of innate ability that can't be taught. It doesn't mean that programmers are smarter than average, it's just that the good ones have their brains wired differently.

Follow the no a**hole role

If I'm given the choice between working with a genius programmer who is an arrogant a-hole and a so-so programmer who is a nice person and easy to work with, I would pick the latter. Presume that everyone has something to contribute and are worthy of respect until they prove otherwise. And if they do, maintain civility even with the pointiest of Pointy-Haired Bosses. The No Asshole Rule book is a good read on this topic.

Surround yourself by people who are smarter than you

Working with better programmers forces you to be at your best. And finding them isn't really that hard to do. If you can't find them in your working environment, start participating in an open source project that you like and that is managed by programmers that you respect. The Passionate Programmer has a chapter about that subject.

Understand that programming is not dogma

It's good to be passionate about something, and it's perfectly normal to prefer Emacs to vi, Mac to Windows, Ubuntu to Redhat, Ruby to .NET, ASP.NET to MVC, lo-carb to lo-fat, et cetera to etc. But none of those preferences should turn into unquestionable, immutable, self-evident truths. And definitely none of them are worth turning perfectly civil debates into CAPS-LOCKed shouting matches. And in all honesty, when it comes to any X vs. Y, half the time the answer is "it really doesn't matter." The other half it's "it depends."

May your requirements never change and your builds never break.

Answer 11

As others alluded to there are two types of things to learn:

Academic Knowledge:

• Know the Theory - get a great handle on the theory of programming, the theory of language design, the theory behind the architectures you are coding on
• Know the Math - all programming eventually boils down to math - know predicate logic, trig, vectors, geometry, (basic) set theory, graphs, basic matrix theory, a little numerical analysis doesnt hurt either - as well as complexity theory
• Know your Language - get a book, read it, make notes for reference. Apress titles work well for C# http://www.amazon.com/Pro-2010-NET-Platform-Fifth/dp/1430225491/ref=sr_1_1?ie=UTF8&s=books&qid=1281215548&sr=8-1 is good. Then read blogs and videos, learn to use the Redgate Reflector and MSDN help
• Know your Tools - for C# this means Visual Studio 2010 - http://blogs.msdn.com/b/saraford/archive/2010/06/17/video-101-visual-studio-tips-in-55-minutes.aspx is a great way to learn. Also get a decent refactorer - ReSharper is my favorite but there are others.
• Know your Ecosysyem - know what libraries are out there, learn how to use one or two of the best

Skills:

• Know how to define a projct - no matter how good a programmer you are if you build the wrong thing you will have failed epically.
• Know how to design - learn the theory on object orientated design - the Gang Of Four software patterns are classics and every coder should be aware of them.
• Know how to document code - this is critical for long lasting code and for working well in a team. Write it, Document it, Test it => Resuse it
• Know how to work in a team - work hard, play nice, communicate well.
• Know which tool to use - get a feel for as many types of languages, actual languages, technologyies, libraries and so on as you can so that you know which to use in which situations
• Know how to learn - from those around you, from the web, from documentation and most importantly from your own mistakes.

I'm sure others can add to these lists ;)

Answer 12

• Learn the core data structures: pairs, arrays, lists, queues, sets, trees, balanced trees, hash tables, dictionary structures in general, tries, priority queues. Each of them has tradeoffs in space, speed, isolation etc.
• Most languages are the same pig in a different dress (e.g., Java, C#, etc.) Don't get too hung up on that, although it's worth learning a few to a get a feel for the territory.
• Building systems is all about managing resources. Understand how to use big-O notation.
• Tackle the whole problem or you risk putting a lot of effort into relatively unimportant aspects of the system.
• Pick a good algorithm. O(1) is best, O(n log n) is usually fine. Bad things start to happen around O(n^2) and up (n is usually small, but unless you can guarantee that, someone will eventually try running your program with a large n).
• Learn something about how garbage collection works. Learn something about concurrency and asynchronous programming. You can learn a decent formalism like the pi calculus in an afternoon or two (you won't write programs in the pi calculus, but it will seriously help you to design better concurrent programs).
• Don't optimise until you absolutely have to. Then find out out where the problem is with the profiler.
• Write for the reader. Make your code simple and elegant.
• Static type checking is your friend. Avoid fancy language features (there goes about 90% of C++ :-). Turn on all the warnings your compiler will check for and write warning-free code. Untyped (sorry, "dynamically typed") languages are great at hiding bugs from you until run-time. Avoid them for serious work, if at all possible.
• Learn how to write and maintain comments and documentation. Write code so that it is as simple as possible for the reader to understand what you have done. If you can't express yourself clearly, you need practice. Buy Strunk and White's "Elements of Style".
• Learn to be disciplined in your planning and coding. Keep a daily log of what you're up to, problems you've encountered, solutions you've arrived at. It will be invaluable.
• It's a team game. Rein in your ego. Listen. Don't get upset.
• Don't fall for ideologies or bandwagons. There's usually a kernel of utility in most of these things, but experience shows much of them to be junk. Be appropriately skeptical when you try out "new" methodologies. Watch out for buzzwords ("extreme" and "agile" are attached to a lot of sins...).
• Keep reading, learning, and trying new things.
• When stuck, ask for help. There's no point spending a week by yourself learning how to do something relatively basic when there's a guru available who can show you in half an hour. Some gurus have bad personalities - don't take them personally, they're just made that way, ask them for help anyway.
• Keep your sense of humour. Take breaks. Have fun. Drink beer (all great software engineers enjoy going to the pub).