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...!
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.
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 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.
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.
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!
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.