As this quick comment has attracted a few downvotes I think I shall elaborate:
Back in the days of my grandmother large organisations had typing pools. When trying to progress a career many found themselves stuck in the pool, or remaining as generic, exchangeable, secretaries.
It was well known that to progress onto the better compensated, less intense, more fulfilling jobs (personal secretary, group secretary, all kinds of travelling roles) you had to show you were capable.
The trick to this was, as it is with any career, identifying which projects will develop the right skills and expose you to the right people.
This is a soft skill, and befriending an older woman who would help you choose projects was recognised as a way to get out quickly.
There are many parallels between this and any career, however I see a very literal one for programmers.
Consulting someone twice my age (in my case friends from traditional engineering disciplines) about the opportunities I have had available has helped me immensely.
Reading that snapchat is not intuitive is always weird for me. It was the most immediately obvious and intuitive app I've ever used.
Maybe you are thinking it is a lot more complex than it actually is? Take a picture then select who you send it to. Swipe left to see pictures sent to you. Swipe right to see pictures people have posted for everyone. That's 99% of it. There is no need for an index of functions that can be mastered as there only are a handful of functions.
Things in Snapchat that aren't intuitive, off the top of my head:
1. Why are my snaps significantly blurrier than the pictures from the normal camera app? (a: you have to explicitly tap the main part of the screen to get it to focus, then take the snap. Why does it not focus automatically when taking the snap?)
2. Why does it do significantly worse in low-light than the normal camera app? (Is it just a problem with Snapchat, or do I need to manually do something that the machine should do, like in #1?)
3. What do the emojis next to names in the friends list mean? (I found a table with the meanings on some spammy website.)
4. What do the smileys that sometimes pop up in chat mean?
5. Why does the menu button not work like it does in every single other app? Sure, "swipe down, then tap the gear" isn't hard, but they removed the mechanism that I'm conditioned to expect to work.
My philosophy is that everyone has useful nuggets of information to share, regardless of age, gender, race, etc. Take it all while ya can. Learn from everyone.
We hired a new grad last year... he's very sharp, though of course inexperienced when it comes to working as part of a team on a large project (but time will fix that).
Now, I have no idea how this is possible, but he has deeper knowledge of Hg and Git than anyone I've ever met (If your experience is limited to school and solo personal projects, how in the world do you develop advanced knowledge of version control? On my personal projects, I rarely need anything more than git add/commit/push/pull and basic branching).
I'm over 10 years older than this guy, but I find myself asking his advice whenever I need to do something advanced or out of the ordinary with Git.
I personally learned better on side projects instead of homework. This usually led to my grades suffering :( However, on the up side, I gained more knowledge on Flex at the time than even my professor. I liked working with it and really dug into it. I'm glad I did becuase I when I ran out of money for school, my reputation got me a few gigs that helped me make it to the end.
That guy is probably smarter than me and both dug into git and was diligent in his homework. Those kind of people can have some really deep knowledge on areas they care about.
Fancy git is still useful on personal projects - if anything it's more so, e.g. you can rewrite history without worrying about other people using it. I think a lot of people who remember a time when committing was expensive are stuck in that mentality, whereas if you commit every 5 minutes you'll naturally end up using the more advanced features to organize your work.
I'm getting better about committing more often (unlike back in the days of SVN/ClearCase/etc.), but I'm still not quite up to committing several times a day like these kids are wont to do :)
I wonder if there is any correlation between commit frequency and a person's tweet or FB post frequency. Are people more active on social networks more likely to carry that over and commit more often?
Well I commit relatively frequently and post on twitter/facebook approximately never, so make of that what you will.
More generally I don't see the connection? I'm not making commits to show off my cool code to my colleagues. I'm making commits in case I want to revert specific changes later.
I learn to commit more frequently every time I realise I need to undo something manually because my history is insufficiently granular.
For me if anything it's the opposite. I blog rarely, because I spend a while thinking over my posts and getting them right. (That said, I commit frequently even there, because I maintain my blog in git).
I don't use git at work, we use TFS instead. I commit to the build server as soon as I have something that is a complete step in the process of developing a feature or fixing a bug especially if that step carries a risk of breaking something.
The build server then builds the whole application and runs the unit tests. I might do this once a day if I'm mostly thinking rather than furiously typing or ten times a day if it is all flowing perfectly.
It's not just the kids who do this, I'll be 61 in a couple of months. On the other hand one of my colleagues who really is half my age prefers to complete the feature and only commit to the build server once the whole feature is complete. He uses TFS shelvesets to make sure he won't lose anything.
Deep knowledge of git is a sign of immaturity :) There are literally 10 commands one will ever need, which can be conveniently aliased to something more sane. Keep the brain space for something that produces higher value add.
Which I've always thought was a sign of mediocre software, but HN/Reddit seems to crucify those that criticize git.
I think Git is like Javascript, it takes relatively little time to learn enough to get up and running, causing most people to forgoe learning all they'll actually need to be successful.
I've been using git for 7 years now, never had the need to go deeper. Lately, I'm using github and pushing / saving my work every so often [kind of like CTRL + S in Windows Office in the '90s]. If something goes wrong, happy to yank the local git and start with a fresh clone from github :)
Ehh, I've been in situations where I screwed up so bad I had to find the "person who actually knows Git" come and save me. Let the kid go deep into whatever they want. Maybe having useful knowledge that others don't drives that person to like coding and makes it fun for them.
I am not sure if that would be a good thing to say about Git. The idea is that a well-designed system with a sane user interface should insulate the user as much as possible from the need to know the system's internals.
Not the internals, but what the commands are doing. What the index is, what a parent or child reference is, things like that are essential to using git effectively.
1) You never know what someone means by 'deep knowledge'
2) What works on a personal project, or microservice repo, might not scale well with many engineers doing overlapping work in the same codebase
3) consider that even if you are perfect, other people can make mistakes that introduce issues
4) 'advanced' techniques can make a complex version history more readable, which pays dividends by saving brain space in the future
I find thinking of git as a DAG of diffs, and branches as mutable references to DAG nodes, a simplifying conceptualization. I found git really easy to pick up and much, much simpler to learn and use than svn or cvs.
Thinking of it this way, I know the solution to my code repo problems before I know the exact commands that perform the graph transitions. Because I have this mental model, I know the commands must exist in one form or another.
I disagree, git is my favorite VCS by far because of the power it gives to truly craft a record of ones development history. A finely crafted development history pays major dividends as a project ages. I just got a thank you note for commit messages I wrote 4 years ago on a previous project.
A lot of devs see commit messages and rebasing as useless pedantry, but once you start to take it seriously it only takes a little bit of extra time, and it provides so much future benefit via git-bisect and general spelunkability.
I also think it's worth investing more time in a tool based on its longevity in ones workload. In that regard I put git at the top of the food chain, as I expect to use it even longer than Linux, for example in my case: Git > Linux > Vim > Ruby/Python > OS X / GUI tools.
A side effect of being this good at git is the ability to bail out your colleagues when they royally fuck up a merge or rebase.
For development history, we're using good PRs and good PR comments on GitHub. We've started using GitHub squash commits, but not enough long term usage to say how reliable it is. No need to manually rebase or fix someone else's broken rebase.
The workflow is directly inspired by git-as-a-wrapper-around-Perforce used at Google.
I'm a big fan of PRs/comments on GitHub as well (although they do raise some data ownership issues). Squashed commits are interesting, but not something I've used personally in GitHub. I think squashing, especially automatically, has big tradeoffs.
It's nice to have a cohesive unit of change in a single commit, but if your mergeable features have a lot of moving parts it may be too much information in one giant blob, losing valuable history. There are certain things I like to be in individual commits, like for instance, DB migrations in Rails or Django, or Gemfile/Gemfile.lock upgrades. Having these in separate commits allows for easier conflict resolution later, and are also a nice granularity for practices like zero-downtime continuous deployment where you need to have multi-phase deploy of migrations (ie. phase 1: deploy migrations that add fields, phase 2: deploy code that requires new fields, phase 3: remove fields required by legacy code).
Maybe in a large team with a large volume of PRs then squashing by default is preferred so you can make sense of a fast-moving history, but given that it's so easy to squash selectively with `git rebase -i` that is my preferred method, at least for the team I'm on now.
hen I do something 'for work' its just that, work. I'm not going to spend my nights and weekends on it or learning the finer points of it. I have other responsibilities and am way past the age where I'm deeply curious about technology and have to 'get it' on a deep level to feel satisfied or competitive. When you're a student and hobbyist, you have all these things. If your curious, then you have the time to fulfill that curiosity.
I also suspect the young coders today are all about github so knowing git's in's and out's is going to be natural for them.
one of my friends was really into doing fancy git stuff for no reason. he knew a lot. but I'll never forget that one time he was trying to do some crazy fancy stuff and accidentaly deleted our local changes for our OS project... Truth is most of it is unneeded.
one of my friends was really into doing fancy git stuff for no reason. he knew a lot. but I'll never forget that one time he was trying to do some crazy fancy stuff and accidentaly deleted our local changes for our OS project... Truth is most of it is unneeded.
> If your experience is limited to school and solo personal projects, how in the world do you develop advanced knowledge of version control?
If your experience is limited to university and programming for work, how in the world do you develop advanced knowledge of... well, anything?
That is - is that new grad perchance a hobbyist programmer? When you do this stuff for fun and without deadline pressure, especially when young and thus having ample free time, it's much easier to actually learn stuff, and to develop deep understanding of it. Adult life and commercial pressures really go a long way to make people avoid understanding things they work with - after all, we're not being paid to comprehend the tech deeply, we're paid to achieve business goals.
> We hired a new grad last year [...] Now, I have no idea how this is possible, but he has deeper knowledge of Hg and Git than anyone I've ever met (If your experience is limited to school and solo personal projects, how in the world do you develop advanced knowledge of version control?
I learned Linux in the '90s, when it came on a stack of floppies, long before anyone else would have thought to use it in production. It was never more than a pet project, but I kept hammering it because it was so cool. Unlimited size matrices. Compile the kernel any way I want. A real multi-user OS? Holy smokes, this is a very cool hobby.
Eventually I got a job at a startup that was running all their stuff on Linux. Lo and behold, I was the local "Linux expert", blowing everyone else out of the water with my knowledge of, well, everything needed to make that thing work.
So that's how it happens. If you like something, and you're passionate about it, and you have an obsessive streak, you'll jump lightyears ahead in a very short time.
The Git guy probably spent countless hours figuring out obscure aspects of the tool's workflow, just for the heck of it. Deep interest + focus + long practice = mastery.
> On my personal projects, I rarely need anything more than git add/commit/push/pull and basic branching)
Neither did he, strictly speaking, but the difference is that he kept hammering it.
So you see, this is not about generational differences. This is good old fashion geeks doing what geeks do best.
> So that's how it happens. If you like something, and you're passionate about it, and you have an obsessive streak, you'll jump lightyears ahead in a very short time.
You forgot lots and lots of free time . Time like that you simply don't have as an adult.
People are wired differently. I know people who are much younger than I am who are much wiser than I am at the ways of the human animal. I rely on a couple of them to be able to, after a meeting where some strange interpersonal thing happened, simply ask: "what just happened there"?
Everyone has their own personal set of cognitive blind spots and may need assistance for navigating those types of situations. For me, simply learning where my blind spots are, identifying who doesn't have my particular combination of defects (regardless of age), and being able to develop a relationship with them so that I can ask them for navigational assistance does wonders.
Lots. I learn from my kids who are 1/7th of my age all the time. Not so much from the experiences of raising them, but from their insights and observations. A couple of times, their observations about something have blown my mind.
yes, Knowledge is a two way street. We can learn from each other. Age bias is bad both ways. The saying "Its hard to teach old dogs new ticks" is WRONG and this articular stinks of it.
Unfortunately, it's a saying that is rooted in truth; as you grow older, your neural plasticity and fluid intelligence steadily declines, and so learning new tricks is, perhaps not impossible, but certainly more difficult - so it's important to recognize this and make the extra effort to remain open to new ideas and new experiences, the way one does almost unconsciously in youth.
Isn't this what is supposed to happen? I mean the whole point of education from the early days is that everyone is collectively standing on the shoulders of the previous generation.
If the idea of accelerating knowledge acquisition - across all domains - is working, then it stands to reason that those with the most plastic brains and access to a wealth of knowledge, as well as tools to figure out what is relevant and contextual, will be able to outperform those who have well worn cognitive paths.
Seems like a great thing to me - but terrifying for anyone who is used to the idea that more time = better.
>America’s younger workers have already been “personal technology consultants in their own families, so it’s a role they’re very comfortable playing,” she said.
Fuck all of that noise.
I'll teach you how to use something if you really want to learn it, but I'm not going to be the guy you just hand your laptop to and go "Fix it for me I don't know how to do it you're so much better at it than I am."
I totally believe that everybody has something to offer to everybody else. I'm 43, can I learn from a 23 year old? Abso-lutely! And vice-versa, of course.
But... I really reject this whole "millenials as digital natives" narrative, in terms of the idea that millenials have some unique relationship to technology and some innate sort of technological prowess. It's just a rehashing of an earlier idea which dates back at least to the 80's, where "kids have to program their parents VCR's". There's always this notion that "the young" - at a point in time - are more technical. But in absolute terms? Well, Gen-X kids grew up with access to computers and a lot of technology as well, although it was (obviously) the technology of the the time. I would posit that there's no reason to assume that a Millenial would be any more inherently technical than a Gen-X'er.
Indeed, I think it's insulting to old and young alike to assume that the young know more about "technology".
At this point my sister-in-law (10 years older than I) and my mother-in-law (30 years older) know more about social networking and Facebook than I do, because I do not use these things and they use them almost daily. Plenty of old people know how to use computers and technology. Plenty of young people do not.
Furthermore, just knowing how to use Snapchat is not really knowing about "technology," any more than knowing how to drive a car makes one a mechanical engineer or knowing how to plug a gizmo into the wall means one knows about electrical theory. So there are some newer things out there that use a smartphone. So what; knowing how to use them does not make one knowledgeable about technology or smart.
If this writer wanted to know how to use Snapchat, good. Find someone who knows how to use Snapchat. One's Snapchat abilities has nothing to do with one's age.
Haha, one to keep around: "The parents seem to have some vague concept that spending hours each evening on Facebook and YouTube will impart, by some sort of cybernetic osmosis, a knowledge of PHP, HTML, JavaScript and Haskell."
And it's so true, you know, you learn about computers when you need a floppy with drivers for the 4x cd-rom drive you just installed yourself (or when you later install Slackware and then Gentoo... also helps). You don't learn about computers using a modern smartphone.
I like this part a lot: I've messed up, as I'm sure many of you have. When we purchased an XBox it was Techno-Dad to the rescue. I happily played about with the mess of cables and then created profiles for everyone. When my son's MacBook was infected with the FlashBack virus Techno-Dad to the rescue. I looked up some on-line guides and then hammered away in the terminal until I had eradicated that bad-boy. When we purchased a 'Family Raspberry Pi' Techno-Dad to the rescue. I hooked it all up, flashed an OS to the SD-card and then sat back proudly, wondering why nobody other than me wanted to use the blasted thing. All through their lives, I've done it for them. Set-up new hardware, installed new software and acted as in-house technician whenever things went wrong. As a result, I have a family of digital illiterates.
There are exceptions. In the DSP realm, it's entirely possible for Olde Guys(TM) to have faced older generations of gear that will have led to a deeper understanding of certain things.
This is especially pronounced since MATLAB became the lingua franca for signals processing education. It's both a blessing and a curse - you can fit the appropriate MATLAB shenanigans into a lecture but it won't be the same as translating certain transforms into 'C'.
I like to think of people as having chronological age as well as a [skill] age, with chronological age being largely irrelevant among adults. I'm 41 and my co-founder is 27. He had been programming Java for 7 years when I met him, and now he's a decade in. He has taught me a ton about programming, and I expect the lessons to continue. As a person gets older and specializes, the likelihood that someone younger than them, on a separate path, will have a higher [skill] age increases, which means they need to be increasingly open to learning from chronologically younger people.
Before I became a software engineer, I was a math supplementary instructor at a community college in my hometown. I love teaching, talking about and thinking about math.
Some of my favorite students were the older students that already had preconceived notions about their abilities with math, what things meant or how things fit together.
I discovered those things they brought with them were great vehicles for bending my explanations in such a way that they could understand them.
Eventually this occurred often enough you work a lot of that into how you talk about the subject, and I feel this made me a better/more effective teacher, more often, than I had been before.
Onto the subject, in my new job, one of the other engineers I work closely with is what I would consider non-trivially younger than me. (I'm in my late 20s)
It set me back a smidge to learn that when I did. But in the time I've been here, and that isn't very long, I've learned an incredible amount from him.
I found and this article only confirms that closing yourself off from even a little only hurts the self and is very narrow minded.
During my first job out of undergrad, I recall a fairly senior and well respected IT director who didn't use a computer, and didn't read email. He was good at "being strategic" and "delivering for customers". While both of those are great things, I vowed never to become him. The only way to stay vital and connected is to hang out with the young, as well as the old. Just never ever talk pop culture.
Instead of being indignant that we can be "mentored" by a person half our age, let's rephrase the question and ask, "What could I possibly LEARN from a person half my age?"
Well, almost everything. Your typical grandparent was probably taught how to use the new technology of their day by their grand kids. People not half their age, but something like a fifth or even a tenth their age.
I've read about a guy, I think his name is Tao and I'm sure HNers are familiar with him, who got his math PhD at 21 and was teching undergrads while a young teen. Could you be twice his age and learn from him? Is that a trick question?
I think the reason this is even a talking point at all is that the word mentor implies imparting knowledge gained from experience, and since experience correlates to age, we inevitably wonder how a person younger than you could be more experienced than you. But really, the thing we are after is knowledge regardless of how it was acquired. When you look at it like that, the age of your source of knowledge becomes a complete non issue.
68 comments
[ 2.6 ms ] story [ 147 ms ] threadWhat Could I Possibly Learn From a Mentor Twice My Age?
Back in the days of my grandmother large organisations had typing pools. When trying to progress a career many found themselves stuck in the pool, or remaining as generic, exchangeable, secretaries.
It was well known that to progress onto the better compensated, less intense, more fulfilling jobs (personal secretary, group secretary, all kinds of travelling roles) you had to show you were capable.
The trick to this was, as it is with any career, identifying which projects will develop the right skills and expose you to the right people.
This is a soft skill, and befriending an older woman who would help you choose projects was recognised as a way to get out quickly.
There are many parallels between this and any career, however I see a very literal one for programmers.
Consulting someone twice my age (in my case friends from traditional engineering disciplines) about the opportunities I have had available has helped me immensely.
I didn't downvote it but I had no idea what the sentence meant.
I think that second "to" was a typo, but it lead to weird alternative ways to parse the sentence.
Damn right. You hear a product is good, you go out and get it, and then you try and use it. Like always you hit a roadblock and you RTFM.
But this time there isn't a manual, no dense text with an index of all the weird and wonderful functions you could master to be an expert.
No this time you only get a string of badly written blog posts, verbose and out of date.
Maybe you are thinking it is a lot more complex than it actually is? Take a picture then select who you send it to. Swipe left to see pictures sent to you. Swipe right to see pictures people have posted for everyone. That's 99% of it. There is no need for an index of functions that can be mastered as there only are a handful of functions.
1. Why are my snaps significantly blurrier than the pictures from the normal camera app? (a: you have to explicitly tap the main part of the screen to get it to focus, then take the snap. Why does it not focus automatically when taking the snap?)
2. Why does it do significantly worse in low-light than the normal camera app? (Is it just a problem with Snapchat, or do I need to manually do something that the machine should do, like in #1?)
3. What do the emojis next to names in the friends list mean? (I found a table with the meanings on some spammy website.)
4. What do the smileys that sometimes pop up in chat mean?
5. Why does the menu button not work like it does in every single other app? Sure, "swipe down, then tap the gear" isn't hard, but they removed the mechanism that I'm conditioned to expect to work.
Now, I have no idea how this is possible, but he has deeper knowledge of Hg and Git than anyone I've ever met (If your experience is limited to school and solo personal projects, how in the world do you develop advanced knowledge of version control? On my personal projects, I rarely need anything more than git add/commit/push/pull and basic branching).
I'm over 10 years older than this guy, but I find myself asking his advice whenever I need to do something advanced or out of the ordinary with Git.
That guy is probably smarter than me and both dug into git and was diligent in his homework. Those kind of people can have some really deep knowledge on areas they care about.
More generally I don't see the connection? I'm not making commits to show off my cool code to my colleagues. I'm making commits in case I want to revert specific changes later.
I learn to commit more frequently every time I realise I need to undo something manually because my history is insufficiently granular.
The build server then builds the whole application and runs the unit tests. I might do this once a day if I'm mostly thinking rather than furiously typing or ten times a day if it is all flowing perfectly.
It's not just the kids who do this, I'll be 61 in a couple of months. On the other hand one of my colleagues who really is half my age prefers to complete the feature and only commit to the build server once the whole feature is complete. He uses TFS shelvesets to make sure he won't lose anything.
I think Git is like Javascript, it takes relatively little time to learn enough to get up and running, causing most people to forgoe learning all they'll actually need to be successful.
Thinking of it this way, I know the solution to my code repo problems before I know the exact commands that perform the graph transitions. Because I have this mental model, I know the commands must exist in one form or another.
A lot of devs see commit messages and rebasing as useless pedantry, but once you start to take it seriously it only takes a little bit of extra time, and it provides so much future benefit via git-bisect and general spelunkability.
I also think it's worth investing more time in a tool based on its longevity in ones workload. In that regard I put git at the top of the food chain, as I expect to use it even longer than Linux, for example in my case: Git > Linux > Vim > Ruby/Python > OS X / GUI tools.
A side effect of being this good at git is the ability to bail out your colleagues when they royally fuck up a merge or rebase.
The workflow is directly inspired by git-as-a-wrapper-around-Perforce used at Google.
It's nice to have a cohesive unit of change in a single commit, but if your mergeable features have a lot of moving parts it may be too much information in one giant blob, losing valuable history. There are certain things I like to be in individual commits, like for instance, DB migrations in Rails or Django, or Gemfile/Gemfile.lock upgrades. Having these in separate commits allows for easier conflict resolution later, and are also a nice granularity for practices like zero-downtime continuous deployment where you need to have multi-phase deploy of migrations (ie. phase 1: deploy migrations that add fields, phase 2: deploy code that requires new fields, phase 3: remove fields required by legacy code).
Maybe in a large team with a large volume of PRs then squashing by default is preferred so you can make sense of a fast-moving history, but given that it's so easy to squash selectively with `git rebase -i` that is my preferred method, at least for the team I'm on now.
I also suspect the young coders today are all about github so knowing git's in's and out's is going to be natural for them.
If your experience is limited to university and programming for work, how in the world do you develop advanced knowledge of... well, anything?
That is - is that new grad perchance a hobbyist programmer? When you do this stuff for fun and without deadline pressure, especially when young and thus having ample free time, it's much easier to actually learn stuff, and to develop deep understanding of it. Adult life and commercial pressures really go a long way to make people avoid understanding things they work with - after all, we're not being paid to comprehend the tech deeply, we're paid to achieve business goals.
I learned Linux in the '90s, when it came on a stack of floppies, long before anyone else would have thought to use it in production. It was never more than a pet project, but I kept hammering it because it was so cool. Unlimited size matrices. Compile the kernel any way I want. A real multi-user OS? Holy smokes, this is a very cool hobby.
Eventually I got a job at a startup that was running all their stuff on Linux. Lo and behold, I was the local "Linux expert", blowing everyone else out of the water with my knowledge of, well, everything needed to make that thing work.
So that's how it happens. If you like something, and you're passionate about it, and you have an obsessive streak, you'll jump lightyears ahead in a very short time.
The Git guy probably spent countless hours figuring out obscure aspects of the tool's workflow, just for the heck of it. Deep interest + focus + long practice = mastery.
> On my personal projects, I rarely need anything more than git add/commit/push/pull and basic branching)
Neither did he, strictly speaking, but the difference is that he kept hammering it.
So you see, this is not about generational differences. This is good old fashion geeks doing what geeks do best.
You forgot lots and lots of free time . Time like that you simply don't have as an adult.
TempleOS lets God talk.
God says... secretariat's policyholders germane puller ogle's excavation's misapprehends illness floweriest expertness tranquilest Andy Manasseh birthmark's breads irrelevance's irritate McMillan's Spackle preventive feather Peking's browses uncertainties Epsom Microsoft's uh catty hillside immediacy's preshrank muscles
I have a space alien.
I am waiting for a white person to notice.
I am in a CIA prison and Frasier is a retard nigger who does not know what a random number is.
It has a happy ending. God is not ready.
God says... insigne cabbage chevron notes dozes thirdly meteor's consul velocities tenpins Ike shiniest exclamation ossified formidable distanced caboodle acronym interlock's dryad Grundy gather's Lauren's fuzz's pleat's wind's faunae pepperoni's manner expenditures actors billionth's
https://www.buzzfeed.com/benrosen/how-to-snapchat-like-the-t...
People are wired differently. I know people who are much younger than I am who are much wiser than I am at the ways of the human animal. I rely on a couple of them to be able to, after a meeting where some strange interpersonal thing happened, simply ask: "what just happened there"?
Everyone has their own personal set of cognitive blind spots and may need assistance for navigating those types of situations. For me, simply learning where my blind spots are, identifying who doesn't have my particular combination of defects (regardless of age), and being able to develop a relationship with them so that I can ask them for navigational assistance does wonders.
You only have to be open and humble.
If the idea of accelerating knowledge acquisition - across all domains - is working, then it stands to reason that those with the most plastic brains and access to a wealth of knowledge, as well as tools to figure out what is relevant and contextual, will be able to outperform those who have well worn cognitive paths.
Seems like a great thing to me - but terrifying for anyone who is used to the idea that more time = better.
Fuck all of that noise.
I'll teach you how to use something if you really want to learn it, but I'm not going to be the guy you just hand your laptop to and go "Fix it for me I don't know how to do it you're so much better at it than I am."
But... I really reject this whole "millenials as digital natives" narrative, in terms of the idea that millenials have some unique relationship to technology and some innate sort of technological prowess. It's just a rehashing of an earlier idea which dates back at least to the 80's, where "kids have to program their parents VCR's". There's always this notion that "the young" - at a point in time - are more technical. But in absolute terms? Well, Gen-X kids grew up with access to computers and a lot of technology as well, although it was (obviously) the technology of the the time. I would posit that there's no reason to assume that a Millenial would be any more inherently technical than a Gen-X'er.
At this point my sister-in-law (10 years older than I) and my mother-in-law (30 years older) know more about social networking and Facebook than I do, because I do not use these things and they use them almost daily. Plenty of old people know how to use computers and technology. Plenty of young people do not.
Furthermore, just knowing how to use Snapchat is not really knowing about "technology," any more than knowing how to drive a car makes one a mechanical engineer or knowing how to plug a gizmo into the wall means one knows about electrical theory. So there are some newer things out there that use a smartphone. So what; knowing how to use them does not make one knowledgeable about technology or smart.
If this writer wanted to know how to use Snapchat, good. Find someone who knows how to use Snapchat. One's Snapchat abilities has nothing to do with one's age.
http://www.coding2learn.org/blog/2013/07/29/kids-cant-use-co...
And it's so true, you know, you learn about computers when you need a floppy with drivers for the 4x cd-rom drive you just installed yourself (or when you later install Slackware and then Gentoo... also helps). You don't learn about computers using a modern smartphone.
I like this part a lot: I've messed up, as I'm sure many of you have. When we purchased an XBox it was Techno-Dad to the rescue. I happily played about with the mess of cables and then created profiles for everyone. When my son's MacBook was infected with the FlashBack virus Techno-Dad to the rescue. I looked up some on-line guides and then hammered away in the terminal until I had eradicated that bad-boy. When we purchased a 'Family Raspberry Pi' Techno-Dad to the rescue. I hooked it all up, flashed an OS to the SD-card and then sat back proudly, wondering why nobody other than me wanted to use the blasted thing. All through their lives, I've done it for them. Set-up new hardware, installed new software and acted as in-house technician whenever things went wrong. As a result, I have a family of digital illiterates.
This is especially pronounced since MATLAB became the lingua franca for signals processing education. It's both a blessing and a curse - you can fit the appropriate MATLAB shenanigans into a lecture but it won't be the same as translating certain transforms into 'C'.
People always have a different perspective to offer, regardless of age.
Before I became a software engineer, I was a math supplementary instructor at a community college in my hometown. I love teaching, talking about and thinking about math.
Some of my favorite students were the older students that already had preconceived notions about their abilities with math, what things meant or how things fit together.
I discovered those things they brought with them were great vehicles for bending my explanations in such a way that they could understand them.
Eventually this occurred often enough you work a lot of that into how you talk about the subject, and I feel this made me a better/more effective teacher, more often, than I had been before.
Onto the subject, in my new job, one of the other engineers I work closely with is what I would consider non-trivially younger than me. (I'm in my late 20s)
It set me back a smidge to learn that when I did. But in the time I've been here, and that isn't very long, I've learned an incredible amount from him.
I found and this article only confirms that closing yourself off from even a little only hurts the self and is very narrow minded.
Good stuff can come from anywhere.
Well, almost everything. Your typical grandparent was probably taught how to use the new technology of their day by their grand kids. People not half their age, but something like a fifth or even a tenth their age.
I've read about a guy, I think his name is Tao and I'm sure HNers are familiar with him, who got his math PhD at 21 and was teching undergrads while a young teen. Could you be twice his age and learn from him? Is that a trick question?
I think the reason this is even a talking point at all is that the word mentor implies imparting knowledge gained from experience, and since experience correlates to age, we inevitably wonder how a person younger than you could be more experienced than you. But really, the thing we are after is knowledge regardless of how it was acquired. When you look at it like that, the age of your source of knowledge becomes a complete non issue.