Be wary of over engineering things. The first rule of sales is that you don't want to talk about a bunch of esoteric technical details in a look-how-smart-I-am manner that talks over the heads of would be clientele. You want to keep it simple and only tell the other party what they want to know. I'm not sure that the same isn't true in the technical sphere. Code should be code a junior developer can follow. Boilerplate code is good for you. Some where T : magic, not so much. Try not to roll a ball of yarn that only you can unspool. The gunk I see that is fancy schmancy tends to be something a hero set up that no one else every touches. Everyone else kinda tiptoes around it. By way of being uncommon it is immune to extension. It took me a long time to realize this. As a junior developer, in wanting to reach high, I mistakenly thought that architecting involved rolling your own pattern that used code for cross-cutting concerns, Func and attributes, and the like. This is not so. Something about these things shines like a diamond from the outside looking in but once you've made your own antipattern with them they're less intriguing. The I-don't-understand-it-so-therefore-it's-awesome logic is a reflection of your own imposture syndrome and not reality itself. The cookies kept in a cookie jar on a high shelf are all moldy and nasty. Don't use T4 templates. They suck. Don't ask your developers to use a WinForms app that you made that barfs out boilerplate code from T4 templates instead of writing boilerplate code themselves. I once was at a consultancy that really blossomed under a sprawling multiyear government contract and packed a lot of what it baked for that project into an open source project that might be repurposed for future projects. Why rewrite the login controls every time, right? Well, this invention was so bloated that it was never used once successfully as a project template. When I was at Veterans Affairs there was an application so peculiar that someone had authored and abandoned yet the VA itself had to maintain that became one of many arguments behind trying to move away from actually doing development towards solving all problems with COTS (commercial off the shelf) solutions. For the developers coming in the door after the fact, .NET developers because the contract still specified .NET developers, there was a "Would you like learn SharePoint?" surprise. This happens downstream of someone else screwing up. Think of some of the painful things you've had to put up with. Don't build landmines for other people. Don't delude yourself into thinking you're being helpful when you're being slick.
No comments:
Post a Comment