
Ask HN: How do you get better at coding? - kilianso
I&#x27;m trying to get insights from developers for a school project on how they get better at coding.<p>The survey below contains just 6 simple questions to answer. Or just answer here. THANK YOU!<p>https:&#x2F;&#x2F;goo.gl&#x2F;forms&#x2F;emc16fdMC8UkTYYh1
======
traviswingo
I get better at coding by coding.

No, really. You can read all the books, blog posts, open source code samples
you want, but nothing will substitute writing code.

I maintain a handful of side projects as well as write code daily for my job.
Plus, I love it. Also, my side projects usually encompass something I have no
idea how to do, which quickly elevates my skill level. I love learning, so it
works for me.

~~~
pen2l
I think I "read" about programming for something like 15 years (books, blogs,
HN, proggit, irc chat)

I started actually _coding_ seriously and properly the past 1-2 years. Easily
learned a hundred-fold more by doing it, literally.

I think too often I told myself I'm "not good enough to make something
serious". And you know -- it was probably true. But _that doesn 't matter_.
Just start, things will fall into place, sometimes you'll fail, sometimes you
won't. It's just the only way really.

~~~
albertgoeswoof
> I think too often I told myself I'm "not good enough to make something
> serious". And you know -- it was probably true. But that doesn't matter.
> Just start, things will fall into place, sometimes you'll fail, sometimes
> you won't. It's just the only way really.

it's not true, most "serious" things aren't that difficult or complex

------
onion2k
I write code on personal projects every day. Sometimes when time is an issue
it's just a single line bug fix or an update to some documentation, but
regardless I get a little green square on my Github graph _every day_. It has
two important effects. Firstly, it means I have to keep coming up with new
things to write code for to stop it getting boring, so I explore a new things
a lot. Secondly, it's made me think about how I can stop wasting time when I
code, and how I can use my tools better. I've been doing it for about 200 days
now, and I've definitely improved already (this is after being a developer for
20 years so far).

------
wiremine
Practice.

1\. If I'm learning a new language, I pick a topic I know well and try to
apply it in the language. Typically the first pass is nonidomatic, and I
iterate as I learn more about the language. 2\. If I'm learning a new
algorithm, I use a language I know really well. 3\. If I'm learning a new
framework, I pick a smallish project and dive in.

Most of it is throw away, and I've found that takes a lot of pressure off.

------
makmanalp
The one thing I've figured out over the years is to not make your goal be "be
great at coding". That's an ambiguous goal, and it's easy to move the
goalposts on that one. I find that that kind of goal encourages a narrow,
syllabus-y definition of learning that doesn't encourage the kind of trial-
and-error that's crucial to grokking the difficult parts of programming.

Instead just learn how to solve your actual problems or entertain yourself
using programming /today/. Making your friends websites, making games for /
with your kids, making an app to water your plants, making spreadsheets to
manage your finances, automating that annoying manual thing you do at work,
making goofy software that converts images to pixel art, whatever floats your
boat.

You have to make a lot of bad things to start making good things. So start
making bad things, and enjoy it while you're at it - I've made my fair share.

Do a little bit of programming every day. Do it for now, and not for later.
Set yourself a direction every so often, but not much more than that. Review
your own work and see what was not great, and figure out what to learn next to
make it better. Show your work to other people and ask them for help, or enjoy
together. It's much more pleasant to look back later and continually be
surprised how far you've come.

------
yoz-y
Your questionnaire is missing a few important questions (in my opinion). You
should ask for the responders current status (student, professional - if so
freelance/employed) because this will quite probably color the answers.
(Unless everybody will just put "by coding" in the Other section). You should
also ask for the number of years of experience, or at least a ballpark. The
way one learns changes depending of what you already know.

Edit: and to answer your question. At first I learned by reading other's
people code and trying stuff. Adapting existing base bit by bit can go a long
way. Back then I had no internet.

At university most of the curriculum was theoretical. We have done very little
actual coding and most problems were too small. Often too specific and vague
at the same time.

Nowadays I learn by coding. When you re-read your code from a few months back
it should look bad, this is the sign that you have progressed. If there are no
idiomatic ways of solving a particular problem, I try to find a better way to
implement it each new time.

Finally, I try to talk to people smarter or more experienced than me.

If I would change one thing, it would be to do more projects in university and
make them follow agile methodology with the teacher as product owner.

------
halayli
A major characteristic of a solid programmer is how they structure and
modularize their code. This is not something you can learn from books because
it ties strongly to the problem at hand. But you can get much better at it by
delving into other solid open source code related to the problem. It took them
many iterations to get it right, so there's a lot to learn from that.

For example, if you want to write an SQL parser/analyzer, take a stab at how
you'll structure it, then try extracting this piece from postgresql. Compare
and contrast. You'll learn how a good modular code looks like and start
learning how to apply such patterns to your code.

Delving into a code base without a goal isn't helpful imo. You need to have a
main goal like fixing a bug, adding a feature, or extracting a piece to
integrate it into your own code.

------
muzani
I disagree about it being all about practice. That's like saying basketball
players get better just by playing basketball. It's about the right kind of
practice.

The best kind of practice is the one you dread most.

Last year I kept hitting the semicolon, curly brackets wrong and getting the
capitalizations off. I deliberately practiced typing those for dozens of
hours. These things really helped me stay in flow instead of stumbling.

I used to dread all the complicated architectures of modern Android. So I did
a few app sprints trying to find simpler ways of building one from scratch and
seeing which corners I can cut.

I felt that I was too slow in coding things that weren't copy paste. So now
I've been doing some 'sprints' by doing Hackerrank or Project Euler as fast as
possible and then taking a long break from them.

------
LeoJiWoo
1\. Read Books/Online

2\. Use Anki for difficult memorization

3\. Use mindmaps for difficult concepts

4\. Practice Coding

5\. Sleep and Exercise for mental health

I've also found a low carb high fat diet helps me focus a lot more ymmv .

------
qwerty124567
1\. Practice. 2\. Read good open source code, design patterns, understand and
apply. 3\. Repeat.

------
afrancis
I believe a large part of getting better at coding is reading about good
coding practices and simply reading other developers' code, regardless of its
quality. For example when I was in junior college a programmer-on-duty
recommended I read Kernighan and Plauger's "Elements of Programming Style."
Reading this style guide had an immense impact on me. Following that book, I
discovered Kernighan and Plauger's "Software Tools" which illustrated
important aspects of the UNIX philosophy (and good design principles) such as
"Write programs that do one thing well" and "write programs that work
together."

------
adventured
Avoid becoming too dependent on referencing easy/fast solutions online when
you hit an annoying problem. I've found that it's extremely valuable to go
through forced stretches of time where I won't allow myself to do quick
solution look-ups using Stackoverflow et al., forcing me to work through more
problems and keep improving. There is always some deadline to get some thing
done, so it can be extremely tempting to turn to Google to quickly move on to
the next problem. I think that's reasonable so long as you mix it up and make
sure your skillset is well maintained.

------
matt_the_bass
The old adage of “practice makes perfect” definitely applies.

However, working with other smart (ideally smart _er_ ) people really helps a
lot. Code review of my own code is helpful. But also reviewing other people’s
code. I find that reviewing other people’s code from projects I am familiar
with is more valuable than just reviewing any code.

I’m also a musician, the same approach applies there too. I always try to play
in bands where I’m the worst player (though hopefully good enough that my
playing satisfies the others in the band). That way I’m always learning and
pushing limits.

------
pnathan
I jump into a new language, a new technology, and immerse myself in it. Ask Qs
on SO, read books, but write code. This is how I taught myself how to code
when I was a teen, and it's been very effective ever since, as I have moved
from teen to undergrad to grad student to professional. Solo self-education
via practice, supplemented by voracious reading.

I would quantify a key difference between an effective intern and an
ineffective intern as "has this person written 10KLoC". Writing software is a
_craft_ , and crafts require practice.

After initial competence is achieved, i.e., you can do your first coding
language/tech and be comfortable, you need to choose another, different, one
and repeat the process. It will break individual understandings of that one
system and show you commonalities. Then, do it again. Even more different.
Rinse, repeat. The breakthrough and toughness are required for getting better.

At a certain point, the problem of "learning how to code" or "getting better
at coding" disappears and you need to understand how to work with others and
building work products for them - open source or otherwise. On and on it goes.

------
abainbridge
1\. Write big enough programs of your own such that you experience them
collapsing under their own weight. That forces you to see the consequences of
your actions. Only then can you really learn how to structure things better.

2\. Try to learn the underlying technologies thoroughly. For example, try
writing a simple C compiler and linker. That will teach you about a lot of
things that a lot of the programming world sits on top of.

~~~
rcr
I've learned no greater lesson about program structure than the time I finally
got around to writing test cases for my first modest (~10k lines of C)
personal project.

------
tempodox
Be aware of the three paradigms
([http://wiki.c2.com/?ThereAreExactlyThreeParadigms](http://wiki.c2.com/?ThereAreExactlyThreeParadigms)).
Get proficient in at least one language for each of them. It will get you a
host of transferrable knowledge.

Tinker a lot and don't be afraid to make your own mistakes (and learn from
them once you've recognized them).

------
akavel
By reading (esp. code), writing code, and reviewing (i.e writing about code).

Reading, esp. code (including learning new languages and reading in them),
shows me new paradigms, new idioms, new ideas, sometimes parts of new ideas
which may click together later. Sometimes the patterns may however be subtle
and not easy to notice by pure code reading; in such cases reading free-form
prose (blogs/etc.) can help notice them. Also reading code invariably provides
examples of bad code, to be remembered as a warning and something to try to
avoid.

Writing code introduces need for actually choosing some of the learned
approaches, excercises the learned theory, ingrains it, shows the shortcomings
and costs of particular patterns/approaches, their nuances, where they fit and
where they don't, allows to experiment with them.

"Exchange with coworkers" is usually also reading in my case, i.e. code
reviews.

And I just realized that also doing code reviews helps me improve coding in
one more way: I sometimes discover stuff when I'm trying to express in words
why I find some peer's code jarring, troublesome, or confusing.

------
Uehreka
For me it's a combination of active and passive modes:

By active I mean actually coding. I usually have a side project or two that
I'm working on (although sometimes barely at all) and I try to pick projects
that involve working with a tool, platform or skillset I haven't tried yet.
That's how I've gotten into things like deep learning, computer vision and 3D
graphics that I wouldn't normally get to use at work.

By passive I generally mean podcasts. As a front end developer, I recommend
Shop Talk Show, DevChat.tv's podcasts, Toolsday and Codepen Radio (and for
people who are new to CS entirely, Base.cs is an awesome podcast). I'll put
one of these on while driving or playing a zone-outable video game and just
absorb.

I suppose I should also recommend things like Pluralsight and Lynda.com for
getting an introduction to a topic I'm completely unfamiliar with. These are
invaluable, but only if combined with actual experience in the thing you are
learning. If I take a course on there and don't apply it soon after, I'll
generally forget most of what I learned.

------
iainmerrick
As everybody else is saying, practice practice practice.

I'll add one extra on top of that: it's important to practice on real,
complete, non-trivial programs that actually do something. Ideally it'll be a
large project because that will give you practice in working with other
people, API design, refactoring, testing, debugging, and reverse-engineering.

------
fuxi
1\. Get a job when you have a good mentor, senior/lead dev that is actually
doing his job, not just a manager. That person should be rather strict

2\. Fix tons of bugs. You will get exposure to all kinds of issues and
shortcomings that people before you made. Those who do not know history's
mistakes are doomed to repeat them (or any variation of this quote)

3\. Talk and work with others. Software engineering is a team sport. Surround
your self with smarter than yourself, that often works best.

4\. Teach others, share your knowledge. No matter if they are more junior or
senior, it does not matter. That will make you understand problem even better.

5\. Build simple things. KISS and done. Simplicity is the ultimate
sophistication. Do not try to impress others with how complicated your
software is, try to do that other way around if you have to.

------
SatvikBeri
Every Sunday, I go through the things I did that week (including work and
social events) and ask "how could that have gone 10% better?" Then I see if I
can apply those ideas to future projects.

Years of accumulating minor improvements based on real projects I actually
worked on have compounded.

------
cdevs
Spread your knowledge around, read on oop, read on functional programming,
learn what google and Facebook do in a situation, learn to get good enough to
criticize with confidence. If you can't criticize a situation with confidence
then learn more about it.

~~~
SatvikBeri
Definitely agree - IME the best programmers can usually give a long list of
informed complaints about their favorite tools, as well as reasonably
discussing alternatives.

------
hinkley
I apply the 80/20 rule recursively. It’s something I caught myself doing at
some point and now I tell junior devs to do the same thing.

If you spent most of a day on something, nobody is going to notice an extra
twenty minutes to fix it up a bit more. Especially if it means fewer
production issues with that code. On a sane project the interesting problems
are given to the most reliable people, not the fastest. So look at th code one
more time than you deem necessary.

Try to look at it the way someone else will or the way you will in six months
when you touch it again. Do the commit comments match the code? Can you tweak
the code a bit to make it mean what you said? Then do it.

------
baby
By coding and reading other people's code.

~~~
amorphid
> reading other people's code

+1 for reading other people's code. I'll build on that by adding:

\- by learning to make your own code readable

\- by working with people who want to make code reviews a priority

------
crispyambulance
The same way everyone else does: by doing it.

... and then suffering through withering dismissals of my urgent questions on
stackoverflow and also facing condescension, ridicule or getting ignored by
people who can help me at work. Seriously.

------
LarryMade2
Lots of coding, bad, good, better, messy, etc.

Challenge yourself, to try the hard task once in a while (prove to yourself,
those "I could do that much better" thoughts), attempt "proof of concepts" (at
least) of your wild ideas. You will be surprised how far you can get.

Exchange ideas and accept bitter pills of criticism, yeah sometimes you will
have to admit you got something wrong and now you have to rethink how to do
something. Once you get over that you will find new opportunities and also
have a new story about "back in the day I was so bad at this, I..."

------
xydinesh
1\. Write code for side projects 2\. Read others code for similar projects in
same language.

On #2, for example, if you are working on a todo list backend in python, try
to find existing solutions for todo list backend in python. Then you can see
what others using in their solutions and try to bring them into yours.

I understand, this approach is not applicable for everything but I have found
lots of gems this way.

~~~
ssyphon
Conversely, avoiding looking at what others have done and doing it yourself
can help loads too.

Only when you get stuck and cant figure something out with your current
knowledge set, should you venture to look at others solutions.

Or after you have completed your solution and are curious about what others
have done. You might find a library that makes your life way easier, but had
you started out using that library, you wouldn't have the best understanding
of the nitty gritty details.

I will admit sometimes I get a little ambitious with what I want to do and end
up looking at other solutions to see just how complex we have to go.

------
paulie_a
Lately, by fixing bad code. But otherwise I find a project I am passionate
about and go forward. I appreciate the wealth of tutorials available, but I
generally find those boring because it doesn't accomplish my goal. I genuinely
appreciate those tutorials/blog posts etc because they make for solid
reference material.

------
raleigh_user
Everyone here is saying by coding. I largely agree. However, there is probably
10% of my time where I talk to others who are way better than me, know about
topics I want to learn about and then go learn. A lot of times you can save a
bunch of time by getting knowledge from the best vs a random guide online.

------
yesimahuman
I get better by giving myself some time to explore new topics. One recent
example was giving myself "time" to learn Jest and writing more frontend unit
tests. Took < 30 minutes to learn it and I was good to go, but we're all so
busy sometimes we don't allow ourselves time to learn.

------
lowleveldesign
Contributing to an open source projects is a great way of learning too. It
forces you to read and understand the project’s code and concepts behind it.
Then you practice coding by implementing your new feature. You also need to
test it thoroughly. Finally, you will get a code review for your code.

------
DonaldFisk
"Lisp is worth learning for the profound enlightenment experience you will
have when you finally get it; that experience will make you a better
programmer for the rest of your days, even if you never actually use Lisp
itself a lot."

\- Eric Raymond, "How to Become a Hacker"

~~~
thijsvandien
The exact same thing can be said about many other subjects, even not related
to IT at all. As an example, inspiration for simulated annealing, an ML
technique, comes from welding.

------
agitator
I get better by taking on projects and challenges that I have never done
before. It forces me to learn quickly and I encounter more problems, bugs,
issues, that I have not encountered before which I learn from, and become a
better developer.

------
Dowwie
Get feedback from more experienced programmers and learn how to improve your
code. Get feedback any way you can-- people contribute feedback for a variety
of reasons other than altruism.

------
bluesnowmonkey
Write code fast that you're going to throw away. Write code carefully that
you'll have to maintain for a long time. Maintain other people's code.

------
quadcore
By thinking about it.

------
duiker101
See what others are doing wrong, notice what I think and realize that I never
want someone to feel like this when reading my code -> IMPROVE.

------
pq0ak2nnd
1\. Eating crow when customers find my bugs.

2\. Rewriting, rewriting, rewriting

3\. Trying new languages for fun (I ported a LAMP website to Node to learn
about node+express)

------
shahbaby
It's not enough just to code more.

You have to be exposed to code written by other people in order to see
_better_ ways to do things.

------
the_solenoid
1\. Choose a project I don't have a clue how to do but I also find interesting

2\. Dive in head first knowing a ton of research will need to happen

3.

4\. Profit

------
flurdy
Pairing.

Bouncing off ideas, war stories, snippets, learning and sharing alternative
ways to solve problems. Priceless.

------
swsieber
Everybody mentions coding... how do you make sure the coding is an improvement
activity?

------
shujito
Learn from your own code, compare other's coding practices.

That worked for me.

------
bootcat
I think the questions are too opinionated !

------
thescribe
How do you get to Carnegie Hall? Practice.

------
SomeHacker44
Coding.

------
davmar
i take courses on udemy and coursera.

------
ronreiter
You... code.

------
a_lifters_life
Do it.

