Way in over my head! (Dealing with better programmers)

Question

I've just been hired as a member of a group that is developing in C++. For the last 11 years, I'd been coding on and off at my last job (some C, some Fortran, some C++).

The coding I'd done was mostly maintaining and adding new features to one of our systems. The code, being 10 years old, did not contain all the modern C++ stuff. Lo and behold, my new job is filled with programmers with 5-10 years experience of pure coding and they all use the most modern aspects of C++ (C++11, template, lambda, etc, etc).

They are expecting someone with that same experience... which I have: I've been working for 15 years total, but when I look at their code, I can't understand half of it! :-|

Anyone been in that situation? What would you recommend?

Answer 1

When I have to work with other "experienced" people that fall into the same category as you, my biggest concern is that they would feel they have enough seniority that whatever they did for the last 15 years has always worked for them and they are happy with that. I've had some nice, clean organized code that has been completely trampled over by these "experienced" people.

What I would wish is that they (and just about everyone else, including myself) would approach programming with the idea that compared to what is out there, each of us actually knows very little and that no matter how much experience you think you have, there's always new things for you to learn and write better code, even in the language that you think you know 100%.

I'm certainly comfortable with C++11, lambdas, templates, metaprogramming, etc... but no matter how much time passes I still find that every year my code improves compared to what I used to write a year ago and I've been doing C++ professionally for 13 years.

Just by asking the question you've asked, I don't think you are in danger of being one of those "experienced" people that leave destruction and mayhem in their path. You already have a job with guys who have skills different from yours. This is great for you, don't be intimidated. Instead, show your openness and willingness to learn and I'm sure anyone on your team will be more than happy to mentor you until you get up to speed. They will be happy that you recognize that you need and want to improve yourself. I know I would be.

Ask for some code reviews and advice on how you could approach tasks differently and when you get that feedback, try to remember it for next time. Also most senior guys love to talk about design and lessons they've learned the hard way over the years. Simply talking informally, they'll give you plenty of knowledge you can take away.

As a general advice, whenever possible you should always try to surround yourself with people who are better/smarter than you. It's not a burden that you have to "deal" with but an opportunity to always improve yourself.

Answer 2

The key is just to never forget that they and you were writing "Hello World" once. You all wrote crappy code once and you all got better.

Modern code does not equal well written code. Experience in years does not either.

The best thing for you to do is to have an open attitude to learning. Don't ask questions that Google would give you the answer to or that you could figure out with a quick prototype piece of code.

Just ask smart questions and learn quick. Your biggest danger here is yourself - experience often makes us cynical and can compel us to resist modern methods. Fight that impulse and approach anything new with an openness to learning. The rest will just fall into place.

Answer 3

They hired you and I assume you weren't the only applicant. They saw something that they thought would be an asset to their team. Sounds like you have good programming and more importantly problem solving skills. Maybe you could improve their code by documenting it so programmers know what it does.

Answer 4

I found myself in the exact same situation a few years back; also with C++ though before C++11. The solution for me turned out to be the following:

1. Read, read, read! Ask your colleagues or scour the net for books that explain the things you're struggling with. As you're learning about these concepts, constantly refer back to your colleague's code and check your understanding. I must have read almost a dozen books the first year I worked with C++.

2. Stop worrying about sounding like a newbie and ask questions. Only do this after reading about the concept so that you're asking for clarification specifically regarding the code, and not something you could just Google (kind of like the concept behind this site). Most programmers love to talk about their code, especially if they're using some snazzy new technique. It lets them sound like experts and show off their skills. I've encountered very few people who found my newbie questions to be a negative reflection on me as long as I showed some basic understanding I gained elsewhere.

3. Attend as many code reviews as you can; even if the code isn't directly related to what you're doing. In teams where code review was done in person I learned a great deal, especially since its a perfect chance to ask your questions.

4. Find out if your company is willing to send you to training. We had an internal course twice a year, but I'm sure you'll be able to find some 3rd party training.

5. Finally: give it time. As you must know by now, programming languages are full of features and nuances that take a long time to learn. And as Bjarne Stroustrup himself put it, "C++11 feels like a new language". Its important to keep in mind that learning these things will take time and in a few months you'll feel much more comfortable than you do now.

Some resources you might want to check out:

• C++11 - the new ISO C++ standard by Bjarne Stroustrup
• Presentation Materials: Overview of the New C++ (C++11) by Scott Meyers
• The C++ Standard Library: A Tutorial and Reference (2nd Edition) by Nicolai M. Josuttis
• And... Google!

Answer 5

Anyone been in that situation? What would you recommend?

It is very common for a senior programmer to be in the situation that you have described. Key point is to catch-up with this guys by learning new features that you did not had chance to use/play. Building good relationship with team members while learning new features is really challenging and might be your opportunity to catch up faster with the recent programming trends.

As an experienced programmer, i am pretty sure that you have knowledge of how to write a maintainable and reliable code. In another words, you have a valuable assets which made the company hire you. This is a skill that only experienced programmers have. This is where you may come with valuable suggestions for the project.

Thus, it is a challenge with an opportunity hidden in it!

Answer 6

I have been working as developer for more than 10 years, and I know EXACTLY what you are dealing with. But the key (in my opinion) is to remember a couple of things... First of all (and foremost) is that programming is about problem solving. Analytical thinking! The language is secondary. And second is that the gap between you and them is most likely having to do with patterns and process rather than code.

Answer 7

To speak to what sounds like the key point in your question:

...when I look at their code, I can't understand half of it! :-|

That's nearly always the case when approaching a new code-base which has been around for any length of time (even just two or three iterations of the main project). Code gets written, then it gets refactored, optimized, fixed, refactored again, abstracted... and that can all happen before the first commit. There may be a few algorithms, techniques or tricks that you are unfamiliar with, but those can be learned quickly enough.

The thing to remember is that there is probably code you have written that would elicit a similar response from any one of the developers you are now working with, but which seems completely straightforward and obvious to you. Hell, there's probably code you've written a few years ago that would elicit the same response from you, if you haven't looked at it in a while.

Walk tall, walk straight, look the world right in the eye and tell it "I deserve to be here."

Answer 8

If possible try and pair up with one of the more experienced developers on your team and work on a project together. This may be a "Friday afternoon" type of project, but it will be useful for you to see how they put the code together and an opportunity to ask questions about specific patterns or techniques that you are not familiar with.

You could also try to take ownership of a small project already in production, learn how it works, and try to fix any small outstanding bugs. Most project teams track open issues or feature requests. You might want to get used to working with existing code (get your code reviewed) which, I think, is the best way of getting used to new techniques or code styles.

Answer 9

When Conquistadors first went to South America from Spain, they were judged to be giants, gods, and a host of other magically powerful things. It is true that while riding their horses they seemed very tall, but later after dismounting it was clear they were not giants. With European arms and armor they were formidable fighters, but the illusion about deity and magic had pretty good explanations.

On your new job, look at the code and see if the advanced stuff is used correctly, or if it is technology chasing a solution, and if some things are done for show or to try new things at the expense of a more obvious and effective approach. Review things and jot down each keyword or technique that they use that you are not using (yet). Find out if there are books they use as tutorials or references and either borrow or buy a copy.

Good managers and teams hire carefully, sometimes based on potential. I like the adage, hire for interest, train for skill. They have plans for you and a vested interest in seeing you ramp up and succeed. This may not always be apparent, but certainly your boss looks most successful when a new hire increases the momentum of the team, not when he goes back to the well and asks for a do over. It is good for the team to extend help to a colleague, and it a big part of why we work in teams. In my book, your supervisor and team are most successful when they give a leg up to someone on the team, and this kind of help bears the valuable fruit of loyalty.

Answer 10

I think you should confront your situation in two phases:

Phase 1:

• Forget about keeping pace with the other developers who know about the latest C++ syntactic sugar.
• Complete your assignments and be useful to your team.
• Make a list of all language enhancements that are new to you.
• Carve out some time every day to learn one of these language enhancements.
  • Critical: As soon as you feel comfortable with one of them, write some sample code!!!
  • This will be your way of proving to yourself that you can "hang with the big boys."

Phase 2:

• After you've proven to yourself that you're up to speed with all of the language enhancements, decide if this is still the best job for you.
  • As many have said, working with highly skilled people often inspires people to "take their game to the next level." (In fact, I often seek out such jobs for this very reason.)
• However, if this working group is too intense or too competitive for your liking, there's no shame. This should be your cue to start looking for a new company where the programming culture is more compatible with your talents and skills.

Answer 11

Firstly, there are many definitions of "Better". IMHO, the KISS principle should be paramount. It sounds to me like the guys you are working with are deliberately obfuscating the code in order to be indespensible (read unsackable).

If you can:

1. Learn enough of it to get by
2. Keep your code simple enough for new guys to (like yourself) read & understand.

Then you will be doing a better job than they are!

Answer 12

When I was last in that situation (needed to know transact SQL), I got a good book on subject and started reading.

Answer 13

Think like a buddhist monk jedi: don't be selfish about your knowledge and experience, but also be able to listen because it will improves your project.

You have to be able to explain and re-explain to make your point reach them, but also try to ask better questions when they explain to help them explain you.

You're not in a field when common language allows you to easily communicate with your peers, and they might also not know or view it that way. Don't be afraid to think it'll help them instead of you, you are a team.

Even if helps them more in the end, don't keep it to yourself because it could create a bad status quo where it might cripple the project, and create tensions for dumb politics.

Don't forget patience is the most utter important quality in programming, so don't be afraid to drain their patience when you talk to them to either ask or explain. If they start feeling impatient, it's on them, at least you tried.

Nobody is the smartest, it's all about sharing knowledge to let the project go better as you guys go.

You're damn lucky you're with such smart people, don't ruin it, they are paid to be here, they are not here to show off their wits. It's called humility.