I've read some articles talking about the challenge of Impostor Syndrome. I never felt like this was a good description for the way I work. I'm good at what I do, that is actually hard for me to write, say, present to others because I am only starting to believe it. I never feared that my deeds were taken beyond what I did, which may actually reflect poorly on my environment as it would suggest no one was around to notice (luckily there have been a few).
What has got me to write this is that I'm starting to realize that my expectations have been too high. I don't know what it is about this industry but it puts out so much BS. I'm only slightly kidding. There are so many patterns, paradigms, practices, and much more out there. They are all rooted in some valid points and even provide great benefits to the industry and the way things are done. The BS comes from the build out of frameworks and idea that these patterns need to be used everywhere.
(I'll be sticking to programming examples, I'm more likely to post specifically about testing if asked). Consider Continuous Integration, historically there was a real problem with long standing branches and the effort to bring them into the mainline. Thus CI was born, learn to make smaller changes and bring them into the mainline frequently. Ok, well the code should compile afterwards, and the unittests written should also pass, oh and also it should work with the entire application suite. CI was a very basic principle to help long standing collaboration, now you can not claim to do CI unless fairies have blessed it with stolen pixie dust. If you're the only team member and doing all the work on a single branch, you aren't doing CI even with a CI framework managing the build, because CI was about collaboration (note I do believe you can collaborate with yourself). Sorry, my point is, if you feel like you aren't good at CI because there are so many tools and frameworks to do it for you... you're probably not looking at what it really means.
Another technique which has been bastardized with frameworks is Dependency Injection. Again it had humble beginnings, things appear out of nowhere (literally you call into a function and it would create a new instance of something and own it). It has some very good applications and can be a little tedious at times, that is where the framework comes it. All of this creating things and passing them through long lines of calls so the one place which needs it can utilize it without creating it, that all goes away with a framework because that framework can be used to specify what to create out of thin air all in one location. If you find that you like to use static classes in your OOP language, or prefer to pass in an argument rather than creating it in the function, then you're doing DI.
My expectations have just been too high. I keep having to look up IoC, should I use MVC or MVP, or how many lines of code should my function have. These patterns are created, defined, and turned into frameworks so they are more accessible. But they are being accessible to people who don't know what they are or how to utilize them at the right time. When you have an application written TDD with DI and no one wants to touch it because the code base is a mess and this new system which uses TDD and IoC is touted to simplify everything because it follows these principles; it is not that I don't know what these things are, but that I have an expectation of myself that I can whip them out and use them well is wrong... no one can (well not enough anyway).
Oldest comments (0)