9 ms·

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

49 points by samblr 10y ago

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.

tmaly 10y ago
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 10y ago
  very true
jneumann004 10y ago
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.
aymeric 10y ago
Learn your IDE shortcuts.
lgunsch 10y ago
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
jskulski 10y ago
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-Guided-Tests/dp/0321503627 https://www.amazon.com/Growing-Object-Oriented-Software-Guid... - https://www.youtube.com/watch?v=nIonZ6-4nuU https://www.youtube.com/watch?v=nIonZ6-4nuU
- johnwheeler 10y ago
  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.
- tedmiston 10y ago
  Another good feedback loop is just using a REPL. https://en.wikipedia.org/wiki/Read%E2%80%93eval%E2%80%93print_loop https://en.wikipedia.org/wiki/Read%E2%80%93eval%E2%80%93prin...
greydius 10y ago
Spend 99% of the time thinking, 1% of the time typing.
- beachstartup 10y ago
  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 10y ago
    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.
ozten 10y ago
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 10y ago
  > programmer notebook or wiki - document steps or arcane knowledge for the next time Any examples of dedicated notebook software?
  - ofcapl_ 10y ago
    markdown files probably ?
  - ktaube 10y ago
    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/id866773894?mt=12 https://itunes.apple.com/us/app/quiver-programmers-notebook/...
    - Raphmedia 10y ago
      I also vouch for Quiver. Works really well.
  - et-al 10y ago
    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.
meagher 10y ago
Walk around and think.
MollyR 10y ago
drawing prototypes on paper
tboyd47 10y ago
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.
im_down_w_otp 10y ago
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.
ofcapl_ 10y ago
currently I'm into switching all keyboards to same model in work and at home (muscle memory boost)
yladiz 10y ago
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 10y ago
  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.
teknologist 10y ago
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 10y ago
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.

49 points by samblr 10y ago

tmaly 10y ago

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 10y ago
very true

jneumann004 10y ago

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.

aymeric 10y ago

Learn your IDE shortcuts.

lgunsch 10y ago

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

jskulski 10y ago

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-Guided-Tests/dp/0321503627 https://www.amazon.com/Growing-Object-Oriented-Software-Guid... - https://www.youtube.com/watch?v=nIonZ6-4nuU https://www.youtube.com/watch?v=nIonZ6-4nuU

johnwheeler 10y ago
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.
tedmiston 10y ago
Another good feedback loop is just using a REPL. https://en.wikipedia.org/wiki/Read%E2%80%93eval%E2%80%93print_loop https://en.wikipedia.org/wiki/Read%E2%80%93eval%E2%80%93prin...

greydius 10y ago

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

beachstartup 10y ago
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 10y ago
  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.

ozten 10y ago

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 10y ago
> programmer notebook or wiki - document steps or arcane knowledge for the next time Any examples of dedicated notebook software?
- ofcapl_ 10y ago
  markdown files probably ?
- ktaube 10y ago
  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/id866773894?mt=12 https://itunes.apple.com/us/app/quiver-programmers-notebook/...
  - Raphmedia 10y ago
    I also vouch for Quiver. Works really well.
- et-al 10y ago
  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.

meagher 10y ago

Walk around and think.

MollyR 10y ago

drawing prototypes on paper

tboyd47 10y ago

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.

im_down_w_otp 10y ago

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.

ofcapl_ 10y ago

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

yladiz 10y ago

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 10y ago
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.

teknologist 10y ago

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 10y ago

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.