Reputation
5,769
Top tag
Next privilege 10,000 Rep.
Access moderator tools
Badges
1 13 31
Newest
 Custodian
Impact
~259k people reached

Jul
16
awarded  Custodian
Jul
16
reviewed Close Is it common to have downtime at a programming job?
Jul
16
reviewed Close Why is this long overflowing to -1, instead of the minimum value for the type?
Jul
16
reviewed Leave Open Balance between “right tool for the job” and familiarity
Jul
16
reviewed Leave Open My coworker commits and pushes without testing
Jul
16
comment How do we control which features get released?
@gnat: Yes, this means more testing, as I mentioned. Nothing is free in life :-). However, in my experience this is manageable, as long as you keep the number of feature flags under control.
Jul
15
revised How do we control which features get released?
expanded
Jul
15
answered How do we control which features get released?
Jul
10
revised Source code “prints” at release
expand "CM"
Jun
17
comment When is optimization not premature and therefore not evil?
Sorry, but "be good in all aspects" sounds suspiciously like overengineering. Plus, it's probably not realistic - life is always about tradeoffs.
Jun
11
comment Is turning UI (or other) features on and off based on dates-a code smell?
Yes, testing is really tricky if the UI can change based on various factors. If it must be done, it must be done, but it helps to keep variation to a minimum - and to provide a way to toggle the UI for testing, independent of things like current date.
Jun
11
comment Is turning UI (or other) features on and off based on dates-a code smell?
"it's better to simply deploy an update at the correct time" Nitpick: Not necessarily... . For example, deployment may require downtime, which is not practical at the time the switch must be made. Or maybe there will be some period of parallel use... it really depends.
Jun
11
comment Is turning UI (or other) features on and off based on dates-a code smell?
@ArturoTorresSánchez: The former - the whole idea is to put the business logic (such as date calcluation) into the server. Anyway, this would make a good question of its own :-).
May
31
comment verify a defect is a production defect or not
"If testers raise bugs ad hoc rather than against the specific requirements the developers are working too it causes delay and frustration." That sounds like a dangerous attitude. Are you saying the testers should just ignore obvious problems because that's not what they are supposed to test? Note that new bugs need to be prioritized (just like features), so not having time assigned should not be a problem - you fix the bug once it has been prioritized and queued for fixing.
May
7
answered Modern.IE VM license
Apr
30
comment Commit at a logical checkpoint only, or also when you're at a stopping point?
If you have changes that you do not want to push without rebasing/amending them, you can start your commit message with "WIP" (git -m "WIP: dirty test code"), and activate the pre-push hook under .git/hooks/pre-push. Then git will refuse to push as long as the commit exists.
Apr
22
comment Is individual code ownership important?
"It also concentrates knowledge of specific functionality with one (or two) team members" ... "Nor am I suggesting building knowledge silos". Isn't that a contradiction? To me, concentrating knowledge with one/two members is the definition of a knowledge silo.
Apr
9
comment Test Driven Development: A good/accepted way to test file system operations?
@soru: That's not what this answer recommends. It recommends first creating interfaces, then mocking the interface. So you do test the business logic, but not the filesystem interface.
Mar
31
comment How to make a “git push” update files on your web host?
@Mario: Yes, you can - which means you are effectively implementing your own deployment solution as a post-receive hook. There are still benefits to using an existing solution, but sometimes roll-your-own may be best...
Mar
31
comment How to make a “git push” update files on your web host?
And why would you want a "backup of the previous commit's files"? You can just push the previous commit, if you want to roll back (assuming you always know what you pushed last - but you should know that anyway).