Working Conditions

For the last week, an article from the New York Times about the working conditions at Amazon has been making the rounds on social media.  It’s worth reading the whole thing, but the gist is: Amazon works you to the bone and you can’t take time off even if you’re sick, just had a baby, or your husband died yesterday.  80 hours a week is the low end of expectations.  

I have no way of knowing if the article is true.  The truth probably lies somewhere in between the article’s insistence that Jeff Bezos is a slave driver and Jeff Bezos’s claim that he values his employees immensely and that they’re a caring company.  I suspect that some employees were treated terribly by some managers.  But “some” can add up to a lot at a big company like Amazon.  Even if just 1% of Amazon employees were treated as badly as the article claims, that’s about 1500 people. And that’s just if you’re talking current employees.  The numbers that have left would add to that.

Whatever the truth is, my first thought was, crap, more publicity about how much it sucks to work in tech.  I thought that before I even read the article.  This Slate article I thought was a good response to the kerfuffle; however, it doesn’t completely dispel the idea that working as a programming is grueling.   The author outlines three things that he finds off about the article:

First and foremost, good software engineers are still in high demand. For all the coders out there, writing production-level, high-quality code is still at a premium, given the amount of it that is required at this point. Combine that with the need for engineers to be able to work well with others, not be hopelessly dogmatic, and not get burnt out, and there’s generally a pretty strong argument for not treating your coders like total garbage.

Second, engineer attrition is bad. A new engineer will take months to get up to speed on an existing codebase to perform as well as her predecessor, and that’s assuming she’s as good as her predecessor (which is nearly impossible to predict for a cold hire).

Third, coding speed is highly variable. I saw work that normally would have been assigned to a team of five people given to a single high-speed engineer without incident. Some engineers simply prefer to do a more thorough job without cutting any corners, with the final 5 percent of perfection doubling the working time. Some engineers simply do additional, elective work to make their lives or the lives of their teams and other teams easier. Some engineers simply make more mistakes in the normal course of things and have to spend more time debugging to produce code of sufficiently good quality.

The first two of these, I was glad to see.  Basically that good programmers, who can not only code but work well with others are still in demand and that it sucks for the company to lose one of these good programmers.  The last I guess is about hours worked.  If you have two days to finish something and you’re a slow coder, you might have to work round the clock to get it done.  If you’re fast, you might just work a normal 8-hour day for two days in a row and be done.  I’ve certainly seen that in my experience as well.

Finally, the author makes the point that we shouldn’t be too worried about the software engineers who are forced out of Amazon.  They have in demand skills that can garner them a good salary.  The blue-collar workers that work in the warehouses are much worse off, both from a treatment standpoint, and from an ability to find good work if they leave.  We should be more worried about those conditions.

Teaching, Programming, and Practice

Over the weekend, I read a couple of blog posts by programmers who were teaching workshops to either students or teachers, and who were quite amazed at how hard it was to teach. They didn’t come out and say that they thought teaching would be easy, but they implied that by talking about the challenges they faced.  They weren’t condescending at all, just clearly surprised.

And then there’s all the venture capitalist folks who think software is going to replace teachers any day now.

Education, teaching and learning are challenging.  People are often surprised by what happens in the classroom, of having to deal with different levels of students, of realizing that students don’t have some foundational information that you thought they would, of realizing that just telling them something doesn’t mean they actually learn it.  There is research out there that helps, but every day, you have different variables, so you try things.  And sometimes it works.

I don’t mean to be hard on the programmers trying to teach, or even the software developers trying to create something that will help people learn.  But the truth is, teaching is something we’re still trying to figure out.  If we had all the answers, then good teachers would be spitting out students who know everything they need to know and are equipped to continue learning all the time.  But we know that doesn’t happen.  And it’s not just that those good teachers miss a couple of students.  Sometimes they miss a lot.  Because there are other factors.  Learners learn in different ways.  Learners face challenges like poverty, drug addiction, lack of parental support that take up their cognitive capabilities, leaving little room for learning math or science.

And for the record, I find programming hard.  And I have much of the foundational knowledge to do some pretty complex programming, but I still struggle with it.  It takes me hours sometimes to do pretty simple things.  In part, that’s because my job is teaching, not programming, so I have less practice.  During the school year, I probably spend less than 2 hours actually programming things.  The things I do program are simple activities for my students.  They’re not complex, real-world problems.  I’ve tried to remedy this in a number of ways, trying to make time for some “real” programming (I did some this weekend, in fact), but I spend most of my off time, grading, giving feedback to students, planning ways to teach basic concepts, all that good stuff.  So I admire programmers, because I know they’ve had some practice and I admire them for wanting to share their knowledge with others, but like programming, teaching takes practice.  And I’m going to guess that programmers spend as much time teaching (at best) as I do programming.  We have a lot to learn from each other.

CSTA: Learning, Programming, and Making

The closing keynote at CSTA was by Michael Kölling, creator of Greenfoot and BlueJ.  The gist of his talk was that learning to program is not the same as being a professional programmer and the tools one uses for each should be different. In fact, he said that the tools you need to learn are the opposite are what you need when you’re programming professionally.  Block-based programming languages are great for learning, but the tools for text-based programming tend to move quickly into the professional programming area and are too hard to use for learners.   There’s not much in between.

Kölling then demoed a new tool that is that in between space.  It eliminates the issues of missing curly braces and semicolons and automatically groups blocks of code together (boolean statements, for example).  It seems like a very promising direction. I enjoyed much of what he said, and have been arguing for years (sometimes with programming parents) that learning to CS is not learning software engineering.

Four years ago at my first CSTA conference, I had lunch with a woman who claimed that every CS teacher should work in industry for 2 years before they teach CS.  I found it very frustrating because I believed that teaching CS is very different thing and requires different skills than what one might get from working in industry.  The tools change and depend on what part of industry you’re in.  If you’re building apps, your tools are going to be different from someone in web development.  It doesn’t make sense to me to teach those tools to a freshman in high school.

In evening, I hosted a #makered chat where we discussed the intersection between CS and Making.  It was a lively discussion.  My sense of things is that Makers use coding a lot and in fact, we sometimes hear that those who don’t code much feel like they’re not doing “real” making.  I don’t think that’s true.  Many maker programs (like mine) have come out of CS programs or are incorporated into it.  However I’ve heard some CS people not want to deal with hardware or electronics (much less paper, glue, and glitter).   I was thinking about this intersection more, and here’s how I think it works:

Intersection of CS,coding, makered and computational thinking
Intersection of CS,coding, makered and computational thinking

Computer science and making both include coding, but Computational Thinking is the umbrella for both, I think. CT doesn’t need coding necessarily.  The Rube Goldberg machine we made involved a lot of computational thinking (the logic alone was quite challenging), but no real coding.  Thinking broadly makes the relationships make sense and eliminates some of the territorial-ness some people feel about both CS and Making.  Maybe there’s an even broader category we could use, but computational thinking makes the most sense to me.

Success and Not Success

First, success. My Physical Computing students are making progress on the Rube Goldberg machine.  Today I tweeted:

That was the list my students gave me so that we could continue working tomorrow.  Two students ran off to the wood shop with a plan.  How glad am I that we even have a wood shop!  The rest of us stayed and worked on the other pieces.  We programmed a robot, printed a scoop for the conveyer belt and planned out what the pulley mechanism will do.  Here are some photos from today:

Robot goes down ramp and completes the circuit to start the motor.
Robot goes down ramp and completes the circuit to start the motor.
Marble runway
Marble runway built by students in wood shop.

We’ve basically looked around the room and said, “Hmm, wonder what we could do with this?” or “Hmm, what do we have that we can build x out of?”  And then we’ve got something put together.  So it’s been fun, and I think we’ll have something cute by Friday.  Did I mention we have to be done by Friday?

One thing I’ve been thinking about is what this has to do with Computer Science.  We do have some programming parts, but mostly, this is not obviously about CS.  But it is about logic and engineering–more logic than anything.  The students planned from the end backwards.  They’ve broken the problem into parts and worked on each part separately before connecting the parts together.  Sounds like functions to me!  It’s a little more linear than most programs, but the concepts are surprisingly similar when you think about it.

And now, not success. 8th grade.  I’m struggling to tweak/overhaul my curriculum (class starts Wednesday) to make the class more interesting to a typical 8th grade girl.  And this is harder than I thought.  I have the time constraint of once per week for 40 minutes for a total of about 6.5 hours. I also have my own imposed constraint of teaching coding and not having them play with Photoshop or MovieMaker.  Last trimester, we did Python, which, as I documented here, didn’t go so well.  So I thought, okay, maybe a different language, maybe JavaScript.  I found a good online resource.  I set up a class, pulled some lessons using their prepared curriculum and a few lessons in, I thought, “Boy, this is boring.” All we’ve done is add some numbers and make some strings and use some if statements.  I’m wondering if an 8th grade girl will stick through the boring bits to get to the fun stuff.  I’m not so sure.

And this has been my struggle more generally.  By 8th grade, the cute, block-based languages no longer appeal.  They’re too cutesy for most 8th grade girls.  But, most 8th grade girls have had little to no programming prior to being in my class.  Without the underpinnings of some programming and without the maturity of high schoolers, syntax really gets in the way.  The colons, parentheses and curly braces get frustrating pretty quickly.  I was writing some if statements in JavaScript and I realized that the && and == were going to freak out a lot of people.  At least with Python, you get some “real” English (and’s and or’s, for example, instead of && and ||).   But there’s nothing really in between something like Scratch and Python or Java, languages that allow you to do pretty much anything.  There are some drag and drop languages out there that are used for app development (like App Inventor or Game Salad) but you can’t get far enough in those in 6.5 hours to really accomplish anything.

But, I think I’m going to forge ahead and see how it goes.  I know some other tools out there that might be interesting to tackle but I don’t have time to experiment.  I’m reasonably familiar with JavaScript and the built in lessons are good given that I don’t have time to develop my own.  I’m still going to have my own Python-based curriculum, but I’m going to let them choose.  We’ll see where people go.  That will tell me something, I guess.

 

Remember Daily Coding?

So I fell off the daily coding wagon.  This is my usual mode of operation.  It takes a few tries before a habit will stick.  The beginning of the school year is a hard time to start and/or keep a habit.  The schedule isn’t normal; there are many evening obligations; and one is generally mentally and physically exhausted.  But this week, I vow to start again.  I’m going to begin by doing a few fun things until Thursday, when I plan to start taking an online course.  Even when I know the material from a course, I like taking them because they do keep me coding, and I often learn new ways of doing things.  They also make me think about how I structure my own courses, which is a win-win.  I will continue to keep myself honest by posting in the daily coding section.

Daily Coding

This morning, I ran into this blog post about a women who decided to learn to code by coding every. single. day.  She also decided to be publicly accountable and is pushing all of her code to GitHub.  It’s very impressive.  There are some great lessons in her post about learning to code that I think every person who wants to learn to code and feels intimidated should take to heart.  In fact, much of what she says are things that I wish I’d said to myself years ago.

It’s scary to have all of my mistakes and misunderstandings out in the open. The fact is, that if you want to learn to code you are going to make a lot of mistakes, but just because your code might look a little goofy doesn’t mean you should stop coding. And you don’t need to be a certain type of person, you don’t need to be a math whiz, and you don’t need any prerequisites, because the compiler doesn’t give a damn about that. You just need to start typing.

When I started learning HTML/CSS, I didn’t worry about mistakes or bad code or anything, mostly because I was doing this for myself.  My websites were public, but this was 1996 and the web was a small place back then.  Everyone’s websites looked awful, even most professional ones.  But as the web developed and as I moved into an IT related job years later, I forgot some of that original feeling of doing things for myself.  I was surrounded by expert coders, both at work and most especially at home (ahem, Mr. Geeky, I’m looking at you).  I did not want to be embarrassed.

Ironically, that feeling has gotten worse as I’ve gotten better.  Now that I’ve ventured past HTML/CSS/PHP/Javascript into other languages that are what most people would consider “actual programming,” I feel even more intimidated and sometimes frustrated.  I need to put those feelings aside.

I think the best way to learn is to solve problems that you actually have. This is the primary reason I decided not to follow a course or textbook. By following my own path, I can tackle new concepts and problems in the most logical order possible, which is precisely when I have them. When I have questions, I look them up on Stack Overflow.

This is what I used to do.  I’d want to build X, and back in the day, I’d actually head to IRC to find answers to my questions (pre-Google, remember).  I still do that and things work best for me when I have a specific, personal problem I want to solve.  During the school year, I often code up my students’ projects that they propose.  I find that very useful for both learning new things and for teaching.  I often find more than one way to solve a problem and then I can point the student in the right direction.  I don’t reveal the actual solution.  I find it harder to be inspired to code during the summer.  During the summer, I’m planning, thinking, reflecting, and not always doing.  Even though I want to be doing.  I have this open schedule, all the time in the world.  I have Mr. Geeky to help me (though I really don’t want his help for all kinds of complicated reasons which I’m sure you married folks out there understand).  But every summer, I do less coding than I intend to.

So, I’m hereby (inspired by Jennifer DeWalt) adding to my goals to code every day, to make something every day.  180 days from today would put me at the end of our first semester, a perfect stopping point for this project as my workload is heavier in the second semester.  If anyone wants to join me, jump on board.

Friday Tabs

This weeks tabs.  I’m sort of amazed that there are only one or two duplicates.  That’s a little scary.

Programming frustration

I’m at the point now where the programming I’m doing is a lot more complicated.  Last summer, I was writing things that I could basically finish in 1/2 hour.  Now, I’m writing things that take days or god forbid, weeks.  Mr. Geeky, like many programmers, will often try to complete a program that should take days in 24 hours.  He does this with the help of Mountain Dew and absolutely no breaks, including for actual food.  This, of course, is the stereotypical way.  But I can’t work that way.  Now, I have been known to get caught up in solving a problem and working way past a normal lunch time, but eventually, my stomach yells at me.  Also, I can’t really focus when I’m tried, hungry, or frustrated.

I feel that it’s important to offer different ways of working.  While I do know girls who work in the “typical” way, coding until they’re done, that doesn’t work for everyone.  I find, for myself, if I walk away, for an hour, for a day, I often can get a better perspective and solve the problem more quickly. I share my methods with my students, so that they can see other ways of doing things.

Maybe I’ll develop other ways of working as I keep doing this.  For now, it works.

Resolution check-in

A week mostly down.  How did it go?

  • Laundry every day: check! So far, so good.
  • Meal planning: not so good.  I had my dad visiting through the beginning of my work week.  We didn’t make it to the grocery store while he was here nor after he left.  So it’s been leftovers and frozen pizza.  Which isn’t horrible, but still.
  • Decluttering: check! I missed a day because I literally wasn’t here, but other than that, I’ve made progress. I’m trying not to think about how overwhelming it is to deal with all the crap. I’ve got a pile to keep and a pile to give away–with even a pickup scheduled today! I’m also decluttering 15 minutes a day in my classroom. So yay!
  • Yoga once a week: check! I even brought a friend with me this week.  So far so good.
  • Budget stuff: sort of check! It’s too early to tell, but I am keeping a close eye on things.  I think this resolution should be changed to something like check accounts every day.  Knowing about spending leads to not over spending.
  • Walk every day: not so much.  I have walked the dog, but that doesn’t really count.  Frankly, it’s just too cold outside.  Mr. Geeky is talking about getting a treadmill, so that might help.
  • Write a program every day: check! A couple of these have been simple examples for class, but still.  And I’m writing my own version of an old game I used to play, just for fun and practice. It’s text right now, but I’m going to graphic-ize it once I have it functioning the way I want.

So not too bad.  I’m taking it a day at a time.  How are you doing?