tags:

views:

445

answers:

8

I'm a C# programmer who programs for a hobby (still in high school) but one day hope to make it a career. I've ran into a couple of walls when trying to write a larger scale program:

1) I can't think of anything to write! (this has to be the worst part, you guys have it easy because a customer knows what they want).

2) I can't go from thinking in great detail (a single function) to very little detail (an entire class).

Any suggestions on where to start?

Edit: I realize now that customers don't always know what they want, I guess I was just using this to refer to my programming block (it's like writers block).

+6  A: 
  • Look for freelance programming work
  • Apply for a programming job.
  • Read Code Complete
Click Upvote
I forgot to tell you I was still in high school. I've read code complete and loved it. +1
Lucas McCoy
+1 for Code Complete
Davy8
@Click Upvote: I was giving the answer to you, but with Giovanni's edit, I was forced to give it to him.
Lucas McCoy
+ 1 For code complete, it should be mandatory reading for people writing software
Raju
+3  A: 

Consider joining an open-source project. There are tons out there and many are looking for help. Scan over CodePlex and find one you are interested in. Read the code. Tinker. Try to add features.

If you are still having trouble coming up with a project, see if you can create your own copy of one. Can you come up with a Twitter client on your own, for instance?

Brian Genisio
A: 

For #1, think of some (relatively) simple program that has something annoying about it, some feature you can't stand or a feature you wish it had. Now try to write that.

For #2 Don't start thinking at the code level. Think about what the goals of the application are and what are the major features. Then slowly break it down. Start at the highest level of abstraction possible. Even thinking in terms of classes is too low level to start. Think of what you're trying to represent and all the parts that go in in.

It's an overused example, but it's a good one. Take a car for example. When deciding how to build one (or a programmatic representation of one) think about what the parts of a car are. An engine, a body, a fuel system, wheels, etc. Don't worry about how to build an engine just yet, that comes later. First you need an understanding of how all the big parts come together. Then when you understand that you can start worrying about how to build an engine, what makes up a door, etc. Some parts you can get pre-made (existing frameworks, open-source projects, etc) and some you'll have to build yourself.

Break things down. Start by trying complex things as if you could get all the parts pre-made. Then if they aren't available, worry about building your own. This of course is an oversimplification and some things you do need to worry about, but in general don't get bogged down in the details too early.

Davy8
+1  A: 

Create a program of some complexity and challenge yourself to expand it. As you make the solution more generic honestly determine what design decisions would have made it easier. Add a graphical interface to it. Add some sound. Port it to the web.

One fun example is finding all the possible paths through a ten by ten maze. The input can be 0's, 1's, 2, or 3--indicating open spaces, walls, start, and finish points. Expand your solution to make it find all paths through the maze. Once you have it working make it more generic and allow the input to be of variable sizes. Add cute details to it (put some cheese at the exit point).

It is a mid level problem as you will have to know if you have visited a spot. As a hint a stack is usefull in keeping track of your current attempt to find an exit. Make sure not to go into an infinite loop by keeping an eye on where your solution has already been.

Also customers do not always know what they want. They make you feel like that rat a lot of the time.

ojblass
I see your point on 'customers do not always know what they want'. Non-tech people can really be a pain in the butt to work with.
Lucas McCoy
Even if techies give requirements we are not much better than non techies.Software I compare to placing furniture if front of a user, when the user gets the aha moment he knows that is what he wants. Rapid prototyping is the way to go
Raju
A: 

Advice For 1:

Write a blog engine. It's easy enough to get started with, and complex enough to keep you going for a little while (once you think about adding comments, etc).
Don't use this blog engine as it will be full of security holes, but you'll have learned a lot. (which is the point, isn't it?)

Advice For 2:

This is tough, and as I see it the answer is "Get more experience".
To elaborate, I mean learn about more kinds of programming styles (functional vs OOP is the big conflict), and simply get exposed to more code.
Once you've seen a lot more kinds of code, and seen how it solves different problems, you'll be able to draw on that when designing things at a slightly higher scale.

Orion Edwards
+4  A: 

Think of something that you can write that can make your life easier (programmer, school, whatever)...

Some ideas

  • Write a code generator that churns out code the way you like it
  • Write a nice PDF, music,whatever catalog program that lets you easily browse your collection... maybe with cool effects via WPF

Edit

Also, see if you can come up ideas by analyzing what some of your working friends and family do at work and seeing if you can come up with software that can improve their productivity at work. Not only will this help you develop skills that are not code-centric (many programming jobs are really programmer analyst positions, so this is a good skill to have), but you may be able to make a commercial product out of it.

One of my first real apps was born this way... and I'm still selling it (5+ years later!)

Outside of the money, It helped me

  1. Land my first professional programming gig (the hiring manager was impressed that I was able to see a business problem and come up with a solution for it).
  2. Communicate with end users (customers)
  3. Learn how to write good (or at least decent) end user documentation
  4. Write solid code (this is for a Windows app, so having to patch your software is something you don't want to do too often.)
Giovanni Galbo
+2  A: 

I think you should do something fundamentally fun and something for which the goals/features are basically well-known. Try implementing a simple strategy game like Tic-Tac-Toe in an object-oriented manner. Move on to something a little more complex like like Othello or Battleship. Refactor your solutions so that the board components are reusable and applicable to all of your games. Implement some generic game playing logic for turn-based games and refactor your games using a strategy pattern so that each of the different games can be played using your generic game engine. Separate the game logic from the display logic so that you can have implementations that are both web- and winform-based. Don't try to do all of this at once, but build it incrementally adding new features in each iteration.

I think by doing this 1) you'll have fun, 2) you'll improve your ability to take your code and reuse it (or at least the ideas), and 3) you'll learn how to apply good patterns of development to make your code easy to change.

tvanfosson
+1  A: 

To fix 1) Come work for me =)

To fix 2) Try doing one or two projects using TDD. I think we as developers have a tendency to dive into the code. TDD helps curbs this a bit and forces us to think of some of the bigger picture stuff. Not a silver bullet. But it helps.

fung
I'll take the job! ;-)
Lucas McCoy