wood burning stoves 2.0*
The moose likes Agile and Other Processes and the fly likes Improving coding speed? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » Agile and Other Processes
Bookmark "Improving coding speed?" Watch "Improving coding speed?" New topic
Author

Improving coding speed?

vibhav kumar
Ranch Hand

Joined: Mar 08, 2006
Posts: 39
Hi,
I am j2ee developer for last 2.5 yrs. I am good at concepts as I have done scjp1.4 & scwcd 1.4 with 90+ scores. I however think I can improve on speed of coding.
Pls advise me on how to do the same.

regards,
Vibhav
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
Practice a lot. Read a lot of code written by other people. There's few magic bullets in software development...


Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
Practice Test Driven Development. At first it may seem to cut down the "lines of code" per day or what ever measure you use, but it pays off in delivering tested and defect free code faster than ad hoc debugging. The benefits in quality increase as you work over time on a growing code base with lots of good tests behind it.


A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
I'd advice to take a look at "Test Driven Development", if you haven't yet.

As up to 80% of "coding time" are actually spend debugging, not writing bugs is one of the most important techniques to improve coding efficiency.

Another important thing is simplicity - or the amount of work you manage not to have to do. Much can be accomplished by a good, simple, well decoupled, reuse-fostering design.

TDD helps with both of those aspects.

(Yes, I started to write this before Stan posted his comment... )
[ April 26, 2006: Message edited by: Ilja Preuss ]

The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
And we both forgot to include any references. Look in the Ranch book review section for recommendations on a couple books about TDD.

All Book Reviews
Jeanne Boyarsky
internet detective
Marshal

Joined: May 26, 2003
Posts: 30116
    
150

Originally posted by Lasse Koskela:
Practice a lot.

Definitely! Just like learning a language, eventually you get fluent.

For example, think about how long it takes you to write a loop to add up all the #s from 1 - 100. How long did it take when you started programming compared to how long it takes now? There's less thinking time on the language itself and more on the problem at hand.


[Blog] [JavaRanch FAQ] [How To Ask Questions The Smart Way] [Book Promos]
Blogging on Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, OCAJP, OCPJP beta, TOGAF part 1 and part 2
Don Morgan
Ranch Hand

Joined: Jul 24, 2003
Posts: 84
One of the best ways to improve your coding speed is to slow down. Slown down and take the time to:

* make sure you understand the technology you are using. A few hours spent reading a manual or a good book can save days or weeks of "trial and error" programming.

* ask questions. This is another big lever where a few minutes spent talking to someone can save you hours or days of work.

* do your work carefully and encourage others on your team to do the same. Often it is the rework and debugging which drag down productivity.

These things seem like common sense, but is it surprising how often they are neglected.


Don Morgan, Founder
www.DeveloperAdvantage.com - FREE Audiobooks for Software Developers
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Don Morgan:
These things seem like common sense, but is it surprising how often they are neglected.


True. It seems to me that the most common motivator for those how don't neglect it is pride. So whenever you wrote some code, ask yourself "can I be proud of this code? Would I show it my best friends? Would they congratulate me for writing it?" (There is one pitfall, though: being proud about complexity. Be sure to be proud about simplicity instead.)
Scott Ambler
author
Ranch Hand

Joined: Dec 12, 2003
Posts: 608
TDD is good, you might find my Intro to TDD to be useful. Better yet, gain some modeling skills. If you think before you code, you'll have a lot less coding to do. See the Agile Modeling site for some good ideas.

- Scott


<a href="http://www-306.ibm.com/software/rational/bios/ambler.html" target="_blank" rel="nofollow">Scott W. Ambler</a><br />Practice Leader Agile Development, IBM Rational<br /> <br />Now available: <a href="http://www.ambysoft.com/books/refactoringDatabases.html" target="_blank" rel="nofollow">Refactoring Databases: Evolutionary Database Design</a>
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
The father of one of my friends was a VP at Bell Labs. He claimed to be a complete fraud when it came to technology. (I didn't entirely believe that.) He said his only management technique was to walk up behind someone, look over their shoulder and ask, "You proud of that?" And if he got a yes, "Tell me about it." I tend to make a lot of noise about code quality, so I try to imagine the people who are most annoyed by that watching over my shoulder.

I mean, if 10 years from now, when you are doing something quick and dirty, you suddenly visualize that I am looking over your shoulders and say to yourself: 'Dijkstra would not have liked this', well that would be enough immortality for me. Edsger Dijkstra
Meghana Meduri
Greenhorn

Joined: Mar 29, 2006
Posts: 27
Nice to read this post.

I am in a position where I m doing lots of trail and error coding.

Unfortunately, code I am working on uses most of the in house frameworks and modules and people here are very resistance to give some information on them.
Situation is like, they don't have any documentation and they don't want to spend any time when there are issues with their modules.
I feel I am very unfortunate to work in this team.

Do you have any approaches to handle such situations even when talking with your project manager does not work.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Write tests for the inhouse frameworks. It will help you in several ways:

- it will help you understand how the frameworks work,
- it will increase your credibility if someone doesn't work as it should,
- it will help you notice when how something works changes,
- you can provide the tests to others as documentation.
Don Morgan
Ranch Hand

Joined: Jul 24, 2003
Posts: 84
It may be difficult to write tests for the inhouse frameworks, especially the validation of the test results, if you don't know how the modules are supposed to behave.

Some other thoughts:
* find code examples in your system or others which use the framework (grep is your friend!). Nice framework developers usually provide these.
* review the source code for the frameworks

I'm not sure how much they will help you, but these have worked well for me when in a similar situation. Make sure your examples and source are for the same version of the framework you are using.
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
Originally posted by Don Morgan:
It may be difficult to write tests for the inhouse frameworks, especially the validation of the test results, if you don't know how the modules are supposed to behave.

I'd like to add that simply writing tests to document the current behavior (a.k.a. "characterization tests") -- regardless of whether that behavior is the correct behavior -- helps protect you from later changes in the in-house framework.

In other words,
1. Write a test
2. See how the actuals (the current behavior) differ from the expectations (typically "null", an empty string, -1, etc.)
3. Change the expectations of your test to match the currect actuals
Martin Spamer
Greenhorn

Joined: Oct 12, 2005
Posts: 4
Originally posted by Ilja Preuss:
(There is one pitfall, though: being proud about complexity. Be sure to be proud about simplicity instead.)


Agreed, The most elegant solution in software engineering is the simplest solution that meets the requirements. Raise the principle of a single responsibility to an art form.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Improving coding speed?
 
Similar Threads
improve my coding skills
To Hans: When to use JSF?
SilverStream Designer
<terminated, exit value: 0>C:\Program Files\Java\jre6\bin\javaw.exe (Feb 12, 2009 1:54:50 PM)
Why can't I code?