4 ms·

1.- We're always wrong. SometimesWereWrong + SometimesWereRight != "We're always wrong" 2.- If something can break, it will break. Good thing this isn't true

by edw519 16y ago

1.- We're always wrong. SometimesWereWrong + SometimesWereRight != "We're always wrong" 2.- If something can break, it will break. Good thing this isn't true. I'm am continually amazed that some of the crap I have to maintain ever ran in the first place, much less that it continues to run. But it does. Sometimes for years without ever breaking. I call it "dodging the raindrops". 3.- All code is crap. OP must have never seen really magnificent code for him to say this. What a shame. It's out there. 4.- There is always a bug. False. The first step in writing bug-free code is believing that it's possible. 5.- The most important thing is the client. Lots of things are important, but it's hard to argue with this one. 6.- Design on paper doesn't work. Sure it can. Just because it usually doesn't work doesn't mean that it can't. I prefer prototyping, but blueprinting can be effective too. 7.- Less is more. Generally, yes. That's what great design and refactoring are for. But there are counterexamples to this. 8.- Coding is only 20% of what we do. If you actually believe this, then you're not spending enough time coding. I'd say more like 50 to 80%. 9.- The customer doesn't know what he/she wants NEVER!. False. The customer often knows exactly what he/she wants, but may have trouble communicating. That's when you expert analysis and prototyping skills come in handy. 10.- Someone has done it before. Similar to #4, the first step in inventing something new is believing it's possible. Lots of stuff that needs to be done hasn't been done for all kinds of reasons. Maybe no one thought it was possible or no one has understood its potential. But we know better. Bonus: Hey! Our job is cool! Yes! I agree!

j_baker 16y ago
"If you actually believe this, then you're not spending enough time coding. I'd say more like 50 to 80%." If you don't include debugging and thinking in that figure (as the author does), 20% doesn't seem unreasonable. I seriously doubt that it's possible (or even preferable) to spend 50-80% of your time literally typing text into your text editor.
- bmj 16y ago
  I think it depends on the size of the team (and related teams) and the sorts of dev cycles you experience. I'd say in my case, including testing and debugging, I code roughly 50% of the time. That doesn't mean, however, that I spend four hours everyday coding and another four going to meetings, etc, etc. The pattern is often more like: code 85% of the time for several weeks, then drift into a period of considerably less coding as we review releases, work with other teams for product hand-off, offer training, and review bugs and issues.
  - drunkpotato 16y ago
    It's also true that we (humans) are terrible at self-reporting information like this. Not that you are lying, simply that you are most likely incorrect.
kenjackson 16y ago
Actually I largely agree with what you say. Here are some rules that I think they should have taught in college, but never did: 1) A good percentage of your time will be spent understanding how a library or framework works. When I was in school the only real library I made much use of was the CRT. This may have changed recently though, as its been a long time since I was in college. 2) You will actually ship a product with known bugs. Triage shocked me when I first joined industry. I was like, "Wait... you're not going to fix that bug? I can fix it, just give me a day!!" 3) Being a great ACM contest programmer doesn't translate to being a great SW engineer. I recall one of my first code reviews where the architect was asking why I didn't use a set of patterns to solve a given problem. I was generally like "The who pattern?"... "Inversion of where?" On teams people like to see patterns for problems they're familiar with. Not my new homebrewed cool method that I just came up with as I typed. 4) People seem to respect how fast you can fix bugs more than the absence of bugs. This is a weird one, but it seems to be something I've seen across multiple places I've worked. People are impressed by people who can fix a lot of bugs. But those people who write fewer bugs to begin with seem to get less praise. 5) Being a debugger whiz is often the difference between fixing a bug in an hour vs a few days. I used GDB in school, and even then, not often. Largely printfs. I can't imagine ever going back to that. I guess this is really "a craftsman knows her tools".
- ciupicri 16y ago
  Regarding number 5, Brian W. Kernighan & Rob Pike mention this in "The Practice of Programming": As a personal choice, we tend not to use debuggers beyond getting a stack trace or the value of a variable or two. One reason is that it is easy to get lost in details of complicated data structures and control flow; we find stepping through a program less productive than thinking harder and adding output statements and self-checking code a1 critical places. Clicking over statements takes longer than scanning the output of judiciously-placed displays. It takes less time to decide where to put print statements than to single-step to the critical section of code, even assuming we know where that is. More important, debugging statements stay with the program; debugger sessions are transient. P.S. The book was published in 1999.
  - 16y ago

by edw519 16y ago

j_baker 16y ago

"If you actually believe this, then you're not spending enough time coding. I'd say more like 50 to 80%." If you don't include debugging and thinking in that figure (as the author does), 20% doesn't seem unreasonable. I seriously doubt that it's possible (or even preferable) to spend 50-80% of your time literally typing text into your text editor.

bmj 16y ago
I think it depends on the size of the team (and related teams) and the sorts of dev cycles you experience. I'd say in my case, including testing and debugging, I code roughly 50% of the time. That doesn't mean, however, that I spend four hours everyday coding and another four going to meetings, etc, etc. The pattern is often more like: code 85% of the time for several weeks, then drift into a period of considerably less coding as we review releases, work with other teams for product hand-off, offer training, and review bugs and issues.
- drunkpotato 16y ago
  It's also true that we (humans) are terrible at self-reporting information like this. Not that you are lying, simply that you are most likely incorrect.

kenjackson 16y ago

Actually I largely agree with what you say. Here are some rules that I think they should have taught in college, but never did: 1) A good percentage of your time will be spent understanding how a library or framework works. When I was in school the only real library I made much use of was the CRT. This may have changed recently though, as its been a long time since I was in college. 2) You will actually ship a product with known bugs. Triage shocked me when I first joined industry. I was like, "Wait... you're not going to fix that bug? I can fix it, just give me a day!!" 3) Being a great ACM contest programmer doesn't translate to being a great SW engineer. I recall one of my first code reviews where the architect was asking why I didn't use a set of patterns to solve a given problem. I was generally like "The who pattern?"... "Inversion of where?" On teams people like to see patterns for problems they're familiar with. Not my new homebrewed cool method that I just came up with as I typed. 4) People seem to respect how fast you can fix bugs more than the absence of bugs. This is a weird one, but it seems to be something I've seen across multiple places I've worked. People are impressed by people who can fix a lot of bugs. But those people who write fewer bugs to begin with seem to get less praise. 5) Being a debugger whiz is often the difference between fixing a bug in an hour vs a few days. I used GDB in school, and even then, not often. Largely printfs. I can't imagine ever going back to that. I guess this is really "a craftsman knows her tools".

ciupicri 16y ago
Regarding number 5, Brian W. Kernighan & Rob Pike mention this in "The Practice of Programming": As a personal choice, we tend not to use debuggers beyond getting a stack trace or the value of a variable or two. One reason is that it is easy to get lost in details of complicated data structures and control flow; we find stepping through a program less productive than thinking harder and adding output statements and self-checking code a1 critical places. Clicking over statements takes longer than scanning the output of judiciously-placed displays. It takes less time to decide where to put print statements than to single-step to the critical section of code, even assuming we know where that is. More important, debugging statements stay with the program; debugger sessions are transient. P.S. The book was published in 1999.
- 16y ago