Programmer Insecurity
I’ve got a lot to say today!
I want to chat about something that I’ve never noticed before, but probably should have. There’s always been a stereotype out there of programmers being nerdy, anti-social people (Q: How do you know when an engineer is outgoing? A: He looks at your shoes!). But my revelation of the week is that most programmers seem to be really insecure about their work. I mean: really, really insecure.
My buddy Fitz and I have long preached about best practices in open source software development — how one should be open and transparent with one’s work, accept code reviews, give constructive criticism, and generally communicate as actively as possible with peers. One of the main community “anti-patterns” we’ve talked about is people writing “code bombs”. That is, what do you do when somebody shows up to an open source project with a gigantic new feature that took months to write? Who has the time to review thousands of lines of code? What if there was a bad design decision made early in the process — does it even make sense to point it out? Dropping code-bombs on communities is rarely good for the project: the team is either forced to reject it outright, or accept it and deal with a giant opaque blob that is hard to understand, change, or maintain. It moves the project decidedly in one direction without much discussion or consensus.
And yet over and over, I’m gathering stories that point to the fact that programmers do not want to write code out in the open. Programmers don’t want their peers to see mistakes or failures. They want to work privately, in a cave, then spring “perfect” code on their community, as if no mistakes had ever been made. I don’t think it’s hubris so much as fear of embarrassment. Rather than think of programming as an inherently social activity, most coders seem to treat it as an arena for personal heroics, and will do anything to protect that myth. They’re fine with sharing code, as long as they present themselves as infallible, it seems. Maybe it’s just human nature.
Check out some of these stories I’ve collected:
- Requests at the Google I/O booth: A couple of weeks ago when my team was at the Google I/O conference, we ran a booth demonstrating our Open Source Project Hosting service. Over and over, we kept getting requests like this:
“Can you guys please give subversion on Google Code the ability to hide specific branches?”
“Can you guys make it possible to create open source projects that start out hidden to the world, then get ‘revealed’ when they’re ready?”
Translation: “I don’t want people to see my work-in-progress until it’s perfect.”
- Requests on the Google Code mailing list: Sometimes users need their googlecode.com svn repositories wiped clean. Legitimate reasons include the accidental commit of sensitive data, or the need to load code history in from a different svn repository. But most of the time we get (invalid) requests like this:
“Hi, I want to rewrite all my code from scratch, can you please wipe all the history?”
Translation: “I don’t want people to be able to find my old code, it’s too embarrassing.” Call it vanity, call it insecurity… the bottom line is that coders want prior mistakes or failures to be erased from history.
- Code-reviews taken as personal attacks. Fitz tells a funny anecdote about a friend of his who went from the open source world to a corporate software job. Vastly paraphrased:
During his first week, he started emailing friendly code reviews to each of his coworkers, receiving strange stares in turn. Eventually his boss called him into his office:
“You know, you really need to stop with the negative energy. Your peers say that you’re constantly criticizing everything they do.”
Moral: not only is code review not the norm in corporate environments, most programmers are unable to separate their fragile egos from the code they write. Repeat after me: you are not your code!
- Distributed version control — in a cave. A friend of mine works on several projects that use git or mercurial. He gave me this story recently. Basically, he was working with two groups on a project. One group published changes frequently…
“…and as a result, I was able to review consistently throughout the semester, offering design tweaks and code reviews regularly. And as a result of that, [their work] is now in the mainline, and mostly functional. The other group […] I haven’t heard a peep out of for 5 months. Despite many emails and IRC conversations inviting them to discuss their design and publish changes regularly, there is not a single line of code anywhere that I can see it. […] Last weekend, one of them walked up to me with a bug […] and I finally got to see the code to help them debug. I failed, because there are about 5000 lines of crappy code, and just reading through a single file I pointed out two or three major design flaws and a dozen wonky implementation issues. I had admonished them many times during these 5 months to publish their changes, so that we (the others) could take a look and offer feedback… but each time met with stony silence. I don’t know if they were afraid to publish it, or just don’t care. But either way, given the code I’ve seen, the net result is 5 wasted months.”
Before you scream; yes yes, I know that the potential for cave-hiding and writing code bombs is also possible with a centralized version control system like Subversion. But my friend has an interesting point:
“I think this failure is at least partially due to the fact that [DVCS] makes it so damn easy to wall yourself into a cave. Had we been using svn, I think the barrier to caving would have been too high, and I’d have seen the code.”
In other words, yes, this was fundamentally a social problem. A team was embarrassed to share code. But because they were using distributed version control, it gave them a sense of false security. “See, we’re committing changes to our repository every day… making progress!” If they had been using Subversion, it’s much less likely they would have sat on a 5000 line patch in their working copy for 5 months; they would have had to share the work much earlier. Moral: even though one shouldn’t depend on technical solutions to social problems, default tool behaviors matter a lot. This was my main theme way back when I wrote about the risks of distributed version control.
OK, so what’s the conclusion here? People are scared of sharing their unfinished work, plain and simple. I know this isn’t headline news to most people, but I really think I’ve been in deep denial about this. I’m so used to throwing my creative output up for constant criticism, that I simply expect everyone else to do it as well. I think of it as the norm, and I can’t comprehend why someone wouldn’t want to do that… and yet clearly, the growing popularity of distributed version control shows just how thrilled people are to hide their work from each other. It’s the classic “testimonial” for systems like git (taken from a blog comment):
“Don’t tell me I should cooperate with other people at the beginning and publish my modification as early as possible. I do cooperate with other people but I do want to do some work alone sometimes.”
Hm, okay. Please just don’t work alone for too long!
Sidetracking a wee bit, I think this is why I prefer Mercurial over Git, having done a bit of research and reading on both systems. Git leans much more heavily towards cave-hiding, and I don’t like that. For example, the ‘git rebase’ command is a way of effectively destroying an entire line of history: very powerful, sure, but it’s also a way of erasing your tracks. Rather than being forced to merge your branch into a parent line, just pretend that your branch was always based on the latest parent line! Another example: when it comes to pushing and pulling changesets, Mercurial’s default behavior is to exchange all history with the remote repository, while git’s default behavior is to only push or pull a single branch — presumably one that the user has deemed fit for sharing with the public. In other words, git defaults to all work being private cave-work, and is happy to destroy history. Mercurial shares everything by default, and cannot erase history.
I know this post has been long, but let me stand on my soapbox for a moment.
Be transparent. Share your work constantly. Solicit feedback. Appreciate critiques. Let other people point out your mistakes. You are not your code. Do not be afraid of day-to-day failures — learn from them. (As they say at Google, “don’t run from failure — fail often, fail quickly, and learn.”) Cherish your history, both the successes and mistakes. All of these behaviors are the way to get better at programming. If you don’t follow them, you’re cheating your own personal development.
Phew, I feel better now.
(This page has been translated into Spanish language by Maria Ramos.)
Nice article! If I had a penny for every time I’ve seen one of those sins committed, I could melt them and make a nice, heavy, copper clue mallet.
So true! This could have been written about academia — no one wants to show work in progress, in part because people are often downright mean about it. Or maybe that’s just our institution…. 🙂 Seriously, advice early on is more useful and far less painful, because there is less at stake.
OK, I’m guilty. I’ve been using git recently, and did pretty much what you are describing. (Actually, I pushed all my git commits into a subversion repository, and wished I had “squashed” them all into one commit instead … not so much out of shame for their contents, but also to reduce the noise in the commit logs.)
But in general, I gotta say, it’s embarrassing letting the world see my pathetic fumblings! Particularly when they’re preserved for all eternity in the repository. It’s sort of like stage fright.
@Bryan: Clue mallet? Nice. 😀
This has reinforced my desire to begin using a version-control system for one of the projects I’m working on, which is a website (plain and simple). I’d try Google Code, but the site’s not exactly open-source. Maybe I’ll talk to the other tech people and see if our server admin can get a DVCS running for us to use. It would make it easier to collaborate with the other team member who’s supposedly helping me (but since it’s hard for both of us to work on the code he hasn’t done much).
The behavior you describe is very similar to how math papers are produced. The author tries lots of stuff in private, exploring all sorts of dead ends, but in the published paper absolutely no hint of any of the exploration is given. The paper is written as though the solution was obvious to the author and should be obvious to any intelligent reader. The fact that the author spent quite a bit of time finding the path or the transformations that make allow the proofs is almost taboo. And for mathematics research, I do not think this a serious problem.
But code is not math, and early exposure and feedback are important.
Inspired by Ben’s piece, here is my note to all those people who have said something like “I have an idea for a new PHP content management system, but I would want to keep the project private for a while until it is good enough”:
You *should* be embarrassed about your code… if you don’t start with a clear vision and work through some requirements and design first. Even before forming your project vision, take some time to look around: is your thing really going to end up surpassing what is out there already?
If you have an itch to scratch, scratch it with a good bug report or even a patch, not a whim project.
Thanks,
jason!
Computers aren’t very forgiving. When you work with something that tells you “you’re wrong” all day, you’re bound to get a bit touchy. It’s not like being a manager where everyone tells you you’re great even when you screw up.
I disagree that Mercurial enforces sharing of modifications any more than git does. In your example, it would be just as easy for the hg user to create a fresh branch from trunk, diff -u | patch -p0, and push their newly sanitized branch. I’ve never used git, but from what I understand, this is effectively what rebase does.
I also disagree, strongly, that DVCS makes code hiding any more difficult than single-branch VCS. When using a single branch, it’s usually a very small group of people who are allowed to commit. Any patches from non-core contributors get lost in a tangle of IRC pastebins, mailing lists, bug trackers, and blog posts. Furthermore, even if these patches are eventually committed, they have lost all their associated version information — the destructive rebase you complain about. DVCS allows anybody to branch from trunk, record their changes, and publish their branch in a service like Launchpad or github. For an example of this, look at the mass of user-created branches for popular projects like GNOME Do[1] or AWN[2].
[1] https://code.launchpad.net/do
[2] https://code.launchpad.net/awn
Great post, Ben!
I was at a conference last year which concluded with a panel discussion. I can’t recall the details, but I remember that at some point the conversation turned to an audience member’s apparent need for offline commits. A panelist asked why he didn’t just use a public branch. The audience member was visibly disturbed by this suggestion, indicating that publicizing imperfect code would be a really bad thing. The implication was that he feared his employer’s evaluation of his skill set based on commits that weren’t perfect every time.
And I confess, I’ve had to deal with the same insecurities at times, too. After all, it wasn’t for no reason that I didn’t make the source code for ThotKeeper public for such a long time. The lie I told myself was, “Who cares if it’s public? Nobody but me is interested in this little toy project anyway.” Fortunately, I was proven completely wrong. Since the project has been publicized on Google Code Project Hosting, it’s attracted a fantastic volunteer who’s already finished most of my TODO list! Does he care that my coding isn’t perfect, and my use of the wxPython library not ideal? Of course not.
Too true. Two observations, though. First, sometimes it’s hard to get anyone to look at your code and criticize it. And second, it’s not paranoia if someone’s really out to get you. Sometimes we fear sharing our code because we have the expectation that our fellow geeks will criticize not wisely but too well.
I’ve gone both ways, and I think your philosophy is the right one to choose, but I’ve also been driven out of open source projects because of excessive and unhelpful criticism. I think that I was better off withdrawing, so being open was still the right thing.
This is really true actually. I know I get SERIOUSLY insecure about people looking before something is done. Like they are going to seriously judge me and think I’m an idiot. The thing I always catch myself at is getting mad at people that test my code when it breaks, don’t ask me the logic behind it.
Well said.
I’d *much* rather a fellow developer point out that I (or one of my peers) screwed up in the source tree and have a chance to fix it before it goes “official” than the other way.
I have low self-esteeem and no fear of public failure. Bring on the criticism!
Signed, a few hundred feet away from you at Dev i/O and yet your brother in solidarity.
RJL
If you’re working with programmers who are shy about their code, a great way to get them sharing is a code dojo. See http://www.codingdojo.org/ and https://dev.youdevise.com/YDBlog/index.php?title=code_dojo. Five or ten minutes of live coding on a toy project is not so scary and it loosens them up to share more.
The attitude to not show unfinished code is understandable and IMHO a good thing.
Think about an author writing a book. A painter painting a picture, etc. Most times these people don’t like to share their unfinished work… The same seems to be true for developers.
Personally I’m not interested in code which has not at least reached a specific quality level. During initial development code is often redesigned, rewritten etc. I don’t want to criticize someone who is in the middle of a thought process which is reflected in the source code.
I even think the best architectures, designs, libraries, … are done by a single person, may be two or three people. Too many people arguing over the architecture leads to the “designed by committee” problem.
Later “the community” can to jump in to the project and continue the work, but at this point the project has already set a solid base.
Of course there is a high chance a isolated group may produce crap that sucks. This can always happen. It will be ignored by “the community” anyway. It’s evolution – the best projects/ideas will in the long run survive.
Another point is: YOU and I is not the (OSS-)COMMUNITY!!! We are individuals. Sometimes “with ego like a small planet (Linus on himself)”. Not everything has to be shared and discussed to death. Everybody has its secrets and (hopefully) its own agenda. Probably all innovations have been achieved by individuals and not by a community. Sometimes you have to protect yourself from outer opinions and think on your own. …Later your idea/product/whatever can be discussed, criticized and compared.
If you present your idea to early there is a very high chance to lose your focus and get distracted by too many opinions until you finally loose all your motivation.
– Ralf
You are making oversimplifications here:
I am geek, and yes I don’t show my code until is finished.
Why? Because I had shown it a lot of times, I loved to make aircraft, ship and landscapes modelling in light weight materials with my hands. I used to tell my friends when 95% of the work was done. It was BAD, people said WHAT IS THAT SHIT!! I continued my work and a day later I had my model finished: OHHH, MAN THAT’S FANTASTIC!!! HOW DID YOU DID THAT. I showed you, and you said it was SHIT. THAT WAS THIS??? Impossible. You are the man…
If I had listen to them, I would never had made anything of value. And they were my friends, they loved me.
Sorry but when I program I only listen those who I respect because are better than me. In my experience when I showed them my ongoing code they don’t criticize, and they used to be busy making things happen, not correcting another one program methods.
It is not insecurity, it is the simple fact that you are not good enough for them to respect you and that people don’t like to be micromanaged like an SLAVE (the micromanager adopts a superior level over them that they obviously don’t like).
If you want to be respected in the OSS world you have to had done something of value, if google founders advise a geek of something, geek will listen, if someone of the same OSS group tell the same thing, he will care less.
Great post. I see this character trait in myself and my coworkers regularly. 🙂
Who isn’t for transparency?
Programming culture is about The Right Way (TM). They quiz you in job interviews. Not knowing how to do something correctly is heresy.
With open-source, in some case the fear can be justified. Too often I have seen people get lynched for (perceived or otherwise) writing poorly thought out, linear code.
In the corporate world, it’s a simple lack of time and resources for doing the job right. In-house teams can be very small, and time is generally far too short, with no written requirements. So the focus is on getting the app out the door, rather than using an open development paradigm.
This isn’t limited to programmers either, designers get into the same funk. No one wants to hear that folks don’t like what you are doing, or that you are doing it in an inefficient/incorrect manor – it’s taken me a long time to divorce myself from my designs and code, but it still stings a bit when I work hard on something and it gets picked apart. But, in the end the majority of the time the work is better for it…..
Good post.
Hi Ben!
Hope my fellow polyglot’s doing fine. 🙂 (For your reference: asmodai.)
It is funny that you mention this distinction in Git and Mercurial, it is actually something I pointed out to my colleague yesterday in that I found Hg to emphasize pushing back patches/code more than git.
And I agree with your assessment that people should not be afraid of committing their stuff. For my own local projects I commit everything to SVN. In a sense I use the repository as both a backup mechanism as well as a normal repository. By committing my parts to the repository it also forces me to start committing semi-working prototypes and build it out to a working version and take it from there.
Hmm, interesting article (as was the “risks of DVCS” posting). In principle, I agree, but there’s one aspect of coding “in private” that I think you missed – which is the difference in granularity of commits that are appropriate.
For example, when coding locally I like to commit very frequently, often simply because I want a break. Commits here are very much my personal savepoints, and log messages can often reflect this (commit -m “Stopping to watch Stargate”…) In particular, I don’t expect commits to pass the test suite every time, or even to compile. Log messages like “fix some more typos, doh” are common.
On the other hand, many projects expect commits to (generally) pass the test suite – at least on the mainline. So pushing a big batch of commits like the above is inappropriate.
Now I’d be the first to admit that I’ve no wish to show off my lousy typing (or my viewing preferences!) to the world, but equally I don’t know that *that* level of detail is necessary in a public repository. The problem (which as you say, is social) is deciding what *is* the right level of detail. And then, coming up with a tool or process to allow for both levels (personal and project).
That’s an area where DVCS tools should be looking to address, IMHO. They are great at capturing the “personal” workflow, and fine for publishing that detail. But maybe some sort of command to “roll up” a series of changes into a single group would help. Something to manage the transition from purely personal to public.
Or maybe I’m still in denial, and the world does need to know how bad my typing is 🙂
Thanks for a thought-provoking article.
Paul
Yet another interesting read, thanks.
Is it fair to suggest distributed version control encourages cave-dwelling? The “everything-is-a-branch” model should make it easier for sub-teams to collaborate and experiment. You can share what you want with who you want, and lose nothing if and when you merge back to the trunk. My impression is that dvcs users are at least as comfortable with exposing their work as svn users (but I defer to your experience here).
As you say, it’s more of a social problem. I think there’s also an important technical aspect, and that’s to do with how you architect, develop and maintain software. An incremental development model helps defuse the “code bombs” you mention.
I think we also need an environment where small improvements are welcomed: if you see a typo, fix it — don’t just wait to roll it in with more substantial changes.
One thing I’ve come across is
While I generally agree with this, I can understand why people want code to not be revealed until it’s “ready”. I’ve already had problems with releasing alpha code and having others get mad when the interface changes (sometimes radically). By taking the time to quietly work on it until I know at least that the interface is relatively stable, I can free myself up from a lot of concerns about breaking things at will.
I think this is a very useful article – clearing recognising issues that most developers are aware of, but perhaps choose to ignore.
Personally, I believe that I started to overcome my fear of others seeing my code-in-progress when I first engaged in ‘pair programming’ on a regular basis.
Perhaps this is because we were constantly seeing each other’s design decisions – I certainly found myself learning new design ideas from other developers, and I got feedback that many of my ideas have some value.
Perhaps pair-programming is a microcosm teaching tool for the macrocosm of sharing code in an open source project?
Isn’t one of the problems with software engineering is that there is no standard practice everybody can subscribe to. So, the person wielding the “clue mallet” against you may just happen to have a difference of opinion with you over exactly which practice is best.
A lot of programmers can be extremely personal in their attacks when performing code reviews…so, whilst you and I may be capable of separating an engineer from their code others quite often are not.
If you’re not making mistakes, you’re not writing enough code. The value of collaborative work methods (pair programming, code reviews, etc) is so high – in terms of code quality, design quality, and morale that I find it hard to see why people don’t routinely use them.
@Bryan
Pennies are only copper coated nowadays…
Hi there!
Great post!
In my experience, I’ve learned to criticize other’s developer (mostly collegues) code without critizing *them*. For instance, saying “this piece of code should have been like that…” instead of “*you* should have done like that…”. Maybe it’s quite a silly thing… but I think it could be important, expecially when leading a team of young (and not-so-skilled) developer.
The devious and the borderline personalities seem to manage to become the chief programmers and architects and project managers, this is the nature of the office world. Honest little mice stay little mice, for the most part.
Improvements to an existing project definitely benefit from being developed in the open, especially since good integration of code requires good integration of developers.
However, I still think that it can make sense for unfinished new projects to be only released when they’re at some minimal level of functionality, because one only gets one chance to make a good first impression. Some projects don’t have any value to the community until they reach a certain level of maturity. But more than that, the author might change his mind about the direction of the project — one’s initial vision can be subject to a lot of modification once one is halfway into the project and reality sets in.
As my friend Glyph has put it: Much like in the world of Frisbee, developers on a new project should not make a statement with more predictive power than “Watch this”!
I guess it all boils down to the finished product.
JT
http://www.ULtimate-Anonymity.com
great advice, sometimes we just need to be reminded of these things explicitly, though they seem like no-brainers.
I think the insecurity comes from some of the feedback you get when you post code. Some coders will absolutely flame bad code.
I am just so happy that there are enough of us thick skinned bloggers and coders to make a vibrant programming community.
Also, as “bad as it is”, if you compare and contrast the amount of cooperation that exists between coders and then again between other industry practitioners (say lawyers), you may be favorably impressed with the degree of cooperation that does exist in our industry.
@ Leo Katzenstein
It IS a problem for Math papers. Imagine how many other people may go down those same dead ends on their own, what a waste of time. Or what if someone else could have crossed that last barrier to a more elegant solution? How much faster could Math, or any science for that matter, advance if everyone were not so cloistered?
programmers want their crappy code hidden because they themselves judge other programmers on their code quality. Also, programmers know they can do better most of the time, and spend time trying to get results rather than making perfect code. I don’t know why this is viewed as shameful behavior (aiming for results rather than perfection) but somehow it is.
It would have been nice if you had not tried to weave the DVCS vs CVCS argument into this post – it has diluted and lowered the credibility of the post.
And pray which features of subversion were developed in full public view ? Are design decisions taken debate on public mailing lists ? Is the usage of WebDAV something that was debated and voted upon ? What about committer-only mailing lists? …
Ben, I think you’re pretty much spot-on in the analysis of why coders do this. I doubt that blaming it on DVCS is useful, even if it’s true that git rebasing has made it much easier to go off in a cave. (And I know cave-dwellers who work on svn projects using git-svn too..)
You’ve inspired me to look at coders’ commits and see if they’re behaving as cave dwellers or not. Actually, this seems easier to tell if they’re using git, since they’ll probably post a beautifully formed patch series that was clearly artificially constucted after the fact. When I know one of my collaborators is working this way, I’ll try to nudge them to being a bit more open, and a bit more self-assured. Can’t think of any better way to attack the problem.
Myself, I’ll keep ‘git push’-ing out my “oops, typo” commits on an hourly basis. I’m insecure in a different way — if my code is not pushed out, my laptop could die at any moment and destroy my work. I’d much rather face embarrasment than have to code something twice.
It’s a matter of human nature.
Yes, life would be a nice big bowl of cherries if people didn’t attack others for political gain.
But here in the real world, your success in the industry depends largely on your popularity, and any weakness you show is an avenue of attack for your enemies.
It’s not right, but it does happen. Not a day goes by that I don’t witness yet another ad-hominem attack on someone’s work or ideas.
Obscurity is safety from the ravaging hordes of idiots and assholes who would rather see a good project burn than see someone do better than they can.
Awesome article. As a student programmer, I don’t often work in projects with others. However, your article is helping me understand the merits of OS, which will become increasingly relevant. Thank you.
This isn’t just a problem for developers. If you ever want to piss off a group of network engineers, just make a comment (any comment) about what they could have done differently. And I don’t mean a six-of-one/half-a-dozen of another comment, but something that is deficient. I was shunned by a group of established network engineers when I joined a company because I told them what was causing their problems. They had problems large enough to take down the entire network multiple times a week, but I was the asshole for pointing out how to correct the problems. These people could not even be civil after I gave my design recommendations.
I’m with Ralf Schneider (comment 16) on a lot of this.
There are times to be collaborative and there are times to be isolationist.
Sometimes code is more than engineering. When there is more than one way to ‘do it right’ working alone for a time can be a good thing for a developer. I know alone time at the beginning of a project helps me figure out what I really mean in a piece of software, and how I’d like it to grow.
After that, where scalability and integration are concerned, bring on the audience! Infact, maybe we could get 10 people to suss the details and I’d just tell ’em what to do. That would be perfect.
Rotten Apple wrote:
(1) All of them. (2) Yes. (3) Yes. (4) There are no commiter-only lists. (OK, well, there’s only one, and it only exists as a way to discuss adding new project members.)
I’m not making this up, go look at the last 8 years of dev@subversion.tigris.org archives.
Paul — I think a rollup command would be very important. For the most part, that isn’t me the original developer talking — it is me the reviewer and me the later maintainer.
At work, some of our code has includes the cvs log in a bug comment at the front. This (normally useless) comment section can be much longer than the actual code, so it is often just distracting clutter. (And when it isn’t, I often want a diff.) The very fact that the comment cruft will grow acts as a deterrent against checkpoint checkins.
When browsing, say, the python svn archives, there is a policy against breaking things with a commit, so intermediate checkins are even more rare. But that is actually useful when researching something old.
So yes, the rollup command (allowing access to the intermediates) is probably a very good idea.
I had a brief stint as a corporate programmer for a finance company before deciding I wanted to be a lawyer because of my social and community involvement, but I can certainly attest to the corporate software job stereotype noted above.
I was in the QA-group-that-does-programming for automated interface testing (cue Ugh!s) and we worked with some oracle stored procedure programming teams, and our “code reviews” were more like “code presentations” and critique was really not desired by the other team. I was fresh out of college, and my persistent critique was “where are the comments?” especially when coders at corporate financial companies are gray-haired bicycles and a revolving door of H-1b Indians. Good people, sucky organization.
Did I mention I bailed on that industry? Heh.