Improving coding

[Rashad Mahammadzade]

I have Java knowledge, but I have difficulties on writing code. How can I improve code skill on Java, especially on Spring Boot? Give suggestions for beginner.

[Campbell Ritchie]

Rashad Mahammadzade wrote:. . . Spring Boot? Give suggestions for beginner.

If you are a beginner, don't use Spring Boot. Use Java® full stop.
Show us a programp you have written, not more than 50 lines of code, and let us see what we think of it.

[Tim Holloway]

To do well at Spring Boot, you must first do well at Spring.

To do well at Spring, you must first do well at Java.

It's also a good idea to become familiar with how webapps work, since Spring Boot operates via an embedded webapp server.

[Les Morgan]

Rashad,
besides the excellent advice that has already been given, consider this: when i was doing my English undergraduate work, my English instructor told us: "Writers write.  Everyday."  

as a programmer, the more you design and code, the better it will become.  i am at the far end of my career, and i look at some of the "really good code" from early in my career, and i am ashamed to let anyone see it, but some of those projects are still in production and running perfectly almost 3 decades later.

i have been fortunate enough to have to read and modify dozens of different people's code.  with each new person i become familiar with a project they coded, i look at their code base, and i critique it: what i dislike, i abandon, and what i like, i incorporate into my style.  i am by training, a 3GL programmer, i have done significant work in Assembler also, and it shows.  i code significantly is SAS, and i write tons of backend code now for SQL Server scripting.  each of these had forced a style modification also.

currently i write textbook type of code.  i do that because JVM's and compilers have to understand my code.  know what environment you write for--JVM's, JIT, and Interpreters need to be able to patter recognize as easily as possible.  where if you have a multi-pass compiler it is not as essential for it to optimize immediately, and can take longer giving you that runnable file.

in any case, take the direction given to me about writers: "writers write.  everyday."

take it easy, and enjoy
Les

[Tim Holloway]

To build on what Les has said, I've a similar history.

When I first started working with computers, a failing program would produce a core dump printout. A core dump is simply a listing of what was in memory at the time the program failed, and got its name from the fact that magnetic core memory was common at the time. The core dump was essentially an display in hexadecimal of the memory space and included parts of the OS, the compiler's runtime library and, of course, my own code. Incidentally, Linux still produces a file named "core" under certain circumstances, and even JVMs do something similar. Most application programmers no longer need to descend to the level of working with them these days, so we forget about them.

Regardless, it's relatively easy to hand-disassemble IBM S/360 instructions from a hexadecimal dump, so I filled up some notebooks wiith samples of IBM code. Incidenally, it was still legal to do that back then. Of course, if you had access to the proper files, you could even see/modify the OS source code yourself up until the mid 1980s or so.

So that was one learning set for me.

Along the way, I also inherited the sysadmin job for the college's Prime 300 minicomputer system. Where I did have complete access to all of the source code for the OS (much of which was written in Fortran), the system utilities, and pretty much all of the other vendor-supplied software plus the user-contributed code library. So I had plently of examples from top-of-the-line pros to learn from.

These days, an equivalent would be to do something like download and play with the source to OpenJDK, although if you are really hard-core, you can do that with Linux, BSD or one of the other open-source OS's. And, of course there are countless open-source apps out on the Internet's archive servers to peruse. I even have one of my own (https://gogs.mousetech.com, which hosts a Spring Boot recipe manager app built with JavaServer Faces).

[Junilu Lacar]

Les Morgan wrote:Rashad,
besides the excellent advice that has already been given, consider this: when i was doing my English undergraduate work, my English instructor told us: "Writers write.  Everyday."  

as a programmer, the more you design and code, the better it will become.  i am at the far end of my career, and i look at some of the "really good code" from early in my career, and i am ashamed to let anyone see it, but some of those projects are still in production and running perfectly almost 3 decades later.

Being afraid that you'll do something that sucks or makes you look stupid is one of the biggest impediments to learning. Get over it. Put yourself out there. Get feedback and advice. Look at how other people do it and if you think it's better than your way, try to replicate it.

I've been working on Advent of Code puzzles and certainly some of my solutions suck. They're too long, too complicated, and inelegant. I'm ok with that. I don't care about anyone thinking that I'm stupid because I know I'm not. Not caring about what other people might say or think about me frees me up to do stupid things. When I do stupid things, I can learn. The more I learn, the less I do stupid things (hopefully).

in any case, take the direction given to me about writers: "writers write.  everyday."

This is the way. If you do something every day and learn a little bit each time, getting good at that thing is practically guaranteed.

Remember: Practice makes permanent. Only perfect practice makes perfect. Be mindful of what you're doing and how you're doing it. Learn to recognize mistakes and opportunities to improve. Don't just go through the motions; practice deliberately, with clear intent.

[Adrian Grabowski]

Tim Holloway wrote:To do well at Spring Boot, you must first do well at Spring.

To do well at Spring, you must first do well at Java.

It's also a good idea to become familiar with how webapps work, since Spring Boot operates via an embedded webapp server.

I see your point but also, there nothing wrong with playing with Spring Boot straight away after learning basics of Java. It's also much less painful than "normal" Spring. And it doesn't have to be anything web related. You can use it for writing console apps - check out this module https://spring.io/projects/spring-shell , pretty fun to use.

[Tim Holloway]

The operative words here are "to do well". If you don't understand something, you're not likely to be able to do very well at it. It's kind of like those magic fire-all-the-programmers systems that pop up from time to time. With little effort you can get an app running. Then the users say "That's great, but can you make this one tiny little change?" and you end up floundering because everything was magically done for you and you have no clue how to do something outside its pre-programmed script.

Spring Boot is a product that's layered on top of other products, and therefore to do well on the top layer, you need to have some ability to understand what the top layer is doing when it dives into the next layer down, etc.

We talk about Spring Boot as a webapp server, because that's the most common use case. Spring Shell doesn't require (so I understand) the webapp server, so knowing about Tomcat and HTTP wouldn't apply there, but Spring Shell is built on the Spring Core, and Spring Core is built on basic Java, so again, there are lower layers that beg for understanding to do well in the higher layers.