Ask HN: Best daily practices u've come across to design-code faster and better | Hacker News Reader

Ask HN: Best daily practices u've come across to design-code faster and better

49 pointssamblr32 comments

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/frameworks/pattern-designs. It can vary from project to project and what stage of projects.

View on HN

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.youtube.com/watch?v=nIonZ6-4nuU

Another good feedback loop is just using a REPL.

https://en.wikipedia.org/wiki/Read%E2%80%93eval%E2%80%93prin...

Feedback loop as soon as possible... Absolutely, this!

Also, I've found setting up deploy to production as early as possible keeps you focused, prioritized, and eliminates a good bit of anxiety helping you produce better work.

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

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

Any examples of dedicated notebook software?

Quiver looks neat.

If you're searching for something plain and simple, keeping a repo of Markdown files on GitHub has worked well for me.

I make one file for each book / article / lecture. The material I cover is mostly about tech or entrepreneurship.

https://github.com/tedmiston/notes

Here are a couple of the most complete pages in it:

- Show Your Work! by Austin Kleon - https://github.com/tedmiston/notes/blob/master/books/Show%20...

- Zero to One by Peter Thiel - https://github.com/tedmiston/notes/blob/master/books/Zero%20...

- Startup School Radio #35: Paul Graham - https://github.com/tedmiston/notes/blob/master/podcasts/Star...

Still trying to find a good one myself. Tried using Evernote but their code formatting isn't that great and I'm always worried about the day they might close shop.

Been writing Markdown files in a git repo, then syncing on Gitlab so I'd have them accessible anywhere, but there's more manual effort involved with writing Markdown (I forget some of the fancier list/bullet formatting) and also defining metadata for future lookups (first few lines of each text file).

If someone made an Electron-based app, this would be great for all the programmers out there.

In the beginning of my career I used a paper notebook. This is still handy as I think I remember what I hand write more deeply. I still use a paper notebook for ideas and sketching.

TODO list / GTD: For the last few years, I've been using altNV, but any notational velocity clone will do. Killer feature is simplicity through full text search as the filename.

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/...

I also vouch for Quiver. Works really well.

I built https://devarist.com for this purpose.

http://zim-wiki.org

iOS GoodNotes for years. Now I've got an iPad Pro with Apple Pencil and it is pretty wonderful. Of course not perfect—no OCR or searchable text but sure is a nice thing to use everyday.

markdown files probably ?

For tmux, do you use something to persist your sessions across a system restart?

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.

very true

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.

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

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.

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.

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.

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."

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.

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.

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

Walk around and think.

Learn your IDE shortcuts.

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

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.

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

drawing prototypes on paper

Reply on news.ycombinator.com