
Ask HN: Best daily practices u've come across to design-code faster and better - samblr
More in the lines of small daily training of IDE, tools, data-structures, design, frameworks. Ranging from fingers warm-up to a drawing relevant architecture&#x2F;frameworks&#x2F;pattern-designs. It can vary from project to project and what stage of projects.
======
jskulski
I try to setup a feedback loop as soon as possible. I spend time setting up so
i can do some simple action (hit a button, run a command, or automatically
watch some files) to see if I'm on target it.

I found this saves immense time and keeps me on task pretty well.

This is from: \- GOOS book [https://www.amazon.com/Growing-Object-Oriented-
Software-Guid...](https://www.amazon.com/Growing-Object-Oriented-Software-
Guided-Tests/dp/0321503627) \-
[https://www.youtube.com/watch?v=nIonZ6-4nuU](https://www.youtube.com/watch?v=nIonZ6-4nuU)

~~~
tedmiston
Another good feedback loop is just using a REPL.

[https://en.wikipedia.org/wiki/Read%E2%80%93eval%E2%80%93prin...](https://en.wikipedia.org/wiki/Read%E2%80%93eval%E2%80%93print_loop)

------
ozten
touch typing - some folks don't learn to type quickly without looking

tmux - per project, persistent terminal

shell aliases - stop typing frequently used commands

GTD - some form of productivity process like Getting Things Done, including a
prioritized TODO list

hot reload - don't accept slow development cycles

timeboxing - avoid rat holing a day or two away on a low value task

programmer notebook or wiki - document steps or arcane knowledge for the next
time

hard coded - unblock yourself for missing data or dependencies

user testing on paper prototypes - save months of throw away code

~~~
arvinsim
> programmer notebook or wiki - document steps or arcane knowledge for the
> next time

Any examples of dedicated notebook software?

~~~
ktaube
I've been using Quiver[0] for past month, and I really like it. It feels like
ipython notebook only for my notes.

Unfortunately, it works only on Mac.

[0]: [https://itunes.apple.com/us/app/quiver-programmers-
notebook/...](https://itunes.apple.com/us/app/quiver-programmers-
notebook/id866773894?mt=12)

~~~
Raphmedia
I also vouch for Quiver. Works really well.

------
tmaly
I like keeping functions small and writing tests first.

When you are under a lot of pressure to finish something same day, it helps to
know all the basics are working by automatically running your tests.

~~~
samblr
very true

------
jneumann004
When I get to work, I try to get any distractions out of the way before I
start actually working; email, rss feeds, project management, etc. This allows
me to focus on the important things throughout the day and not worry about if
I missed something that happened.

Since I get the distractions out of the way in the morning, I will know what
I'm working on throughout the day and not have to change gears unless
something urgent comes up.

------
greydius
Spend 99% of the time thinking, 1% of the time typing.

~~~
beachstartup
yes and half of that 1% of typing should be commenting and documenting!

the trick is to remember, you're commenting for _you_ , because you're the one
that's going to forget all this stuff in a few months and have to figure it
out at the worst possible time.

sounds a little weird but i always liked commenting my code. it felt like i
was bragging to myself about how clever i was.

~~~
brianwawok
When I find myself writing a comment, 9 out of 10 times I pause and think. I
can usually clean up the code so I don't need a comment.

Comments in a codebase often lie. Someone makes a statement then code changes,
making it a lie. A comment that is a lie adds negative value.

I think more than 1 comment per 100 lines of code means you should think more
and refactor more and comment less.

------
im_down_w_otp
1) Spend significant time understanding "why", not just "how and what" things
are going on in your local problem, and also do the same at least 2-3 layers
above and below you in the stack. You should be able to walk away from any
significant piece of work with functional expertise in at least two domains
related to your local problem.

2) Carve out the time and space to make 3-5 variations of a unit of work
before considering it minimally complete for iterating and building upon.

3) Pay really close attention to feelings of pain and/or drudgery when
implementing something. Very often those are signals your design and
separation of concerns are wrong, because you're fighting uphill against your
problem space.

------
yladiz
It's not really along the lines of IDE, tools, etc., but one thing that's been
helpful for me is to bounce ideas off of someone, even if you're trying to
remember something, and the act of explaining or working through my thought
processes helps me pieces together "mental puzzles". This is also known as
rubber duck debugging.

I've had multiple instances of talking to a coworker about a topic, and
halfway through the topic I realize what I was going for and cut it off,
saying, "I got it! Thanks for being my rubber duck."

~~~
Mikhail_Edoshin
Same here, except that I write it down. For each project I have a text file
called "TODO" that is always open and if I need to decide on something, I
usually write it down as a task. I normally start the task description with a
verb and these tasks start with "Think". First I quickly write down the issue
I'm facing, then write "Variants:" and list all the different ways of solving
this issue. I do not evaluate them as I do this, just get pen them down. And
once I'm over with variants, I write the final decision and rationale.

(I once read about problem-solving therapy that is used in cognitive-
behavioral approach and this is almost the same pattern. It sounds obvious,
but few people really follow the steps in practice. It's also similar to
brainstorming.)

In many cases I come up with more variants that I initially had in mind and
quite often I end up choosing the variant that didn't appear promising on the
first look.

------
tboyd47
I like to do exploratory coding in an interactive shell, then when I've
accomplished something, save the readline history to a file and refactor it
into a reusable module with tests. This works in both Ruby and Python.

Over the years I've developed a pretty good sense for when I've gone too far
down a dead end. Some people try and dig their way out, I prefer to just turn
around. It helps when you delay the design stage as much as possible. Makes it
easier to let bad ideas go.

------
lgunsch
Aside from using TDD for years, a few incredibly helpful tips I remember daily
out of the book titled _Test Driven Development: By Example_ , by Kent Beck:

Test lists - plan out a feature/system by listing out its tests. I do this in
the form of behaviours and required inputs.

"Start small or not at all" \- begin coding by doing the simplest super basic
pieces first. You can then start the harder pieces last with a more informed
complete understanding of the problem.

 _Edit: formatting_

------
meagher
Walk around and think.

------
aymeric
Learn your IDE shortcuts.

------
teknologist
Things that I find helpful:

\- an ability to restore clipboard history (alfred on mac or hain on windows)

\- snippets

\- keyboard shortcuts

\- toast notifications for lifecycle events (test and linter failures, CI
build events)

\- having enough monitors (I tend to arrange mine in an way so that the
leftmost shows designs, the middle is for my IDE and the right one shows live
output)

\- most of the things already mentioned

------
tedmiston
When the code is something tedious, I keep a physical timer on my desk and
timebox a working solution to 10–20 minutes, then (as long as it works), I
move on after that. No need for perfection with everything.

------
ofcapl_
currently I'm into switching all keyboards to same model in work and at home
(muscle memory boost)

------
MollyR
drawing prototypes on paper

