
Ways to be a Better Programmer in 2014 - ingve
http://programming.oreilly.com/2014/01/7-ways-to-be-a-better-programmer-in-2014.html
======
greatzebu
One of the biggest ways I became a better programmer in 2013 was essentially
the opposite of this advice from item 3: "Don’t be afraid of your code. Who
cares if something gets temporarily broken while you move things around? A
paralyzing fear of change is what got your project into this state to begin
with."

I was formerly working in an environment where no one was really responsible
for making sure that features worked consistently or that new features didn't
incidentally break old features, and the result was a huge amount of
frustration and wasted time. Learning to spend some time and effort up front
to make sure that new features and small-scale redesigns won't break old code
has really clarified my thinking about system design. Taking it for granted
that no one really cares if things are broken for a bit while you refactor
really presumes a lot about the problem domain you're working in.

~~~
DavidWoof
I think the idea of things being broken for a bit while you refactor implies
that you haven't checked the code in, not that you don't care about breaking
things in production.

I've been working with some pretty bad programmers lately, roughly sub-
fizzbuzz or close to it, and one of the most stunning differences I've noticed
is how terrified they are of their code. They program like they're building a
house of cards. Once it seems to work, the idea of refactoring it for
readability is completely foreign to them (of course, so is the idea of unit
testing).

I think it's that kind of programmer this article is aimed at. Sure, you
should make sure you don't break things, but you should also have some
confidence in your code and be willing to constantly improve it.

~~~
InclinedPlane
_" I think the idea of things being broken for a bit while you refactor
implies that you haven't checked the code in..."_

This makes me cringe. I think it means that the code hasn't been merged with
the main branch, or to the release branch, or that the feature flags which
turn on the new code haven't yet been set to turn it on by default yet.

------
danso
How about: Learn tools to make you more efficient? As technologies and stacks
become more complicated -- and our brains retain the same capacity -- it's
important to find ways to minimize the barriers to learning. It can be as
simple as reducing small discomforts, which build up quickly in day-to-day-
coding. I've found taking a few more minutes to pick a better color theme for
my code editor can make syntax much easier to read through, especially when
working with a new language.

~~~
taeric
I worry about concerns over efficiency. As much as I'd like for that to be a
fairly objective word, I am forced to acknowledge it is anything but. Almost
as bad as that wonderful word "quality."

For me, the challenge is to look at older technologies as often as newer ones.
I don't quite believe that everything new was old at some point, but it is
rather impressive to see the tricks and techniques that were used by folks
years ago. To the point where I'm sometimes curious exactly what we have that
is truly new. (I'm starting to learn just how powerful emacs can be, for
example.)

------
taeric
I'm not so sure I would be so negative on the code in isolation. Yes, I think
I would personally like to get my code out there more with/for others.
_However_ , I see no real reason to think this should be a moral imperative
that is given to others. To the point that, while I would love for it to
happen, I more want to make sure I just write more programs. Even if they are
of the "I ran them exactly once just to see if it worked" variety.

~~~
gedrap
I've had to maintain some codebases where the previous developer was working
alone for 6-30 months. They often share the same issue that bad practices get
repeated over and over and over again, not knowing something turning into a
habit because no one pointed out. Also, knowing that someone will go through
gives some extra motivation and makes you think twice before doing something
lazy or stupid.

Also, another person can recommend you a tool, library, etc which you wouldn't
have thought of. For instance, at my early days as a developer I didn't know
that things like SQL schema version control exists. I got introduced to
liquibase which saved me from many many hours of work making sure all
environments are using the same schema.

It all depends on who sees your code and the way they approach with comments,
and how do you deal with criticism.

------
lightblade
> 3\. Don’t Be Afraid to Break Things

The last time I broke things, I got fired. Not gonna happen again.

~~~
nit3ch
Who is the boss ? :D

------
gdubs
Looking back, the point at which I started writing better code came after I
read "The Art of Unix Programing".

------
9emE0iL18gxCqLT
UTF-8 Everywhere Manifesto
[http://www.utf8everywhere.org/](http://www.utf8everywhere.org/)

------
riledhel
As a side note, I was very impressed with the ReadSpeaker solution they
implemented when you select a paragraph of text. Didn't know that
product/company.

------
oh_nvm
I work in an office with a hundred lawyers. They do NOT spend their own time
staying current.

