How to stop wasting time programming?
May 1, 2007 1:57 PM Subscribe
Why do I always take the long route when programming? I'm no master programmer - but - I feel like I'm missing something. I'm constantly finding myself trying to tear down one wall or another, in attempt to resolve some issue, only to find halfway into it, that there was a ten minute fix right in front of me. Complications fade away, problem solved.
I'm no master programmer - but - I feel like I'm missing
My current process is: Big to small, broad to specific. In my mind that seems to be golden - but in practice I can waste hours working out a problem that was misconceived to begin with.
Though I think to a degree it is epiphany, but its happening too often for that to be the case. It has become almost part of my work process - one I would like to stop. I was wondering if there is some sort of strict method developing code that might save me some cycles and have me stop wasting time.
I'm no master programmer - but - I feel like I'm missing
My current process is: Big to small, broad to specific. In my mind that seems to be golden - but in practice I can waste hours working out a problem that was misconceived to begin with.
Though I think to a degree it is epiphany, but its happening too often for that to be the case. It has become almost part of my work process - one I would like to stop. I was wondering if there is some sort of strict method developing code that might save me some cycles and have me stop wasting time.
Well, how long have you been doing it? It's all about adding tools to your toolbox.
Don't program in the dark. Talk to other people about how you plan to implement something before you do it. Bounce ideas off your peers. Find groups to post it to, etc.
posted by jeffamaphone at 2:16 PM on May 1, 2007 [1 favorite]
Don't program in the dark. Talk to other people about how you plan to implement something before you do it. Bounce ideas off your peers. Find groups to post it to, etc.
posted by jeffamaphone at 2:16 PM on May 1, 2007 [1 favorite]
Maybe look into UML, and start modeling/drawing out your programs before you start coding anything. I usually have a good idea of what the structure I'm going to be working on is before I commit anything to disk, and I rarely have to go back and rework things.
posted by fnerg at 2:16 PM on May 1, 2007
posted by fnerg at 2:16 PM on May 1, 2007
To me, the best tool I have at hand is the ability to reduce the problem to it's smallest components while keeping an eye to the big picture. Here's my usual train of thought:
1. Look at the problem, and the surrounding landscape. Is it actually part of a larger process? Could it be done elsewhere more efficiently, or can I make this part easier by doing more processing elsewhere?
2. What am I actually trying to do? Am I using a technique that does that, or am I using a screwdriver to hammer in nails?
3. Is there a design pattern that covers what I'm doing? There's no reason to reinvent the wheel if I can apply an off-the-shelf pattern to churn out code a little faster. Go with known quantities.
You're going to end up stopping and rewriting code eventually. That's part of why modern development tools include so many facilities for refactoring and source control gives you the ability to backtrack versions. Use the tools you're given!
posted by mikeh at 2:21 PM on May 1, 2007
1. Look at the problem, and the surrounding landscape. Is it actually part of a larger process? Could it be done elsewhere more efficiently, or can I make this part easier by doing more processing elsewhere?
2. What am I actually trying to do? Am I using a technique that does that, or am I using a screwdriver to hammer in nails?
3. Is there a design pattern that covers what I'm doing? There's no reason to reinvent the wheel if I can apply an off-the-shelf pattern to churn out code a little faster. Go with known quantities.
You're going to end up stopping and rewriting code eventually. That's part of why modern development tools include so many facilities for refactoring and source control gives you the ability to backtrack versions. Use the tools you're given!
posted by mikeh at 2:21 PM on May 1, 2007
You don't say if you're educated as a computer scientist, but in my experience this is exactly where people who have picked up coding often get kneecapped. There's a real value in having studied the smallest pieces and overarching concepts.
So, if you're not, you might want to pick up a book on algorithms that would be used in an intermediate programming class.
The other way I see this manifest itself in a big way is just experience. There's a lot of people in the industry who view each programming language or platform as if it's some new and unique thing and a compartmentalized practice. The reality is that we solve the same old problems the same ways, over and over again. Those missteps you make are painful and frustrating but you shouldn't be upset by them unless you find yourself making the -same-ones- over and over again.
posted by phearlez at 3:01 PM on May 1, 2007 [1 favorite]
So, if you're not, you might want to pick up a book on algorithms that would be used in an intermediate programming class.
The other way I see this manifest itself in a big way is just experience. There's a lot of people in the industry who view each programming language or platform as if it's some new and unique thing and a compartmentalized practice. The reality is that we solve the same old problems the same ways, over and over again. Those missteps you make are painful and frustrating but you shouldn't be upset by them unless you find yourself making the -same-ones- over and over again.
posted by phearlez at 3:01 PM on May 1, 2007 [1 favorite]
How to become better at programming...
How to become better at go...
How to become better at chess...
How to become better at math...
How to become better at intellectual puzzles...
...for dummies.
Coding is hard. The usual tricks for becoming a better programmer include: complete an undergrad degree in computer science, read the classic textbooks on programming, learn a new programming language, learn functional programming, read the source code of an open source project, become friends with a super programmer and convince him to share a coding project with you, and practice practice practice.
I was wondering if there is some sort of strict method developing code that might save me some cycles and have me stop wasting time.
The entire industry is wondering that too. "The civil engineers seems to have brought bridge design down to a strict method", they will say, "why can't we do the same thing with software?" The short answer is, there is no such method, and programming is much more difficult than bridge design.
You can think of the content of an undergraduate degree in computer science as the collection of all the best ideas on how to program. It is the closest you will get to a "strict method." Perhaps you should enroll.
If what you looking for is a silver bullet, a programming trick to make all your hardship disappear, watch your money. Lots of people sell that silver bullet, but it's always made of tin.
posted by gmarceau at 3:01 PM on May 1, 2007 [2 favorites]
How to become better at go...
How to become better at chess...
How to become better at math...
How to become better at intellectual puzzles...
...for dummies.
Coding is hard. The usual tricks for becoming a better programmer include: complete an undergrad degree in computer science, read the classic textbooks on programming, learn a new programming language, learn functional programming, read the source code of an open source project, become friends with a super programmer and convince him to share a coding project with you, and practice practice practice.
I was wondering if there is some sort of strict method developing code that might save me some cycles and have me stop wasting time.
The entire industry is wondering that too. "The civil engineers seems to have brought bridge design down to a strict method", they will say, "why can't we do the same thing with software?" The short answer is, there is no such method, and programming is much more difficult than bridge design.
You can think of the content of an undergraduate degree in computer science as the collection of all the best ideas on how to program. It is the closest you will get to a "strict method." Perhaps you should enroll.
If what you looking for is a silver bullet, a programming trick to make all your hardship disappear, watch your money. Lots of people sell that silver bullet, but it's always made of tin.
posted by gmarceau at 3:01 PM on May 1, 2007 [2 favorites]
It's common, once you've found an elegant solution, to wonder why it was you didn't see it instantly. More experience and maturity in the art will show you that what's obvious in retrospect isn't always obvious going forward, and the fact that you had to struggle to find that elegant solution doesn't necessarily represent a character defect.
posted by Steven C. Den Beste at 3:06 PM on May 1, 2007
posted by Steven C. Den Beste at 3:06 PM on May 1, 2007
That's what programmers do -- at least that's what good programmers do-- refactor stuff to make it better. Ever heard the bit about genius is one percent inspiration and 99 percent perspiration?
Programming is actually very hard to do well. And the preceding analysis likewise. So a lot of good programmers spend a lot of time rethinking things -- why do you think the figures for commercial code production show such a low count of lines per day? The problem isn't writing the code, but writing the right code.
Obviously experience helps. And good modelling helps. And not rushing to code before you have developed a good feel for the behaviour of the key objects/functions.
I agree with fnerg that UML offers useful thinking tools, but unfortunately too many of them for most projects -- look at some lite version, find a simple teaching (not reference) book, or pick your own pieces from the armory. And reading some of the pattern literature will give you useful ideas about overall architecture.
You don't really need anything that you can't pick up in a few years of hard slog, providing you range widely enough, as gmarceau indicates.
posted by Idcoytco at 3:23 PM on May 1, 2007
Programming is actually very hard to do well. And the preceding analysis likewise. So a lot of good programmers spend a lot of time rethinking things -- why do you think the figures for commercial code production show such a low count of lines per day? The problem isn't writing the code, but writing the right code.
Obviously experience helps. And good modelling helps. And not rushing to code before you have developed a good feel for the behaviour of the key objects/functions.
I agree with fnerg that UML offers useful thinking tools, but unfortunately too many of them for most projects -- look at some lite version, find a simple teaching (not reference) book, or pick your own pieces from the armory. And reading some of the pattern literature will give you useful ideas about overall architecture.
You don't really need anything that you can't pick up in a few years of hard slog, providing you range widely enough, as gmarceau indicates.
posted by Idcoytco at 3:23 PM on May 1, 2007
When you find the easy solution quickly, it just seems easy, not like you're smart and clever.
posted by smackfu at 3:24 PM on May 1, 2007
posted by smackfu at 3:24 PM on May 1, 2007
I think that there are two separate problems here.
1. Implementation.
I'm guessing that you have fairly "hacky" habits (like me). This is a design issue. So long as you factor things out into bite sized subroutines (be aware of when you start writing spaghetti code and factor the spaghetti out into nice bits of filled pasta) this part should fix itself as you increase in experience.
2. Finding the right tool.
I hit this problem with stats programming. I start a job working with one tool, and realise a long way down the track that with a little more mental effort and discipline, the other tool will solve the problem much more quickly. So I reimplement using the correct tool very quickly and I've wasted time using the wrong tool. Experience and keeping a good searchable archive of the code that I've worked on in the past (with comments etc.) helps me learn from my mistakes so that next time I'm less likely to make this mistake. The problem here is realising that the mental effort required to use the correct tool is much smaller than the effort required to use the "simple" tool and then work around the defficiencies caused by the apparent simplicity of the solution I work for first.
posted by singingfish at 4:22 PM on May 1, 2007
1. Implementation.
I'm guessing that you have fairly "hacky" habits (like me). This is a design issue. So long as you factor things out into bite sized subroutines (be aware of when you start writing spaghetti code and factor the spaghetti out into nice bits of filled pasta) this part should fix itself as you increase in experience.
2. Finding the right tool.
I hit this problem with stats programming. I start a job working with one tool, and realise a long way down the track that with a little more mental effort and discipline, the other tool will solve the problem much more quickly. So I reimplement using the correct tool very quickly and I've wasted time using the wrong tool. Experience and keeping a good searchable archive of the code that I've worked on in the past (with comments etc.) helps me learn from my mistakes so that next time I'm less likely to make this mistake. The problem here is realising that the mental effort required to use the correct tool is much smaller than the effort required to use the "simple" tool and then work around the defficiencies caused by the apparent simplicity of the solution I work for first.
posted by singingfish at 4:22 PM on May 1, 2007
If you realize there's a better way to solve a problem, you're already way ahead of most people.
Either find a coworker or trap the spanish-speaking maid or get a rubber ducky to put on top of your monitor. When you're approaching a problem, explain what you want to do to your audience. Anticipate "but what if-" questions. You need a cardboard analyist, in the lingo.
posted by cmiller at 4:27 PM on May 1, 2007
Either find a coworker or trap the spanish-speaking maid or get a rubber ducky to put on top of your monitor. When you're approaching a problem, explain what you want to do to your audience. Anticipate "but what if-" questions. You need a cardboard analyist, in the lingo.
posted by cmiller at 4:27 PM on May 1, 2007
It's a favorite axe of mine to grind, but whenever I see questions like this I refer folks to Jon Bentley's Programming Pearls, one of the best books I have ever read about how to think about programming. The book is about back-of-the-envelope design, how to recognize where the gross inefficiencies and bottlenecks are, how to recognize subtleties in implementation, and how to think creatively about problems when you have limited storage/bandwidth/execution time.
posted by ldenneau at 6:24 PM on May 1, 2007
posted by ldenneau at 6:24 PM on May 1, 2007
> only to find halfway into it, that there was a ten minute fix right in front of me.
Is it really all that unusual to have this experience? I don't think you're likely to have that Aha moment of clairvoyant insight in any complex situation with more than a few variables until you're pretty well immersed in it, and reaching that point takes some digging and getting dirty.
posted by jfuller at 6:27 PM on May 1, 2007
Is it really all that unusual to have this experience? I don't think you're likely to have that Aha moment of clairvoyant insight in any complex situation with more than a few variables until you're pretty well immersed in it, and reaching that point takes some digging and getting dirty.
posted by jfuller at 6:27 PM on May 1, 2007
Whenever you need to do something new, google the shit out of it.
If there's something that you think you should be able to do in a given environment, but you're not sure how, google it.
If you think there should be some sort of third party widget to do something that needs doing, google it.
If you're new to a problem space, and you're looking for a place to start, don't be afraid to google something like "how to call c# code from stored procedures." You'll be amazed at what you find.
Post questions to forums. Other people know more then you do, and sometimes they'll answer your questions.
After a while, you'll start to refine your "am I wasting my time" sensor. It will go off every now and again, that little voice in the back of your head that says, "you're reinventing the wheel, this has been done before, you're wasting your time." I try to give that voice at least a moment of consideration whenever it speaks up.
posted by Afroblanco at 7:58 PM on May 1, 2007
If there's something that you think you should be able to do in a given environment, but you're not sure how, google it.
If you think there should be some sort of third party widget to do something that needs doing, google it.
If you're new to a problem space, and you're looking for a place to start, don't be afraid to google something like "how to call c# code from stored procedures." You'll be amazed at what you find.
Post questions to forums. Other people know more then you do, and sometimes they'll answer your questions.
After a while, you'll start to refine your "am I wasting my time" sensor. It will go off every now and again, that little voice in the back of your head that says, "you're reinventing the wheel, this has been done before, you're wasting your time." I try to give that voice at least a moment of consideration whenever it speaks up.
posted by Afroblanco at 7:58 PM on May 1, 2007
Practice.
As you gain experience, you'll waste less time and identify these things up front (at least, if you are intent on improving, which it seems you are). Just keep programming.
posted by RikiTikiTavi at 10:11 PM on May 1, 2007
As you gain experience, you'll waste less time and identify these things up front (at least, if you are intent on improving, which it seems you are). Just keep programming.
posted by RikiTikiTavi at 10:11 PM on May 1, 2007
I agree that there's no silver bullet but you could try some of the parts of processes and maybe one will click with you.
Read advice from the pragmatic programmer
Learn from others. Are you on a project with other programmers? If you have other people to work with, try reviewing the small step with them. not just actual code, either. use cases, scenarios, suggested interfaces, &c. And also do the same for them because you will learn from your cohorts (if you are lucky enough to work with people you can learn from).
Try out ways of thinking about things. I like to think about things in layers of interfaces, with sequences of messages going back and forth. I also like to think in terms of use cases.
Pattern design? the original WikiWikiWeb!
Maybe I/we could think of more specific advice with some more details about what you have to work on and your work environment. Do you do embedded stuff? desktop applications? web development? Do you work by yourself? large team? small team? on a vast, complex system?
posted by bleary at 1:08 AM on May 2, 2007
Read advice from the pragmatic programmer
Learn from others. Are you on a project with other programmers? If you have other people to work with, try reviewing the small step with them. not just actual code, either. use cases, scenarios, suggested interfaces, &c. And also do the same for them because you will learn from your cohorts (if you are lucky enough to work with people you can learn from).
Try out ways of thinking about things. I like to think about things in layers of interfaces, with sequences of messages going back and forth. I also like to think in terms of use cases.
Pattern design? the original WikiWikiWeb!
Maybe I/we could think of more specific advice with some more details about what you have to work on and your work environment. Do you do embedded stuff? desktop applications? web development? Do you work by yourself? large team? small team? on a vast, complex system?
posted by bleary at 1:08 AM on May 2, 2007
Oh yeah, forgot to suggest local user groups.
and I agree with the earlier comment about Programming Pearls and the author has a sequel.
You can also do things like get an ACM or IEEE membership (or just peruse articles. helps if you have a technical library at work).
online communities. mailing lists. usenet. I used to do a lot of work in tcl and comp.lang.tcl was a great newsgroup.
are there any online communities where you work? wikis, mailing lists, irc, jabber chat rooms, newsgroups, web forums, &c.
posted by bleary at 1:14 AM on May 2, 2007
and I agree with the earlier comment about Programming Pearls and the author has a sequel.
You can also do things like get an ACM or IEEE membership (or just peruse articles. helps if you have a technical library at work).
online communities. mailing lists. usenet. I used to do a lot of work in tcl and comp.lang.tcl was a great newsgroup.
are there any online communities where you work? wikis, mailing lists, irc, jabber chat rooms, newsgroups, web forums, &c.
posted by bleary at 1:14 AM on May 2, 2007
I don't think there is anything particularly wrong with coding something up that is broken, and then starting again. You learn something from that initial process. But as others have said, with experience and practice comes a better understanding of the sorts of solutions to problems you will face. Another good habit to develop is to not rush into coding till you have a good sense in your head of what you'll need to do from start to finish. Thinking through a problem will probably help identify issues before you are half way through hacking a solution up.
posted by chunking express at 6:29 AM on May 2, 2007
posted by chunking express at 6:29 AM on May 2, 2007
This thread is closed to new comments.
posted by devilsbrigade at 2:05 PM on May 1, 2007