Advices to become a better developer

[Violet_82]

Hi guys,
I wonder if you can help me.
As I’m now doing java development as a profession now, I’ve realized that I’m a little weak when it comes to fix, modify and understand code within large applications, and, needless to say, I need to find a way to get better at it.
So, I was wondering if any experienced java developer could give me some advices and perhaps help me in getting a little better.
Of course I know the basics, I’ve studied the theory, I know how to create classes, instantiate them, using interfaces etc – although this is more theoretical knowledge than practical in all honesty – but I feel like I’m lacking ‘something’, perhaps just experience…

[JamesCherrill]

Yes. Once you have the basics then it's just getting lots of relevant experience.
There are lotsof experienced developers here who can help with specific topics and questions - so if/when you hit a roadblock we will be here to help.

[Violet_82]

Well, it's not just a roadblock to be honest, but for example, say there is a bug in the application and I need to address it, where do I start from? I know a lot is specific to the application of course, but is there any general principle that I can apply across every application?

[JamesCherrill]

Well, here are some ideas about debugging in the real world...

Debugging is an art as well as a science! The best deguggers I ever knew were people with huge experience of that kind of program, which enabled them to make really good educated guesses as to the kind of mistakes that usually lead to that kind of problem.

But as a science it's all about small logical reproducable steps. (That's the opposite of making some random change and seeing if that helped.

Start by pinning down the circumstances under which the bug does or does not appear. Keep copies of the cases that fail so you test your fix later. Write them down. You'll need this to test your hypothesis about whet went wrong.
If it's possible to reproduce the bug in a subset of the full system, or in a stand-alone test program, that wil save a lot of time.
If you have a bug that can't be reproduced reliably then settle in for a long and painful process - thread race bugs for example are always a nightmare.
Obviously: read all the log and error files very carefully indeed.
If there is configurable logging turn it to max and reproduce the bug.

Now it's typically a process of working backwards through the code starting from where the bug appears. Reading the code is probably a good idea, but you probably won't see the error - neither did the original programmer or the QA people! Use debug/trace tools if available, or add debugging prints so you know what's happening. I repeat know, not just think or assume you know. Assume nothing - it's probably a bad assumption that cuased the big in the first place.

If possible work with a partner. Explain out loud what you are doing and thinking at each step. It's amazing how often you can explain something that's obvious to you and the listener says "hey, wait a minute, that's not right!"

If still stuck never be afraid to call for help - people will be impressed by the quality and depth of the work you have done so far if you follow the above steps.

Finally, get independent review and testing of your fix before deploying it live.

[Violet_82]

Thanks, that's helpful :-). Coding-wise, I reckon I'm having a few issues with the MVC model, I mean it's pretty clear what it does and how it works in theory but when you try to look at larger projects it's incredibly difficult to find out what's what. Same things for design patterns in general, it's all OK (well the few design patterns I looked at) when it's a small application but when it grows in size it's a nightmare

[JamesCherrill]

I wouldn't get too hung up about design patterns. Use them when they fit is all.
In a large or complex system you will probably find that some were used at quite a low level, and others (eg MVC) at a very high level - in which case you won't see them in the code but you will in the overall module design. Many designers have them in their metal toolkit when designing, but apply them loosely or in a way that's adapted to the situation

[Violet_82]

Yes, I actually noticed that, in fact one of the applications I'm working at use MVC extensively, but it's just so hard to understand what's going on, and I kind of wondering whether practicing MVC would help me to understand that or whether I should focuss more on how classes interact with one another in large system, as I this in as area where I know I'm weak

[JamesCherrill]

Maybe Sequence Diagrams would help you to visualise. I'm a massive fan of using them to refine and validate how classes (and modules) interact.
Quick intro: https://en.wikipedia.org/wiki/System_sequence_diagram
More examples: http://www.agilemodeling.com/artifacts/sequenceDiagram.htm

[Gribouillis]

I just found a straightforward python app named seqdiag to generate sequence diagrams, see blockdiag.com/en/seqdiag/examples.html

[Violet_82]

that is a great idea, but I don't believe the organisation I work for has any...shame because it would be reallly helpful.

[Violet_82]

In any case, is it still worth me looking at the Java theory, as there are things that I haven't really touched upon, or just doing some practice (and if so what would be the best way to practice on medium/large application? Get a project off github and modify it?)

[JamesCherrill]

that is a great idea, but I don't believe the organisation I work for has any...shame because it would be reallly helpful.

In that case why not take a small example from their current software and build the seq diagram for an easy part (eg user logon). You could even impress them into using seq diagrams more! For me they are the most useful part of the UML toolset.

is it still worth me looking at the Java theory... or just doing some practice

I say practice. Doesn't matter what as long as (a) it's not TOO simple and (b) you don't skip over the tricky bits like handling errors etc.

[Violet_82]

OK great, thanks for the advice. So in terms of practice is getting stuff from the internet (github) and modify it a good idea? Do you know any other resource where I could get some code and play with it?
thanks

[JamesCherrill]

I would do something with your current employer's software - that will help you "get" the local style and coding standards, and increase your value to your employer. Maybe reverse-engineering the class and sequence diagrams for one of their apps would be good learning for you and show them how you can add value.

[deceptikon]

I’ve realized that I’m a little weak when it comes to fix, modify and understand code within large applications, and, needless to say, I need to find a way to get better at it.

There are two books I rather like: Code Reading and Code Quality. They go beyond the how to code beginner books and take a higher level view using examples from large open source projects.

I feel like I’m lacking ‘something’, perhaps just experience…

Yeah, that's it exactly. Understanding the features of the language and how to use them is the bare minimum for functioning as a developer. The real challenge is noodling over and solving problems in an efficient manner. And by "efficient" I don't mean runtime execution, I mean developing a viable solution in a reasonable amount of time. While hobbyists can take all the time they want to make things "perfect", pros don't have that luxury.

Unfortunately, experience is a mountain of mistakes, and there's no shortcut. I'd recommend three things to get started:

1. Carefully review the established code at your company and try to understand the reasoning behind it. If you have questions, you now have resources in the form of the more experienced developers at the company and perhaps even the original authors of the code.

2. Understand the business and general business concerns when it comes to custom software. Developers are not an island, and it pains me when new devs come in expecting to crank out code on their own terms. Software is written to meet business needs, and an excellent developer should be capable of at least rudimentary business analysis and project management.

3. If possible, offer to do QA. Again, excellent developers have a full stack view of software from bare metal to business needs to end-user experience. This complete understanding greatly enhances your ability to solve problems in a way that satisfies everyone.

In terms of actual code, don't be afraid to try new things. Each failed attempt adds to your experience and each successful attempt adds to your toolbox. At this point in my career, a not insignificant portion of each new application or feature involves reusing code or solutions I've already added to my toolbox.

[Violet_82]

Right thanks guys, really good suggestions! I will try to work on the code of the organisation I work for, but I can't bring that at home with me unfortunately so it might be proving a little challenging, that's why I was thinking to get hold of some code from the net too :-)