Ask HN: What habits have help you succeed as a programmer? - febin
======
onion2k
I made a conscious choice to write 'non work' code every day. It's now a habit
(thanks largely to Github's contributions graph... I've got to get a little
green square every day!). Sometimes it's just 5 minutes to refactor something
or update a README, sometimes it's 5 hours to work on a project, but the
result is the same - I spend more time writing code. This has introduced me to
frameworks, libraries, patterns and algorithms that I wouldn't have been
exposed to otherwise, and it's _definitely_ making me a better developer.

~~~
mithras
Good on you, but I'm afraid that's not going to work for me with two small
kids running around.

~~~
onion2k
A friend of mine in a similar situation is making a game with his kid - he
writes code while his child is drawing sprites. They collaborate on the game
mechanics, testing, etc. That works for him and (he says) it's quality time
that's loads of fun. Maybe you could include your kids?

------
acutesoftware
as well as the comments below, I would add

1\. Get a visual prototype going as early as possible - even if its screen
mockups. Your interpretation of what the client wants and what they tell you
they want are often completely different, and many times they don't really
know at all. Once they can see something, then requirements get a lot better.

2\. Once you have a better idea on what you will be building, work out in your
head how you will build it. Think about all the parts and do the bits that you
haven't done before, or don't know how to do and build them FIRST. This will
avoid showstoppers down the road - you may not be experienced enough to know
if it's something you can't / shouldn't do, or if extra help / libraries are
needed to complete the job.

So once you have a clear idea on what you are building, and have done test
functions to do the hard bits - then it's time to turn on the music and build
the rest.

------
nukeop
1: Keep everything as simple as possible.

2: Keep your toolchain and build process independent from the operating system
and editors.

3: Don't use IDEs.

4: Have a one command automated build and run as soon as you write a basic
skeleton of your project.

~~~
axvk
What do you have against IDEs and what languages do you mainly write in?

~~~
Teichopsia
Not the OP. When I started out I took a conscious decision to stay away from
IDE'S.

an IDE adds complexity when the main goal should be to learn to program. An
IDE has a bunch of features you need to learn and understand when learning to
program by itself is hard enough.

~~~
cc81
What language did you use?

~~~
Teichopsia
Python.

~~~
cc81
That is a language that is perfectly fine to start without an IDE but for
example Java and C# are pretty much designed to use with an IDE, at least when
you are building something that is non trivial.

You don't have to use all the power but letting for example Visual Studio
handle the project references and build for a .NET project will allow a
beginner to focus on coding. Not to mention all the tutorials will assume they
use Visual Studio.

~~~
Teichopsia
I had a feeling it would be something along those lines. When I began I
actually started with Java and later dabbled with C# but didn't get far with
either one of those. I had no idea what I was doing. I probably still don't
¯\\_(ツ)_/¯

I finally settled on Python after jumping around quite a bit and am still
learning.

------
tboyd47
Don't commit to anything you haven't already verified is possible

------
EliRivers
Code without ego. You are not your code, and your code is probably not very
good.

------
kleer001
Read other people's working code. Figure out what they're doing and why and
why you like or dislike it. Add their unique qualities to your own repertoire.

------
fiftyacorn
Delivering to your deadlines and estimates as much as possible

------
navyad
reading code.

