Expectations
Looking for feedback to sanity check my expectations of junior and not-so-junior C++ developers. Currently wondering how things have changed since I started in the business, and whether agile practices have damaged the way things work.
When I was a junior developer it was drilled into me to:
* always initialise variables
* pass non-built-in types by const reference when in-parameters
* use const correctness
* know how short-circuit evaluation works and use it to prevent unnecessary execution of code
* avoid the use of
* use clear naming (including the single responsibility principle)
* format code neatly and consistently (including spaces around in-fix operators and keeping line lengths down to minimise scrolling when using debuggers or diff tools)
I also expect them to know the basics of OOA/D and (in particular) when not to add a method to a class (things which should be a stand-alone utility function.) And know how to do routine things with the C++ standard library.
Should these basic facts be known by all C++ developers? And are there any others you think people should know before they drop the "junior" from their title?
Thanks, Andy
When I was a junior developer it was drilled into me to:
* always initialise variables
* pass non-built-in types by const reference when in-parameters
* use const correctness
* know how short-circuit evaluation works and use it to prevent unnecessary execution of code
* avoid the use of
using namespace std* use clear naming (including the single responsibility principle)
* format code neatly and consistently (including spaces around in-fix operators and keeping line lengths down to minimise scrolling when using debuggers or diff tools)
I also expect them to know the basics of OOA/D and (in particular) when not to add a method to a class (things which should be a stand-alone utility function.) And know how to do routine things with the C++ standard library.
Should these basic facts be known by all C++ developers? And are there any others you think people should know before they drop the "junior" from their title?
Thanks, Andy
Last edited on
Speaking from the perspective of a self-taught programming hobbyist, abso-fraggin'-lutely that list should be known and adhered to. From the beginning even when one is first starting the journey of learning programming.
My two biggest "set in stone" guidelines are "avoid 'using namespace std;'" when writing new code and "always format code" for a consistent look and feel.
But then I'm not even an "expert beginner" when it comes to programming so take what I say with a truckload of salt.
https://daedtech.com/how-developers-stop-learning-rise-of-the-expert-beginner/
My two biggest "set in stone" guidelines are "avoid 'using namespace std;'" when writing new code and "always format code" for a consistent look and feel.
But then I'm not even an "expert beginner" when it comes to programming so take what I say with a truckload of salt.
https://daedtech.com/how-developers-stop-learning-rise-of-the-expert-beginner/
Those are all good ideas, but unless you have a document spelling out what is and isn’t correct you have no standing to enforce it.
Everything is ultimately a business decision.
(It might be worth reading through https://isocpp.org/wiki/faq/coding-standards.)
Everything is ultimately a business decision.
(It might be worth reading through https://isocpp.org/wiki/faq/coding-standards.)
Should these basic facts be known by all C++ developers?
Yes.
Although now dated (C++98) there is a C++ book called 'Common Knowledge'
https://www.amazon.co.uk/Common-Knowledge-Essential-Intermediate-Programming/dp/0321321928/ref=sr_1_1
which distils what every C++ programmer is expected to know (its only 240 pages).
and in particular I'd suggest:
- string/string_view
- stream i/o
- algorithms
- iterators
- containers (especially vector)
I'd also suggest some understanding of RAII.
Definitely! There should be a document detailing what is expected as coding standards (detailed even to the level as to how variables, types etc are named - using underscore, capital letter, how braces are laid out [which can be a very emotive issue!] etc etc). Every programmer should have to follow this as part of their contract.
Yes.
Although now dated (C++98) there is a C++ book called 'Common Knowledge'
https://www.amazon.co.uk/Common-Knowledge-Essential-Intermediate-Programming/dp/0321321928/ref=sr_1_1
which distils what every C++ programmer is expected to know (its only 240 pages).
| do routine things with the C++ standard library |
and in particular I'd suggest:
- string/string_view
- stream i/o
- algorithms
- iterators
- containers (especially vector)
I'd also suggest some understanding of RAII.
| unless you have a document spelling out what is and isn’t correct you have no standing to enforce it. |
Definitely! There should be a document detailing what is expected as coding standards (detailed even to the level as to how variables, types etc are named - using underscore, capital letter, how braces are laid out [which can be a very emotive issue!] etc etc). Every programmer should have to follow this as part of their contract.
| Should these basic facts be known by all C++ developers? |
The list is less important than comprehension why each entry is on the list.
| Should these basic facts be known by all C++ developers? |
Probably not.
Let's go through them:
always initialise variables |
I've had professors not do this. I'm of the mindset that you should initialize variables in a class rather than waiting for a constructor to set them for you. I've been burned more than once by some dumb code where, for one reason or another, the constructor is not called. It blows my mind that one would REWRITE the variable name just to set it to nullptr in the constructor when they could have done so when creating the variable, less code, faster, and safer!
pass non-built-in types by const reference when in-parameters |
Don't even remember const references being taught, but it's possible they slid it in there somewhere.. I don't think the majority of students I was with in university would ever use a const reference.
know how short-circuit evaluation works and use it to prevent unnecessary execution of code |
I didn't know the terminology, but I knew the concept. I don't remember where I learned it, but I don't think it was from any professor..
avoid the use of using namespace std |
Consistently used and shoved down our throats as students, I doubt many of them even know what it really does besides let them type less code. I've tutored students in higher than beginner level coding classes who used it and didn't understand why it was a problem (a problem that has bitten me many times).
use clear naming |
I don't know if it was taught as being particularly important.. And I know I'm very guilty of not doing so myself....
format code neatly and consistently |
Programming environments basically do half the job for us these days, yet I still see people creating horrid looking code - but not often.
I think the take away is.. assume they know nothing until proven otherwise.
Last edited on
most places I have worked couldn't care less as long as it was readable (formatted and decent variable/function names) and worked.
Everything else, even if it didn't follow the stated formatting document or guidelines, was ignored until it caused problems. Consistently causing bugs due to errors created from not following guidelines would be a problem.
Expecting interviewees to have an identical background to yourself and to do things the way you do them is not a good way to find good people. For example, possibly not anymore but if not, until rather recently many c++ programmers educated in another country were using c++ 98 because their education system could not afford to upgrade the books and computers in their system. Not long ago, using namespace std was encouraged(!!) and someone who studied in that era may not have kept up with the don't-do-that-now trend. Line length is totally subjective... used to be a smackdown if you exceeded 80 characters because that is what fit 1000 years ago when screens were not wide and editors didn't scale the display etc, but now? 100? 200? they all fit on some setups. I am old and blind so I keep my font large and my lines short, but meh. This isn't something to get worked up about, as long as its a LINE of code (1 or 2 statements) and not 20 statements all on line. A lot of the formatting nonsense is 'book format' to save printing costs when the code is printed out, something that just isn't done today (in bulk, you may print a page here and there but rarely every line in a modern program!). For example not putting braces on their own line with nothing else so they align correctly is for printing books -- but unfortunately, a lot of coders use this style to squeeze more code onto a page at the sacrifice of aligned brackets and neatness.
None of that matters. When hiring someone, you just want them to be willing to comply to your coding standard document, and be good at solving problems and expressing them in the language. If they can do that, you are better off than some robot who makes pretty code but can't think their way out of a paper bag.
Everything else, even if it didn't follow the stated formatting document or guidelines, was ignored until it caused problems. Consistently causing bugs due to errors created from not following guidelines would be a problem.
Expecting interviewees to have an identical background to yourself and to do things the way you do them is not a good way to find good people. For example, possibly not anymore but if not, until rather recently many c++ programmers educated in another country were using c++ 98 because their education system could not afford to upgrade the books and computers in their system. Not long ago, using namespace std was encouraged(!!) and someone who studied in that era may not have kept up with the don't-do-that-now trend. Line length is totally subjective... used to be a smackdown if you exceeded 80 characters because that is what fit 1000 years ago when screens were not wide and editors didn't scale the display etc, but now? 100? 200? they all fit on some setups. I am old and blind so I keep my font large and my lines short, but meh. This isn't something to get worked up about, as long as its a LINE of code (1 or 2 statements) and not 20 statements all on line. A lot of the formatting nonsense is 'book format' to save printing costs when the code is printed out, something that just isn't done today (in bulk, you may print a page here and there but rarely every line in a modern program!). For example not putting braces on their own line with nothing else so they align correctly is for printing books -- but unfortunately, a lot of coders use this style to squeeze more code onto a page at the sacrifice of aligned brackets and neatness.
None of that matters. When hiring someone, you just want them to be willing to comply to your coding standard document, and be good at solving problems and expressing them in the language. If they can do that, you are better off than some robot who makes pretty code but can't think their way out of a paper bag.
Last edited on
| Not long ago, using namespace std was encouraged(!!) |
Even Saint Bjarne uses it in his college course sources. Hiding it in his generic #include that accompanies the code examples in "Programming Principles and Practice Using C++, Second Edition."
The frikkin' guy who (mostly) invented the language uses it. *SMH*
| but unfortunately, a lot of coders use this style to squeeze more code onto a page at the sacrifice of aligned brackets and neatness. |
I'm glad we're on the same side of the bracket debate.. When the brackets don't have their own line, sometimes I just miss them entirely and takes a few extra seconds to figure out what brackets align with what.
One of my professors REQUIRED opening brackets to not be on their own line. To me, this was a complete overstepping of their role as a professor, as it should be up to personal preference. Each method has its advantage (one is more compact code and the other is more readable code). And though I think readable outweighs compact, there's little point to arguing.
Could count on one hand the number of professors that didn't upset me..
| Could count on one hand the number of professors that didn't upset me.. |
😃
Last edited on
I distinctly remember two professors I enjoyed, both were for English classes, go figure.
A good portion of professors were alright, I don't remember them much. The rest pissed me off somehow.
Like one professor who thought C++ sucked because the authors didn't use "data and evidence" to determine the best way syntax should be written. He then went on to author his own programming language that he made us use in his class which was universally hated by all of us for being unintuitive to use with a terrible GUI.
He wrote his new language in.... Java! Definitely the most ergonomic syntax language out there! And his programming language was extra slow for complex functionality! And the whole time I was thinking, we could have just used Java directly - and I hate Java!
He couldn't go 3 sentences without mentioning how programming languages should be "evidence-based". Sorry bro, the evidence came in, people like using C++, no one likes using your language.
The sad thing is he wasn't even a bad professor, he was mostly cool, but he couldn't let this go.
A good portion of professors were alright, I don't remember them much. The rest pissed me off somehow.
Like one professor who thought C++ sucked because the authors didn't use "data and evidence" to determine the best way syntax should be written. He then went on to author his own programming language that he made us use in his class which was universally hated by all of us for being unintuitive to use with a terrible GUI.
He wrote his new language in.... Java! Definitely the most ergonomic syntax language out there! And his programming language was extra slow for complex functionality! And the whole time I was thinking, we could have just used Java directly - and I hate Java!
He couldn't go 3 sentences without mentioning how programming languages should be "evidence-based". Sorry bro, the evidence came in, people like using C++, no one likes using your language.
The sad thing is he wasn't even a bad professor, he was mostly cool, but he couldn't let this go.
//////// UNDER CONSTRUCTION //////// Thank you for all your replies, you've given me plenty to think about.
And I have at least on question to ask, once I get my act together.
As this forum is going though a quiet phase at the moment I'm going to take advantage of the space and spawn a few follow-up thread.
Three so far, but at least one more to sort out. Will close this thread once I'm done, and remove the "UNDER CONSTRUCTION" banners.
Andy
Expectations - Expert Beginners
https://cplusplus.com/forum/lounge/285849/
Expectations - Coding Standards
https://cplusplus.com/forum/lounge/285850/
Expectations - Common Knowledge
https://cplusplus.com/forum/lounge/285851/
//////// UNDER CONSTRUCTION ////////
No need to close the thread, should no replies get added eventually it will "close" itself in a month or so disabling any ability to add a reply.
| Could count on one hand the number of professors that didn't upset me. |
Be glad you ain't 'No Fingers Fred.'
Topic archived. No new replies allowed.