Technology Lab / Information Technology

In over my head! How can I work with more advanced programmers?

Working with more advanced code means you'll have to learn, quickly.

Stack Exchange

darkman asks:

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 (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?

Related: "Why would I learn C++11, having known C and C++?"

Answer: Be Confident, Be Smart, Be Open (20 Votes)

carleeto replies:

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: Try Five (4 Votes)

Yoni replies:

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". It's 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:

Related: "Is there any reason to use C++ instead of C, Perl, Python, etc.?"

Answer: Pair Up & Take Ownership (2 Votes)

Luhar replies:

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.

Related: "Best way for a senior programmer to switch languages/jobs in next job?"

Think you know how to get along with more experienced programmers? Disagree with the opinions expressed above? Bring your expertise to the question at Stack Exchange, a network of 80+ sites where you can trade expert knowledge on topics like web apps, cycling, scientific skepticism, and (almost) everything in between.

Expand full story

17 Reader Comments

  1. 4 answers but 0 comments. Are these from the staff??

    Clicking on any of the folks replying, such as "Luhar replies" leads to this: ... 6067/65752
    Server Error in '/' Application.

    Runtime Error


    Theory: Perhaps the can't figure out the code OP is working on the new comment system?

    Regarding the article: EVERYONE has been in these shoes. Be open. Be polite. Figure out the local conventions and standards; stick to them. And must of all: Try not to f*** things up too badly.
    3312 posts | registered
  2. trikster2 wrote:

    Server Error in '/' Application.

    Runtime Error

    probably because of this: ... s-weekend/
    1182 posts | registered
  3. Yeah, pretty much all of the above. I answer a lot of questions from both other developers and testers on my team, and other teams. Some about my code, others about design, and so on. The only time I get annoyed is if a quick Internet search would have gotten you the answer. If they're particularly persistent with searchable answers, I reply, "Do I look like MSDN to you?" Snarky, rude, but effective.

    But yeah, the gist is I agree with the above. Don't be afraid to learn new techniques, make a couple mistakes, dig around on the Internet, and then ask some clarifying questions.
    42 posts | registered
  4. I wouldn't worry about asking too many C++11 questions these days. I think it's safe to say we're all in learning mode despite knowing awful sounding concepts like lambdas, which remind us of something worse than C++ coding, Calculus. I recommend lot of good modern C++ videos over there especially under the "going native" category.
    2929 posts | registered
  5. You've actually found people who understand C++? Nah, they're bluffing.
    508 posts | registered
  6. I agree with Trencher93.

    If your colleagues were really that advanced, they would be more wary of C++.
    I've seen the really smart ones shy away from C++ and OO, and either go back to using more C, or functional programming.

    If the project is big enough, those C++ antics are going to explode in your face.
    Read Scott Meyers' More effective C++/STL books on how C++ can bite you in a 1000 different ways.
    Also read Noel Llopis on data oriented design.

    10 posts | registered
  7. Mazarax has a point, not because c++ is poor, far from it, but because you can take even the simplest language and write the most convoluted,un-maintainable, "clever" code ever. So keep it simple, and always be wary of the overly complicated.
    607 posts | registered
  8. Whenever I have to find my way around new code or new languages, I'll grab myself an example. Not one from the textbook, but some short script or small program. Then I try to understand it. Where's main, what gets called, what calls what, how's the basic structure and execution path.

    On this way I'll stop whenever I encounter something I don't know or don't understand fully yet. E.g. a Java class with "that pointy bracket notation". Then I Google to find out what the hell this construct is called. Then I Google what it is supposed to do and what idea is behind the construct. What does it model and for what seems fit to be described that way. Then I Google for the syntax. Then I check back with the code and make sure I understand what it does in this context and especially what the edge cases are and how they are handled.

    The most crucial point is then describing what I have met. In my own words and as written notes. If the verification of my own, self made definition matches with a known good and exact one, I have gained a slice of understanding. If it does not, it's back to reading again. The part about writing it down is to not only link the learning experience with words, but also an image. I rarely need to search my own notes (although I can easily do, Tablet PC), because I have made them.

    If you encounter a complex new concept, not just a new notation of something you already knew, this can take a considerable amount of time. If I'm done with something small, I'll go on and either try using the new stuff or look for something bigger, more complex with other new stuff.

    If you think this is complete BS, well, you might be right. I learned over the years that people and their learning skills and habits can differ a lot. I'm personally totally language driven. If I can't explain something on the spot and precisely in spoken words, I've not yet understood it myself. (Note, no native speaker in English, that's the reason why this is so badly written)
    So take this as it is, a very subjective description.

    For the given situation I would not only rely on that, though. As has been said, get yourself some good books. For the new things that you need to wrap your mind around, those will help a lot. If you have a problem with a certain construct or concept in one book, don't be shy to peek into another one on the spot for that particular thing.

    The other advice I would have would be to learn steady and to expect the process to take time. There's books that tell you to learn anything in 21 days, 24 hours, a week or whatever short time frame. That's crap, which you likely already know after 15 years, but even if you "know C++" already, it's not going to be 21 days. Don't get frustrated.
    You also can't force more than a certain amount of new understanding in your head in a given timeframe, with this timeframe for me being a full night of sleep. If you don't learn anything new in a week, because you neither read about nor try to use anything new, you lost this week and can't make up for that by trying to read twice as fast, twice as long or just twice as much the next week.

    And as it has also been said, programmers are usually friendly folk. If there's something that you can't figure out by googling or thinking yourself for some minutes, go and ask politely.
    Also go and ask WHY they decided to use <fancy stuff> at this point or that point, if it is not totally obvious to you.
    Figuring out when to use what is hard on your own and for some things up to the local convention. That is what I would use my questions for.

    At the end, good luck. In such an environment you will have hard workdays, but until you catch up, you will spend your time very productively for yourself.
    1205 posts | registered
  9. In 15 years of doing this I don't think I've ever started on a new team and NOT felt like I was in over my head. Just remember that conscientious programmers know that they didn't get to where they are overnight. Don't pretend that you know more than you do and you'll usually be given the latitude to learn and grow. Welcome all advice and resist the urge to show off what you do know in a vain attempt to fit in. If you're on the team you've already passed their litmus test - you may not know what you need to know right now but the team is confident that you can learn it, and that's your first task - to learn! Dive in and show some progress and you'll be successful before you know it.
    164 posts | registered
  10. Mazarax wrote:

    We are talking about new language features that enable doing stuff that took a ton of coding back in the years of C++ and C. One should not shy away from that if it is going to make them more productive.

    Yes, modern code can still be bad, but that most likely isn't the case here.
    1150 posts | registered
  11. The fact that you admit you are in over your head distinguishes you in a positive way from 98% of all programmers, so you're on the right path.
    48 posts | registered
  12. To me, if all my team members are at the same level as myself, it's a good sign I need to look for a new job(Or get promoted ;) ). When I started at my current job I was tasked with taking over a few projects with a codebase that made absolutely no sense to me. I remember staying up long hours at home and off the clock trying to figure out exactly how things worked, VPN is your best friend at this stage! One of the things I found really useful was to rebuild portions of the code locally dissecting projects piece by piece. Try not to look at the whole code base of a project, instead compartmentalize things and work on individual components. As pointed out above make sure to remain open and teachable, and don't be afraid to ask questions when you need help. From a management standpoint it's better to have someone ask questions than have them stuck working on something for two hours that could have been solved in two minutes!

    Oh yeah and... GOOGLE GOOGLE GOOGLE!!!

    Good luck!
    6 posts | registered
  13. Sorry, but I don't see the issue. Whenever I stop learning in a specific job, it is time to find a new job. Always keep learning. ALWAYS.

    I recall during a phone interview many years ago being asked for the reasons to use a virtual destructor. At the time, I hadn't needed to use them - we didn't use inheritance much in my current role. Since I didn't know, I looked up the answer and really learned it. When they called back for a 2nd interview, I pointed out that I'd learned the answer. Later, I found that had impressed them and was a key reason I got the job.

    BTW, I didn't learn C or C++ in college. I was 100% self taught to that point, so there were gaps in my knowledge. The last time I did any serious programming in C++, everyone used Rogue Wave libraries. Templates weren't considered stable across all compilers.

    At that new job, I taught them source control, intelligent source heirarchies, automatic builds, automatic testing, cross-platform development, fantastic logging techniques (so you don't need access to the running code to find issues) and project estimation skills, so the knowledge trade was reasonable. Their testing was point-n-click, not reproducable. Their code organization sucked. Developers were copying headers and libraries around from each others' workspaces manually, there was no automatic build, no code libraries specifically grouped into subdirs, it was scary. Most of the other developers were hired fresh from college. They were smart, just not fluent in production development methods.

    Nobody knows everything.

    There is always something new to learn. If you aren't still learning AND contributing, it is time to find a new job.
    295 posts | registered
  14. Assuming you and another developer on the team can both stand it -- I find it's a bit of a love-or-hate thing -- I can't overstate the usefulness of pair programming here. I love pair programming but was becoming quite unhappy in general with my chosen field about a year ago. I did some soul searching and ended up realizing I like to work with people to develop their skills, so I started pushing my manager to put me on projects with our junior dev.

    Eventually the manager handed us what turned into the worst swamp-crawl 40 days and 40 nights kind of refactor I've ever experienced. It was date/time code. Despite the horror, we both really enjoyed working on it. We hung out instead of rotting at our desks, I got to watch somebody learn and grow, and she was a vastly better developer at the end of the 6 month refactor.

    We're back at it again merging the refactor into a forked codebase. Sounds horrible, right? And in a way, it is. But for the couple weeks between the refactor itself and the merge, we were kinda lost. Pair programming can be great even for experienced developers, but it can be priceless when leveling up.
    849 posts | registered
  15. I've only been on the other side, so here's my tip: Ask questions. Once.

    If you ask me a question once, I think you're smart. If you're asking me the same question again, I think you're dumb. If you're asking me a third time, you're classified as "waste of time".

    I agree with what everyone else said too. C++ is hard but it's not rocket science. Google is your friend for anything you don't know.

    Also beware, just because something is complicated doesn't mean it's good. I once inherited a code base that was written by some very clever very expensive consultants (hello IBM!). I was in awe - anything that's cool in programming - they'd used it. But over time we ended up throwing more and more of this code base away, and eventually we just abandoned it - it was over-engineered, hard to understand, impossible to change. And I am only saying that _after_ fully understanding what it was doing, which took a while. If you give me a piece of normal code, I can usually pinpoint what does what in a few minutes. I am good at analysis. But this code - it took me a whole working day to trace one web API call... it was crazy. There were 10 layers of abstraction in this web server. Anyway - lesson learned!
    546 posts | registered
  16. I'd recommend a quickie continuing ed or community college class to get up to speed. I've worked with SQL & VB (VBA) for years. Took community college classes in both a few years ago. Thought VB was a breeze until they sprung "try / catch" and other stuff on us. It was both unexpected, but interesting, b/c all of the new stuff provided much more elegant solutions to old coding issues. The SQL class had me hammer out loops and other complex logic structures which my job had never demanded. VB class also got me familiar with the IDE. I learned a lot from both of those classes...some I use in my job now to help automate things.

    Never underestimate the power and cost-effectiveness of a community college class. Can cost like $150, and in about 3-4 months time you can get some experience with a teacher, some projects to code on, etc, etc.

    Might want to be careful of continuing ed courses, though, b/c sometimes it's the same stuff just in an over-priced package.
    4886 posts | registered
  17. From my 30 years in the industry, I've learned that many "hot shot" programmers will write needlessly complex code when a much simpler, and more understandable, solution is possible. My advice would be to NOT try to be like such programmers. Instead, focus on writing clear and simple code which is well commented. The programmers who come after you and have to maintain your work will sing your praises and additions and modifications will be made much faster to your code, thus increasing productivity. If you can't understand another programmer's code, perhaps the problem is theirs and not yours.
    31 posts | registered

You must to comment.