tags:

views:

815

answers:

12

How would you guys recommend I actually learn to program real things?

I mean, I know how to do basic academic things. I can implement a templated stack/queue/map/etc. data structure in C++ or Java or whatever. I can make a text-based hangman game or whatever. Etc etc.

But how can I learn to program something real, something useful? I've done project Euler up to question 100 or so, and I feel like that's given me more mathematical maturity but not programming maturity. Should I buy a book and follow exercises, struggle through interesting projects, etc.?

In short, how did you guys transition from academic exercises to real, fun and/or useful programs?

+18  A: 

Perhaps try helping out on an open source project? Or even start your own open source project?

Start small, work towards bigger things.

EDIT: A commentor below argues that if you're not being paid, you're not doing it for real. While there may be some truth to this - at least in so far that the pressures will always be different - in an open source project you will potentially be exposed to a lot of things that are important to "real" development:

  • Using some form of version control
  • Communicating with users and other developers
  • Software maintenance (the art of writing code for the future, not just for today)
  • The software lifecycle
Adrian Mouat
+1 A very good idea, also helps to ground the OP in dealing with team dynamics.
T.J. Crowder
I was about to put the same answerthis is the best way to get involved in real life with less damagetry working with any of the projects listed in "Launchpad"
A.Rashad
Start helping with an Open Source project with a well maintained bug database. You can improve the quality of that project in a meaningful way, while learning how to read other people's code and noticing how complex systems can create unexpected trouble.
extraneon
-1: until someone is paying you to write programs you are not doing it for real.
High Performance Mark
Not really, Getting to open source like *ix would be a great way... Also it is a real world work.
kumar_m_kiran
Being paid means you will do things you would not do if it was for fun, i.e. non-fun things. I do not necessarily agree that it is better, but it usually ends with an actual release.
Thorbjørn Ravn Andersen
Many open source developers endure painful tasks in order to release software even without the motivation of money.
Adrian Mouat
+3  A: 

Why not try an intership at a real software development company like Microsoft, Google or Fog Creek?

If you have a good academic background you are in a very good shape to apply to these companies intership programs.

Carlos Loth
+1  A: 

You learn to program real things by programming real things.

Join or start an open-source project - that's where I got a lot of my experience from. Get an internship or job at a software company. Maybe even do your own project and release it on the internet, get some real users, and maintain it for some time. Any of these ways should teach you about dealing with bug reports, users, feature requests, planning, code design and architecture and maintainability, etc. All the "real world" stuff :)

AshleysBrain
+7  A: 

Depends on your interests, but games can be an interesting project area. Pick a small simple game, like tetris, or a retro arcade game, and reimplement it from scratch.

Keep it simple to start with, and concentrate on getting the mechanics up and running.

Technology wise you can do this in pretty much any language - C, C++, Java, Python, Flash, etc. There are lots of frameworks out there if you want to, for instance, concentrate on one area and not on another (although personally it's much more gratifying when you do it from scratch).

I have a couple of base-games that I use to learn new platforms - I reimplement the same game in different languages, which lets me learn the specifics of the platforms/libraries without having to worry about logic, etc.

Joe
A: 

It's nearly always the humdrum everyday jobs where you learn the craft. Approach someone who owns a business and needs a way of automating part of their business process, see if you can do it.

Kevin Sedgley
A: 

It really depend on what the really useful thing that you want to create is. If you have a good idea about what you want to create then there's no substitute for getting down and doing it yourself. Two things are important here:

  1. If you have a broad outline of what you want to acheive then write down your definition and break it down into smaller chunks. Then, break them down further until you have a reasonably detailed idea of exactly what you're planning to build.
  2. Don't try to do everything in one go. Work from the detailed plan in (1) and try to get pieces of your code to work individually as modules before linking them together. For example, a CL interface could well be enough - you could add a GUI as a second phase. This makes testing easier too.

If you put together an idea of what you're going to acheive and by when, it will give you added motivation to hit the milestones. Otherwise it can be too easy to lose focus and give up.

Really, without doubt the best way to build real software is to get a job at a company that does this. This has many benefits (including pay!) but it also has the drawback that you might not always be able to work on what interests you and you may end up feeling like a small part of a big machine. Getting invloved in an open source project, either on your own or with others, is a good way to focus on something you feel is meaningful and, hopefully, to give something back to the community.

Robin Welch
+1  A: 

It all comes down to - what do you want?

What is your goal?

  • To learn new programming skills
  • To learn how a specific programming language works?
  • To makey money?
  • To get into a job
  • To get into a specific programming job
  • To learn the skills that will ensure you a job
  • To learn everything you can about everything and be a wise man on top of a hill?

Why not set yourself a goal to create an application that you can try and sell or one that you might give to others for free in exchange for feedback or even ask another programmer to look at so you can see if your approach is good? Perhaps consider making it open source so the community can give you help?

To quote an adapted phrase stuck on my cupboard undoubtedly created by someone else:

"If you want to set off and go develop some grand new thing, you don't need millions of pounds of funding. You need as much pizza and diet coke that your fridge can handle, a cheap PC, connection to internet (for SO) and the dedication to go through with it".

My practical jump-head-first advice:

  1. Set yourself an interesting but simple project - a project with lots of different features to help expand your skills in small ways but in a wide variety.
  2. Write a specification so you know what you want it to do. This may take a long time to create but this is more important than the implementation because it is an essential skill to learn (otherwise you will grow up to what we call a 'n00b') and it acts as your compass when your mind starts to get 'arty'.
  3. Try and make your code efficient - learn in detail as you go what specific code REALLY does- don't assume knowledge - really drill down and get clued up from any number of source e.g. video, books, internet, programmer next door
  4. Stick to your specification and have faith that you will be able to achieve what you have set yourself as a goal in your specification (unless you been silly! lol)

I believe that learning is all about the journey - but you have to be going somewhere first.

Thanks for the question - has made me think a little bit.

May I recommend SQL Server, C# 4.0, ASP.NET, Silverlight, WPF. Most the tools are completely free - so a cost effective way to get learning something which is popular and not on it's last legs like java (sorry java developers lol). But C# is very similar to Java anyway (sorry again java developers!)

Dan.

Dan B
The amount of work needed to create any modern non-trivial application actually used by others is so large that it takes more than one person to do. Hence, you _will_ need to work in a group, and need to be able to do it well, unless you want to do trivial applications.
Thorbjørn Ravn Andersen
A: 

The simple answer is to find a problem and solve it. Really, look around. Is there anything you think you can do better? Something lacking in software you use?

Find a problem and then solve it.

Patrick
+4  A: 

Ask someone dear to you, if there is something you could write that could help him or her, and then do it and do it well (the last part is the important one).

Thorbjørn Ravn Andersen
+8  A: 

But how can I learn to program something real, something useful?

I know this will sound tongue-in-cheek but here you go: find something useful and implement it :)

Things to look out for (while writing this I mostly thought of small projects, developed by yourself. The list will need modifying if you work in OSS projects):

  • keep it simple; if you make a very big design, a very large application, a complicated architecture and so on, you will probably never have anything working or finished (at least if you're like me :) ).

  • don't overextend yourself (don't try to make both the GUI, the database, the logic and the middle layer at the same time). If you overextend yourself you will never finish.

  • solve a real problem. Choose something that you could benefit from. The more removed you are from the utility of your code, the more your enthusiasm will go down.

  • work in small iterations. Make sure at the end of each iteration you have something that is working and can be tested. For example if you write a log parsing application, first write a small application that opens files and displays them (minimalist application that displays text files). Then, start enhancing and replacing parts of it, one at a time (like highlighting, column delimiters, regular expression highlighting and so on).

  • if the type of application allows for it, develop so as to have something usable at each iteration (following my previous example, after writing an application that opens text files, use it to open your text files and so on).

  • use source control. If possible, work with Mercurial or Git (seem to be one step above everything else).

  • for anything more than 1000 lines consider using unit testing and defect tracking software.

  • don't strive for perfect code. Strive to write good code, but working code beats perfect code any time (and takes a fraction of the effort). Write (mostly) decent code and avoid the type of code you will be ashamed to show somebody else :). Then, improve it as needed.

  • split everything you do into tasks that are at most 4-5 hours long. If they take more, split them into sub-tasks.

Should I buy a book and follow exercises, struggle through interesting projects, etc.?

You can do that, but I'd go with solving a real problem and only using books for references at this point.

In short, how did you guys transition from academic exercises to real, fun and/or useful programs?

First identify your needs, then pick a small one (something that gets solved relatively quick), then solve it. Rinse, repeat.

utnapistim
+3  A: 

"Fake it until you make it."

The best way to learn how to write commercial, production-ready code is to write commercial, production-ready code. Get a job in the software industry. Even if it's an entry-level position, even if you're only doing grunt QA work and writing no code at all, you'll learn a lot from it if you want to. You'll be working with seasoned professionals who are the masters of their craft, and you'll have access to all their tools, their knowledge, and their code base. Talk to everyone you can, and try to stretch yourself with tasks that are at the limit of your ability and knowledge. Then switch to another job with a bit more responsibility, repeat until you get bored or have enough to retire.

Ether
+1: as @Ether puts it: get a job.
High Performance Mark
A: 

As well as the other great tips here, try to find mentors (in projects / friends / work), keep coding and always reflect on your code. You will find your coding will get better.

If only I got a dollar every time I looked at my old code and thought "What was I thinking?"

Linz