51–60 of 142 posts
I've personally spent 10 years in academia deeply understanding many things that more often than not were good for nothing. Now I'm OK with just getting things to work quickly and not looking back.
PS: I'm a really fast typer.
Earlier quoted context omitted.
You've just hit a real actual problem in the code. Factoring that out isn't premature, it's responding to reality.
I was reacting to the idea that instead of fixing the immediate bug you just found you're going to redesign the whole thing to prevent that type of bug from occurring ever again in the future.
Don't get me wrong, you have a point - there is certainly a balance to be struck.
This is relevant: http://esr.ibiblio.org/?p=316 Also, I'm curious about something. Those of you who are good at building mentals models: are you also visual thinkers?
Interesting to note that he has now replaced C with Go (GoLang)
I also found that interesting, but not a big surprise since he is one of the co-authors of go...
i'm conflicted because on one hand i don't want to be the code police that simply refuses any changes from others, but at the same time its hard to be responsible for a system when so many core updates are done by other team mates w/out proper testing.
i think the happy middle ground is: no such changes in common trunk. Do those in a branch, and only merge them in when benefits are clear, team is on board with all changes, you're ready to release to production, and will be around during the release.
http://cm.bell-labs.com/cm/cs/tpop/debugging.html
I had this in my wishlist for a while. This just made me buy it.
Wonder how different it will be from Code Complete 2.
Earlier quoted context omitted.
I also found that interesting, but not a big surprise since he is one of the co-authors of go...
Agreed - we'd probably all be most productive working in a language we'd designed ourselves, irrespective of the merits or demerits of that language for other programmers.