6 ms·

A few habits I've found that work well for me: 1. Start small, then extend. 2. Change one thing at a time. 3. Add logging and error handling early. 4. All n

A few habits I've found that work well for me: 1. Start small, then extend. 2. Change one thing at a time. 3. Add logging and error handling early. 4. All new lines must be executed at least once. 5. Test the parts before the whole. 6. Fix the known errors, then see what’s left. Taken from here: https://henrikwarne.com/2015/04/16/lessons-learned-in-software-development/ https://henrikwarne.com/2015/04/16/lessons-learned-in-softwa...

chx 9y ago
A few additions 1. If at all possible start from something existing. It is entirely possible by the time you are done nothing remains of the existing. That's fine. To me, it's easier to tweak existing code than fill in an empty editor window. To some, an empty editor window is all opportunity, to me, it's analysis paralysis. 2. Always be ready to throw everything away. You perhaps will save a few choice lines but be ready for your first, sometimes even the second solution to suck badly. This is fine. Putting in more time to have an easier to maintain solution is always useful. 3. To continue from there, easier to maintain code is king. Unless you are writing something extremely time critical do not try to be clever. A little slower is okay (and yes, I am in the performance consultancy business) if it significantly decreases the maintenance burden. Clever hacks belong to toy projects and blog posts. The next person who maintains it will be stupid to the code -- even if it's yourself. That clever hack is now a nightmare to untangle. In short: always code under the assumption that you will need to understand this when the emergency phone kicks you out of bed after two hours of sleep in the middle of the night. The CTO of Cloudflare was woken to the news of Cloudbleed at 1:26am.
- jgrahamc 9y ago
  #3 I agree. Maintenance matters. And I strongly agree with "The next person who maintains it will be stupid to the code -- even if it's yourself."
majewsky 9y ago
> All new lines must be executed at leaat once. What if you write a function in Go that's littered with the usual if err != nil { return err } and the error that's being propagated is hard to reproduce, e.g. a filesystem error? I never cover those "return err" in actual programs.
- henrik_w 9y ago
  I sometimes temporarily modify the program by for example misspelling a file name of a data base column name just to provoke an error that will execute the error handling code. Or changing a condition from == to != to cause an exception. Not ideal, but at least the new code is executed at least once, so I see that it executes as expected. Creating tests for some of these cases would involve mocking things out, and then you have to make assumptions that may not hold anyway. That's why I like to see it execute in the real environment at least once.
  - vram22 9y ago
    >I sometimes temporarily modify the program by for example misspelling a file name of a data base column name just to provoke an error that will execute the error handling code. Yes, a lot of things like that are possible. I remember in one client-server project I worked on, we unplugged the network cable from one PC (while the program was communicating between client and server), to see if we got the correct error message that we had written for that case. And did other stuff like that.
    - vram22 9y ago
      To continue the anecdote: This was done in a project I handled, for the World Bank. I had a team of 9 motivated though young developers (first project for most of them). Near the end, before we sent the software to the client, a colleague was assigned to test the software - testing by a member external to the team, a slightly senior guy, ex-CITIL (a Citi IT subsidiary which had more mature software processes than we did then), though of course we did test the software ourselves a lot, first. I remember what happened: We prepared the machines and software for the test. Called him over. He said: I am going to sit down and destroy your software. We said: Go ahead, please try. And he tried to. But could not. He only found a few minor cosmetic defects. Getting up after a few hours of rigorous testing, he said something like - I am happy with your work.
- mustardo 9y ago
  Consider using a language that has exceptions instead of 1980's error codes
sidcool 9y ago
I have always been a bit confused about logging. On the one hand it's invaluable for debugging, but on the other it creates some unpleasant looking code. Not only that, sometimes, log statements introduce defects in code. I am not sure of the performance implications of logging. But I put logs anyway.

chx 9y ago

A few additions 1. If at all possible start from something existing. It is entirely possible by the time you are done nothing remains of the existing. That's fine. To me, it's easier to tweak existing code than fill in an empty editor window. To some, an empty editor window is all opportunity, to me, it's analysis paralysis. 2. Always be ready to throw everything away. You perhaps will save a few choice lines but be ready for your first, sometimes even the second solution to suck badly. This is fine. Putting in more time to have an easier to maintain solution is always useful. 3. To continue from there, easier to maintain code is king. Unless you are writing something extremely time critical do not try to be clever. A little slower is okay (and yes, I am in the performance consultancy business) if it significantly decreases the maintenance burden. Clever hacks belong to toy projects and blog posts. The next person who maintains it will be stupid to the code -- even if it's yourself. That clever hack is now a nightmare to untangle. In short: always code under the assumption that you will need to understand this when the emergency phone kicks you out of bed after two hours of sleep in the middle of the night. The CTO of Cloudflare was woken to the news of Cloudbleed at 1:26am.

jgrahamc 9y ago
#3 I agree. Maintenance matters. And I strongly agree with "The next person who maintains it will be stupid to the code -- even if it's yourself."

majewsky 9y ago

> All new lines must be executed at leaat once. What if you write a function in Go that's littered with the usual if err != nil { return err } and the error that's being propagated is hard to reproduce, e.g. a filesystem error? I never cover those "return err" in actual programs.

henrik_w 9y ago
I sometimes temporarily modify the program by for example misspelling a file name of a data base column name just to provoke an error that will execute the error handling code. Or changing a condition from == to != to cause an exception. Not ideal, but at least the new code is executed at least once, so I see that it executes as expected. Creating tests for some of these cases would involve mocking things out, and then you have to make assumptions that may not hold anyway. That's why I like to see it execute in the real environment at least once.
- vram22 9y ago
  >I sometimes temporarily modify the program by for example misspelling a file name of a data base column name just to provoke an error that will execute the error handling code. Yes, a lot of things like that are possible. I remember in one client-server project I worked on, we unplugged the network cable from one PC (while the program was communicating between client and server), to see if we got the correct error message that we had written for that case. And did other stuff like that.
  - vram22 9y ago
    To continue the anecdote: This was done in a project I handled, for the World Bank. I had a team of 9 motivated though young developers (first project for most of them). Near the end, before we sent the software to the client, a colleague was assigned to test the software - testing by a member external to the team, a slightly senior guy, ex-CITIL (a Citi IT subsidiary which had more mature software processes than we did then), though of course we did test the software ourselves a lot, first. I remember what happened: We prepared the machines and software for the test. Called him over. He said: I am going to sit down and destroy your software. We said: Go ahead, please try. And he tried to. But could not. He only found a few minor cosmetic defects. Getting up after a few hours of rigorous testing, he said something like - I am happy with your work.
mustardo 9y ago
Consider using a language that has exceptions instead of 1980's error codes

sidcool 9y ago

I have always been a bit confused about logging. On the one hand it's invaluable for debugging, but on the other it creates some unpleasant looking code. Not only that, sometimes, log statements introduce defects in code. I am not sure of the performance implications of logging. But I put logs anyway.