Jump to content
Can't remember your login details? Read more... ×
Kung Fu Hung-Su

I'm bored of programming

Recommended Posts

Right now, maths, algorithms, programming...I find it all horribly dull. Who'da thunk huh? I've been using computers unattended since I was 4, had my first whiff of primitive programming with ZZT by Epic Megagames sometime in the mid 90s, was once quite the geek, entering chess maths and IT competitions etc, I bought two 24" monitors to help me see more code, am now finishing up my 3rd year in a Software Engineering degree...and finding programming painfully uninteresting. Not a good thing with another year to go.

 

Have any of you had a time when you just thought lines of code were boring as shit? What did you do?

 

 

 

Atm, I'm looking at the problems over on ProjectEuler but it's not helping too much. I'm thinking of taking a note out of xkcd and learning Python as a break from the usual C and Java.

 

Maybe looking for some slightly more fun text editors and monospace fonts too. Currently using the Dina font and Notepad++.

 

 

 

Anyone have any other suggestions to make programming fun?

Share this post


Link to post
Share on other sites

Why did you decide to study programming? Maybe the answer to that question will help you "get back on track".

 

We all get bored from time-to-time. There are times when I wish like crazy I didn't like software development so much. Mainly because the effort of continual learning can sometimes be just that, an effort. Especially when time outside of work is at a premium.

 

Programmers are constructionists. We like to build from scratch and take control of our designs (at least I do!).

 

The most boring times were when I was doing maintenance programming. Specifically simple defect fixing, or at least, not thinking up new classes and interactions. But that's the way software development goes. You might have 9 months where you're flat out 12 hours a day, and then a lul for a few months, where you're primarily doing defect fixes or "skills upkeep" (reading blogs :)).

 

When I was in a particularly boring span, I'd grab existing software designs and re-engineering them. Nothing official source control or part of the product plan though, just keeping code on my pc and trying a few things I wanted to try in the busy periods but didn't have time.

 

Any suggestions I give you to make programming fun aren't going to last, because when you graduate and start coding 8hrs a day, you don't have a choice. You'll either love programming (enough to put up with the boring work from time to time) or you'll quit and find another career. (Or just put up with it and live a miserable unfulfilled life :p)

 

Going back to my original question, how to bring back the fun depends on what you enjoy about programming. What do you love and hate about development?

Share this post


Link to post
Share on other sites

We all get bored from time-to-time.

This.

 

When it happens, I generally just take a break. If you can't do that, it's unfortunate, but if you can just take a little break, you'll usually come back with renewed enthuasism.

Share this post


Link to post
Share on other sites

I'm lucky, I'm programmer and SysAdmin so I never have whole days of one thing at work.

When I was a programmer I called that unlucky :p Never get a solid days work done, constantly interrupted by inane request from support to do this or that. Context switches killed the productivity.

Share this post


Link to post
Share on other sites

Programmers are constructionists. We like to build from scratch and take control of our designs (at least I do!).

This.

 

If I get bored, I like to jump to another contsructive activity of a different nature for a while, it's a breath of fresh air.

Share this post


Link to post
Share on other sites

Why did you decide to study programming? Maybe the answer to that question will help you "get back on track".

No reason, actually. Because I did IT in college, and everyone expected me to continue cos I kept topping class. And I did IT in college because I did IT in High School. And everyone expected me to continue cos I kept topping class. Etc...

 

Any suggestions I give you to make programming fun aren't going to last, because when you graduate and start coding 8hrs a day, you don't have a choice. You'll either love programming (enough to put up with the boring work from time to time) or you'll quit and find another career. (Or just put up with it and live a miserable unfulfilled life :p)

You're probably correct, no little tip will help me like programming any more or less than I currently do. I don't expect or want to get permanently ingrained in software dev career path.

 

Going back to my original question, how to bring back the fun depends on what you enjoy about programming. What do you love and hate about development?

"Marketing" it probably! Writing doco about why my stuff is awesome and how to use it. I don't understand how other students are so freaking bad at writing good doco, I think it's unbelievably easy. I look at almost all open source projects today and even many commercial products and cringe at the absolutely freaking horrendous doco and other material available.

 

I find working on software and software modules itself to be rather boring. Learning new languages of different levels, writing lines of code, reading up on how to use whatever libraries I need, debugging, etc...bleh. Running it, tweaking it, testing it and writing about it is the fun part.

 

When it happens, I generally just take a break. If you can't do that, it's unfortunate, but if you can just take a little break, you'll usually come back with renewed enthuasism.

I'll get a 3 month break in a few weeks. Hope that'll be enough!

Share this post


Link to post
Share on other sites

Oh I forgot the key thing which renews my interest in software developement

 

 

kaching! :p

 

What do you mean by documents? Do you mean creating design documents? writting spec documents? test documents? Document output is probably 30%-50% of the work of a software project (as opposed to maybe 30% implementation). Unfortunately documenation is usually left to senior engineers and architects (or maybe analysts) and you can't skip junior to get to senior :). Reminds me of a team member I had on a project I did at uni. He couldn't code worth a damn but his excuse was "I want to be an analyst so I don't need to know how to code." of course, knowing how to code, in my book, means knowing about classes and interactions and software design. Spend enough time thinking about and impementing designs and you're on your way to becoming an architect and writting all the docs you want. Junior testers write documentation too, so you could get into that (snoring) section.

 

Have a read through this article, which in my experience accurately portrays the roles you could find yourself in the software development stream of IT.

Share this post


Link to post
Share on other sites

Oh I forgot the key thing which renews my interest in software developement

 

 

kaching! :p

 

What do you mean by documents? Do you mean creating design documents? writting spec documents? test documents? Document output is probably 30%-50% of the work of a software project (as opposed to maybe 30% implementation). Unfortunately documenation is usually left to senior engineers and architects (or maybe analysts) and you can't skip junior to get to senior :). Reminds me of a team member I had on a project I did at uni. He couldn't code worth a damn but his excuse was "I want to be an analyst so I don't need to know how to code." of course, knowing how to code, in my book, means knowing about classes and interactions and software design. Spend enough time thinking about and impementing designs and you're on your way to becoming an architect and writting all the docs you want. Junior testers write documentation too, so you could get into that (snoring) section.

 

Have a read through this article, which in my experience accurately portrays the roles you could find yourself in the software development stream of IT.

Heh, yeah writing doc certainly does take a long time! I mean just about any kind of doc, technical stuff like design, requirements, specifications, manuals and so forth, to pretty stuff like website blurbs =) I certainly will not make an excuse that I don't need to learn to code, writing documentation about code certainly requires understanding only gained from writing code!

 

Article looks curious, thanks for the link =)

Share this post


Link to post
Share on other sites

Most people will get bored with it after a while. Nothing surprising about it, it happens, then your interest gets renewed etc, and you might find it fun again.

 

"Marketing" it probably! Writing doco about why my stuff is awesome and how to use it. I don't understand how other students are so freaking bad at writing good doco, I think it's unbelievably easy. I look at almost all open source projects today and even many commercial products and cringe at the absolutely freaking horrendous doco and other material available.

 

I find working on software and software modules itself to be rather boring. Learning new languages of different levels, writing lines of code, reading up on how to use whatever libraries I need, debugging, etc...bleh. Running it, tweaking it, testing it and writing about it is the fun part.

Keep these thoughts in mind if you get a job in software. Find your feet, and if you still feel this way, make sure your employer knows about it.

 

There are (at the extremes) 2 ways for your career to run - Controlled and Uncontrolled. most people I know who are happy with their job it's because their careers are more controlled - they didn't just fall into being something, they deliberately picked a direction and headed there - and a big part of that is making your employer aware of it (through formal performance/development reviews, or through discussions around the coffee pot).

 

Consider the type of working you want to do. There are ways to achieve variety in software development.

I know contractors that basically spend 90% of their time coding, they join a project for 3-12 months during the coding phase, code like crazy and then move on. They get their variety by repeating the same lifecycle step on lots of different systems/languages/environments.

Other people stick with one project and get the variety by following the project through several stages (requirements->design->implementation->unittest->integration->systemtest etc.)

 

Smaller companies tend to have more options for you to do more parts of the software development process, however for really small companies, the projects are smaller and there's usually a lot less that goes on outside the design->implement->test stages.

large companies tend to have more defined roles, so junior people won't get as much opportunity to do lots of things, but they're also big enough to support people creating niches for themselves if they want to be a specialist.

 

Medium companies are I find the sweet spot if you like lifecycle variety, reasonably flat development team structure, with projects that run for a decent time.

Share this post


Link to post
Share on other sites

Right now, maths, algorithms, programming...I find it all horribly dull. Who'da thunk huh? I've been using computers unattended since I was 4, had my first whiff of primitive programming with ZZT by Epic Megagames sometime in the mid 90s, was once quite the geek, entering chess maths and IT competitions etc, I bought two 24" monitors to help me see more code, am now finishing up my 3rd year in a Software Engineering degree...and finding programming painfully uninteresting. Not a good thing with another year to go.

 

Have any of you had a time when you just thought lines of code were boring as shit? What did you do?

Music =o) Nothing breaks up the monotony like a good jam or you could like, go outside... =oP

 

On occasion just going into the garage and making something, a project that isn't related to IT (although often you can think of ways to add IT functionality).

 

Atm, I'm looking at the problems over on ProjectEuler but it's not helping too much. I'm thinking of taking a note out of xkcd and learning Python as a break from the usual C and Java.

Yes! Python is a very nice language that helps you skip over all the repetitive and boring skeleton code you need with C. That and it is by design nice to look at.

 

Anyone have any other suggestions to make programming fun?

I like projects where I'm producing a tool that I will use myself, there is a lot more satisfaction in using a tool you have built yourself.

Share this post


Link to post
Share on other sites

Heh, yeah writing doc certainly does take a long time! I mean just about any kind of doc, technical stuff like design, requirements, specifications, manuals and so forth, to pretty stuff like website blurbs =) I certainly will not make an excuse that I don't need to learn to code, writing documentation about code certainly requires understanding only gained from writing code!

There's a huge difference between writing requirements, design, and manual doco. All 3 types are hugely different, and very few people I know are good at all 3.

 

It takes a lot of work to make designers good requirements writers, and both design and requirements writers usually make lousy manual writers.

 

If I was to suggest an order:

Learn to Code

Learn to write design Doco

Learn to put to the side what you think is good design doco, and learn to write informal test doco.

Take what you know about informal test doco and then learn to write formal test doco.

Take everything you learned (and all the things you cursed about) while writing test doco, and you'll be well on your way to writing formal requirements doco.

Completely empty your mind of everything you've learned about code, design, test and requirements and try and write manuals (either user or maintenance - not both at the same time)

 

It's all about audience. By the time you've finished uni degree that involves programming, you've lost your ability to get in the user or maintainer headspaces, and you're entrenched in the coder headspace.

You can write code and design for other people like yourself to read (given the enthusiasm and time to do so - most "poor" design doco is usually either out of date or lacking depth, rather than badly targeted)

There's a risk of course that after several years of coding, then advancing to higher levels of design, you start to become detached from how low level coders think - it happens more than you think.

But the coder headspace is focused on why and how it works, not does it work, and good test doco is abstracted from that - so is requirements, both fit a more legalese headspace.

The problem is that the test/requirements headspace is all about abstract definitions of the capability, and that's no good to the end-user/maintainers.

They want tangible information for someone who doesn't know what the product is about - but they don't want to know the how/wht that the coder/designer does, nor do they care about legalese.

Share this post


Link to post
Share on other sites

Most people will get bored with it after a while. Nothing surprising about it, it happens, then your interest gets renewed etc, and you might find it fun again.

 

"Marketing" it probably! Writing doco about why my stuff is awesome and how to use it. I don't understand how other students are so freaking bad at writing good doco, I think it's unbelievably easy. I look at almost all open source projects today and even many commercial products and cringe at the absolutely freaking horrendous doco and other material available.

 

I find working on software and software modules itself to be rather boring. Learning new languages of different levels, writing lines of code, reading up on how to use whatever libraries I need, debugging, etc...bleh. Running it, tweaking it, testing it and writing about it is the fun part.

Keep these thoughts in mind if you get a job in software. Find your feet, and if you still feel this way, make sure your employer knows about it.

 

There are (at the extremes) 2 ways for your career to run - Controlled and Uncontrolled. most people I know who are happy with their job it's because their careers are more controlled - they didn't just fall into being something, they deliberately picked a direction and headed there - and a big part of that is making your employer aware of it (through formal performance/development reviews, or through discussions around the coffee pot).

 

Consider the type of working you want to do. There are ways to achieve variety in software development.

I know contractors that basically spend 90% of their time coding, they join a project for 3-12 months during the coding phase, code like crazy and then move on. They get their variety by repeating the same lifecycle step on lots of different systems/languages/environments.

Other people stick with one project and get the variety by following the project through several stages (requirements->design->implementation->unittest->integration->systemtest etc.)

 

Smaller companies tend to have more options for you to do more parts of the software development process, however for really small companies, the projects are smaller and there's usually a lot less that goes on outside the design->implement->test stages.

large companies tend to have more defined roles, so junior people won't get as much opportunity to do lots of things, but they're also big enough to support people creating niches for themselves if they want to be a specialist.

 

Medium companies are I find the sweet spot if you like lifecycle variety, reasonably flat development team structure, with projects that run for a decent time.

 

Interesting. I'll muse on this. =)

 

Right now, maths, algorithms, programming...I find it all horribly dull. Who'da thunk huh? I've been using computers unattended since I was 4, had my first whiff of primitive programming with ZZT by Epic Megagames sometime in the mid 90s, was once quite the geek, entering chess maths and IT competitions etc, I bought two 24" monitors to help me see more code, am now finishing up my 3rd year in a Software Engineering degree...and finding programming painfully uninteresting. Not a good thing with another year to go.

 

Have any of you had a time when you just thought lines of code were boring as shit? What did you do?

Music =o) Nothing breaks up the monotony like a good jam or you could like, go outside... =oP

 

On occasion just going into the garage and making something, a project that isn't related to IT (although often you can think of ways to add IT functionality).

 

Atm, I'm looking at the problems over on ProjectEuler but it's not helping too much. I'm thinking of taking a note out of xkcd and learning Python as a break from the usual C and Java.

Yes! Python is a very nice language that helps you skip over all the repetitive and boring skeleton code you need with C. That and it is by design nice to look at.

 

Anyone have any other suggestions to make programming fun?

I like projects where I'm producing a tool that I will use myself, there is a lot more satisfaction in using a tool you have built yourself.

 

(un)fortunately for me, being a Windows vet, there's a free application for just about every need I require. Except...batch video conversion. Hmm.

 

Heh, yeah writing doc certainly does take a long time! I mean just about any kind of doc, technical stuff like design, requirements, specifications, manuals and so forth, to pretty stuff like website blurbs =) I certainly will not make an excuse that I don't need to learn to code, writing documentation about code certainly requires understanding only gained from writing code!

There's a huge difference between writing requirements, design, and manual doco. All 3 types are hugely different, and very few people I know are good at all 3.

 

It takes a lot of work to make designers good requirements writers, and both design and requirements writers usually make lousy manual writers.

 

If I was to suggest an order:

Learn to Code

Learn to write design Doco

Learn to put to the side what you think is good design doco, and learn to write informal test doco.

Take what you know about informal test doco and then learn to write formal test doco.

Take everything you learned (and all the things you cursed about) while writing test doco, and you'll be well on your way to writing formal requirements doco.

Completely empty your mind of everything you've learned about code, design, test and requirements and try and write manuals (either user or maintenance - not both at the same time)

 

It's all about audience. By the time you've finished uni degree that involves programming, you've lost your ability to get in the user or maintainer headspaces, and you're entrenched in the coder headspace.

You can write code and design for other people like yourself to read (given the enthusiasm and time to do so - most "poor" design doco is usually either out of date or lacking depth, rather than badly targeted)

There's a risk of course that after several years of coding, then advancing to higher levels of design, you start to become detached from how low level coders think - it happens more than you think.

But the coder headspace is focused on why and how it works, not does it work, and good test doco is abstracted from that - so is requirements, both fit a more legalese headspace.

The problem is that the test/requirements headspace is all about abstract definitions of the capability, and that's no good to the end-user/maintainers.

They want tangible information for someone who doesn't know what the product is about - but they don't want to know the how/wht that the coder/designer does, nor do they care about legalese.

 

I agree completely, there are many kinds of doco, and I'm certainly not good at all of them. I admit I'm pretty damn good at writing manuals, and not so great at requirements specs. I don't think I'll ever lose my ability to get into user headspace, I talk and listen too much, but also admittedly I am not a spectacular coder.

 

 

 

This thread is bookmarked, heh.

Share this post


Link to post
Share on other sites

A lot of good advice in this thread. Let me suggest something on the coding side of things.

 

From what you've described it definitely sounds like you'd be much better suited for development with a dynamic language. There's more of the running, tweaking and testing, and less of the coding boiler plate.

 

There's a lot of stories of web developers out there who'd been coding for years on .NET or Java platforms who'd just gotten bored with it before their enthusiasm was revived with frameworks like Django or Rails (Python and Ruby respectively).

 

Stick to one of these, I think. I'm biased, I prefer Ruby. Probably partly because it makes metaprogramming easier (which you probably don't care about :P), less effort for sophisticated class management (which you may care about), and because it can be adapted to a much more declarative style (which you probably would care about).

 

Why? Have a look at RSpec: http://rspec.info/

 

RSpec is a behaviour driven development suite (BDD is kind of like test driven development with a specific focus shift). The idea is you write out a behavioural spec before you code anything, then you run the behavioural spec on your code to make sure it complies.

 

Unfortunately syntax that is so close to your problem domain isn't possible in Python, although you'd still prefer that language over Java I can guarantee it :)

 

Anyway, good luck with your searching.

Share this post


Link to post
Share on other sites

A lot of good advice in this thread. Let me suggest something on the coding side of things.

 

From what you've described it definitely sounds like you'd be much better suited for development with a dynamic language. There's more of the running, tweaking and testing, and less of the coding boiler plate.

 

There's a lot of stories of web developers out there who'd been coding for years on .NET or Java platforms who'd just gotten bored with it before their enthusiasm was revived with frameworks like Django or Rails (Python and Ruby respectively).

 

Stick to one of these, I think. I'm biased, I prefer Ruby. Probably partly because it makes metaprogramming easier (which you probably don't care about :P), less effort for sophisticated class management (which you may care about), and because it can be adapted to a much more declarative style (which you probably would care about).

 

Why? Have a look at RSpec: http://rspec.info/

 

RSpec is a behaviour driven development suite (BDD is kind of like test driven development with a specific focus shift). The idea is you write out a behavioural spec before you code anything, then you run the behavioural spec on your code to make sure it complies.

 

Unfortunately syntax that is so close to your problem domain isn't possible in Python, although you'd still prefer that language over Java I can guarantee it :)

 

Anyway, good luck with your searching.

+1 I was sick of coding websites. This mainly came down to doing it in either Java or PHP. I switched the Django and I am much happier. At work its Java or C#, for anything for myself Django. I picked it mainly because I was more familiar with Python then Ruby. Python also really opened my eyes. I found once I switched to it I spent more time solving the problem then proving to the compiler I knew how to create objects etc...

Share this post


Link to post
Share on other sites

Go learn a different language, one that makes you approach things slightly differetly.

 

Python/Ruby would be a good start :)

Share this post


Link to post
Share on other sites

I was falling asleep during the 'Software Enginerring' unit in the second semester of the Software Engineering degree at ECU in 1997 and planned to struggle through it. The day the lecturer told us this was what we'd be doing in the workforce was the day I withdrew.

 

From there I did plenty of private study and scored a job as an entry-level tech at Harvey Norman and learned as much as I could. Took my skills to a NSW TAFE institute and ran the helpdesk.

 

Then I changed career altogether 5 years ago and haven't looked back :)

Share this post


Link to post
Share on other sites

I was falling asleep during the 'Software Enginerring' unit in the second semester of the Software Engineering degree at ECU in 1997 and planned to struggle through it. The day the lecturer told us this was what we'd be doing in the workforce was the day I withdrew.

 

From there I did plenty of private study and scored a job as an entry-level tech at Harvey Norman and learned as much as I could. Took my skills to a NSW TAFE institute and ran the helpdesk.

 

Then I changed career altogether 5 years ago and haven't looked back :)

I'm assuming the software engineering course is the one about requirements gathering, spec writing etc? I to would cringe if if I had to do that, thankfully there are Business Analysts that do that job.

Share this post


Link to post
Share on other sites

I dunno about coding...

 

But when I get bored of travelling around photographing landscapes, I photograph pretty girls, when I get bored of that I find actual models to photograph, when I get bored of that I do nude shoots... when I get bored of that I go back to landscapes, seems to work well.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×