{"id":920,"date":"2016-08-21T15:35:40","date_gmt":"2016-08-21T19:35:40","guid":{"rendered":"https:\/\/sheldon-hess.org\/coral\/?p=920"},"modified":"2017-01-02T19:15:20","modified_gmt":"2017-01-03T00:15:20","slug":"notes-from-abstractions","status":"publish","type":"post","link":"https:\/\/www.sheldon-hess.org\/coral\/2016\/08\/notes-from-abstractions\/","title":{"rendered":"Notes from Abstractions"},"content":{"rendered":"

Pittsburgh’s Code & Supply<\/a> just held a huge (1500 people) conference<\/a> over the last three days, and of course I’d signed up to attend months ago, because 1) local 2) affordable 3) tech conference 4) with a code of conduct they seemed serious about. Plus, “Abstractions” is a really<\/em> cool name for a tech conference. The timing ended up being non-ideal for me in a couple of ways: I am really scrambling to get my fall class put together before the semester starts, and I have just had a final interview for a (really good, but) decidedly non-technical job, which I was (am) having all kinds of angst about. But Abstractions happened when Abstractions happened, so I went.<\/p>\n

It was excellent! Lots of solid content, on a variety of topics. I learned new things about UX, accessibility, JavaScript, mental health, and a whole variety of other topics. And both Dale (my spouse, he went too) and I are slowly coming to the conclusion that functional programming is going to be hard to avoid. (OK, he’s a bit more jazzed about learning it than that<\/em>.)<\/p>\n

Big Takeaways<\/h3>\n

The biggest takeaway is no surprise: I’ve determined that, if I stay in programming, I want a development job where there is a decent onboarding and mentoring process—I would want to be an apprentice developer<\/strong>, short-term, so I can do great things with code, long-term. (Very long-term, I want to be a data scientist. But I can build skills at any dev shop!) And, sure, I sort of already knew that, but Erika Carlson<\/a> gave a great talk about apprenticeship and mentoring junior devs. I had a chance to talk with her on the last day and learn how her employer’s apprenticeship program works. It’s amazing<\/em>. I want that. I have it in me to be a great developer: I have a strong track record in two different fields (electrical engineering and librarianship). I’ve taught myself Python and, arguably, also PHP and JavaScript; and I’ll be teaching JavaScript to a class of graduate students in the fall. But I need that first full-time development position, you know? (OK, I had<\/em> a first position, but I was explicitly barred from asking questions, which is not<\/a> how you mentor a new developer. I had to leave before they completely ruined me.) Sparkbox put their program online<\/a>, so I could try it alone, but that’s not exactly what I want.<\/p>\n

Apprenticeships also seem like a good way to solve this problem:
\n

\"This
This photo shows two very full boards, one with ‘HIRE ME’ and the other with ‘HIRING’ – if you zoomed in, you’d see a lot of junior devs needing jobs and a lot of companies looking for higher level developers.<\/figcaption><\/figure><\/p>\n

I definitely need to go to more local coding meetups—and make that a higher priority, in general. The Code & Supply organizers are nice, and they’re trying to be thoughtful about inclusion. I need to just decide “this contract work isn’t getting done tonight” and go<\/em>. I already knew I liked the folks at Code for Pittsburgh<\/a>, but, again: I need to put down what I’m doing and just go<\/em>, even if I’m not sure what I have to contribute to a given week’s topic. I now know how easy it is to throw together a fast map. And, worst case: I take on something more challenging, but don’t get it done that night; so, I have to work on it for longer. No biggie.<\/p>\n

I’m going to get my (senior dev) spouse to sit down and pair program with me on some as-yet-undetermined project. It will be good for him, since he’s hiring a more-junior developer to work with him; and it will be good for me, since I’ll have some mentorship at home.<\/p>\n

I was introduced to the concept of “UX debt,” which is a useful way to think about something I had long ago intuited: bad interface decisions made for expediency and good interface decisions that aren’t periodically revisited will eventually become liabilities. I’ve lived that reality as both a user and a web librarian, so it’s nice to have terminology for it.<\/p>\n

Open offices continue to be a really bad idea, for an ever-increasing number of reasons. <\/p>\n

Have empathy – this is the most important skill for developers.<\/p>\n

Be courageous – this is the second most important skill for developers. “I don’t know, so I will ask.” (A little hubris—”I’m definitely smart enough to solve this”—can also be OK.)<\/p>\n

Nobody should ever give Richard Stallman a platform anymore. I’ve seen a lot of the same material shared by speakers with a more modern and inclusive take—and without patronizing their (tech- and information-literate) audiences, e.g. Kate Krauss<\/a> from the Tor Project. I know the guy has star power within the tech community and probably lent a sense of legitimacy to the conference among a certain crowd, but he was incredibly off-putting to a large portion of the audience. … On the bright side, he did get us discussing. I made a lot of Twitter friends during that talk. So maybe as a mid-note, instead of an endnote, he could have been a real force for good.<\/p>\n

A few pseudorandom notes I don’t want to lose<\/h3>\n

(Most of these I’m copying off of my Twitter stream for the conference—hence, doing this today—or from the few written notes I made.)<\/p>\n