- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
What a terrible survey.
"Size of team" options go from "3 or 4" to "8 to 12". OK, an oversight.
Page 3 about code reviews first asks what tool(s) you use to do code reviews, then asks if you do them at all. Of course, the tool is required, even if code reviews are not performed.
That's all the further I got before being too frustrated to bother.
__ EDIT FROM ALEX: Thanks for the super-helpful feedback Scott! This was a huge survey to write, and since I do this as a hobby, in my free time after a loooong day at work, I tend to make a few careless mistakes (dragging questions out of order), which is totally unfair to you. I'm so sorry for making a "terrible" survey... but now thanks to your quick feedback I've fixed the mistake you noticed.
Admin
I Agree, the wording on some later questions is very awkward too. On the code review section i had to put in some random answers to questions that didnt apply to me because it wouldn't let me continue otherwise :^(
Admin
I just noticed something a bit odd with one of the first questions. We have a team size of 6, but the options jump from "3 or 4" to "8 to 12". :(
Admin
"watching someone with godlike SQL abilities scold the unworthy masses was inspiring" - no, it just showed he was a bit of a git.
Admin
I'm mostly going to disagree with Alex on this one. The converse problem is far more common and serious: A programmer is asked a specific question. He does not know the answer, and instead of admitting that he does not know the answer, or even understand the question, he instead uses his weight to get the asking programmer to start over doing it his way, as if that will not introduce its own problems and cause additional delays. It is kind of like the following situation: A person is driving from Maine to California. They get to the Midwest, and get a flat tire. They call the office to find out the adminstrative procedures for dealing with it. Instead of an answer to their question, or even "I don't know", they get instructions on how to go from Maine to California via a different route. So they have to go back to Maine and start over, without any guarantee that the new route will not cause its own problems.
Not addressing a programmer's actual question (even "I don't know the answer to your question, but I'd recommend you do this instead" is better than ignoring the question and buffaloing them into starting over) is effectively punishing them for asking a question. This causes enormous delays in the long run, because the programmers learn that it is better to waste time finding the answer to their question themselves than risk asking a question which could save a lot of time if the other person happens to know the answer, but for which they will effectively be punished if the other person doesn't know the answer.
Admin
@jinpa I think we agree?
I used to believe that "punishing for asking a question" was an effective way to teach, but now I know it's not. As you identified, delays are one problem... and so is morale, etc.
That's why I'm trying to do a survey to get developers to say how they actually want to learn :)
Admin
Celko actually got banned from SQLServerCentral.com for being too tough on newbs! No idea if he still is or not. Though I'm no longer active there, I was for over a decade and saw him slam some to the ground. I've since changed professions and no longer live in the database developer/administrator world.
And the mantra for SQL Server has always been that there are many ways to do things. Celko is an amazing programmer, but he doesn't know how to dial it down for dealing with people who are just starting out.
Admin
Umm ... asking what the syntax is for nesting IF's is not a stupid question. Yes, IFs can be nested or they can be sequential. So what? That doesn't answer the question. It's like someone asking, "What is the speed limit on Route 32?", and he scornfully replies, "Don't you know how to drive? Of course roads have a speed limit!" Knowing that most programming languages allow IFs to be nested does not tell me exactly how to write this in one specific language.
Admin
It sounds more like someone asking "What is the speed limit on asphalt roads?"
And yeah, I'm not surprised that he's become "problematic" in today's participation trophy snowflake-dominated world. "Too tough on newbs"? Maybe they could put their brains in gear and do a little bit of research before asking basic questions. Some call it "lurk moar".
Admin
There are no stupid questions. Only stupid/ignorant people. Whether the stupid/ignorant person is the asker or the askee can be nebulous.
Admin
"On a scale of 1-5 (where 1 is low and 5 is high) how much do you care about knowing the business value of your work? *" . Except there are no numbers in the answers...
Admin
I'd love to take it, but my employer blocks Google Docs.
Admin
You will find that the commercial software industry - that is, the very small part of the computer programming world that actually generates commercial software for sale - is extremely different from the larger world of programming, where people write code to drive factory robots, send astronauts to the moon, run nuclear plants, &etc.
As a person who has worked with every facet of the computing except commercial software development, I often find the comments and perspectives of commercial software developers to be sort of weirdly otherworldly. For example, in many American companies a "code review" is not something likely to happen if the code makes the machine work. That's not contributing to bottom line profits so it will not be done unless something goes wrong. QA doesn't happen in half or more of programming shops, honestly. I've written operating code for breeder reactors, and I used to BEG (to no avail) to have my code reviewed.
Admin
Asking "What's the speed limit on Route 32?" and then being slammed for trying to ride a horse when Route 32 is built for cars.
Admin
Public scolding is wonderful, assuming you want to discourage your students. If you punish people for asking questions, you punish them for being curious. Trying to learn? Well, screw you. Your first attempt wasn't perfect? Go die in a fire.
It might not be the worst way to mentor, but it's somewhere in the top five.
Admin
D'oh! Yes, I didn't read the article carefully enough. But it's good to underestimate an estimate an article for once!
Addendum 2019-10-24 08:21: By "an article" I meant in general, not just here, which are of good quality.
Admin
I submitted a WTF regarding one of the questions to the dailyWTF. Now to see if they're self-reflective enough to post it :P
Admin
Au contraire, code review has, in my experience, been a favorite weapon of the mediocre in their unending war against the competent. Its sole purpose is to empower petty tyrants to dictate style preferences. Thus, the focus is entirely on brackets and spacing at the expense of any functional aspects. No matter how many deadlines you miss due to, among other things, mountains of unfixed bugs in a locked repository, there's always time to haul a bored programmer before a tribunal, berate them over their local variables, and make them reformat thousands of lines of working, tested code.
Suffice it to say, when I had to do code review (elsewhere), I was shocked that "no, we don't feel like it" was deemed an acceptable response to real problems like zero error handling or documentation. Every time a former employer makes the news with another embarrassing IT problem, I laugh and laugh and laugh.
Admin
You seem to like blunt and honest feedback, so here it is.
Your survey absolutely sucks in every way. Not only is the target audience incredibly limited, they aren't likely the ones that are opening the survey, because they don't know about it. I found this via channels I subscribe to as a leader, not as a mentee, so I expected this to make sense, but it wasn't for me.
Additionally it is extremely biased, it has two blatant failure modes based on the assumptions:
Every question on there was written in the guise of "What's wrong with your mentorship right now". You'll get biased results and even if you didn't, it wouldn't be worth anything because the questions don't make sense.
Furthermore, as someone who is in leadership, having the answers to these questions is completely worthless. That is because everyone is different, if not slightly then very different. You can't look at mentorship as a whole and know how to lead or help your team members. You need to carefully understand them, and then use that information to help.
Additionally your team members change over time, even if the answers to the survey were right today (which of course they aren't anyway because bias and uniqueness), this data immediately becomes useless tomorrow.
Okay, that was really harsh, and the truth is that my teams have developed good strategies for identifying not only how to mentor but overall health of the team. For both junior members as well as more senior ones, we have tools (which we now share publicly) to identify the challenges and opportunities for improvement. If you are interested in what we are doing there I'm happy to share our wisdom, learning, and what our survey's look like.
Admin
What's a "menor"?
Admin
I'm not a fan of this survey. A lot of developers who want mentorship are still students, and so aren't /part/ of a company -- so why make all that information required? Or maybe they're unemployed, or retired, or... And, of course, much of the rest of the survey isn't focused on mentoring at all, but current processes at your company. Which, again, may not exist. Students are mentored at school. Why is that never asked about?
Similarly, not all teams do code review. I think this is an issue, yes, but for a survey meant to ask people about their real-world situations, it's rather annoying that the "It isn't :(" option leaves the rest of the "so how does your team do code reviews it doesn't do" questions mandatory.
Likewise, "who has helped you the most at your organization increase your knowledge" is both unwieldy (and possible grammatically incorrect) and allows for "no one" -- but then you're still required to answer questions about this nonexistent person. I also don't see why the "at your organization" qualifier has been added; are our best mentors not allowed to be in previous jobs?
Why is "who gives you institutional knowledge" limited to one choice, instead of multiple? Where's the option for "internal documentation"?
This one's comparatively minor, but "how much do you care about knowing the business value of your work" is "on a scale of 1-5" but has six options, none of which are labeled 1 to 5. Though, to be fair, the last two options do seem to be repeated.
There's also a serious lack of consistency. I can understand wanting to customize the text a bit, but seeing "how X is your Y" and "on a scale of 1-5, how Z is your W" right next to each other when both have answers forming five gradations on a scale and only /one/ is labelled is... odd.
Admin
"Do you know how your company makes money and achieves its overall mission? * Not a clue…. Something about making money, probably I know code has something to do with it, but I couldn’t tell you how Fully… I totally understand how we help our customers"
You feel these three answers cover the full range for this question? Wow.
In general, every question you only have three options for is very lacking on range. Most of your questions would benefit by having an 'other' option so that people who fill these things out could tell you in more detail about what you're missing.
Further, "requiring" answers is rather short-sighted. Some people don't have all of these answers, but still have valuable information to contribute on other points. By requiring answers, you skew your results to random. Not requiring answers increases the chance that the answers you get will be good ones.
Admin
Oh, another thought I had while looking at the survey:
While 'expert in the technology' can be very useful in code reviews and 'well versed in institutional knowledge' is often pretty vital, it was surprising to me just how frequently basic boolean logic is useful. One of our best reviewers is known for just saying, "Could you document this better?" The majority of the time, several bugs are found while bringing the code documentation up to his standards. (He does sometimes say. "This code doesn't match the comments", but that only happens when someone's making a change to properly commented code, and he's new enough that most of our code isn't well commented yet.)