"Code style" is about more than formatting, and this article isn't identifying "good programmers," it finds a rather weak correlation with people who are good at doing programming contests--the two are not necessarily the same.
Interesting that little correlation was found. My experience has been that "good" programmers follow the most prevalent conventions of the language so their code is easily parsed by other humans used to seeing it that way. Like I use a braces on their own lines in C# but an opening brace at the end of the line in Ecmascript. When in Rome...
This is somewhat silly, though. Prevalent conventions are followed by the majority by definition. Such that most of your experience will be with those conventions. Again, by definition of it being prevalent.
I grant that conformity does signal education of the norms. Which can be seen as signaling effort. But I expect it to be so noisy that it will have little predictive power.
Bad drivers I have encountered are much more likely to follow the rules of the road to the letter. Good drivers will often break them based on the situation. The difference is situational awareness.
>My experience has been that "good" programmers follow the most prevalent conventions of the language so their code is easily parsed by other humans used to seeing it that way.
Agree. To take this a step further, I would say good programmers follow the style that exists in the codebase, if applicable, for consistency and therefore maintainability's sake.
It' doesn't necessarily mean they are a good programmer, but it means they are fairly meticulous, which can be a trait of a good programmer.
The "good"/experienced programmers are the ones that will break established styles to improve readability in corner cases, instead of following the rules blindly. On top of that, they've probably been doing it long enough they have their own preferences and idiosyncrasies, some of which may go against established styles.
On the flipside are the "bad" and new programmers, who don't really have their own style nor have learned an established one, so they just do whatever.
It's the average ones in the middle who only follow established styles that I would expect to be easy to pick out.
I guess I'll be the first to disagree with your disagreement :)
I think the value of standardization is much higher than the value of "break[ing] established styles to improve readability in corner cases". I just find the marginal value of these little stylistic improvements to be extremely low, and the value of code looking quite similar everywhere to be quite high.
Exactly, that's my basic ask for anyone making a PR on any of my OSS code, and when doing a PR myself I try to do that as well, be it for work or for fun. The first code I wrote as a self-taught programmer had a lot of weird spacing, like I'd write `<div class = "hello" data-label = "...">`
Code style has zero to do with how good a programmer is. Good programmers structure and architect their applications well. Bad programmers doesn’t even have a clue what that means.
I would agree with this. Follow the language’s official formatter, don’t customize it, run official linters if they exist. Otherwise it’s endless bikeshed.
I've seen a lot of very different styles of code over the years, and I can safely say that some of the most productive programmers I've worked with have been ones with surprisingly unusual styles.
That said, using a programming contest as a judge is also likely to bring out the more unconventional styles, like minimised whitespace or indentation.
Over the years I came to use more and more custom vertical alignment of short code lines (whatever the language is). This makes semantic similarity/symmetry stand out, elicit functional decomposition, and enables one to have a complete one-screen bird's eye view over complex problems like this MQTT pulser that trigger interrupts in unison (because musicality of what appears in my MQTT console matters too):
I’m a huge fan of vertically aligning similar things, and right-side comments. I’ve been building an maintaining a plugin for my editor that aligns code into grids; vertically aligning everything in the line across similar lines. I also like conciseness too, though I sometimes back off when it gets too dense.
Purely my opinion, not a critique of your style at all, but I don’t love vertically aligning the open braces of functions, unless they’re one-line and similar (like readTDS & readEC), nor do I love starting code or data way off to the right just to align it with the first paren or brace. I want my code/data block to have a single indent, not a random content-dependent amount. It gets unbelievably stupid when function names are longer, it wastes half the page/screen, and it drives me nuts how clang-format does this by default (yes I know there are different profiles, but I’m stuck with the one my work peers chose to use). For me, the opening braces aren’t a semantic similarity that I want to see or emphasize, because the opening code for each function is expected to be different, and because they’re rarely on subsequent lines.
All that said, the most important thing when working with other people is to have an automatic formatter, and eliminate arguments over style! It’s nice to have a datapoint in the article that style has no correlation with quality of GCJ entries.
Aside from the impossible to read without printing it out on ruled paper, change the length of one variable and your auto format pollutes git history with a five line change.
Most statements aligned like this aren't even related, they just happen to be colocated but then the (forced by the autoformatted standard) vertical alignment makes it look related.
Coding style (more precisely whitespace) is able to say a lot about the code without you even reading the code. This code style paints a picture that isn't there.
> It's a coding style that lies and it should be taken out back.
I’m a fan of only aligning things that are actually similar. The important part IMO is to make it easy to see differences in the middle of something that’s a pattern, not to extract similarity out of semantically different things (which is the reason I don’t love aligning the opening function braces). I’m also a fan of using the -w flag with git diff, and of avoiding hyperbole, but there is a valid and very good point in there about causing merge conflicts! ;) I don’t get to use my grid aligner all that often, because using clang-format is more important, so I don’t use it around other people very much. But all that said, I never hesitate to re-grid something if a variable changes, as long as I know it won’t cause a source control conflict.
* edit BTW I just realized the better argument which is that clang-format already has the very problem you mentioned: renaming anything can and will often cause reflow of text. Avoiding grid-alignment of text has very little bearing on whether this is going to happen to you. The only way to avoid formatting changes in your source control is to never reformat code, which isn’t something my team wants to prioritize, so we make do with selective application of clang-format. It’s sometimes useful to separate code changes from whitespace/format updates.
Golang, amusingly, is evidence that this not only won't die, but is not a problem. Auto formatting tools work. Well, even. And the idea of pollution in code history is signaling an ignorance of code repository capabilities. They have been able to show history ignoring whitespace changes for a long time.
It might be worth us outlining a workflow (and I’d be interested to hear yours). I realize that the impulse to be afraid of whitespace changes is reasonable for several reasons: one because git (for example) has defaults that show differences & conflicts on whitespace changes, and you have to change the defaults, two because git and other version control systems are usually much less great at managing cross-line whitespace changes, and three because not everyone is (or should have to be) an expert in their version control tool.
Specifically, the workflow here that allows intra-line whitespace without worry is to merge with whitespace disabled, and run the auto-formatter after merging. This means that vertically aligning things is almost innocuous, but having certain tools re-wrap text can still be problematic, at least as far as I know. If there are good ways to handle that second problem, I want that.
In general, change what you have to. And no more. If you are fixing whitespace on functions and lines scattered throughout the code, do that deliberately as a code cleanup. But don't expect that running an auto formatter on the entire code base will go over well.
Yeah completely agreed and good point; in my team’s case our guidelines are to never re-format something you didn’t touch in the commit - we request spurious whitespace changes to be reverted during code review, whether accidental or deliberate - but we also request that the block of code that is touched gets formatted. Every once in a while, like maybe once a year or less, we’ll re-run the formatter on the code base because too many things are drifting, and we’ll do it by first broadcasting the intent to the entire team, and then scheduling a good time for it, and lastly changing only formatting and nothing else, and finally if it causes any major problems, reverting and re-scheduling. Formatting the whole code base is never something I’d do lightly.
It’s true that searching for something will return the lines as they’re formatted. I’m certainly curious to hear how whitespace changes over time in git grep causes problems, what the problems are, and what the alternatives are. I can imagine reasons that might happen, but that particular example isn’t something I’ve experienced myself or heard of before, so I don’t know if I’m discounting it unfairly. Like I said in defense of your comment higher up, I see why people like you react to certain formatting tools this way, but it turns out that tools that insert and delete line breaks are far more serious when it comes to workflow implications than tools that only insert spaces or tabs to get vertical alignment, so it’s worth making that distinction right from the start.
I don’t think vertical alignment is going away, I think it will become far more common, and that our tools will catch up. My prediction is that git and other source control systems become more tolerant of formatting changes, and that developers in general will learn more workflow techniques for allowing whitespace churn.
For me, having the alignment and making the code more readable to me is more valuable than the minor inconveniences with source control that it might cause, and on top of that I’ve learned that there are ways to mitigate most of the issues. I’m not arguing that it doesn’t cause any problems, I’m only saying that it’s worth prioritizing for me, that there are things you can learn to do about it, that the tools give you options and will probably improve, and that vertical alignment in particular does far less damage that line-breaking reflows like clang-format impose… and use of clang-format is pretty widespread and standard in my experience.
Code does change over time. Refactoring happens. Variables are renamed. Comments change over time. We don’t ask people to avoid writing code or adding comments because the changes appear in git diff or grep, or even because they might cause merge conflicts… those things are considered an acceptable cost of doing business in software. I don’t see any reason to treat good formatting differently, within reason.
Oh, of course, that makes sense, you’re right. Does git grep actually do this, or were you thinking of git log or git blame? The git grep command by default is searching for a string in the working directory, not in the commit history. I do that using the “pickaxe” git log -S, or when I don’t have a substring I use git blame or git gui blame.
(Edit: I see that yes git grep can search history if you pipe in a git rev-list command. Is that what you do? Note the trivial workaround with git grep is to put variable whitespace in the regex you’re searching for. If you aren’t looking for a substring with spaces in them, maybe use the much simpler git log -S command?)
Good news: the pickaxe command ignores whitespace changes by default, it only shows you when the substring itself was changed. And git blame takes a -w flag so you can ignore these whitespace changes. -M can help too. First Google result for “git blame ignore whitespace”: https://coderwall.com/p/x8xbnq/git-don-t-blame-people-for-ch...
Git gui has a menu option to ignore whitespace changes too, if you’re spelunking through changes on a given line an don’t have an exact substring change you’re looking for.
So hypothetically, if you had version control tools that truly and completely took care of not showing you whitespace changes, and you were free to reformat your code any way you like without causing any trouble at all, if you had complete freedom, what would you want out of your text formatting tools?
Hey that’s good; git log -S doesn’t show you whitespace changes.
I’m not sure I follow, what does consistent mean to you, can you elaborate? Is that consistency something you have a hard time getting right now because of source control issues? I guess I was wondering about whether you had a wish list for formatting, things that you don’t have but would take if you knew it wouldn’t cause any issues with source control. Do you use clang-format, or any other auto-formatters on your team?
It's organised but unconventional. Not hard to read. Incidentally, I've found that embedded stuff,which your fragment seems to be, tends to have the most examples of such unconventional styles, often written by EEs or specialists in other fields who learned programming as a side-endeavour. Zero indentation, and code that otherwise looks like English prose, is also surprisingly common there --- and yet they seem to have little trouble reading or writing such code. Here's a memorable example of that: https://rloewelectronics.com/
Sorry, but not good. Too many statements on one line. By indenting the functions, you lose too much space at left of the screen. If I had to work with this code, the first thing I would do would be to completely reformat it.
However, if you are the only person maintaining this code, chacun à son goût!
looking at the left is nice, you can see all the various functions very quickly. but the actual code just looks like visual noise to me, blending together, not clear where sub-blocks are within functions, "lines" (as in units separated by semicolon) blending together too.
If I was tasked with changing anything in there, or analyzing the code, the first thing I would do is run autoformat on it. even if I have to preserve the code style, I would just translate it back once I'm done
One thing I notice myself doing a lot is using lots of empty lines in my code. Sometimes I go really overboard with it, to the point that every other line is empty. I feel like it helps me read the code more easily. This seems sort of like the antithesis of that.
Imagine if lawmakers got this hung up on indentation. Not the wording, correctness, or effect. The indentation. We would say they were fiddling while Rome burns.
If you are working on your own you do you. If you are working in a team pick a style that is okay and has great tooling and support in different editors.
As this exchange proves everyone has opinions about this stuff. Standardisation is more important than optimal choice especially as everyone thinks theirv choice is optimaland yours is terrible. It doesn't have a huge impact, solve it once and make it go away so you can focus on everything else.
Just set git to format everyone's code on checkin and never talk about it in a code review again.
Sure, but this thread of conversation started with someone specifically asking for opinions on their indentation. It's not like the discussion was about the code, and this is just a big side-track of the actual discussion.
> Imagine if lawmakers got this hung up on indentation. Not the wording, correctness, or effect. The indentation.
I mean that seems reasonable to me. If someone submits a giant bill with no indentation/paragraphs/punctuation etc. then it should be rejected. Being able to grok the bill itself would be an important part of then determining whether or not to pass it.
I think the semi-obsession we have with "correctness" in style is actually something programmers do a lot better than most other disciplines.
Arguing over indentation is functionally the same as arguing over unix principles, or frameworks or languages. The fact that we're always looking not just for the solution, but the right solution, on every level of the process, is part of what makes programming so beautiful and enjoyable.
Law is actually a perfect example of the opposite; without that obsessive concern for correctness, the systems created are hopelessly confounding and difficult to navigate.
> If I was tasked with changing anything in there, or analyzing the code, the first thing I would do is run autoformat on it. even if I have to preserve the code style, I would just translate it back once I'm done
This could be done with local reindentation/deindentation. You'd need some way to map back to the original style, maybe treating the whole process like a git edit, putting a newline before each new addition, highlighting it, with a checkmark button to "commit" them once the indentation is adapted to the original style, and by "commit" I mean make the highlighting go away.
However the criticism about the right part of the code being visual noise I see in your reply and others is somehow unfair, the second pic bordering on the limits of what I find acceptable myself. It's still linguistically readable as in you'd still be able to replace the parens and braces by reading that one line of code aloud. It's not code that's supposed to be readable in a typographical sense, with harmonious spacing meant to catch the wandering eye like an ad, it's code that was written to be thought through. Sit and think. For 30 minutes before hitting 'build'. After minor compilation errors and the first successful build, I had just a single one-line fix to make before having the code run correctly.
I would still find it easier to sit and think about the code if it was formatted differently. To me, this reads like a book that's just one long paragraph.
> One thing I notice myself doing a lot is using lots of empty lines in my code. Sometimes I go really overboard with it, to the point that every other line is empty. I feel like it helps me read the code more easily. This seems sort of like the antithesis of that.
One trick for that is making your height line higher in focused mode in the editor.
An ex co-worker had this on VSCode and looked very useful.
Not sure what he thinks but here's what I think. Although the verticality thing isn't bad in and of itself (it does look nice) it effectively gives you less space on the screen which encourages usage of space saving measures like one letter variable names and abbreviations. This makes it difficult to understand your intention and may make it difficult for someone else to take over your project.
My code style too became more and more „vertical“ over the years — I‘ve found it to be much better scannable and therefore comprehensible especially outside its original authoring context (e.g. when doing code reviews in the web browser interface of BitBucket or GitHub).
Love it. I need to figure out a way to get this automatically, because it looks super useful as high-level view - I could then switch back and forth, using clang-format to go back to company-accepted style.
Love it too. Reminds me of the terseness of Haskell, which I also enjoy.
Whenever I need that "high-level view" you mentioned, I enjoy seeing the whole module without having to scroll/search. In codebases where I gotta jump around too much, I feel disoriented and slowed-down. Like for example on Rails classes where single-use variables are replaced by single-use private methods, that are often far away from it's original usage point. I understand the rationale for doing it but it still tax me mentally when trying to get a holistic understanding of the code.
But then again, some people get used to sparse code and for then I assume such terseness can be overwhelming. Oh well. I just wish they could see my point of view too.
I really consider this a false dichotomy. It's a limitation of tooling (and ultimately of our plaintext-based mode of programming, in which we always edit the single, canonical form of the source code).
My preferred form really depends on why I'm looking at particular piece of code at a particular moment. I like my code sparse and modular if it eliminates details I don't care about. I love my code dense, tight and inlined, if it lets me fit all details I need on a single screen, or otherwise minimize the amount of scrolling and jumping between files. Depending on my particular goal, the same code can be perfectly readable, or a horrible mess.
In practice, I find most of the code I deal with too sparse, but that's again the function of the work I typically do.
Needs more \n, at the very least after each function to separate them. Although it is surprisingly compact to read at a glance, I think it would also cause problems with source control when automerging two statements that are the same line.
Source control is not a closed part of the problem. Diffs engine can be customized to tackle this problem, see `git difftool`, diff-so-fancy, there might even be something for Github's diff view. Something that is not often talked about or implemented (in comparison with linter use).
Exactly. There’s a running joke when talking about code style of “Rich Hickey’s Java” - as the exemplar of weird style. (Which it is if you ever glance at core Clojure’s code base.) But RH in my mind is the epitome of one who understands real practitioner productivity.
I started programming something in Python for the first time ever, a few weeks ago. (In the PyCharm IDE.)
I was somewhat afraid of the enforced indentation and newline policy, but I must say I love it, at least so far. Consistent and unified code style reduces my cognitive workload and lets
me concentrate on the business logic of the classes I am working on.
When everyone has their own style, as was the case in all my previous projects (C++, C, Java, PHP), the extra friction costs some non-trivial amount of energy and time of everyone involved.
Of course there is more than just formatting to a "programming style", but still.
IOCCC is one program contest that favors surprisingly unusual styles, and some of the winners are very productive programmers. Probably not so much for what they did in IOCCC, but for the fact that they care about the source code as much as the compiled binary.
To not appreciate code style is to not appreciate art. I have almost no freedom trying to accomplish the extremely robotic task of pushing some silicon to do something correctly perhaps also efficiently. The fine line between those things separates the people easily between those who are paying attention and those who are falling asleep at their jobs.
Honestly I am moving to a work-mandated IDE (very modern) and all I want is a big button saying "turn off all the helpers".
I am I suspect being grouchy, but I don't think that saving me some typing strokes is worth all that effort.
I love linting and really like real-time linting and syntax catching. But they usually just underline my typos. Anything else (like trying to prevent me from making the typos as I type, or worse adding in brackets just annoys me.
I don't want to invest time in learning an IDE with a million knobs - i can write my own functions if I see the need - just mostly I need to work on actual work.
> Although four style clusters
were found, good programmers could not be associated
with a particular cluster. However, supervised machine
learning showed that stylistic attributes can be used to
predict good programmers. Seven machine learning models were trained and evaluated using recall, macro-F1 and
AUC-ROC. A Balanced Random Forest yielded the best
results with 0.650 recall, 0.511 macro-F1 and 0.695 AUCROC. The results indicate that code style can be used as
a measure to identify good programmers.
I think what is really encoded in the otherwise arbitrary choices of code aesthetics is the care one puts into it and overall greater readibility/understandibility that you get from consistency.
This seems to focus on code style in terms of placement of brackets and new lines. From personal experience, I know there are some programmers with awful code style - random brackets, lines and indents everywhere. But above that low bar? I don’t know how it would matter.
I’d be more interested in the commonality of design patterns and standard data structures and algorithms.
Perhaps things like casing conventions? That would be covered by a linter too.
Or does it mean style-of-semantics (if that's even a thing), for example in C#, preferring to define explicit constructors instead of a parameterless ctor and trusting the user to set properties in the post-ctor initializer correctly?
Or use of higher-order/FP techniques (like map/filter/reduce/fold) over explicit for-loops?
The summary says this (note the last remark):
> The results demonstrate that good programmers may be identified using supervised machine learning models, despite that no particular style groups could be attributed as a good style.
Obviously they're not saying, for example, that one particular bracing style is better than another (1TBS tho!), nor that co-incidentally "good" programmers prefer one style over another; but despite knowing what they're not saying, I don't know what they are saying with that...
Actually.... It's not. Continental Europe mixes priority-to-the-right with driving on the right side of the road, which is not that good. It would have been way better to mix driving on the right with priority to the left as it gains the driver a bit of reaction time. (Of course, driving on the left with priority to the right would have been fine too)
Randomly incoherent layouts, spacing and so forth are just signs of (a good programmer exploring and or a bad one who thinks it's finished)
But then there are other layers - too much going on, more than one thing happening, having to go back and work out what that call did. Just failing to follow a thread.
Then business layers and oh I give in. Determining "good programming" is like determining "good literature" or "truth". You know it when you see it. And you vomit on the bad stuff. But you have to read a lot of it.
To be fair, sampling from a very specific subset of programmers (ones who would participate in a code jam) to do this study just seems like it would introduce various kinds if sampling bias. I would like to see someone try to figure out a better sampling method before I would even consider looking at the results of such a study.
I’d suspect that using GCJ as a data source they assume that “good” = solving a given round of competition. The further you reached in rounds - the better programmer you are.
Not the best measure if they really used it. Coding competitions have almost nothing in common with day to day work of software engineer.
My own coding style has been whatever clang-format emits, with a few tweaks to its configuration agreed upon by all in the project. I think it's ugly, but it sure beats having a formatting fundamentalist hold up a review because they fear that the cargo may not flow.
Code style and code formatting introduce so much friction in modern .NET and Java development teams, that despite any advantage these might have due to their ecosystem maturing, it's more efficient and sane to avoid these languages altogether.
this paper is extraordinarily bad. Like what variable makes a good programmer. doesn't say that. just says variable importance. so frustrating. at least show the signs of the values form logistic regression.
I worked with a guy ten+ years ago that used so much whitespace it was unreasonable.
Literal full screen worth of newlines between thoughts. Indentation the reasoning behind only he knew - if there even were any.
I've never seen anything like it before or since.
I'd say otherwise he was a pretty average programmer.
Interesting job, that. We all had our own projects fully ours unless we went on vacation, it made weird formating choices like that largely not a problem.
My first programming job. Th owner had a rule that all equal signs lined up.
Didn’t matter the purpose. Or how deeply nested his if else statements were. Which he would have 40 layers nested with tons of math between them.
The sample data seems dubious. What do they mean by, "good?" I imagine most of the code in that sample set is going to be a mix of completely rehearsed, "I've written breadth-first search 500 times before," and complete messy hacks, "I need to cut down the number of comparisons at each node to limit the search space so I can get this in under time..."
reductionist paper without stating all assumptions in the title..
This relates to a long-term, diverging trend in the practice of programming.. Vast numbers of highly skilled coders are paid money to meet requirements of a much larger system.. old-school is corporate but the cloud in general could be thought of this way..
Many strong programmers are on the opposite end -- dreaming of patterns and applying them diligently; much more like weaving or industrial arts.. not "paint by numbers" like the requirements work.
There are many, many gray areas in that analysis. Like that physics class demo of a growing balloon where all points expand and diverge at once.. the practice of programming will never be contained into one or more categories.. But to call out "good programmers" without recognizing the breadth and depth, is shallow and at worst counter-productive to the craft. This labeling gives fodder to the "Henry Ford"s out there looking to make other humans work as efficient machines themselves.. personally I can do without that.
If you've ever looked at the top submissions for any coding competition, you know that the premise of this study is flawed. I assume that the people who score well on these competitions are quite capable and would write good code in other circumstances -- but they definitely don't care about style during the competition.
Working on a system where we had no code review procedure, I liked that the worst developpers were also the ones respecting the least the codebase style, so that we could easily identify their code and check it when stumbling on it.
On that topic, I am more and more starting to believe that most of the "aesthetic" aspect of code style (ie types of quotes, wether or not braces should be on a new line, spacing, spacing type, line length, etc…) should be simply be an IDE settings determining how the code is presented.
That way, everyone would get to see the code the way they want, and no one would have to live with other people’s mostly arbitrary choices.
Basically, prettier, except you‘d have one (personal) setting for how things are displayed on your IDE, and one (shared) setting for how things actually are written to disk.
The main issue I see, is that it’d be introducing one more error source.
I have learned to not worry about coding style anymore, not because I don’t care, but because too many people care about that. Having worked with one of the largest monorepo, I’m happy enough to align with others with a standard coding style that is supported by a formatter and just let the formatter do its job. Humans are amazing when it comes to learning new patterns, and coding style is one that can be easily adapted to.
I stopped at "Good Programmers". Seriously though, it would have been perfectly fine to phrase it as "Exploring the correlation between Code Style and Competitive Programming Performance". Everyone knows that competitive programming has constraints (e.g. small time limit, throwaway one-off deliverable, no collaboration) that favours a style of coding that you wouldn't normally find, for example, on a business setting.
It's not clear whether this paper was accepted at the conference, but if it was, it is a testament to the low bar of the examining board. I like to follow the "if you don't have anything nice to say, don't say anything" mantra, but this paper deserves an exception.
Please don't let academics plant more ideas in the heads of students about what software development is.
Last time we did that, we got the Google/Leetcode interview that too many people are still cargo-culting. (Not realizing that it was originally what a professor thinks is important in industry software development, and then morphed even worse, into stereotypical university fraternity class filtering and hazing. Now you have other people, who should be scrappy street kid fighters, deciding who can join their gangs based on how good their posh accent, because they want to make money, and posh accents is what rich people seem to do.)
Academics should stay in their lane. And students should be very skeptical when academics swerve the school bus into oncoming traffic.
What does industry interviewing process have to do with academics? Is there some history I don't know where it was pushed by academics?
I think it's just a runaway process where some metric that's easy to measure was chosen, and it's become a worse metric that's more burdensome on candidates every year as it has become more and more gamed.
During dotcom boom, you had PG recruiting student founders out of undergrad, and also students at rich-kid schools with no experience getting investor money forced into their hands.
So, led by students, you were stuck with a student's idea of what software development is about. Which was heavily influenced by their classes thus far (and unaware that, traditionally, a new college grad is usually not much use until mentored).
Then, pretty soon, "tech" jobs became seen as a big-money career, which meant gatekeeping and smugness.
