[b0ng01]

I am a senior in undergrad with a year left until I graduate with a C.S. degree. School wise I am completely on track, but I am not sure if I am up to par on the skills that I should have for the workforce. Let me elaborate, presently I can generally figure out a way to do 95% of the things I try. But, my algorithms are crap, my program design is mediocre at best and I won't even begin to mention my horrible structure.

My point is this, those developers that actually work in the industry, what would you hands down require knowledge wise from any developer you are interviewing. Any recommendations book or link wise would be greatly appreciated.

I have noticed there isn't really a set guide on what one should learn to become a developer.

This post has been edited by b0ng01: 16 October 2010 - 05:34 PM

[macosxnerd101]

I have a thread in the Java Programmers subforum you may find helpful. It is called Getting Better at Programming Java. While some of it is Java specific, a lot of it can be generalized to most contemporary OO languages.

Also, you might want to try to get an internship as a developer to get some real world experience. The best way to improve as a programmer is to practice, and an internship is a mainly about learning.

[b0ng01]

Yea, I have read your thread already. My post is more intended towards non-specific information. I get learn my language as best as I can. But, besides that, what else should I be learning? I get the question is kind of vague, but that is a by-product of inquiring about a field that has so many different specialties. To consider it another way, if I were interning for a company what kind of tasks on average would I be required to complete?

[Dogstopper]

I'm going to intern next year for the same reason. It basically just introduces you to the daily life in the workforce and often, you complete products for your employer, and usually you work on teams. This allows you to focus on making your "part" of the puzzle as "best" as you can, be it OOP (if you are using an OOP paradigm), or whether it be making the code more robust.

[mostyfriedman]

getting an internship or joining a small company is a good idea actually. you can also try and join an open source project, there are tonnes of those all over the web, just pick one that you like and start contributing to it. If you want to work on your algorithms, there are many books for design and analysis, you can also practice your skills at www.topcoder.com or www.spoj.pl or any other online judge site. As for your program structure, there are also many books about code practices and good design, you can also look at other people's code and understand how they structured there code to get more ideas.

[macosxnerd101]

b0ng01, on 16 October 2010 - 11:12 PM, said:

To consider it another way, if I were interning for a company what kind of tasks on average would I be required to complete?

The type and complexity of the programs and components you would work on will vary from company to company, as well as the technologies used. But some standard practices regardless of where you work will be source control, component development and integration, component design, unit testing, and working with others. So you should have a good handle on proper OO design, including delegating responsibilities to the appropriate components, and not having one component take on too much (ie., your XML Parser should do exactly that: parse XML; it shouldn't be specifically setting up the layout of your GUI). You should also take a look at design patterns. Are you comfortable with the Factory and Wrapper patterns? How about the state pattern for GUI Management? And event-driven programming both in terms of GUIs and beyond the basic GUI event-driven model? Could you properly apply these? I would start trying to make sure you are comfortable with these somewhat, and once you get an internship, that should help a lot more in gaining real-world experience.

[Sergio Tapia]

Here's a very clear cut path you can use a check list of sorts.

• Learn one language well enough that you're comfortable using for most projects.
  
• Learn some good database relational skills. Normalization, indexes in db's, etc.
  
• Learn a bit about threading, just enough to run code methods that won't lock your GUI.

After you learn those three points, congratulations, you are can consider yourself a good programmer. Now the fun part starts!

• Learn what a code repository is, and how to use it. I'd recommend Mercurial if you're working on Windows.
  
• Learn what design patterns are and how they can benefit you when creating good clean code. (PLEASE also learn when you should apply them and when they are just overkill)
  
• Learn what unit testing is and start making a habit of using them.

This checklist will probably keep you busy for a year or two before you can confidently claim to know them. I'm barely scratching the surface of design patterns and can already see they're great to use.