Category Archives: Techie

the things I believe about learning to code (again)

This “learning to code” thing is turning into a meme. Or is a meme. Or something.

In January, I wrote Thoughts on Code Year, Codecademy, and Learning to Code because I have a visceral reaction to “hey! everyone code!” and it’s not a good one…despite the facts that I sell a lot of books that provide some foundation for learning some things about some programming and markup languages (that last sentence is accurate enough to appease all the people who think books like mine, and especially mine, suck).

I’m just going to restate this: everyone who wants to should learn to code. But they also damn well better know why — there has to be some goal besides “I want to be able to print ‘hello world’ in seven different languages”.

And if people want to learn to code so as to set themselves on a path to becoming a professional or an expert, then they also need to understand that any book (mine included), website, webinar, badge system, or anything else that isn’t actually working in some apprentice craftsman type of environment is just one teeny tiny step along the path. And note I didn’t say “forward” because sometimes it isn’t. Sometimes books, websites, webinars, badge systems, etc are lateral or backwards moves.

Blah blah blah.

And go read what Jeff Atwood has to say, because it’s smart and true, and honestly? It’s a heck of a lot like what educators have been saying about all this—that would be “educators”, not “Codecademy and Codecademy-knock off creators”.

Avoiding Tall Hedges (or silos, if you prefer a different farming metaphor)

A recent 37signals blog post, “Making shit work is everyone’s job”, captures the essence of the spaces in which I like to work (and currently do). The post has also ruffled a few feathers, at least in the comment thread, of those who focus not on the concept but on the literal practicality of it.

Before going any further, it’s important to note that the emphasis in the title should be on the word work, not the word shit—the latter implies a bunch of pointy-haired bosses doling out tasks from the Big Bucket of Scutwork you just know they keep under their desks. Instead, DHH’s point in the post is that when you hear an employee say “Oh, that’s not my job,” you have some managerial work to do.

Departmental hedges grow fast and tall if not trimmed with vigor. It’s the natural path unless you take steps to fight it.

Taking steps to eliminate the “that’s not my job” attitude is crucial; no one should ever consider themselves too good to do any job that makes the company go.

In my company, there is a natural split between the people who do technical development work and the people who handle large amounts of paper (which end up as electronic documents). Both are important to the forward progress of the company, but there are skillsets among both groups that do not overlap. People in each group are not inherently better than people in the other, but of course the efficiency and quality of the work would differ depending on who did it—case in point, I can create web apps in my sleep, but if you ask me to work a scanner of any sort, I will stare at it for an inordinate amount of time trying to figure out which way to put the paper in (and don’t ever ask me to print on letterhead, because it’ll never work). But we know we have the right people because if shit had to get done, people would try to find a way to do it. All of them, from the CEO on down the tree.

Sure, there might be fallout, but I’d rather deal with the fallout of monkeypatched code and its ilk than deal with the ongoing management problem of people with delusions of grandeur or who overly value turf.

To my mind, there’s also a related issue of the very real need to ensure that the people who are doing particular tasks are free to do those tasks. It’s not building hedges (or silos) to have people dedicated to tasks such as systems administration and engineering so that developers are free to, well, develop. I would argue that filling gaps with people possessing the right skillsets to ensure continual forward momentum (smoothly) is actually an ongoing hedge-trimming activity.

Leveling Up (or, "I have a new job!")

It’s been a busy month around here. In the two-and-a-half weeks since I wrote my last blog post (“Be a Sponge”), in which I alluded to a job that I’ve had my eye on since (I kid you not) August 8th, 2009, I was working my then-future-now-current employer pretty hard to make it happen. Luckily for me, it worked! I am again gainfully employed.

I’m pleased as punch to tell you all that I’m now the Executive Vice President of Product and Technology at Interfolio.

Specifically, it’s my job to lead the already-intact and highly capable Development and Product Management teams in the design, development, implementation, maintenance, and analysis of software applications, information systems infrastructure, and data management policies and systems. Easy, right? As I told Steve Goldenberg, CEO of Interfolio and My New Boss, “Great! That’s plenty to do. I’ll be here a while.” As part of the company’s strategic leadership team, my focus is the continual alignment of product and technology initiatives as we create and maintain solutions that streamline the application, communication, and review process between institutions of higher education and their applicants.

Continue reading →

Dear StackExchange: Will You Be My Valentine?

With all due respect to my partner, I am totally in love with StackExchange, the network of Q&A sites that began with StackOverflow and, over the last few years, has blossomed into one of the best communities I have ever seen on the interwebs.

I don’t say things like that lightly. I mean, I’m one of those grumbly old jaded “get offa my lawn, you!” people who has been working and building things on the web for a really long time (18 freaking years, if you’re counting at home). I’ve kept my distance from discussion/Q&A forums and listservs in recent years for a few reasons, boiled down to these: a lot of people are jerks, and a lot of people don’t even try to help themselves—both of these factors just waste everyone’s time, effort, and goodwill, and those are things I let affect me far more than I should.

But given the new year (always a good time to start new things), time on my hands after quitting my job, and a deep desire to get back to my roots (firmly planted outside of academia), I decided to commit time to becoming a good community member at StackExchange. Since I follow both Jeff Atwood (@codinghorror) and Joel Spolsky (@spolsky) on Twitter and have read/enjoyed/learned from each of their blogs for a long time, I figured if there was going to be any network that I embedded myself within, it was going to be one that they started.
Continue reading →

Thoughts on Code Year, Codecademy, and Learning to Code

By going one click away from this post you’ll see that I’ve spent the last twelve years writing books specifically geared to the newbie coder—be it someone who wants to learn the markup language of HTML, the style sheet language of CSS, the query language for relational database systems, the client-side programming language of JavaScript, or the server-side programming language of PHP (or, in fact, all of them together). As I wrote a few weeks ago, learning from tech books is not dead. But it’s not the only way to learn; straight up learning from a book doesn’t work for everyone, and certainly not every tech book pays attention to pedagogy (I do, with the help of all of my editors who keep me honest).

Then again, neither does every online learning environment. Do any?

Continue reading →

Spend a Buck & Read "The Professor's Assassin"

Have a spare buck in your pocket? Allow me to recommend Matthew Pearl’s dramatization of “The Shocking Campus Shooting in Virginia You Never Heard Of”. This long short story/short novella (you can argue which it is among yourselves) is set in 1840, on the grounds of the University of Virginia. On November 12 of that year, the dean of the faculty was shot—and later died—after attempting to quell a student-led disturbance on the Lawn (it’s true). The true story itself is interesting, but as usual with Pearl’s books both his characterizations and the locale are richly described and the tale told well.

I thoroughly enjoyed Pearl’s work, despite being in the perfect position to nitpick it to death since I work on Grounds and have held in my hands and read original accounts of the shooting and John Davis’s death courtesy of the Albert & Shirley Small Special Collections Library. But there’s no nitpicking from me—just praise, and the fervent desire that you all go take that dollar that’s been burning a hole in your pocket and spend it on this story.

While reading “The Professor’s Assassin” (available as a download from Amazon and numerous other outlets) you’ll be introduced to one William Barton Rogers, the future founder of MIT. This tidbit is important, as the novella is a prequel to The Technologists, a novel that focuses on the first class of students at MIT and, well, a fictional, yet historically-grounded, mystery. Intrigued? The book has its own trailer…and it’s about science and technology…in the nineteenth century. What’s not to love?

sort of interesting note: Matthew Pearl’s The Dante Club was one of the only books I read for pleasure during my PhD work in c19 American Lit.

Tech Books: Not Dead!

As someone who has made a decent secondary income for the last twelve years writing technical books, a recent post in the SD Times caught my eye: “Are tech books dead?” it asks. The author comes to the conclusion that no, they’re not, although the rise of blogs and other online material certainly plays a role for learners more than it has in the past. I agree with this conclusion, which itself isn’t interesting, but that this is the conclusion still in 2011—almost 2012—is interesting to me (and it supports my desire to keep on writing books).

I started writing technical books in 1999; I wrote the second PHP-related book that came on the market (for Prima-Tech which became part of Course Technology which became part of Cenage, if you’re interested), and from that point on I was solicited to write some more, eventually writing only for Pearson and putting out an edition or two of something or another each year.

I never thought I’d still be doing this a decade later. As a developer myself, I knew how I learned new things in the ever-changing tech landscape, and it isn’t from technical books. I thought “who on earth would pick up a chunky ol’ book and sit it next to their computer while working on something?” … my choice of “thickbook.com” as my domain name was meant to be funny, like “here are Thick Books From Which You Shall Learn Things” (tongue firmly in cheek). The joke’s on me, because that income has increased or remained steady each year; there’s been no noticeable drop-off in either the number of sales of my books, the purchase of rights for translation, or the amount I’ve earned in royalties.

Continue reading →

This is What I Do

NOTE! As of the end of 2011, I don’t do this at all. I resigned my position after one year at UVa Library.

The other day I wrote up a “it’s June 1st, sounds like a good time for a quick status update” email for my bosses, and in doing so stepped back for a second and said “holy crap—we’re really doing a lot.” It’s true, we are. “We” in this case is the Online Library Environment group at University of Virginia Library. Seven super people (three senior engineers, a senior programmer, two programmer/analyst/DBAs, and a librarian/project manager) report to me, and I report to a director who reports to the Deputy University Librarian. Like I said in my post about an internal presentation I gave on the development lifecycle, my group is responsible for many of the public-facing web services that the Library provides plus the technologies that sit behind those interfaces. Almost every project we take on is driven by stakeholders outside of our department who have their own highly valued areas of expertise (e.g. librarians, archivists, media specialists, etc.)

The reason I thought about writing this blog post was because this morning I had the opportunity to see some of the folks at the NINES / NEH Summer Institutes for Evaluating Digital Scholarship…not because I was participating in the institute in any way, but because I was on my way downstairs to get coffee and the participants were all working in the beautiful, wonderful, comfortable Scholars’ Lab. I was able to talk for a few moments with some scholars I like and respect very much, and one of them (Amy Earhart, if you’re playing along at home, who—to reiterate—is pretty great!) asked me what project I’m working on right now.

Project, singular.

Continue reading →

Julie's Recommended Web Hosting Provider

This is a question that I am asked all the time: “do you have a recommendation for a good hosting provider?” You know what? I do.

In August 2009 I wrote a ProfHacker post called Website Hosting 101 which explains what a hosting provider does, how to use it, and what to look for (or, what makes a good hosting provider) such as reliability/server uptime, customer service, bandwidth, domain name purchase and mangement, price, scripting languages and database support, and having a good control panel for host management. Also in that post (and in Sams Teach Yourself HTML and CSS in 24 Hours, 8th ed.) I linked to several perfectly good hosting providers, all of which I have used in some way…yet I did not name a favorite.

I’ve always had a favorite, though. Well, at least since mid-2005, when I started using Daily Razor. That’s right: my #1 web hosting provider recommendation is DAILY RAZOR.

Continue reading →

a short presentation: "Development Lifecycle: From Requirement to Release"

In my capacity as Lead Technologist/Chief Architect for the Online Library Environment at the University of Virginia Library, I manage a group of people who are responsible for many of the public-facing web services that the Library provides plus the technologies that sit behind those interfaces. Almost every project we take on is driven by stakeholders outside of our department (e.g. non-developers, or people not versed in technical matters) who have their own highly valued areas of expertise.

This is a relatively new department; it wasn’t fully staffed until I got here in January. As you can imagine, any processes we’ve recently started to implement (e.g. having processes for starting/working through projects) require a lot of training and reiteration of norms and ideals. Within the Library we have several interest groups that meet regularly to talk about current and future projects, possibilities, questions, and so on; one of those groups is the User Experience (UX) interest group. People from all departments and at all levels (from the University Librarian on down the line) come to these meetings to hear presentations and ask questions.

Today I took the opportunity to talk briefly about how we in OLE work with the specific UX folks (Joe Gilbert and Erin Mayhood, if we’re naming names, which I am) in the service of our stakeholders and their projects. Specifically, I discussed what we expect stakeholders (project instigators!) to do, and what we do with that information, how we communicate throughout a project, and so on. These slides are pretty generic (and my presentation was only 15 minutes) but it was another opportunity to get in people’s minds how we as developers don’t (or shouldn’t) just come up with stuff on our own and decide willy-nilly to do something. There’s actually a process!

(The titles of the slides are: functional requirements, example functional requirement, writing use cases (or epics), writing stories, an actual example, writing code, never stop communicating, releasing)

Here are the slides themselves (view at slideshare.net if they do not appear below):

Development Lifecycle: From Requirement to Release
View more presentations from Julie Meloni