Struggling to see point in learning Java

[Colby Toner]

I've been doing java programming for a little bit. (Mostly just console programs) I have just been stumped as to why I should learn this language. As I wish to go into computer programming as a major later in life I want to learn as much as I can before then but I don't know what exactly is needed to do what I wish to do. Firstly I want to be able to make professional programs and apps that solve problems and aren't a problem in of themselves. In summary I'm struggling to see where all the knowledge is going as I know it is a slow process to doing something "cool" but exactly how slow and at what cost? Thanks.

[Zachary Griggs]

Java is just one of the languages you should learn to be a programmer, but it is valuable

Career-wise: Java developers are in high demand. From infoworld:

More than 16,000 Java positions are open on any given day, says Shravan Goli, Dice president, in the company's January bulletin, and demand for Java is only heating up. "Java was named one of the Top 10 skills hiring managers search for when in the market for cloud candidates, according to our November report,"

Java is relatively simple, in that you don't have to worry about messing around with memory addresses (it's a safe language, unlike C++), making it an alright first language

You say that you feel the language isn't going anywhere, but learning Java teaches you not only the language but programming skills that can be applied to most other languages that you want to learn. It will teach you object oriented programming, inheritance, abstraction, and other concepts like that.

If you're just memorizing syntax, then you're missing out on 95% of the skills that learning a language like Java can provide. Try learning how to write your own classes to learn object oriented programming, learn how to extend classes and inherit methods from them, or learn how to write tests or about the various structures you can store data with.

I know it is a slow process to doing something "cool" but exactly how slow and at what cost?

Honestly, it depends on how cool of a thing you want to do. What are some of your specific goals in learning java? Maybe you could try writing some GUIs since you say that you've done mainly console work.

[Colby Toner]

@Zachary Griggs I thank you for the thoughtful reply. I have been trying to learn the reasoning as to why things are done and not just learning syntax. And when I say "cool" I mean something created that when you see it, you know a ton of work went into it and wasn't just made in a few hours. I'm still confused as to where to go from creating console programs such as "Hello, World" to taking those concepts and creating the next big app or something.

[Zachary Griggs]

Hmm, so the problem is that the programs you create seem too small and simple? If you're just doing things like hello world, I would advise you to move on to larger, maybe multiclass projects. I can't tell you exactly what to do for this - just try imagining something you might want to do on the computer and see if you can code it. Some random ideas:

- Java calculator that handles the four basic functions (use GUI)
- Program that reads in a file and decodes/encodes it with a simple encoding algorithm (File IO and maybe Maps)
- Create a GUI program to load and display an image and save it in any other format (ImageIO)
- Program to solve a famous game, such as Towers of Hanoi or 15 Puzzle (Recursion)
- Create a GUI text editor with an undo feature (Stacks)

Or anything like that. Just imagine something that people have to do on the computer, and then find a way to code it.

[Junilu Lacar]

I've said this a number of times over the last couple of months: what you're feeling is common with beginners who are taught language syntax and program structure but are never given a practical way to relate to these new concepts. You have all these bits and pieces of information being thrown at you and you have very little context in which to tie them all together to form a clear, bigger picture. In your mind, you have an idea of being able to create some cool programs and apps but you lack the recognition that comes with experience and expertise that more seasoned developers have that allows them to do what you can't right now. It's the same difference between a high school freshman football player and a professional NFL quarterback: the former is still learning the game and probably wouldn't recognize a blitz until he was on his backside while the latter draws on his rich pool of experience to "read" a blitz just by looking at how the opposing team's players are lined up.

Zachary already hinted at part of what you need to do: practice, practice, practice. The other thing is to study, study, study. Targeted study combined with purposeful practice is something that a number of authors have written about, such as Anders Ericsson in his book Peak: Secrets from the New Science of Expertise and Malcolm Gladwell, author of Outliers: The Story of Success, and his 10,000-hour rule. There's even an article that cites both these authors and some clarifications about Gladwell's rule. So even the experts can't quite agree exactly how one becomes an expert. The common thread though is practice and study. Of course a little aptitude and talent doesn't hurt. But that can only take you so far. Just ask ex-Cleveland Browns quarterback, Johnny "Mr. Football" Manziel.

One thing that has helped me over the years has been an understanding of principles. There are many ways you can say the same thing to a computer using a language like Java. However, there are some ways that are better than others. Learn to recognize "good" code and "bad" code. Understanding software design and coding principles helps you see what makes good code good and bad code bad.

Then, learn how to refactor code because unless you're in the top 1% of programming talent, you're going to write bad code. Guaranteed. Then learn how to use automated tests and combine that with refactoring.

Start with the simple principles and refactorings. For principles, familiarize yourself with SOLID, DRY, SLAP, GRASP. Reading about these will lead you to other related principles and practices. As far as refactoring, there's a whole book about it by Martin Fowler. I recommend learning at least three: Rename, Extract, and Composed Method.

Finally, and this is what I tell everyone, beginner and experienced alike: Learn how to do test-driven development. It's probably the most important skill I have learned as a developer that has helped me tie all of the above into one neat bundle of goodness.

Basically, what I'm saying is that software development is as much a craft as it is an engineering discipline and science. The stuff that you're confused about right now has to do with the "engineering and science" side. The things I mentioned above are more about the discipline and craft.

There's a lot of work ahead of you. Good luck.

[Les Morgan]

Colby,
There has been a lot said here, and I rarely put my 2 cents in after there are 3 or more posts, but I believe there has been a lot of things unsaid.

If you are looking at doing things now so you can go into computer programming later, then I have to ask you why? What do you think you are going to learn now. I mean significant things that will help you down the road? How far down the road are we talking--a year, two, or ten? In any case the things that are going to stay with you, and the industry, are the fundamentals. Those things upon which all languages are based--no I'm not talking about cod's rules or Euler's theorems, or Turing principals or what have you, but there are some things you should learn and recognize.

The first thing is that a language is only a tool. Just like there are saws, hammers, and etc there are many different tools in a programmers toolbox. If I wanted to use a hammer, I have to realize there is a wide variety of hammers, so what do I want to do with the hammer. That influences the hammer you choose. Java is a "C-Style" of language. In todays environment there are literally dozens, or more, of C-Style languages, so what do you want to do. In reality C and Assembler, IMO, are the languages you need to learn so you can learn programming. Before everyone jumps down my throat and ways, "Les you are crazy, nobody learns Assembler any more..." Well, it's because the closer you get to the machine, the more you have to do manually to implement your thoughts--less happens I the background or hidden behind the curtain of the language.

You come down to the bare implementation of things--looping structures, stacks, queue's, file formats, and etc are not available the lower you go, that means you have to learn what they are, how they work, and how to implement them. You start thinking differently than when you have higher levels of language heaped over the fundamentals. So how does that help? When you know how things are implemented beneath the surface you, IMO, actually think what to use and how to use it on a less abstract and more meaningful basis. Why would you use a deque over a queue or a map. Can you learn that from the more abstract view of a higher language, yes, you can, but then you are probably going to look at the API and say: well, maybe this would fit better than that? But why?

At some point you have to move into higher level languages, but at what point do you do that? What kind of foundation do you want to have before you throw layers of abstraction over the fundamentals?

I see the questions posed in these, the Java, blogs and I am shocked and amazed that people don't know and cannot seem to find, nor reason out, how things work. They really don't have a clue. So I would have to say: now before you start a formal education for programming, is the time to delve into the dark recesses of what is under the covers of the abstract layers represented by popular and cool language of the day.

I also suggest you do a study of introspection on languages--look into the development and design of language--compiler and interpreter theory and how that relates to things you are interested in doing. You may come to appreciate that when you develop things compiler and interpreter theory can help appreciate what needs to be done from "Hello World!" to the most complex game design and everything in between.

One of the questions that was posed in one of the other answers was: "How do you become an expert?"

When you come to the point where you know something from the fundamental to the complex and everything in between, you can assume that you have some expertise, but in reality, when you see the path to implementation and know it's supported by sound principals, then your opinion becomes valid, and in reality, you are an expert. In my career I have worked with many recognized experts in the field, and often, I have had to convince the client that we both contract for, that my opinion is the valid path to implementation of their business needs over the expert. If you do not know the fundamentals through the high level implementation, then you may not have the confidence to say hey--he's the recognized expert, but follow me because I have the appropriate answers.

I've alluded to it, but now I will just come right out and say it: plan on going to college. Just do it. That piece of dead animal skin covered in ink that carries an endorsement from an accredited university makes a lot of difference. I hired into a job one time where they had to give all of their programmers a 10K raise before they could hire me. I still make thousands more than they other guys did, and I am not bragging, but I had a CS degree and 1 year of experience--none of their other programmers had a degree, but all had at least 8 years of experience. That was not the only time my degree gained more money for me, but it was the most pronounced in my mind, and because I have that degree I have a better bargaining stance in contract negotiations--more money for the pain I want through in college.

The most important thing you have to consider is: do you really enjoy all this stuff? Do you delight in seeing your code looping through and spitting out the answer--for me the answer has always been a resounding "YES", and I have enjoyed the journey. I hope you do the same.

Les

BTW: don't ever take a book as a Bible--read from it the things you need and toss it aside, technology is something to move through rapidly and not set up as carved in stone law, like the 10 Commandments or Bible. There is only 1 technology based book that I reference time and time again and that is the "Mythical Man Month", and then only 1 line--You can't put 9 women in a room and make a baby in 1 month, so too is learning and program development.