Difficulty in a young programmer's understanding, and hints to help progress.

Question

I have attained a point where I can manage to quickly code things like mathematical or sorting functions in multiple languages, including Java, C++, Haskell (still haven't got the hang of monads), lisp and Ruby.

I have also attained, at the other end of the process, a point where I have a rather vague and intuitive understanding of how an application works and holds it's internal state.

The problem is more around the part between the conception to the coding. By my understanding, it seems to be what being a developer is about, when compared to a Programmer/code monkey.

In other words, even if I have an intuitive notion of what I should do and have the possibility to code the specific bits, I'm at a complete loss so as to where to begin or how to actually build more complex systems. I also have a very hard time expressing time boundaries or estimates. Is this what makes an experienced programmer?

EDIT: I have definitely been through a lot of the "Best Practices" stuff on the web and in books in general.

Answer 1

The next step is to learn about writing testable code and adhering to SOLID principles, learning to apply design patterns is good as well. As for estimates, if you're like me, they just come with time. I'm still not great at providing estimates, but I get better each day.

Answer 2

have you read Code Complete? Reading it will take you to the next level. Also, nothing will make you better than actually working on some projects.

Answer 3

To understands the ins and outs of what's going on behind your code I would suggest reading one of "Programming Languages" books, here's a good one.

If you want to learn how to architect applications, the best approach is to learn some design patterns and try applying them, however make no mistake and try to learn all of them at once, since you will be just overloaded with information and lost. Just take your time understand and remember each one of them. Here's a good book for learning that.

Remember there are no shortcuts and fast way to become an expert, it all takes years of practice and experience, so just enjoy the process and don't rush.

Answer 4

A lot of that stuff just comes with practice. Try writing a couple of small but complete programs (even just rewriting things that already exist), and you'll start to understand the rest of the process. Similarly, schedules and estimates and all that annoying stuff gets easier once you do it a few times.

Answer 5

I think at your stage of development, what you should be studying is Object-Oriented Design Principles. Of the languages that you mentioned, the best one for studying this is Java.

Note that I'm not advocating any language in particular, but Java is definitely good for learning these principles, and these principles will serve you well no matter what language you ultimately settle on. If you can develop a good grasp of Object-Oriented Design, and an excellent command of the language, I believe that your design skills will improve.

After that, you can begin studying Design Patterns.

Experienced programmers are not necessarily better at time estimates, but they do know what kind of programming tasks they can estimate well, and which ones will require "research."

Full Disclosure: This is how I learned. I do not use Java today. If you have questions about my answer you can email me at robertwharvey aht yahoo dhot com.

Answer 6

If you can arrange it, the very best growth opportunity would be to work closely with a well seasoned developer -- especially one who sees mentoring bright but inexperienced juniors as being one of his tasks. I bet many of us old-timers had such golden opportunities (however briefly) at least once in our careers -- and since we can't pay it back, we pay it forward, by taking some mentoring duties of our own when the occasion arises.

Some of us are lucky enough to be able to learn from reading (books, mostly, but good code is also a great read). Besides technology-specific books, Pragmatic Programmers has several books worth trying -- everything I've tried in their Career development category, for example, has proved worthwhile (which doesn't mean I agree with 100% of what each book says: it means each book is well written and prompts thinking, reflection and growth).

Answer 7

It sounds to me as if you may have hit the point where you're now running at full speed.

To learn more, you've basically got two choices. You can do it the slow painful way by reading books, thinking about things, and studying as best you can, or, if you're lucky, find someone to work with who's got a lot more experience than you and happens to have learned the particular things you want to know about.

If you can do the latter, good on you, but don't get used to it. After a year or three, you'll come up to speed, and be in exactly the same place. And you'll have to go the painful way of teaching yourself.

But don't worry, a fair number of people have been in this situation. It's how the human race makes progress.

Answer 8

Have you taken a course in data structures and algorithms?

Answer 9

get a job - thatll push you as far as you can think :)

Answer 10

This is why I wrote Building Skills in Object-Oriented Design. It might help.

Answer 11

There's a lot that you can learn from just doing stuff. It sounds like you're already doing a lot of that, and you should continue, because you can solidify your knowledge a great deal through practice. Designing and implementing large systems is a Hard Problem, and in order to do it well you you need to have not only general knowledge about computer science and coding, but specific knowledge about the problem domain that you're attacking. I wouldn't worry too much about big systems versus small systems though.

There are some other good suggestions here. Definitely learn from other people around you by reading, talking to them and scheduling code reviews if you have the ability. But in my opinion the best thing that you can do is have a very specific problem to solve in mind, hammer away at it for a while and learn from your mistakes until you have something. Then once you're done, learn from whatever you mistakes you might have made and do something else!

Answer 12

Just code.

Some "better practice" ideas won't make much sense (or they won't stick in your mind) until you see the context that they're meant to be used in your own work.

My other piece of advice is to work with frameworks. Through working with a complex framework (like .NET or Ogre or CakePHP) you'll see how a really complex system is built and you'll see design patterns in action.

I'm not saying to analyze the source. But to use and work with advanced frameworks will teach you how complex software is put together.

Answer 13

Let's just walk through the SDLC and ask about each step for another way to look at this:

Requirements gathering - This is usually the first step as this is the what to build part. This is usually far from perfect or comprehensive in terms of all the features that a user wants but one has to start somewhere.

Design & analysis - This is the big part where you may have some "analysis paralysis" which is probably common as there may be a few different ways to fix things depending on resources needed like money, time, and people. Sometimes there are ways to resolve things in 2 hours, 2 weeks, or 2 years depending on what one wants to do. There are many competing factors to consider here and this is usually the really hard part of a project in my experience. Suggesting various Design Patterns and architectures to use are a part of this step.

Implementation - This part you likely have done well and wonder, "Where can I go from here?"

Testing - This is after you write the code, what kinds of tests does it have and how well can this be given to others.

Maintenance & support - This is the last phase where various patches or hotfixes may be needed for what was released.

Answer 14

You might want a better feel as to what's going on at a lower level, and for that you can learn C. It's pretty basic, and most of what's in the language translates readily into machine language, which is the lowest level you can program on standard systems.

Aside from that, what you need is practice. Pick some sort of simple problem and write a program around it. (Ideally, run it by somebody more experienced. A surprising number of things that superficially look simple aren't. If you can't, select several problems and work on them until one or two get finished.)

There are several good books suggested by others, and some of them will have exercises.

Very few people are good at estimates, and most of those have devoted a significant amount of time to becoming good at estimates. Don't worry about this for a few years.

Answer 15

Architecture is what you're looking for. The ability to map out a monolithic application into a manageable collection of components that interact with one another. It's easy to make utils but taking the next step is tough if you don't know how to do it.

In terms of reading you could check out the Gang Of Four patterns book, that displays some patterns and sample usages which may give you a head start.

The way I learnt the majority of this though is through trial and error. Try and build large programs yourself and you'll start to learn what works and what doesn't. I built a pluggable framework back when I started and that taught me a lot about architecture and how to manage services.

You'll basically want to master a few fundamental topics:

• Service distribution - how to get the right objects to the right places (IoC and Dependancy Injection are worthy topics, a simpler scenario is a humble service container)
• MVC - UI and controller frameworks. You want to be able to show a series of UIs with associated logic in a generic yet specific fashion.

plus probably loads of other things I can't think of now...