How to Become a Better Developer
coderwall.com
coderwall.com
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.
+1 can't say enough good about this point. True not only of being a good software developer, but really anything meaningful we do in life.
The best developers work for themselves.
1. I think you can get some pretty interesting assignments even if you work for someone else.
2. I've worked with developers that work for themselves (contracts/consultants) who write code that's difficult to maintain.
What I do think is true is that the best developers you read about online tend to work for themselves. But there's selection bias there: succeeding as an independent (whether as a consultant or building your own product) tends to require a keen sense of self-marketing, and on top of that having online communities to connect with (HN, OSS, etc) is especially appealing when you don't have coworkers in the same office as you to shoot the shit with.
When you work for a company, you get to handle challenges that only come at a certain scale. For example, working just by yourself, you are unlikely to deal with huge distributed systems, or scaling an application to millions of users.
Getting good feedback is critical to improving as a developer. I've learned so much by working with others and picking up on stuff they have done.
Why not though? When companies run into these problems, they have to get the services somewhere.
Why not a small development company?
Plenty of one man bands doing crazy interesting work for surprising big names.
And invoicing £800+VAT per day for it!
And on that I have to agree. It's the difference between a seat-warmer and person who will improve throughout his career.
I just wanna code, I don't want to deal with administrivia. I've worked at large companies that get out of my way and let me do the parts I'm good at, I don't have to worry about billing or anything.
I work for myself and I definitely don't recommend it for anyone who wouldn't refuse my advice to work a solid salary job. =)
What I mean: you are best when you code the stuff you code for your own (non-monetary) purposes. That includes being employed by Google and work on massive scalability issues, because scalability is an issue you are just dying to learn more about.
McCool does make some excellent points and his contributions to Laravel and other projects have been very helpful to me.
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.
There is something to be said for a craftsman who has achieved a master level with his tools and not simply shopping at Home Depot every month buying the next wizbangfixitall framework. It's as if Christmas comes every 2 months and you unwrap a shinny new hammer (framework/language/database/etc) for which everything must be smashed with.
You should be using hammer.js
/s
That's the whole problem with this; it's entire focus was on "me" and not on "others".
I have always believed that the best way to transcend mediocrity is to focus on others, not yourself. All this talk about mentors, technologies, methodologies, communities, opinions, and intelligence is about oneself and while probably will provide some improvement, you won't really get to the next level until you find a way to apply it.
Find a customer with a difficult problem. Find a way to solve it with whatever it takes. Trust yourself to rise to the occasion. That's the best way to become a better developer.
This all seems like standard stuff, but if you look at it like a framework and evaluate all actions using that methodology, it will help to identify areas in need of improvement.
Personally, the number one technique that helped me grow was to always ask "How & Why is this feature/framework/Technology important to the end goals of the business/product?" As you start being entrusted with more complex systems the amount of "religious" arguments begin to multiply (Java is slow, Ruby is cool, Python is old, Mongo is the hotness, Postgre is for old farts,...) At this point focus on the Business needs ..What is absolutely essential?
What ELSE would you call .par[1] files?!
The idea that a professional programmer can pick up a language/technology in a day or two is unlikely. They can PLAY with a new language or new technology and understand the basic idea behind it but they are not going to know it well enough to write anything serious. The problem is not the architecture or the know-how but the syntax and limitations of the tool. Programming in multiple languages is hard; you must keep on shifting your brain back and forth between the syntaxes and the nuances of the languages. A design pattern is a design pattern no matter what language it is but the syntax of that language complicates things.
Last, let’s take a tool such as GIT for example, this thing has a zillion of commands and most of them do the same thing Why? All we need is tool to help with versioning our codes not something that stands in the way. There are a couple of GITUIs but when there is a problem, they send you straight to the command line without any real explanations. Now you realize that you should have learned it using the command line to begin with. A lot of people hear this tool was written by the creator of linux and they just jump on board like sheep when in reality this thing was not written with human being in mind. Why are we complicating things? Programmers are being smart so lets focus our energy to solve real problems instead of boosting our egos with the next tool that does not solve anything.
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.
Reading code starts out being really hard, but with practice it can become almost as easy as reading prose. It's a winning proposition on all levels as you can pick up new techniques, understand how things are done (rather than just what they do), and see the trade offs and decisions that are actually made. Practicing code reading also improves debugging skills as you have to use the same skills to understand the what and the why of perfectly working but unfamiliar code.
Whenever anyone asks me what they should do to improve their programming, I usually suggest reading more source code. Another benefit is that code can't lie as easily or as convincingly as the documentation can.
Are there books or websites that have snippets of bad code for readers to test their skills with? I know I've seen something like that for C (maybe as part of a larger book) but what about all the other languages?