This week's book giveaway is in the OCMJEA forum.
We're giving away four copies of OCM Java EE 6 Enterprise Architect Exam Guide and have Paul Allen & Joseph Bambara on-line!
See this thread for details.
The moose likes Java in General and the fly likes I want to be a better at Java? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of OCM Java EE 6 Enterprise Architect Exam Guide this week in the OCMJEA forum!
JavaRanch » Java Forums » Java » Java in General
Bookmark "I want to be a better at Java?" Watch "I want to be a better at Java?" New topic
Author

I want to be a better at Java?

Aron knight
Greenhorn

Joined: Aug 18, 2012
Posts: 9
I have been working with Java a few years now, but i dont feel like im any good... I have read books such as effective Java(very good book), read some of growing objects by tdd (was okay), read clean code(good book)... read various spring, hibernate books.. am currnetly reading agile design practises and grounded java developer...

But the thing im finding is that im never happy with the code i write... I can never say im happy with this, i want my code to be better... and right now i really struggle with reading other peoples code.... legacy systems... any tips?... or help?

How can i become better?

Ps.. its a little random question i know... but im jsut throwing this out there, maybe someone has a golden nugget which may help... or maybe im just not cut out to be a developer...!
Junilu Lacar
Bartender

Joined: Feb 26, 2001
Posts: 4458
    
    6

Are you saying you don't think you're not cut out to be a developer because you still struggle with reading legacy code written by other people? If you are, then I would say that's not a very good benchmark. I struggle with reading other people's legacy code day in and day out. In fact, that's almost part of my job description. Then after much cursing and gnashing of teeth, I have to clean it up. Humility aside, I have to say I'm pretty good at it.

So maybe it's the other's people's code that's a problem. If your code looks much like the other people's code that you struggle with, that's a problem. However, if you've read, understood, and applied what you've read in those books you cited, then you should have a very good foundation in good development practices.

You said you think the book "Growing Object-Oriented Software Driven By Tests" was "okay" (I'm assuming that's the book you're referring to with "growing objects by tdd"). I actually think that book is more than OK. Are you doing TDD now? I think that doing a lot of TDD is essential to becoming a really good developer. TDD makes you think about good design and it makes you write unit tests and refactor your code all the time. If you do TDD enough, you'll quickly get to the 10,000 mark that's necessary to be good at anything, as noted in this article: http://norvig.com/21-days.html

"Clean Code" is really good too and you might want to read another Bob Martin book, "Agile Software Development: Principles, Patterns, and Practices," aka "The PPP book".

On the other hand, Dirty Harry once said "A man's got to know his limitations." I don't think anyone wants to be like poor old Cecilia Giminez.

Bottom line is that you have to really like what you do. If this is just a paycheck for you, then maybe you should find something else. But if programming is really your passion, then you should just stick to your guns and keep plugging away at getting better. Sooner or later, you'll get past what Kathy Sierra calls the "Suck Threshold" of the "Kick Ass" curve.

Good luck!


Junilu - [How to Ask Questions] [How to Answer Questions]
Aron knight
Greenhorn

Joined: Aug 18, 2012
Posts: 9
Hi,

Thanks for the reply...

I have started doing TDD in the last few weeks, I still find it difficult, but I know it will help in the end. As for my review on growing objects by tdd, i loved the first part.. but the example in the book wasnt as helpful, but still a good book.

Its funny you should mention the PPP book, i ordered that last week, and started reading it...

I do love what I do, I want to be good at what i do, i have so many books at home, that I cant wait to start... But at times i just feel, im not very good, and im never happy with what i write, i see room for improvment constantly, everytime i cme back to something i have written, i can see things i should change, could do better.. then i wonder why didnt i see this before.
Ulf Dittmer
Marshal

Joined: Mar 22, 2005
Posts: 41635
    
  55
then i wonder why didnt i see this before.

Because you're learning and becoming more experienced. You *should* be dissatisfied with the code you wrote least year.


Ping & DNS - my free Android networking tools app
Junilu Lacar
Bartender

Joined: Feb 26, 2001
Posts: 4458
    
    6

Ulf is right, you should rejoice rather than despair when you look at code and find ways to make it better. If it's your own code that you've improved, that's even better. I find that learning can also come in spurts. Sometimes you'll reach a plateau where for a while, it doesn't seem like you can improve any more but then suddenly a light goes on, you have some kind of epiphany, and you're off learning a bunch of new things or making old things even better.
Jayesh A Lalwani
Bartender

Joined: Jan 17, 2008
Posts: 2347
    
  28

IMO, being succesful as a programmer depends on 2 things

a) You should be happy with the work that you do:- When you leave work and go home, you should have a feeling of accomplishment. You want to feel like you did something worthwile. Doesn't matter what the project pressures are, or what's going around you. End of the day, when you put your head on the pillow, you go to sleep with the thought that "today was a good day". It doesn't happen everyday. But it should happen most days. You don't want to leave work most days feeling bad about something or the other. If you are in a job that keeps you awake at night, you should be finding a way to rectify the situation. I've been there, where I thought if I go through only a month more of this shit, I'll be out of it. And the month never ends, and after being awake 2 nights in a row, I felt like I'm going to have a stroke or something in the client's office. Never doing that again!

b) You shouldn't be too happy with the work that you do:- Building software is an iterative process. It's a process of constant improvement. No matter what you do, you can do it better. You should be constantly looking for improvements. Also, no matter what technologies you know, there's always something that you don't. The pace at which technologies change in this industry, you have to be in a constant race to keep up

Yes, I know both things are conflicting. Success in this industry is like walking on a tight-rope. You get too dissatisfied with yourself, you end up stressing yourself. You get too satisfied with yourself, you fall behind. It requires quite a bit of Zen to be at peace with yourself. Accept that you are always going to be imperfect. Be happy with your imperfections. You can spend 10-15-20 years in this industry and there will always be someone else who knows more than you about a particular topic. At the same time, work on those imperfections.
chris webster
Bartender

Joined: Mar 01, 2009
Posts: 1671
    
  14

Aron knight wrote:i see room for improvment constantly, everytime i cme back to something i have written, i can see things i should change, could do better.. then i wonder why didnt i see this before.

Relax - that's a pretty clear sign that you're learning!

In 1975 Fred Brooks wrote a great book called "The Mythical Man Month", all about the challenges and realities of software project management. One great piece of advice in the book is:

Plan to throw one away; you will, anyhow.


This was decades before Agile, iterative development and all the cool buzzwords that dominate Java-land today, back in the age of the (partly mythical) "waterfall process", but Brooks recognised what we all know: by the time you've built a pilot system, you've learned a lot and your original ideas may no longer seem so great, so you can see all the places where the system could be redesigned/re-implemented in order to better meet the customer's needs. Of course, these days we use iterative Agile-style approaches and things like TDD to try and identify/resolve such problems as early as possible, before the code ever reaches the customer, but the same basic principle applies.

The good news is that as you gain experience, you'll learn to avoid making a lot of the same old mistakes. But you'll probably just end up making new ones instead!


No more Blub for me, thank you, Vicar.
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18541
    
    8

Aron knight wrote:and right now i really struggle with reading other peoples code...


I know exactly what you mean. For me Java code is easy, I've been a Java programmer for a long time now, so reading other people's code isn't much of a problem. But now I'm working with legacy CSS, which is a language I don't know that much about. Incredibly frustrating. I put a table in one place and it looks the way I wanted it to look, then I put it somewhere else and it looks like the dog threw up its dinner.

But I will say one thing about working with other people's code: People often write too much code. And that makes it harder to understand. I quite often find myself removing chunks of code or rewriting pieces of code so they aren't so long. Sometimes I will remove a whole section of code, and then put back pieces until the result is working code. That enables me to understand what each of the pieces does and to get rid of the ones which were unnecessary. When you're doing that, make sure you have (and use) a good source control system so you can go back to the original version if you make a complete mess of it. And it helps to have a set of tests which you can run to make sure your changes are correct.
James Boswell
Bartender

Joined: Nov 09, 2011
Posts: 1012
    
    5

And it helps to have a set of tests which you can run to make sure your changes are correct.


Amen to that. There is nothing like a good "safety net" when you are refactoring.
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 61106
    
  66

As I opened this article with, I always think that the code I wrote last year sucks. This is a good thing.


[Asking smart questions] [Bear's FrontMan] [About Bear] [Books by Bear]
 
Don't get me started about those stupid light bulbs.
 
subject: I want to be a better at Java?