Threads for kelsey
-
Got an awesome comment explaining something I missed about map on lazy sequences: http://nerd.kelseyinnis.com/blog/2014/05/06/talking-to-yourself-a-twitter-bot-in-clojure-by-a-total-newb/#comment-1374191718
-
Going back to university after Christmas break. In addition to new and exciting classes, this semester I’m going to be a student assistant and help students one year below me with an Intro to OOP in Java class. I’m also going to be joining a student initative to teach coding (Scratch and Python) to younger students (Lower Secondary School in Norway, age 13-16). Any teachers/tutors want to share some tips?
-
I taught a course for 8th grade students using Scratch last semester. I just want to warn you that, for younger students (ours were 13-14 years old), it can be hard to get their attention. This is especially true in a computer lab where there’s a world wide web of distractions sitting in front of them. This was mainly because our students didn’t self-select, but were chosen by the assistant principal of the school we were working with. Also, we tried using Python in the course at first, but that wasn’t really working with the kids because they didn’t understand why they were doing anything. That’s why we moved to Scratch because you can get richer visual feedback.
So, to summarize, some key takeaways.
- Make sure the students are self-motivated and actually want to be there. This may or may not be under your control.
- If you need to lecture, make sure the students are not sitting in front of the computer screens when you are. If this isn’t possible, tell them to turn their monitors off during the lecture portion.
- Recognize that students think in a different way than you. Some things you find interesting they will find boring. For instance, anything involving UNIX. Philip Guo wrote a great article about a trap you should avoid falling into. http://pgbovine.net/two-cultures-of-computing.htm
- Don’t get too discouraged if you feel you aren’t getting through to the kids. Teaching children is hard. That’s why we pay professional teachers to do it (although in the US we probably don’t pay them enough, compared to Norway).
-
-
Yeah, he really has some great insights on teaching CS and programming. I just graduated and will be moving away to work, but my co-instructors are all continuing on to teach in the Spring semester. I sent them all this article after I read it because I think it is something very useful to keep in mind. Also, for anyone teaching Python to beginners, Philip Guo’s Ph.D. thesis was Python Tutor, a really neat tool for visualizing the execution of a Python program.
-
-
I’ve been teaching coding (w/ a sort of barfy Javascript curriculum) to middle & high school girls for a bit. Try to recognize when someone needs actual help and when they need attention. Find ways to divert the latter when it gets the point of being disruptive; a good technique is having the person sitting next to them help them finish the task. Allocate way more time than you think you need for setup/login/environment configuration. Seriously, practice beforehand giving the instructions and allocate twice as much time as you think you’ll need.
-
My senior year of high school I was a student assistant for a Scratch/Python intro course. The biggest issue I had (and still have while tutoring) is not just saying the answer. Coming up with different ways to phrase an assignment (or chunk of an assignment), and coming up with leading questions on how to get to the right result can be difficult. It’s also difficult for me to not introduce new ideas and concepts that are beyond the material being taught while helping people.
-
Lesson plans really help with this. Have some material to cover, problems they should be able to answer and a series of questions (Socratic method) that help the students complete the problems.
-
Plans would be nice, but I don’t really have the ability to do that. Right now I’m just one of my CS department’s tutors, and the way my school’s tutoring system works is by appointment, and most people are really bad about specifying what class their in and what assignment they’re working on (or they say something like “I’m working on assignment 3”, which means nothing to me).
-
-
-
-
I’m meeting with some other folks tonight to flesh out the requirements for a community activism DB project. Going to try to be mindful of balancing technology choices that I find exciting and choices that are going to make future maintenance by volunteers easy–would love to hear from others who’ve faced that tradeoff before.
I need to rewrite the intro to FP talk I’m giving at CUSEC. I suspect that Canadian college students won’t know who Pam Grier is but who says you can’t do a little cultural education along with the programming bit?
Stretch goal this week (yeah right, probably going to lay about with my new dog instead) would be finishing a little Scala macro toy project I started over Thanksgiving and writing a blog post about it. Nothing particularly groundbreaking but seems like consolidating good links to resources for writing macros in Scala is desperately needed, considering how hard it was for me to find anything useful.
-
I do an awful lot of interviews. Sadly, few people ask questions like this.
It’s too bad because at least with me, I’m far more impressed with candidates who turn the tables on me and interview me as well. Far too many end up just trying to be “amendable” and “impress”. My advice to people interviewing is, don’t worry about fucking it up. Think about what you want in a job and make sure the place you are looking at will give you what you want. If the place is really good, the interviewer is probably going to be delighted that you asked more probing questions.
-
-
and if you don’t and end up somewhere were you only got the job because you didn’t ask questions? it fills an immediate economic need but we are talking about software engineering jobs. the ratio of supply to demand is greatly skewed towards demand.
-
Eh, I’m totally on board the ask-lots-of-questions train–I have been known to ask more questions of my interviewer than they asked me!–but let’s not pretend there’s not risk involved. For example, a company’s parental leave policies are a GREAT (maybe one of the best) indicators of their approach to gender relations and work-life balance, but as a woman of childbearing age there is no way in hell I’m risking an offer by bringing that up in an interviewing situation, even though I know that legally and in a perfect world that is not supposed to influence hiring decisions. (FFS, I feel the need to disclaim that I have no interest in taking advantage of anywhere’s paternal leave anytime soon, in case someone I know in real life is reading this!) Most of the questions under “quality of life” have similar implications that can potentially be negative; if you’re working against various implicit biases to begin with the risks involved in even planting that seed of doubt may not be acceptable. There’s other skews than demand over supply in the software engineering world…
-
i wasn’t trying to say there is no risk. i’m suggesting that not asking those questions mean you risk ending up somewhere you aren’t going to want to work and that has to be balanced again the need for gainful employment. we are fortunate as engineers that we can be more selective. unfortunately, due to various biases, some of us can afford to be more selective than others, but as a profession, we are blessed that we can regularly take this into account.
-
Agreed! I’d add that if you’re on the hiring/recruitment side it’s worth thinking about how your potential hires are weighing that risk vs information calculation. If the answers to any of those more risky questions are a selling point for your company, getting out ahead of that dilemma by volunteering that info up front or highlighting it in your job listings is a great idea.
-
i try to do that as the vast majority of the time, i’m on the hiring/recruiting side.
-
-
-
-
-
It doesn’t need to be tons of questions, but 3 good probing questions can easily give you a feel for what the company and environment are really like.
-
-
My advice to people interviewing is, don’t worry about fucking it up.
I think I understand the intended mindset this is meant to advocate, but I wonder if this works when I know I’m interviewing for my dream job? How do I not worry about the interview, when I, as the interviewee, already know the job is precisely what I want? This seems like a special case where my primary objective has to be to impress and possibly show I’m amenable (we’re talking about a dream job after all).
Further, what if I give the interviewer the wrong impression by asking questions that could either be interpreted as pedantic or intrusive? What if I give the interviewer the impression I don’t trust the company to get even the basics right? Leading with the impression that I’m concerned at once with small details most decent places are bound to get right or showing mistrust doesn’t seem like something an employer is likely to respond positively to. Conversely I do see how some of these questions might be interpreted positively, as showing an interest in the particulars of the job and how they relate to you as a potential employee–certainly that should be a positive signal to the interviewer.
However, if I know I’m interviewing for my dream job, I’m probably not wondering if they use version control, for instance. And asking a question like that seems like it could be a bit of a red flag or at best noise that could be avoided in favor of more relevant discussion. So maybe this list is potentially less applicable to an interview you know you can’t fuck up. In which case, I’m not sure I can walk into an interview without worrying if I’m going to make a misstep.
-
-
Really like this concept, since looking at code in active use & development is a critical part of getting past beginner level in a language. Would love to see code-reading lists like this for other languages.
-
That’s similar to how I got started with Go – I read the first chapter of Summerfield’s book (it has five example programs covering a couple of langauge features), then the spec and Effective Go. When I have questions about how to do things, I look in the standard library for places where they do something similar; the standard library is eminently readable.
-
lol, lobsters so serious…