Live data from Hacker News

How to Become a Better Developer

coderwall.com

1–10 of 40 posts

Re: How to Become a Better Developer

#3
I've been coding for only a little over 2.5 years, and especially agree with the point on learning technologies that are significantly different from what you're comfortable with. I started by learning Java to understand programming fundamentals, which made Ruby pretty easy to learn.

I then learned Ruby on Rails, which I thought was a bunch of "magic" until I started learning iOS development. A lot of the Ruby on Rails architecture concepts were very useful in figuring out how to architect my iOS application. Knowing some Java was also super helpful, since Objective-C is a strongly typed language. Learning iOS helped me understand both Rails and iOS better, and why people didn't like Rails. I also feel a lot more comfortable picking up JavaScript frameworks, such as Backbone.js and Angular.js, which were harder for me to understand and pick up when I was just doing Rails.

Next up, I'll be learning a little bit of Android development, hoping to learn the different philosophies for mobile and how to better structure my layouts for different devices, and will probably learn a bunch of other things I can't even think of right now!

Working with amazing engineers who are open to mentoring me has also been priceless.

Re: How to Become a Better Developer

#4
> Learn technologies that are specifically different from those that you already know.

Careful with this point. A lot of people take this to heart a bit too much and dip their toes into 10+ different languages with only a couple weeks each. This is definitely a big mistake. While it's good to learn technologies that are different from what you know, you need to actually learn them, not play with them for a week. This means actually building something substantial and at least a few months of heavy usage. You need to really understand the technology and the reasons for the decisions the technology makes before the learning will be transferable beyond meaningless syntax.

Re: How to Become a Better Developer

#5
This post belongs to Shawn McCool of Big Name (http://heybigname.com/2013/01/21/how-to-become-a-better-deve...). Though he was credited, I think we should use the original content source when possible.

McCool does make some excellent points and his contributions to Laravel and other projects have been very helpful to me.

Re: How to Become a Better Developer

#6
Something missed in this article is the need to reflect and have personal retrospectives. Back when you first learned to code, you may have chosen names for your variables like `foo` and `bar`. This was fine when you're learning how an if statement or a for loop works. But once your program gets a little more complex it's hard to keep track of what `foo` or `bar` represent.

I notice a lot of people who run into these types of problems and consider it to be just the way things are. This makes your productivity plateau. But, the reflective programmer notices the meta problem and asks, "How can I make this easier to think about?" In this specific example, the answer is to give the variable a meaningful name. I think you've gotta be reflective to learn this lesson. You can be taught and you can be told why you should do it, but it won't click very well until you feel the pain and the satisfaction of solving the problem.

---

New cynical topic: The real way to become a better developer is to be passionate about development. Everything else will fall into place. I'm not sure that this can be taught. I've seen a lot of people with the attitude of, "even if I'm more productive, I still have to work an 8 hr day so what's the point?" These developers (which in my experience is the majority of them) won't improve because they don't want to. But for me, maintainable code is its own reward.

Re: How to Become a Better Developer

#8
Good developers tend to focus on patterns for solving problems beyond a language and beyond a framework. Focus on understanding the patterns in payment systems, GIS systems - whatever interests you - and write a lot of code in that area. Figure out what worked and what didn't, improve. Rinse, repeat for about ten years.
Post reply on HN