Ask HN: Was there a time when you realized you “got better” at programming? - gravy
======
chatmasta
At some point I had the realization that I had not been “stumped” by a bug in
a long time. Aside from a few very exceptional circumstances, I am nearly
always able to identify the cause of incorrect behavior within 15-30 minutes.
When I first started programming, it was common for me to be frustrated with a
bug for hours, only to discover an obvious logic or framework error the next
morning.

In my experience (self taught and also CS major), the best way to get better
at programming is to consistently adopt a few core habits: Read good code,
read your _own_ code (I often review the day’s commits before bed), and
prioritize defensive programming above all else. If you do these things, you
will naturally evolve into a better programmer as you gain more experience.

~~~
minionslave
Could you share a few tricks with me? I'm still stumped by bugs, sometimes for
days

~~~
chatmasta
Sure. Spend a day learning how to use a debugger, and force yourself to use it
until it feels natural. In the most common cases, the bug is in code on your
computer, even if it's buried deep in some dependency. Even if you're working
on a distributed system, you should have a local test environment and
hopefully some sort of tracing capabilities. With a properly configured
debugger, you should be able to quickly find the source of most problems.

After replicating a bug, I usually follow a process that looks roughly like
this. I try each step, and if it's not resolved by then, I move onto the next.

1) Examine git log to hopefully determine which commit introduced the bug, in
order to narrow the search space

2) Set breakpoint when the bug becomes observable, attach debugger and
identify root cause of bug.

3) Verify that any function calls to dependencies are correct according to
documentation, and any conditionals are working as expected (double check
logic too)

4) Try a bunch of google searches

5) Read dependency documentation more closely, and read its code on GitHub to
understand how it works

6) Ask for help in an IRC channel if available

7) Re-evaluate priorities

------
lordkrandel
When I started coaching a junior guy, I've been able to see all the logic,
speed and wisdom I've learnt in time and that he still needed to work on.

------
avichalp
Understanding and getting comfortable with alternative paradigms. Functional
programming if you do lot of imperative programming. Imperative if you do a
lot of declarative programming (eg sql) etc.

------
axansh
Whenever I get a bug in the production system and I have all the required
information in log - that time I thought I became better at programming.

------
elamje
When I started learning lisp/Emacs/clojure I felt enlightened in a way I never
did before with Java and Python

------
jrochkind1
Most times I look at old code i wrote!

