Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: What are your "great" programmer habits?

news.ycombinator.com

Post reply on HN
Print view View original

11–18 of 18 posts

Re: Ask HN: What are your "great" programmer habits?

#11

Post by drooby »

stemcanuck wrote: post #7
drooby wrote: post #3

1. Deeply understand the problem before you start writing code. 2. Provide in depth summary and explanation of the problem and solution in your PRs Engineers can waste months or years of their collective time because they don't understand the problem they are trying to solve. They slap bandaids and fight wack-a-moles. Both steps I listed above combat this issue.. the person(s) dedicated to solving the problem must un…

This is so interesting. What is your process of understanding the problem deeply? How do you keep track of your progress?

Honestly.. just keep asking "why?".

Most engineers ask "why" to the surface level questions. E.g. "Why is the bug doing this instead of that?" A: "Oh, because this conditional does thing..simple, just fix this conditional. Solved!"

Then the issue pops up again... The engineer probably didn't ask why enough.

The should have investigated more... "Why did the original author choose this logic instead of the alternative? Was it purposeful, or was it a truly logical mistake?". If it was purposeful, why was this alternative not considered? What was Product's intentions here?" etc. etc.

Re: Ask HN: What are your "great" programmer habits?

#14

Post by muzani »

1. Commit for half the sprint, then add one uncommitted item. Say, you have a 10 day sprint. You commit to 5 days of work. You add another item, but don't tell anyone.

Studies show the work takes about 1.8x the estimated time. But if you underestimate, then Parkinson's law fills out the time and the 1.8x rule still applies. The uncommitted item is there to combat Parkinson's Law.

2. Sketch a full plan before any code. Wireframe, which fields does this item fetch from, where is it stored in DB. Especially if you're either FE or BE, it prevents blind spots from either of you. You also want peripheral vision of the whole playing field and this is how you do it. Spend minimum time on this; all plans are meant to be thrown away. If you don't need it, it takes 5 mins.

3. (and to answer your q3) If you can't spare half an hour, then you need half a day. The more out of control things are, the more discipline you need. If you can't make it, then accept that you have lost and figure out how much ground you need to concede. Overextending is how you lose everything, burn yourself out and burn out your team.

Re: Ask HN: What are your "great" programmer habits?

#15

Post by Davidbrcz »

stemcanuck wrote: post #9
Davidbrcz wrote: post #5

- Take notes of past decision (what context, deadline, available skills on the team, compromises that had to be made...). - MR/MR contains a ref to the ticket, an explanation of the changes, proof of work or way to test the change. - Know how to leverage your tools (git, editor) - Be curious [other languages, tools (formal methods, fuzzing..), fields (web if you embedded, or the other way around), maths ... ]

Proof of work is so interesting! For backend changes, does that mean curl commands? some screenshots? Could you give me an example format of your notes? I would love to see the detail one can get from them?

- curls commands, unit tests, screenshot ... It depend on what you work on and need to do.

- You can look up architecture decision record (ADR). There are plenty of good resources on google.

Re: Ask HN: What are your "great" programmer habits?

#18

Post by dave4420 »

stemcanuck wrote: post #8
dave4420 wrote: post #6

1. Keep notes. Depending on context, that might be comments written on the ticket, a notes file (that I delete when I open a PR), or todo notes (with my initials) that I either resolve or defer to another ticket before opening a PR (and I have a `git todo` alias to find them all). Partly this is just so I don’t have to rely so much on my memory. Partly this is communication to the rest of the team. Sometimes I leave…

I want to know more about note taking! I'll give you my example, when I am driving to work I might realize something or during lunch. In that case, what do you do?

If I realise something during lunch, and I don’t have my laptop next to me, I’ll write a note to myself on slack (which I have on my phone). No reason you couldn’t use a note taking app, if you remember to check it later.

When I commute, I commute by train. Leave yourself a voice memo, if you’re driving?

Post reply on HN