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.
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
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
Joined: Jan 29, 2003
And we both forgot to include any references. Look in the Ranch book review section for recommendations on a couple books about TDD.
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.
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.)
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.
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
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.
Joined: Jul 11, 2001
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.
Joined: Jul 24, 2003
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.
Joined: Jan 23, 2002
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