Be honest with yourself. Have enough hubris to think you can do a better job than the guy that came before you, but tempered with the humility of knowing that he also was a very smart person. Try not to personalize feedback, because it's the fertilizer that will help you grow. Learn to ignore half the feedback you get. After years and years, you will see patterns that others don't see. Don't be afraid to have a respectful argument over implementation. If everyone agrees right off the bat, then you have the wrong team, or nobody cares.
How to Become a Better Developer
21–30 of 40 posts
Re: How to Become a Better Developer
#22while he touched on learning from more advanced engineers, the number one way I found to be better is to actually read their code. Look at many of the best open source projects and even the source code for the language you're using. You'll learn a lot.
Reading code is the best way to get better at programming. It's good to start with really smart, really good code, but you should also read bad and mediocre code (and more importantly, be able to figure out from reading why it is bad or whether it only seems bad at first glance.)
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.
Re: How to Become a Better Developer
#23while he touched on learning from more advanced engineers, the number one way I found to be better is to actually read their code. Look at many of the best open source projects and even the source code for the language you're using. You'll learn a lot.
Reading code is the best way to get better at programming. It's good to start with really smart, really good code, but you should also read bad and mediocre code (and more importantly, be able to figure out from reading why it is bad or whether it only seems bad at first glance.) 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 a…
> but you should also read bad and mediocre code (and more importantly, be able to figure out from reading why it is bad or whether it only seems bad at first glance.)
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?
Re: How to Become a Better Developer
#24Earlier quoted context omitted.
I can understand this attitude, working for other people is pretty boring. The best developers work for themselves.
I disagree. 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.
>> For example, working just by yourself, you are unlikely to deal with huge distributed systems, or scaling an application to millions of users.
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!
Re: How to Become a Better Developer
#25Something 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…
I can understand this attitude, working for other people is pretty boring. The best developers work for themselves.
This is just silly. Not everyone wants to be self-employed or work at a startup, and that doesn't make them not potentially a "best developer".
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.
Re: How to Become a Better Developer
#26Something 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…
I can understand this attitude, working for other people is pretty boring. The best developers work for themselves.
It is funny how everyone immediately jumps to the conclusion that I am talking about self-employment.
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.
Re: How to Become a Better Developer
#27Earlier quoted context omitted.
I can understand this attitude, working for other people is pretty boring. The best developers work for themselves.
This is just silly. Not everyone wants to be self-employed or work at a startup, and that doesn't make them not potentially a "best developer". 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.
Working for yourself requires a lot of sacrifice and a desire to handle all things for yourself. This is not some admirable goal. Rather, it's an option for people whom it fits.
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. =)
Re: How to Become a Better Developer
#28These are fairly nice and straight-forward suggestions, but I'm always surprised that these articles (or conversations like it) never mention ideas not directly related to programming. It might just be me, but in my opinion programming is a specific application of a given mindset, not the other way around. Anything that can improve this mindset can be beneficial, even if it's not always directly obvious. I've personally become a considerably better programmer by learning more about cooking, music, different languages, biology, physics, philosophy and many other things. I find it somewhat sad that so many people seem to consider programming an end rather than a means.
Re: How to Become a Better Developer
#29These are fairly nice and straight-forward suggestions, but I'm always surprised that these articles (or conversations like it) never mention ideas not directly related to programming. It might just be me, but in my opinion programming is a specific application of a given mindset, not the other way around. Anything that can improve this mindset can be beneficial, even if it's not always directly obvious. I've persona…
Yes, and this can have very sad consequences – such as very capable people working unreasonably hard on projects which never pick up or don't have much relevance to the rest of the world. It's very important to stay as connected as possible to as many fields as possible; I suppose in the end this is how you become a creative person.
Re: How to Become a Better Developer
#30All good and straight-forward points. Once you internalize these, you are on the way to being a "code craftsman" - someone who knows their tools well yet is humble enough to ask for help & make himself/herself uncomfortable again and again in the quest of more understanding.
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?