Should I be using advanced techniques most of the time at my new job just because I can? [closed]

Question

Simply put I'm new to the company, should I rather write advanced techniques with things like templates, std techniques..etc to make a first good impression and have my colleagues trust/be impressed at my work or should I be more concerned in writing more solid/based standard code for each current problem to be solved?

Answer 1

Absolutely not.

If you joined my team and spent your whole time using more advanced techniques than were necessary for the task at hand, I would certainly be less than impressed. You'd be making it more difficult to read, understand and maintain the code … not only for your teammates, but also for yourself. And for what reason? Showing off? Not cool.

Though at least you'd be making it easy for me to find content for your first performance review!

The way to impress me is to use the right tool for the job. If a problem comes up which is best solved with an "advanced technique", and you are capable of delivering such a solution in such a way that code stability and maintainability is not compromised, then I'd be impressed.

To be clear, though, the use of templates and standard library facilities is hardly "advanced". I require anyone joining my C++ team to be familiar with these as a matter of course.

Answer 2

As a disclaimer, I'm interpreting "advanced" here as not like a basic class template for a data structure or a function template for a generic algorithm which inputs iterators. This hardly seems like showboating territory unless it's among a team of people who don't know how to use C++. I'm assuming things like, say, policy class templates that allow infinite combinations in policies when only one combination is actually useful: exotic solutions far beyond the norm... maybe even more advanced than policy classes: things without a name yet that people have never seen before, tricks using the language that have never yet been applied in production code.

Noooooooooooo!

The hallmark of an experienced developer is not one who applies recursive metatemplates to create something resembling a basic DSEL to solve a routine task. That's programming masturbation -- it's best saved for scrap projects on the side to better understand how the language works or when writing a book on how to explore the deepest boundaries of a programming language.

It doesn't even come from an elaborate mechanism to replace 3 lines of straightforward boilerplate in 50 source files with 1 line of code. If anything, experience will have you initially excited with such solutions only to, over the years, come back to the straightforward solution when realizing that maintainability was actually degraded instead of improved by getting so fancy.

One of the key hidden metrics of maintainability that isn't discussed so often is "familiarity". Exotic code is unfamiliar code, and likely to be unfamiliar even to yourself after some time has passed upon revisiting it. This is why idiomatic code is so valuable -- it improves maintainability by improving familiarity. We're saturated by idiomatic code, and so it tends to remain ever familiar. "Exotic" is the polar opposite, and it's usually coupled by a desire to reshape the programming language being used rather than to embrace its strengths and accept its weaknesses.

Templates can be wonderful and straightforward ways of achieving compile-time abstractions at no runtime penalty, and sometimes are even properly used in a recursive or DSEL-like context for something the language would otherwise be incredibly inept to handle. I'm assuming that, when you say "advanced", it's to use templates in a very unusual way. But embraced too quickly, they can quickly end up counteracting the goals they were intended to serve: they can turn into the elaborate macro.

If you want to impress people, use the simplest, most idiomatic, straightforward solution you can get away with -- the less exotic the better. Sometimes there will be sections in a codebase that have an unusually complex demand where we have to break away from the norm. Yet the key here is to do this sparingly, reluctantly, to not apply complex solutions for simple tasks. The genius-level solution is to find a simple, symmetrical solution to a seemingly very complex task -- this is often very difficult, but it's not so hard to avoid applying complex solutions for simple tasks.

While this is C instead of C++, check out the Linux kernel. It's written in the most astoundingly straightforward way given the combination of complexity and the critical nature of what it's doing, yet it's organized logically and better than some basic codebases that are doing far simpler things. Take these kinds of sources of simplicity and straightforwardness as inspiration, and as a way to impress your colleagues.

It's great to understand really advanced techniques like the intricacies of SFINAE, but save such advanced knowledge for the most advanced problems where the advanced solutions end up being the most elegant and straightforward solutions.

Answer 3

Sometimes the environment is conservative or just not open to do things any other way then what people are used to and thus comfortable with. Then you will meet opposition whenever you go off the path your co-workers know and they will throw bogus reasoning at you for not using a particular technique rather than trying to catch up and learn something new. There is no standard way to deal with that. Sometimes it is better to just do it and let the results speak for themselves, other times it is better to not stir the pot too much and let everyone get used to the new guy first, to gain some credit, acceptance and willingness. It is more of a social challenge than a technical one.

Answer 4

It's easy to say, "No. Don't do that," or "just write maintainable code." It's easy to assume that any programmer in their right mind will gravitate toward the same obvious, simple, beautiful solution. But I'm here to tell you that's nonsense. The complexity (if we can call it that) of any project is determined by some hard-to-define dynamic including institutional culture, programming language culture, individual tastes, community tastes, and the changes in all of those things over time. Put simply, what's obvious today wasn't obvious yesterday and won't be obvious tomorrow. To me, that means the obvious way of doing things isn't.

In way of illustration, take a practice like DI. When I first started working on big projects, DI didn't exist. Then suddenly it was everywhere. I was confused. Why add a layer of indirection to straight-forward code? Where before it was easy to follow dependencies from implementation to implementation to implementation, now I had to navigate to an interface and figure out which concrete implementation I was dealing with. It wasn't obvious. But... it had its benefits. It made testing easier and, with a little luck, created a shift in thinking that made testing a primary concern. So, I like DI. But to say it's obvious and simple is a half-truth. It's obvious and simple given certain goals (testability, programming to an interface) but it's not obvious and simple to a new programmer.

As a less enterprise-y example, look at the Lua source code versus Linux kernel code. Both projects are very concerned with simplicity and performance and yet both projects look very, very different. How can that be if all good programmers arrive at the same simple solution? (I assure you that both projects enjoy the efforts of excellent programmers. Personally, I find the Lua source inspiring and delightful.)

What this means for you is that it's impossible for us to say if you should or shouldn't use "advanced" techniques. It really depends on your team and on your project. What's advanced for one team isn't for another. Pay close attention during code review. (You have code reviews, right?) If a team member or two comments that your code is a little complicated, process their feedback and try to make your code "locally idiomatic". If you're doing it right, it should be hard to tell who wrote which code in a project. Blend in. If that doesn't feel right, (it happens) maybe the project or team isn't for you.