How to learn Java

Simon Harrer — Thu, 08 Nov 2018 16:44:02 +0000

Quite often, I’m asked: Hey Simon, how to learn Java? Here are the top five resources I typically recommend. Happy reading. Happy learning!

Top 1: Head First Java

Head First Java by Kathy Sierra and Bert Bates

I’d recommend starting with Head First Java. I did the same 13 years ago and I still think this is the best book to start learning Java. It’s not your usual textbook, so be prepared for having actual fun learning Java. Be surprised how much you’ll know after having worked through that book.

Top 2: Java by Comparison

Java by Comparison by Simon Harrer, Jörg Lenhard and Linus Dietz

Next, I blatantly recommend reading the book I co-authored: Java by Comparison. We’ve taught Java for over six years at University, and from that experience, we’ve written Java by Comparison. Our audience in mind has been students knowing enough Java to write simple programs but lacking practice and a mentor that can guide them towards cleaner and more readable code. It features a unique before/after approach comparing bad code to better code, so you can learn step-by-step to transform code into even better code. It’s the book I wished I had when I finished reading Head First Java.

Top 3: Effective Java

Effective Java: Third Edition by Joshua Bloch

Now, we move on to the book on Java, the classic item-style book that provides uncountable insights how to use Java the right way: Effective Java. Just read that. It’s simply mandatory when you want to call yourself a professional Java developer.

Top 4: Head First Design Patterns

Head First Design Patterns by Eric Freeman and Elisabeth Robson

When your programs start to become bigger, you’ll start to feel pain when organizing your code in methods, classes, and packages. That’s when you need to learn about software design. I began my journey with Head First Design Patterns. It features a similar learning style as Head First Java but focuses on how to design your classes instead.

Top 5: Functional Programming Java 8

And last but not least, with more and more people adopting a more functional programming style in Java and everywhere else, I recommend watching the unique Venkat Subramaniam explaining how to program in a functional way in Java 8. Happy watching!

howtolearn.de

These top 5 resources to learn Java originally appeared on howtolearn.de. Feel free to browse all the other topics there as well.

Let’s Talk. About Problems. Less About Solutions.

Simon Harrer — Thu, 14 Jun 2018 15:31:01 +0000

The other day, I stumbled upon the following tweet.

Simon Martinelli

@simas_ch

It's easy to explain "things" to people that are eager to learn. But how do you explain "things" to people that are not?

11:13 AM - 11 Jun 2018

0 2

It really was thought provoking for me. And I compiled the following answer, taking full 12 minutes, rewriting the tweet over and over.

Simon Harrer

@simonharrer

@simas_ch You just don't. You have to convince them that "things" are worth learning. After you convinced them, you can explain "things" to them. Typically, the convincing part is the real challenge.

11:25 AM - 11 Jun 2018

0 1

But still, the topic didn’t let my mind free. It struck me, that there’s something really really important in there. So I try to break free by writing my thoughts down in this blog post. Enjoy!

I used to teach a lot at University. The two courses I co-taught, Advanced Java Programming and Programming Complex and Interactive Systems were known to be really time-intensive and not mandatory. Hence, the vast majority of the students who ended up in these courses were really motivated to learn and they accepted the large amount of work they needed to do — despite a lot of easier courses available as alternatives! For that experience, I feel privileged. Teaching those courses typically fell into the category of “it’s easy to explain “things” to people that are eager to learn”. They were already convinced that these courses are really important for themselves and didn’t need convincing.

But that’s not the whole truth. Apart from the technology part, we put a large focus on teaching clean code through code reviews in class, of their homework assignments, and even in the oral exam. Not every student shared our enthusiasm for clean code as we lecturers did. These students were already struggling with the course workload and simply wanted their code to run correctly and get good grades. That’s fine. Nothing wrong with that attitude, however, we ended up in the other category: “explaining “things” to people who aren’t eager to learn”. We, as idealistic teachers, wanted to teach and reach every student. So we talked a lot about why some code is hard to read and what consequences this will cause. Each semester, we put more and more emphasis on why a particular code is hard to read. It payed off. We could see this quite well in the feedback we’ve written as part of the grading of the student homework over the years. It changed from talking only about the solution at first to talking about the problem and the solution in a 50:50 split, giving the problem the same amount of space as the solution. I don’t have hard data to support my argument, but students stopped complaining about clean code advice after we switched to the 50:50 explanation. I assume it was convincing enough for the students to walk that extra mile despite the extra work.

We took that experience further and wrote our book Java by Comparison according to that 50:50 share between problem and solution. For each comparison in our book, we dedicate the left-hand page to the problem alone and the right-hand page to the solution. There are a lot of books on clean code that focus on solutions, but none of them spends so much space on the problem alone as far as I know. I think this really sets our book apart and makes it so appealing to beginners and experts alike. Have a look to see it for yourselves.

Let me generalise the point here. Talking about solutions is natural to us developers who like to share what we know. We want to share that cool new framework, programming language, IDE, CLI tool, or library. We want to show how it works and how cool it feels. But we often don’t spend enough time on why we should switch from the currently used framework, programming language, IDE, CLI tool, or library. We are already convinced, often strongly convinced, that the new is simply better. But we tend to forget that others haven’t thought our thoughts, haven’t gained our experience, and may reach totally different conclusions because of their current needs.

When you read the next article, listen to the next talk, or simply attend your next meeting, think about the ratio of time spent about the problem and the solution. Do you think the article/talk/meeting would’ve been better by talking more about the problem and less about the solution? Please let me know in the comments.

DEV Community: Simon Harrer