How do you make programming fun (or at least less painful/frustrating)?

Question

I'm unemployed and I don't have that much programming experience. So I need to get experience and I figure the best way of doing so is programming my own projects. Now there are a few problems with this:

1) I have a hard time thinking of practical/fun projects that are within my ability to program.

2) I have a strong aversion to getting started and I get frustrated very easily. Usually I'll get a little bit done, then get an error and try to solve it a few different ways then get incredibly frustrated.

I'm very interested in the math and theory behind programming, it's just that the actual act is incredibly frustrating for me.

Answer 1

perhaps start with game programming ... it's a great intro to programming, and it certainly has the capacity to be fun :-) check out XNA

Answer 2

If you get frustrated by things not working properly, then programming is probably not for you. Everyone gets frustrated, but good programmers generally react to the "this is not working the way it should" challenge by digging in deeper rather than giving up. The best programmers know when this behavior has run its course and it is time to attack the problem in a different manner.

I find the challenge of solving hard problems what makes programming fun. Generally, the actual application I'm working on makes little difference to how much I enjoy the process, though some are much cooler to talk about later.

Answer 3

Not an exact duplicate, but you might check out this question: Hints for making programming even more pleasant.

Answer 4

I would recommend to read a good book and follow its examples. You should then soon figure out an interesting project of your own. Check out Head First programming books.

Answer 5

Programming is both fun and frustrating.

It's frustrating when you can't get things done.
It's fun when you can get things done.

Stick with it, or give up.

Answer 6

You have to take the good with the bad in this field, and the job will never be 100% pain-free. One thing that you need to do is find what is rewarding to you and make sure that you incorporate it in whatever way you can.

For example, I find it frustrating sometimes to work within the constraints of an iteration when it is nothing but fixing defects. As a reward, I will look for a way to incorporate something new to help not only fix the defect, but prevent it from mutating and occurring in other places. Maybe it is in implementing something new to manage flow within the code, or the beginning of a new library, etc.

The end goal is, though, you need to find a way to make good things out of a bad situation.

Answer 7

You definitely have to accept debugging (i.e. finding out why it doesn't work) as one of the primary challenges of development. If you only focus on "making it work", and consider finding/fixing/preventing bugs a frustrating waste of time, you will be frustrated most of the time.

If you look at developers books, forums, education, you will notice that 90% of the discussions are not concerned about "making it work". Often will approaches that works perfectly fine be derided as bad and ugly. When developers say "ugly", they really mean "hard to maintain" which basically means "easy to break and hard to debug". Experienced developers know that their primary focus is to write code that is hard to break and easy to debug, and that is the main challenge of the programming profession.

When you accept debugging (and its flip side - preventing bugs in the first place) as the primary challenge, you will start incorporating methods to make debugging easier and less painful. For example, when I have found a bug that was hard to locate, I ask myself how I could make it easier to locate this class of bugs in the future. If a program terminates with an obscure error message, I always try to improve the error handling to be more helpful before I fix the actual bug.

Some development approaches like unit tests makes it easier to locate and fix bugs because you test small parts of the program in isolation. If one unit test indicates a bug, you know the bug is found in the unit under test (or in the specific test :-)) - you don't have to investigate the whole program to locate the bug.

"Test driven development" may be an antidote to your frustrations. In TDD, you write a test first, and watch it fail, before you implement the feature under test. If you discover a bug, you have to write a test to expose it, before you are allowed to fix the bug. This approach may be helpful for you, because it turns the failure of the test into a small victory.

Answer 8

Constantly learning new languages, techniques, patterns, etc... will make your programming experience a dynamic and live one.

This is an ever changing career-line and if you can't keep up, the boat will leave without you.

Answer 9

Given what you've said, especially

I'm very interested in the math and theory behind programming

I wonder if programming might be a bad fit for you and that you might find testing more interesting?

Though still quite often the case in many companies, the days of testers being only new or junior employees are beginning to end.

At enlightened companies, they realise that testing needs to be much more than an afterthought bolted on at the end of a project. Testing forms an integral part of the development of the project itself. Testers are not treated as second-class programmers who can't program.

Maybe have a read of Gerald Weinberg's new book "Perfect Software: And Other Illusions about Testing" (Amazon link)

BTW Your interest in maths might also reveal an interest in code review and lambda calculus.

HTH

cheers,

Rob

Answer 10

If you get stuck then request help from your programming colleagues, many of which are on this site. A collaborative programming effort with a partner can also be very helpful to get out of those "stuck" phases. And then you can pay it forward by helping others in the same boat. That's what this site is about and you are off to a good start by asking now.

Answer 11

I'd actually go with Joel Martinez (who downwoted it anyway?) Programming games was the most fun part when I first started coding. Of course, today it's a bit different because a game is expected to contain shiny graphics and stunning sounds. But there are still plenty smaller games that don't need that many graphics - like board games, card games, etc. Math skills are quite needed there too.

Start with simple things and advance one step at a time. Don't try to make a big program all at once. Make your first projects small.

Answer 12

I think it is a good idea to try programming things that you understand very well. So for instance:

1. start with a calculator
2. something more complex: a calculator that plots graphs (ie enter a function it plots it)
3. Tic-tac-toe (ie noughts and crosses)
4. Anagram generator

You like maths. Solve differential equations. Try to determine if a number is prime.... etc

As you build your skills you can try to work with other coders (many projects at http://sourceforge.net/) and do things that you enjoy or personally find useful.

Who knows, you might even make some cash!

Answer 13

I'd say its discipline. If you expect to just drop into an application and start tapping away at the keys and everything just magically happens for you, and they you can forget the boring bits like documentation, comments, structured design.... then your life as a programmer will always be disappointing.

See, if you do take the time to do it at least semi properly, then you'll find that things fall into place much more readily. When you come back to code you won't say "which moron wrote thi.. oh, it was me", you'll instead find that its easy to get back working with it, it'll be much more likely to do what you want, and you'll be able to understand what and why you did with it originally.

It will not give you instant coding gratification, but you'll really appreciate it in the long run.

Answer 14

If you don't have a project of your own to work on, working on an open source project is an option. A well run project should have a backlog of bugs and feature requests that would provide a range of simple to challenging tasks. You might also make some new contacts through the project that could include a mentor or future colleague.

Speaking of which, a mentor might be very valuable in your situation, since there are going to be countless questions and speed bumps during this learning process. I realize that SO is kind of a cloud of mentors, but having the same person to turn to for even a few weeks at a time would be ideal.

As far as making software development (or any knowledge work) more fun, I would say that you've got to combine first-hand learning with more traditional "book" learning, which should contain blogs and possibly magazines as well. This way you can both figure out your own style (and make your own mistakes) while considering new ideas from varied sources. As you learn, you gain the foresight to avoid or mitigate the frustrating parts (bugs, repetitive code, dealing with IE for web developers) and get to the rewarding parts.

On top of all that, if you're not interested/invested in what the project accomplishes or how it is accomplished, then it's probably going to bore or frustrate you. A little perspective on this can go a long way.

Answer 15

It sounds like you are not yet at the stage where you can build interesting whole projects. Instead, you need to find small interesting problems that will help you learn. A problem is something you might do in an hour or a day, depending on difficulty. A project might take weeks or months.

A good book full of fun problems for the beginning programmer and also great stories is Programming Pearls by Jon Bentley. The chapters are small, make enjoyable reading, and there are good problems at the end of each chapter. Some answers are in the back of the book.

For a very different experience download a copy of PLT Scheme and work your way through The Little Schemer.

I personally loved Bentley and found The Little Schemer too cutsie-pie for my taste, but between these two works in such highly different styles there is more chance that you will find something you like.

Answer 16

You should find a task or project that interests you, that also incidentally requires some programming to get done. I don't find writing code to be very satisfying unless it's solving some useful problem or building something interesting.

If you can't find any projects that are interesting to you, I would say the best way to get experience is on the job. This provides the motivation to get things done. It might be painful at first, but many entry-level jobs are pretty chill and give you time to learn the language, make mistakes, look up tutorials and examples, etc. Once you finally have working code that somebody will actually use to do cool stuff with, it's very satisfying. Even if the problem domain isn't inherently interesting, I enjoy programming because it gives me creative freedom to come up with technological solutions that make people's lives easier.

As far as getting frustrated, start very small and get just a very small part working. Then add features one at a time, making sure each feature works before moving on.

Answer 17

I'd suggest some competition would be good for you, it's usually what makes me going further and further in solving a challenge. You could find a buddy who has about the same or a little better experience and try to solve couple of dozens problems from Project Euler either in pair or against each other. You could do it alone if you don't have any interested in programming friends of course but it's not that much fun.

Another option would be to participate in developers community groups, a lot of smart people attending them and you can not only learn a thing or two from them but also overcome your fear of pushing the task to the end. I'd suggest Haskell or OCaml related since they more close to academia and math, which is much more fun then serialization of objects or other technology related stuff.

Answer 18

Move away from COBOL.