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?

  • 5
    Career advice and/or workplace relations are off-topic here. We focus on conceptual questions about software design. But the answer most people will tell you is that you should never write code solely designed to impress; always write readable, maintainable code, and ideally impress them with how readable and maintainable it is. Like any other feature, use templates and std:: stuff if and only if they benefit the code
    – Ixrec
    Jan 4, 2016 at 1:39
  • 5
    "Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?" - Brian Kernighan, "The Elements of Programming Style", 2nd edition, chapter 2
    – Gusdor
    Jan 4, 2016 at 10:16

4 Answers 4


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.

  • 1
    Makes a lot of sense. yeah not just simple template stuff you know, that's just a hint of where I'm trying to get
    – Vinícius
    Jan 4, 2016 at 1:44
  • @ViniyoShouta: I figured as much; it's why I kept that particular observation to a footnote. Worth saying so as not to mislead other readers, but not tainting the core of my answer. Jan 4, 2016 at 1:45
  • 5
    This, this is the answer. I love the subtle way this says "I'd fire you for using things that in your opinion 'look cool' without a reason" Jan 4, 2016 at 7:44
  • 1
    @user3834459 I would hope that your first reaction would be to just tell the developer to cut out the fancy crap instead of firing him over an easily correctable quirk! This is a common misconception for new programmers that's easily resolved by simply explaining the importance of maintainability and simplicity in a real-world environment.
    – Lilienthal
    Jan 4, 2016 at 13:49

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.


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.

  • 2
    I should really take a look at the linux kernel.. :P Jan 4, 2016 at 8:06
  • 1
    @user3834459 Available here! github.com/torvalds/linux. I don't understand half of it -- don't get me wrong. But I tend to sift through it from time to time for the parts I do understand. It always impresses me how uniformly designed and organized it is. There's no clumsy helper functions, little to no use of exotic language features -- just a very symmetrical codebase, and headers denoting clear interfaces (at least for relatively speaking for the very low-level nature of what things are doing). It's a reminder to me of simplicity -- since I used to be those types...
    – user204677
    Jan 4, 2016 at 8:12
  • @user3834459 ... getting all excited about the most exotic and advanced language features (expression templates, policy classes, etc, though I didn't do it for showboating but just with poor prioritization), only to find myself back again at favoring plainness, idiomatic code -- the aesthetics of the language we use.
    – user204677
    Jan 4, 2016 at 8:14

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.

  • 2
    I don't agree. If it's a people problem, it is in the sense that people who program often fail to arrive at the most straightforward solution, choosing instead solutions that are either popular, exotic or both, when they should be choosing instead the solution that makes the most sense from a practical perspective. Jan 4, 2016 at 5:30
  • 2
    Interesting. You do not agree and then you almost repeat what I have said, using different words. The trouble is that "practical" and "making sense" to some people just means "what I know". Sometimes that may even be a valid argument but in the long run it often means falling behind and growing less effective. In order to be able to choose that most straightforward solution, you will need a skill set to choose from. Not just one skill. This can be a problem either way: folks just knowing old technology, clinging to it, or folks just knowing some arbitrary modern technology. I have seen both. Jan 4, 2016 at 6:25
  • It is of course possible that in some organizations, some co-workers will behave in a defensive manner to prevent either new employees or new techniques from gaining a foothold, but this didn't answer the OP's question, and I don't think letting someone make sub-optimal changes simply because they're new and in "breaking-in" period is warranted.
    – Dan1701
    Jan 4, 2016 at 7:42
  • 1
    <g> Just to let you all know how polarizing a topic this is: I am getting multiple upvotes and downvotes for this contribution. Apparently people can identify with one of the two camps. It is a common phenomena in our industry: a new guy who is being a "smart ass", stepping on some toes, shaking things up... A co-worker once said "a company is like a container with mice. Drop in a new one and it will cause a big stir. Until they all stink the same again, then peace returns." Jan 4, 2016 at 9:34

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.

  • I like it how you say programmer groups have their own defined idea of a language culture.
    – Vinícius
    Jan 4, 2016 at 21:17

Not the answer you're looking for? Browse other questions tagged or ask your own question.