Unit tests are great, especially for important logic, but we all coded for years before unit tests were en vogue and not all of the code was bad. If you are a competent developer working within your area of expertise on something of moderate scale the logic _should_ work the first time you write it, or with minimal fiddling. Unit tests don't add much to this scenario in the short term. The value of the unit tests in this scenario would be for other developers or yourself making changes to this logic or logic that integrates with it later on, doing refactors, ensuring any invariants / requirements are met / enforced, and so forth. For me, while unit tests have some value all the time, they offer the most value when I'm doing something exploratory, working out API's for libraries, writing low level logic that other logic will depend on, when working on teams, when I fully intend to write the initial logic and throw it over the wall to others, and so forth.

It is not an opinion question, it is an architecture question. Solid security is built into an architecture, not stapled on later. Ideally you design a system to be secure from the inside out, rather than enhance a unsecure system towards security from the outside in. The challenge of developing and getting "alpha and beta testers" into a system is a nonsensical / straw man argument. You want your testers testing the system as it is intended to be used when deployed. Trying to add security (or any major / important feature) after initial testing just means you will have to go thru (at best) one more round of intensive testing. Put the security in from day one, and configure the testers properly as users; initial security concerns such as authentication and administration is then among the first tests. Further development _must_ take the security already in place into account / consideration avoiding the oops factor of forgetting to remember that security will "be added later {wink wink nudge nudge}" resulting in busted api's or hidden vulnerabilities. Security is intrinsically inconvenient (in fact security vs convenience is a classic polarity...generally the more secure something is the less convenient it is). It can also get esoteric and / or academic when taken to extremes. For most development projects its an irritating pro forma necessity rather than a "fun" thing to develop. Thus there's a lot of friction and a tendency to want to procrastinate and put it off until the last possible moment and instead focus on the exciting aspects of a project. But like any chore, putting it off until later often comes back to bite you in the end. As to your team, even if you are the junior person, if you feel strongly that security (or any consideration) should be done now rather than later put your money where your mouth is. Take charge of the situation. Make it happen. If the group does not want to tackle security (or whatever it is) and your initial foray is shot down don't get locked into a contentious back and forth with the team. Instead take the initiative and state that you will focusing on the security up front and take ownership of it. Get out in front of it. Put together a small working initial implementation, document it, and apply it. If your cowboy coding colleagues add unsecure code, check it out and make it compatible with your security system, adding features as necessary to accommodate any new security considerations you encounter. Become the "security expert" (or whatever) for

It's a subjective preference of course, so there's not absolute reason(s). Back in the day I used Hu notation; we pretty much all did when it was the "thing you should do". However, here are some points that collectively tilt the scale towards not using Hu these days. * Hu originally solved a problem, the difficulty of quickly differentiating typed variables in primitive development environments. However the modern use of more powerful IDE's having more robust intellisense or similar capabilities that make it trivial to "see" applicable metadata about variables (etc) addresses the need for a quick means of figuring out what is what. Though you say you like to take snippets of logic to review in a simple text editor rather than "have the entire project" local and use your IDE of choice, I would think that you are an exception. Using source repositories it is trivial and normal to have a copy of all source on your workstation or laptop, to work "disconnected", and to synch delta on either side up with the repository when connected and you wish to. I'm not sure what benefit you would gain from working with snippets in a "dead" environment, when it is so easy to work on a compilable, runnable local version. For that matter, these days the source repository is generally only a VPN connection away unless you are on the road or in the air in most corporate environments. This usage of snippets to take home may be an old habit of yours that bears reevaluation; maybe it's no longer necessary. * In the style of OOP currently en vogue, injection is often favored. Many things that used to be variables are often parameters or properties now. Any localized variables tend to be very localized, as in declared very close to their usage, and at method scope or even less (lambdas, etc). Short, concise methods are greatly preferred over long rambling ones, making it much more likely that variable declaration is in close proximity to its usage. * Refactoring is commonly practiced, ideally altering implementation while maintaining functionality. What is a double today might be an int tomorrow; a string might become a char[] or vice versa. Ideally the name shouldn't need to change. Related to this, is the consideration of once and only once; if the name of a variable contains some token or segment that is a direct reinstatement of its (original) underlying type, you have effectively duplicated the information. If the underlying type changes, the "duplication" of the original type information should als

I typically guard condition, delegate to some other logic outside of an event model, and then bubble if applicable. I also try to reuse the same abstracted event as much as possible and deal w/ variability via arguments vs having an event per usage. I feel that event handlers are just listeners / hooks and not workers. Just middle men basically, that facilitate decoupled collaboration. I do make some exceptions where common usage dictates...like a repeater item data bound event handler; it doesn't always make sense to punt the binding if it's tiny. But for non-trivial scenarios I'll push the repeater's body template into a separate component with a "Bind(someModel)" method, and forward to it from the event handler on the containing page or component. As it happens, I'm currently refactoring a ASP.NET client server app towards patterns, paying back a big design debt incurred by the original developers. Refactoring bloated event handlers in this app is one of the biggest sources of code improvement. In particular I'm frequently finding baskin robbins 31 flavor events that all basically do the same thing with only slight variations. This one is chocolate, that one is double fudge, that one is choc-vanilla swirl, etc. Extracting the commonality and variabilizing the differences has significant impact on thinning down code behinds and standardizing the logic; it also has lead to the detection of latent or inconsistent bugs, and generally been a major enhancement to the code quality. It's also a lot easier to read / maintain the end product.