4 ms·

I don't have an account there, but a few things immediately spring to mind. - Caching and cache invalidation are really hard - if you have to go there, make su

by mpk 16y ago

I don't have an account there, but a few things immediately spring to mind. - Caching and cache invalidation are really hard - if you have to go there, make sure you can disable the cache at any time - Using regular expressions for anything but processing lines of text means you're probably doing it wrong - Few programmers can handle concurrency, provide APIs with lots of run-time checks - Have coding guidelines and enforce them in code review - Boring code is good code - Lack of automated tests make every commit a crap-shoot - Use consistent logging (with levels), if this is a major performance hit scrub the code out for the production build - If there is no expert on the team, become the expert. If there is, learn from the expert and become one as well - Always take responsibility for your code - Sometimes ugly hacks are necessary. Deploy them, but make it a priority to factor them out at the start of the next cycle (don't leave this crap around for 'someone else later') Oh man, I could go on like this for hours.

spolsky 16y ago
you don't need an account to post. Pick one of those and write it up!
- TheSOB88 16y ago
  I wonder why he thought he needed one.
  - pjscott 16y ago
    Because it's a reasonable default assumption, when you're looking at an unfamiliar discussion website?
    - TheSOB88 16y ago
      Hmmm... maybe the opposite should be pointed out.
silentbicycle 16y ago
> Using regular expressions for anything but processing lines of text means you're probably doing it wrong And since half the people noting this usually just handwave about the jwz quote* : Regular expressions have very definite limitations, which is why complex parsing is usually done with a second layer on top of REs. Regular expressions for tokenizing (AKA "lexing": breaking a stream of characters into individual tagged tokens - this is an operator, that's a floating point number, etc.), and then a grammar is made for those tokens with a parser. If you aren't aware of the limitations of REs, you can just keep adding layers and layers and eventually end up with madness like this RE to recognize RFC822-valid e-mail addresses (http://www.ex-parrot.com/~pdw/Mail-RFC822-Address.html http://www.ex-parrot.com/~pdw/Mail-RFC822-Address.html). * "Some people, when confronted with a problem, think 'I know, I'll use regular expressions.' Now they have two problems." -jwz. Funny for people who already know, but not very enlightening otherwise.
- eru 16y ago
  > Using regular expressions for anything but processing lines of text means you're probably doing it wrong Depends. The theory of regular expression works for all semirings (http://sebfisch.github.com/haskell-regexp/regexp-play.pdf http://sebfisch.github.com/haskell-regexp/regexp-play.pdf). On the other hand, if you are using backreferences or something crazy like that, you have left regular expressions.
MartinCron 16y ago
Lack of automated tests make every commit a crap-shoot The last thing I want to do is start another broad TDD flamefest, but I honestly believe that if a programmer hasn't even tried a test automation framework (xUnit or similar) then they are being professionally negligent. Would you want to work with a surgeon who was too set in his ways to sterilize instruments? The last time I was doing developer candidate interviews, I would start the phone screen with "what test automation frameworks do you enjoy using and why". If they couldn't answer that, I did my best to make it a very short phone call.
- keyist 16y ago
  You are misusing the term, and the conflation around definitions of TDD make up half of every 'TDD flamefest'. http://c2.com/cgi/wiki?TestDrivenDevelopment http://c2.com/cgi/wiki?TestDrivenDevelopment TDD specifically calls not only for unit tests, but for writing them first, ie the test _drives_ the development. You write a test that fails, then write code to pass the test. One can be anti-TDD but still believe in unit tests, full coverage, etc.
  - silentbicycle 16y ago
    Indeed. I've never seen a TDD debate that has focused specifically on whether tests upfront are sufficient for designing good APIs, etc., though (ironically, the most important part of TDD!). Usually, one side is aghast that the other side doesn't believe in testing (when they usually do, just not to an eXtreme), and the other isn't convinced that letting tests do all the design work makes sense. They're usually talking (or firing cannonballs!) past each other, mistaking disagreement for mutually extremist positions. (And then the "us vs. them" feelings kick in...) I'm in very strong agreement that automated testing (unit, regression, integration, etc.) pays for itself in most sufficiently large projects, but skeptical of TDD specifically - testing during exploratory programming often gives good feedback, but it's just one of many tools.
    - c00p3r 16y ago
      Writing a test-cases based on business cases (domain knowledge) before any code is a good practice. It is that simple.
rikthevik 16y ago
My old boss had a good saying: If it isn't tested - it doesn't work.
- gaius 16y ago
  A former cow-orker had in her .sig, next time you release untested, why not release undeveloped too?

by mpk 16y ago

spolsky 16y ago

you don't need an account to post. Pick one of those and write it up!

TheSOB88 16y ago
I wonder why he thought he needed one.
- pjscott 16y ago
  Because it's a reasonable default assumption, when you're looking at an unfamiliar discussion website?
  - TheSOB88 16y ago
    Hmmm... maybe the opposite should be pointed out.

silentbicycle 16y ago

> Using regular expressions for anything but processing lines of text means you're probably doing it wrong And since half the people noting this usually just handwave about the jwz quote* : Regular expressions have very definite limitations, which is why complex parsing is usually done with a second layer on top of REs. Regular expressions for tokenizing (AKA "lexing": breaking a stream of characters into individual tagged tokens - this is an operator, that's a floating point number, etc.), and then a grammar is made for those tokens with a parser. If you aren't aware of the limitations of REs, you can just keep adding layers and layers and eventually end up with madness like this RE to recognize RFC822-valid e-mail addresses (http://www.ex-parrot.com/~pdw/Mail-RFC822-Address.html http://www.ex-parrot.com/~pdw/Mail-RFC822-Address.html). * "Some people, when confronted with a problem, think 'I know, I'll use regular expressions.' Now they have two problems." -jwz. Funny for people who already know, but not very enlightening otherwise.

eru 16y ago
> Using regular expressions for anything but processing lines of text means you're probably doing it wrong Depends. The theory of regular expression works for all semirings (http://sebfisch.github.com/haskell-regexp/regexp-play.pdf http://sebfisch.github.com/haskell-regexp/regexp-play.pdf). On the other hand, if you are using backreferences or something crazy like that, you have left regular expressions.

MartinCron 16y ago

Lack of automated tests make every commit a crap-shoot The last thing I want to do is start another broad TDD flamefest, but I honestly believe that if a programmer hasn't even tried a test automation framework (xUnit or similar) then they are being professionally negligent. Would you want to work with a surgeon who was too set in his ways to sterilize instruments? The last time I was doing developer candidate interviews, I would start the phone screen with "what test automation frameworks do you enjoy using and why". If they couldn't answer that, I did my best to make it a very short phone call.

keyist 16y ago
You are misusing the term, and the conflation around definitions of TDD make up half of every 'TDD flamefest'. http://c2.com/cgi/wiki?TestDrivenDevelopment http://c2.com/cgi/wiki?TestDrivenDevelopment TDD specifically calls not only for unit tests, but for writing them first, ie the test _drives_ the development. You write a test that fails, then write code to pass the test. One can be anti-TDD but still believe in unit tests, full coverage, etc.
- silentbicycle 16y ago
  Indeed. I've never seen a TDD debate that has focused specifically on whether tests upfront are sufficient for designing good APIs, etc., though (ironically, the most important part of TDD!). Usually, one side is aghast that the other side doesn't believe in testing (when they usually do, just not to an eXtreme), and the other isn't convinced that letting tests do all the design work makes sense. They're usually talking (or firing cannonballs!) past each other, mistaking disagreement for mutually extremist positions. (And then the "us vs. them" feelings kick in...) I'm in very strong agreement that automated testing (unit, regression, integration, etc.) pays for itself in most sufficiently large projects, but skeptical of TDD specifically - testing during exploratory programming often gives good feedback, but it's just one of many tools.
  - c00p3r 16y ago
    Writing a test-cases based on business cases (domain knowledge) before any code is a good practice. It is that simple.

rikthevik 16y ago

My old boss had a good saying: If it isn't tested - it doesn't work.

gaius 16y ago
A former cow-orker had in her .sig, next time you release untested, why not release undeveloped too?