

How to Become a Better Developer - bitsweet
https://coderwall.com/p/hd49fq

======
tieTYT
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.

~~~
auggierose
I can understand this attitude, working for other people is pretty boring.

The best developers work for themselves.

~~~
stephenbez
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.

~~~
GrinningFool
I suspect he doesn't mean literally "working for yourself". Or by yourself,
for that matter - but rather, do the work and seek improvement because you
enjoy the doing of it.

And on that I have to agree. It's the difference between a seat-warmer and
person who will improve throughout his career.

------
j4pe
This post belongs to Shawn McCool of Big Name
([http://heybigname.com/2013/01/21/how-to-become-a-better-
deve...](http://heybigname.com/2013/01/21/how-to-become-a-better-developer-
straight-talk)). 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.

~~~
bitsweet
thanks for calling our attention to this. We've updated the post so it directs
readers to the original source.

~~~
vdaniuk
That is a really great policy, if you do that with all posts!

~~~
bitsweet
when we are aware of it, we do it.

------
RyanZAG
_> 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.

~~~
rschmitty
Worse, you dip your toes in a new language and then suddenly that is your new
hammer for which will solve all of your problems.

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.

~~~
jackweirdy
You're still using a hammer?

You should be using hammer.js

/s

------
TrainedMonkey
TL:DR - learn new things, don't be a dick, ask for help, and write code.

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.

------
suprgeek
All 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?

------
grownseed
These 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.

~~~
a_olt
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.

------
NDizzle
The only thing I disagree with here is "never call anything magic."

What ELSE would you call .par[1] files?!

[1]:
[http://en.wikipedia.org/wiki/Parchive](http://en.wikipedia.org/wiki/Parchive)

~~~
ShawnMcCool
Par files are magic...

------
astonteck
“This is why experienced developers can pick up a new technology in a day,
where a beginner could spend months.”

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.

------
ryan-thompson
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.

------
natasham25
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.

------
poulsbohemian
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.

------
dcomartin
Focus on Principles, Patterns, and Practices. Ask yourself "why" regarding
everything. Understand the problems and solution a
technology/pattern/framework/library solves rather than blindly using said
solution.

------
edw519
Wow, 2226 words and not one of them was "customer" or "user". ("user groups"
doesn't count because in this context the user is "me".)

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.

------
VishalRJoshi
The most important of it all is write a lot of code. Write it for a cause.
Write more of newer, faster, cleaner, clever, smarter code. The more you write
the better developer you will become.

------
trenchwarfare
I just registered to say: both this and the "how I work" posts are awesome. I
love the ideas and the friction between them. Where can I find more content
like this?

------
Grue3
Judging by the notice, the best way to become a better developer is to copy-
paste others' code.

------
angryasian
while 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.

~~~
schleyfox
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.

~~~
DanBC
> 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?

------
stephenitis
humility is attribute #1

